techie
-
Posts
41 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by techie
-
-
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.
-
...The assumption is, from what I understand, correct. What we don't know is whether that fact allows us to conclude that it is necessarily feasible and "easy" for the parser to ignore all IPv6 addresses that appear prior to the point it decides that it has found the location at which it can stop trusting the headers. I think that is not an unreasonable conclusion but it is, nevertheless, a conclusion the validity of which we will never know because the SpamCop engineers won't ever reveal the answer to us. And since it's their product, they get to define the rules, so I for one feel unworthy to challenge it and can't imagine that anyone else outside the SpamCop staff circle is able to do so for certain, either.
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?
-
...Steven, while I share your frustration and agree with your point, I think it may be misplaced to direct it at techie. IIUC, techie is making a suggestion about how to code for IPv6 in general, not how specifically to do it in SpamCop and has made no public judgment about whether the time it has taken is appropriate. On the other hand, techie's "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" comment seems to assume something that isn't true -- that the current code was intended to address IPv6, which (IIUC) it was not!
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.
-
...That's a very good question and one to which I'm sure everyone here wishes she or he knew the answer, so that we all could have taken that step and it would have been done long ago! My naive guess is that SpamCop is working hard to get it right, rather than just throwing out some solution that doesn't work and that it's harder to get it right than anyone thought.
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.
IPv6 Routing Support
in SpamCop Reporting Help
Posted · Edited by techie
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.