Jump to content

techie

Members
  • Posts

    41
  • Joined

  • Last visited

techie's Achievements

Member

Member (2/6)

0

Reputation

  1. In early 2011, when the first IPv6 aware version of spamcop (which simply detected IPv6 headers) was inflicted upon us, I pointed out that the IPv6 detection was in the wrong place. Instead of checking for IPv6 anywhere in the headers, and immediately tossing the report if IPv6 is found anywhere in the headers, it would be just as easy (and would make a lot more sense) to add the IPv6 checking to the parser, and only toss the report if IPv6 is found prior to the point where we can no longer trust the headers, which would eliminate most of the problems that people have been complaining about. Since then, we have had at least two attempted upgrades, both of which failed, and were immediately rolled back. Given that the coders don't seem to be able to get IPv6 working, and have forced us to live with a badly broken (and IMHO easily fixed) system for almost two years, I find it extremely difficult to be optimistic that this "upgrade" will be any better.
  2. As I posted in http://forum.spamcop.net/forums/index.php?...ost&p=83739 on 12/27/12, I predict that there will be an attempt to upgrade in a couple of months (ie: mid-February), which will fail, followed by another attempt about 6 months later, which will also fail. Given Spamcop's current track record, and the fact that reporting has been puking on IPv6 for no good reason for almost two years, I predict that Spamcop will have working IPv6 support no earlier than March 2014.
  3. Well, if we also assume two other things, namely that the IPv6 detection code is written as a subroutine, and that the parsing process works on the headers one hop at a time, then the real question is: why did they call the subroutine at the beginning, instead of as a conditional during the parsing process?
  4. IIRC, the Spamcop update of March 2011 was advertised as providing for future support for IPv6. Immediately after this update, I started receiving bounces for spam containing IPv6 loopback addresses, which had never been rejected prior to this update. I went back through my spam archives, and verified that I had submitted spam containing IPv6 loopback addresses several time during the previous month, none of which had been rejected. My assumption, based on observed Spamcop behavior before and after that update, is that code to detect IPv6 was added during that update, and that instead of using that code to gather data, or as a step-by-step sanity check, it was instead used as a cop-out. My comments on the "right way" and the "wrong way" are based on one assumption about the parsing process, namely that the process works from the recipient back towards the sender. This is the logical method, since Spamcop needs to eliminate hosts within your MX path, so as not to report your receiving server as the spam source, which of course it is not. The host immediately upstream of your receiving server is the last host which can be properly verified, since all headers upstream of that point can be forged. If Spamcop trusts the header upstream of that point, it is only because Spamcop trusts the upstream ISP (such as Yahoo/Google/AOL/etc), and has decided that the internal headers added by those ISP's are trustworthy. Given that the parsing process needs to work backwards, it is logical that sanity check for IPv6 headers should be done at each step in the parsing process, which would eliminate all of the problems with IPv6 loopback addresses in the first hop, forged IPv6 headers, IPv6 tunnels and 6-to-4 gateways prior to the upstream server. This would not eliminate the problems with IPv6 use at the receiving site, or actual IPv6 transit between the receiving server and the host immediately upstream, but it would eliminate the vast majority of the current set of problems, since the spam source would be reached, and parsing terminated, prior to an IPv6 address being encountered. Instead, what I have observed is that the parser looks for IPv6 addresses anywhere in the header as the first step, and pukes if any IPv6 addresses are found, instead of actually attempting to parse the headers in proper sequence, and only puking if an IPv6 address is encountered prior to determining the spam source.
  5. The "Right" way of doing this would have been to add the IPv6 detection code, and have it log to a file for debugging. This doesn't change the existing behavior from the user perspective. The detection code should include checks for the IPv6 loopback address [::1], and treat it the same as 127.0.0.1. The next step would be to add some hooks for each step of the parsing process to call the code, and let it bail out if IPv6 is detected at those points, but you could still do reporting up until the IPv6 handoff, which on all the rejections I have seen, has been on the first or second hop from the sender. It gets more complicated when the receiving site is running IPv6 internally, or if there is actually IPv6 within the path, but most of the rejections I have seen are either the loopback within an Exchange server, or occasionally a internal handoff within the originating site, or a 6to4 gateway within the originating site. You parse as far as you can, and include the IPv6 header in the last report. The wrong way is to simply add a check for IPv6, and puke if found, which is what currently happens, as of the update in March 2011.
×
×
  • Create New...