alvarnell Posted March 25, 2012 Share Posted March 25, 2012 I know that you are still unable to process IPv6 and although I don't understand why it has taken so long, I'm only a programming hack, so I fully accept this explanation. But in looking at this report that my wife just received <http://www.spamcop.net/sc?id=z5289635500z16378c05fd5d4dde0a8c11817145f277z> I see only one IPv6 associated with server <MailboxCluster3.adsroot.uts.edu.au> which I can easily locate as IP 138.25.27.135. I'm not understanding why you would not use such a workaround to process such spam? There is no way to know whether they intentionally inserted an IPv6 to thwart SpamCop in this case, but I'm sure you are aware of instances where that has been done. Link to comment Share on other sites More sharing options...
gnarlymarley Posted March 26, 2012 Share Posted March 26, 2012 I know that you are still unable to process IPv6 and although I don't understand why it has taken so long, I'm only a programming hack, so I fully accept this explanation. But in looking at this report that my wife just received <http://www.spamcop.net/sc?id=z5289635500z16378c05fd5d4dde0a8c11817145f277z> I see only one IPv6 associated with server <MailboxCluster3.adsroot.uts.edu.au> which I can easily locate as IP 138.25.27.135. I'm not understanding why you would not use such a workaround to process such spam? There is no way to know whether they intentionally inserted an IPv6 to thwart SpamCop in this case, but I'm sure you are aware of instances where that has been done. The main problem as to why IPv6 is taking so long is, how can you properly check for accurate IPv6 headers? Below is a snippet of email that I get which uses IPv6 in transit. I was not immediately able to locate the RFC that is more specific than RFC 2822. RFC 2822 does not dictate the format as exact as one would like. This can make decoding the lines by scri_pt or program more difficult to decode. Received: from hub.freebsd.org (hub.freebsd.org [iPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 22EA01587C2; Mon, 26 Mar 2012 00:37:01 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0C3841065675; Mon, 26 Mar 2012 00:37:01 +0000 (UTC) Link to comment Share on other sites More sharing options...
SpamCopAdmin Posted March 26, 2012 Share Posted March 26, 2012 Parsing IPv6 headers requires a huge and complicated change to SpamCop's code. The new code should be in Beta soon, and published in April. He said hopefully... - Don D'Minion - SpamCop Admin - - service[at]admin.spamcop.net - Link to comment Share on other sites More sharing options...
turetzsr Posted May 8, 2012 Share Posted May 8, 2012 ...Latest update: Scheduled Service Outage - Thursday May 10, 2012. Link to comment Share on other sites More sharing options...
Neil Parks Posted July 6, 2012 Share Posted July 6, 2012 Parsing IPv6 headers requires a huge and complicated change to SpamCop's code. - Don D'Minion - SpamCop Admin - - service[at]admin.spamcop.net - Please have a look at this tracker: http://www.spamcop.net/sc?id=z5365951489zf...02d05da767f8ebz There is an IPv6, but it occurs entirely within a domain that is on my mailhosts list, rollernet.us. Rollernet received the email from yahoo.com. Until the IPv6 parser is ready, could something such as this be treated as an exception? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.