You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@spamassassin.apache.org by bu...@issues.apache.org on 2011/04/26 03:17:32 UTC

[Bug 6577] New: IPv6 encapsulated IPv4 sender not detected correctly

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6577

           Summary: IPv6 encapsulated IPv4 sender not detected correctly
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: Plugins
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: jeffc@surbl.org


Got a 419 scam spam with an IPv6 encapsulated IPv4 address that was not
detected correctly:

Received: from userPC ([::ffff:82.128.107.32])
 (AUTH: LOGIN zzzz@yyyyy.com, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
 by mail.xxxxxxx.com with ESMTPSA; Mon, 25 Apr 2011 16:nn:00 -0500
 id 0000000000aaaaa.00000000bbbbb.00000ccccc

"I believe that this is a new method to obfuscate an IPv4 address from
harvesters and DNSbl's by hiding it in a IPv4 over IPv6 tunnel address so that
it doesn't get processed." says a friend.

I might call this v4 obfuscation via v6.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by Justin Mason <jm...@jmason.org>.

On Fri, Apr 29, 2011 at 17:04,  <da...@chaosreigns.com> wrote:
> On 04/28, Warren Togami Jr. wrote:
>> I therefore propose that folks should get in whatever they can to
>> the 3.3.x svn branch, and whatever is there on May 4th I will cut
>
> On 04/29, Justin Mason wrote:
>> +1 (from the sidelines ;)
>
> On 04/29, Kevin A. McGrail wrote:
>> +1.  Hope you did well on your GMATs.  This has been my main hold up
>
> I'm very happy to see this, thanks guys.
>
> According to ReleasePolicy, that's enough votes for the release candidate
> (beta) Warren proposed.
>
> That's two PMC members, one more needed for a "full (general availability)"
> release, when that time comes.  Based on recent activity on this list,
> I'm guessing Karsten Bräckelmann and Daryl C. W. O'Shea are most likely,
> which is excitingly more than enough.

well, to clarify, a release vote is performed on a tarball.  we
haven't seen one of those yet.... so it'd be premature to call it
releaseable.

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.

The key purpose for me with the 3.3.2 release is the perl 5.12 warnings so that makes sense.

As for the keys, we have too few people clearly but I understand your concern!
Regards,
KAM

"Warren Togami Jr." <wt...@gmail.com> wrote:

On 4/29/2011 3:28 AM, Kevin A. McGrail wrote: > >> I know the password for the signing keys. I've just been crazy busy. I >> will have some time May 4th. >> >> By the written policies, it appears that any committer is authorized >> to unilaterally release an unofficial beta. >> >> I therefore propose that folks should get in whatever they can to the >> 3.3.x svn branch, and whatever is there on May 4th I will cut for a >> beta tarball. Sometime shortly thereafter we can kick off the real >> release process. >> > +1. Hope you did well on your GMATs. This has been my main hold up on > cutting the tarballs. Can we add to this task to get a key for me onto > the signing key? > > Regards, > KAM That isn't up to me. We as a project need to decide upon a signing key policy. On one hand we need people who are active in the project to be empowered to do necessary tasks. But OTOH it is dangerous to spread the key and passphrase to too many people. Witness the drama that exploded a whi!
 le back
because too many people had root access to freedesktop.org's servers. BTW, I haven't seen any voting on 3.3 bugs for quite a while now. Meanwhile the written policies allows releasing betas at anytime. So we might be better off just cutting a beta right now instead of waiting. I'll try to do it this weekend if nobody objects. Warren

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by Mark Martinec <Ma...@ijs.si>.

> +1 from me. And I'm paying attention again, so I expect to be voting when
> that's needed.

I'm here too, just returned from a two weeks vacation.

  Mark

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by "Warren Togami Jr." <wt...@gmail.com>.

On 5/4/2011 1:46 AM, Mark Martinec wrote:
>> Proposed: 3.3.2-beta1 on May 4th
>
> Please give us a day or two more to sort out some pending bugs,
> I came late for the show :)
>
>    Mark

OK fine, too many appointments today anyway. =)

Warren

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by Mark Martinec <Ma...@ijs.si>.

> Proposed: 3.3.2-beta1 on May 4th

Please give us a day or two more to sort out some pending bugs,
I came late for the show :)

  Mark

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by Steffen Schwigon <ss...@renormalist.net>.

"Kevin A. McGrail" <KM...@PCCC.com> writes:
> On 4/30/2011 10:40 PM, Warren Togami Jr. wrote:
>> On 4/30/2011 4:07 PM, Todd Rinaldo wrote:
>>>
>>> I know it's not the current procedure, but the CPAN way would be to
>>> release a dev version with _01 at the end of the version. This makes
>>> it readily available to everyone and allows the CPAN testers
>>> infrastructure to report on the test suite across multiple platforms
>>> and versions of perl. It does not get installed by any
>>> cpan(plus/minus) clients because of the underscore.
>>>
>>> I definitely don't want to slow down a release but this might be a
>>> good approach eventually.
>>>
>>
>> While I personally don't use CPAN, I do recognize this as a welcome
>> additional means to ease exposure to testing of spamassassin
>> prereleases.
>>
> +1 for sure.

+1, just to express the opinion from a lurker. :-)

Thanks.

Kind regards,
Steffen 
-- 
Steffen Schwigon <ss...@renormalist.net>

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.

On 4/30/2011 10:40 PM, Warren Togami Jr. wrote:
> On 4/30/2011 4:07 PM, Todd Rinaldo wrote:
>>
>> I know it's not the current procedure, but the CPAN way would be to
>> release a dev version with _01 at the end of the version. This makes
>> it readily available to everyone and allows the CPAN testers
>> infrastructure to report on the test suite across multiple platforms
>> and versions of perl. It does not get installed by any
>> cpan(plus/minus) clients because of the underscore.
>>
>> I definitely don't want to slow down a release but this might be a
>> good approach eventually.
>>
>
> While I personally don't use CPAN, I do recognize this as a welcome 
> additional means to ease exposure to testing of spamassassin prereleases.
>
+1 for sure.

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by "Warren Togami Jr." <wt...@gmail.com>.

On 4/30/2011 4:07 PM, Todd Rinaldo wrote:
>
> I know it's not the current procedure, but the CPAN way would be to
> release a dev version with _01 at the end of the version. This makes
> it readily available to everyone and allows the CPAN testers
> infrastructure to report on the test suite across multiple platforms
> and versions of perl. It does not get installed by any
> cpan(plus/minus) clients because of the underscore.
>
> I definitely don't want to slow down a release but this might be a
> good approach eventually.
>

While I personally don't use CPAN, I do recognize this as a welcome 
additional means to ease exposure to testing of spamassassin prereleases.

Warren

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by Todd Rinaldo <to...@cpanel.net>.

On Apr 30, 2011, at 5:50 PM, Daryl C. W. O'Shea wrote:

> On 30/04/2011 6:05 AM, Warren Togami Jr. wrote:
>> BTW, I haven't seen any voting on 3.3 bugs for quite a while now.
>> Meanwhile the written policies allows releasing betas at anytime. So we
>> might be better off just cutting a beta right now instead of waiting.
>> I'll try to do it this weekend if nobody objects.
> 
> Back when Theo and I were hammering out a release a month for about a year, we were giving one week notice that we were going to cut a tarball to vote on.
> 
> There's no need to call it beta if you don't want to.  Just cut the tarball, post it to your home directory on people.a.o and let the dev@ list know where it is.  We then let the vote run for the minimum time required -- at least (I prefer a 5 day minimum myself).
> 
> Let me know if you have any issues with the associated rule tarball.  I can help out with that if you like.  Copy me directly on any emails to the dev@ list about any required help.
> 
> Daryl

I know it's not the current procedure, but the CPAN way would be to release a dev version with _01 at the end of the version. This makes it readily available to everyone and allows the CPAN testers infrastructure to report on the test suite across multiple platforms and versions of perl. It does not get installed by any cpan(plus/minus) clients because of the underscore. 

I definitely don't want to slow down a release but this might be a good approach eventually.

Re: How were monthly releases done? Re: Proposed: 3.3.2-beta1 on May 4th

Posted by Daniel McDonald <da...@austinenergy.com>.

On 5/6/11 11:31 AM, "darxus@chaosreigns.com" <da...@chaosreigns.com> wrote:

> On 04/30, Daryl C. W. O'Shea wrote:
>> Back when Theo and I were hammering out a release a month for about
>> a year, we were giving one week notice that we were going to cut a
>> tarball to vote on.
> 
> How was that done?  No branching, just do a release a month, call it a
> beta, and if no problems were found in the next month call it a stable
> release?

As I recall, there were no "betas".  They just cut the tarball, it would be
hosted on Daryl or Justin's server, and the committers would download and
test the tarball.  Normally there would be votes cast pretty quickly (2 or 3
days tops), and it would be published in the official channels once there
were enough +1 votes (and no -1).

-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281

How were monthly releases done? Re: Proposed: 3.3.2-beta1 on May 4th

Posted by da...@chaosreigns.com.

On 04/30, Daryl C. W. O'Shea wrote:
> Back when Theo and I were hammering out a release a month for about
> a year, we were giving one week notice that we were going to cut a
> tarball to vote on.

How was that done?  No branching, just do a release a month, call it a
beta, and if no problems were found in the next month call it a stable
release?

-- 
"Life is either a daring adventure or it is nothing at all."
- Helen Keller
http://www.ChaosReigns.com

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.

On 30/04/2011 6:05 AM, Warren Togami Jr. wrote:
> BTW, I haven't seen any voting on 3.3 bugs for quite a while now.
> Meanwhile the written policies allows releasing betas at anytime. So we
> might be better off just cutting a beta right now instead of waiting.
> I'll try to do it this weekend if nobody objects.

Back when Theo and I were hammering out a release a month for about a 
year, we were giving one week notice that we were going to cut a tarball 
to vote on.

There's no need to call it beta if you don't want to.  Just cut the 
tarball, post it to your home directory on people.a.o and let the dev@ 
list know where it is.  We then let the vote run for the minimum time 
required -- at least (I prefer a 5 day minimum myself).

Let me know if you have any issues with the associated rule tarball.  I 
can help out with that if you like.  Copy me directly on any emails to 
the dev@ list about any required help.

Daryl

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by "Warren Togami Jr." <wt...@gmail.com>.

On 4/29/2011 3:28 AM, Kevin A. McGrail wrote:
>
>> I know the password for the signing keys. I've just been crazy busy. I
>> will have some time May 4th.
>>
>> By the written policies, it appears that any committer is authorized
>> to unilaterally release an unofficial beta.
>>
>> I therefore propose that folks should get in whatever they can to the
>> 3.3.x svn branch, and whatever is there on May 4th I will cut for a
>> beta tarball. Sometime shortly thereafter we can kick off the real
>> release process.
>>
> +1. Hope you did well on your GMATs. This has been my main hold up on
> cutting the tarballs. Can we add to this task to get a key for me onto
> the signing key?
>
> Regards,
> KAM

That isn't up to me.  We as a project need to decide upon a signing key 
policy.  On one hand we need people who are active in the project to be 
empowered to do necessary tasks.  But OTOH it is dangerous to spread the 
key and passphrase to too many people.  Witness the drama that exploded 
a while back because too many people had root access to 
freedesktop.org's servers.

BTW, I haven't seen any voting on 3.3 bugs for quite a while now. 
Meanwhile the written policies allows releasing betas at anytime.  So we 
might be better off just cutting a beta right now instead of waiting. 
I'll try to do it this weekend if nobody objects.

Warren

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.

> I know the password for the signing keys.  I've just been crazy busy.  
> I will have some time May 4th.
>
> By the written policies, it appears that any committer is authorized 
> to unilaterally release an unofficial beta.
>
> I therefore propose that folks should get in whatever they can to the 
> 3.3.x svn branch, and whatever is there on May 4th I will cut for a 
> beta tarball.  Sometime shortly thereafter we can kick off the real 
> release process.
>
+1.  Hope you did well on your GMATs.  This has been my main hold up on 
cutting the tarballs.  Can we add to this task to get a key for me onto 
the signing key?

Regards,
KAM

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by Justin Mason <jm...@jmason.org>.

On Fri, Apr 29, 2011 at 06:44, Warren Togami Jr. <wt...@gmail.com> wrote:
> On 4/28/2011 8:09 AM, Quanah Gibson-Mount wrote:
>>
>> Actually my impression is the devs do care. But it seems no one knows
>> the password to the signing keys, so they can't make a release and sign
>> it.
>>
>> --Quanah
>
> I know the password for the signing keys.  I've just been crazy busy.  I
> will have some time May 4th.
>
> By the written policies, it appears that any committer is authorized to
> unilaterally release an unofficial beta.
>
> I therefore propose that folks should get in whatever they can to the 3.3.x
> svn branch, and whatever is there on May 4th I will cut for a beta tarball.
>  Sometime shortly thereafter we can kick off the real release process.

+1 (from the sidelines ;)

Re: Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by Sidney Markowitz <si...@sidney.com>.

Warren Togami Jr. wrote, On 29/04/11 5:44 PM:
> I therefore propose that folks should get in whatever they can to the 
> 3.3.x svn branch, and whatever is there on May 4th I will cut for a beta 
> tarball.  Sometime shortly thereafter we can kick off the real release 
> process.

+1 from me. And I'm paying attention again, so I expect to be voting when
that's needed.

 Sidney

Proposed: 3.3.2-beta1 on May 4th Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by "Warren Togami Jr." <wt...@gmail.com>.

On 4/28/2011 8:09 AM, Quanah Gibson-Mount wrote:
>
> Actually my impression is the devs do care. But it seems no one knows
> the password to the signing keys, so they can't make a release and sign it.
>
> --Quanah

I know the password for the signing keys.  I've just been crazy busy.  I 
will have some time May 4th.

By the written policies, it appears that any committer is authorized to 
unilaterally release an unofficial beta.

I therefore propose that folks should get in whatever they can to the 
3.3.x svn branch, and whatever is there on May 4th I will cut for a beta 
tarball.  Sometime shortly thereafter we can kick off the real release 
process.

Warren Togami
warren@togami.com

Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by Quanah Gibson-Mount <qu...@zimbra.com>.

--On Thursday, April 28, 2011 1:53 PM -0400 darxus@chaosreigns.com wrote:

> On 04/27, bugzilla-daemon@issues.apache.org wrote:
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6577
>>
>> --- Comment #11 from software+spamassassin@kd6lvw.ampr.org 2011-04-27
>> 15:53:28 EDT --- RE: Comment #7.  It may very well be working in "the
>> trunk," but what good does that do us if that's NOT pushed out into a
>> release version (such as 3.3.2)?
>>
>> Ever since the release of Perl 5.12.0, we've needed 3.3.1 to be updated,
>> yet more than a year later, 3.3.2 has NOT been released?
>>
>> What exactly is the problem?
>
> Existing devs don't care, and aren't willing to give access to anybody who
> does.

Actually my impression is the devs do care.  But it seems no one knows the 
password to the signing keys, so they can't make a release and sign it.

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Re: New release Re: [Bug 6577] IPv6 encapsulated IPv4 sender not detected correctly

Posted by da...@chaosreigns.com.

On 04/28, darxus@chaosreigns.com wrote:
> What needs to happen for a release?  Tarring up trunk, and testing it?
> What would the version be?

There is excellent documentation of the SA release process here:
http://wiki.apache.org/spamassassin/ReleasePolicy
Command lines involved, including building tarballs:
http://svn.apache.org/viewvc/spamassassin/trunk/build/README?root=Apache-SVN&view=markup

A good point is that releases generally should not be done with critical
bugs.  Although I suspect none of the currently open critical or blocker
bugs are new, so not really a reason to put off a release.

For anybody else wondering what has changed:
http://svn.apache.org/viewvc/spamassassin/?view=log
Although I haven't figured out how to filter out all the automated rule
updates, which makes this pretty useless.

-- 
"Whom God wishes to destroy, he first makes mad."
- Euripides (c.480 - 406 BC).
http://www.ChaosReigns.com