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...@bugzilla.spamassassin.org on 2010/04/08 10:59:37 UTC
[Bug 6403] New: RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Summary: RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Product: Spamassassin
Version: 3.3.1
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: Rules
AssignedTo: dev@spamassassin.apache.org
ReportedBy: rasky@develer.com
Hello,
we have several false positives that are mainly triggered by RCVD_IN_PBL. The
problem appears to be that the rules matches also the last "Received:" line,
that in some cases it contains the end-user sender IP (eg: home DSL
connection). Those IPs are present in PBL by definition, and obviously there is
nothing wrong with them.
For instance:
Received: from Home (host167-186-dynamic.22-79-r.retail.telecomitalia.it
[79.22.186.167])
by mx.google.com with ESMTPS id 2sm12491398fks.42.2010.04.07.09.05.26
(version=SSLv3 cipher=RC4-MD5);
Wed, 07 Apr 2010 09:05:27 -0700 (PDT)
This mail is from a legitimate user using his @gmail.com through the
authenticated SMTP interface Google offers. The string "with ESMTPS" obviously
means that the user has authenticated with Google. But SA will still look up
the end-user IP in the PBL:
* 3.6 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
* [79.22.186.167 listed in zen.spamhaus.org]
Notice that the Received header above is the ONLY place is the whole e-mail
where the IP address appears. I can provide full headers on request.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #6 from Giovanni Bajo <ra...@develer.com> 2010-04-09 09:06:24 UTC ---
# spamassassin -t -D -L < spamtest.txt 2>&1 | grep X-Spam-Relays
Apr 9 11:00:11.352 [26652] dbg: metadata: X-Spam-Relays-Trusted:
Apr 9 11:00:11.352 [26652] dbg: metadata: X-Spam-Relays-Untrusted: [
ip=209.85.220.218 rdns=mail-fx0-f218.google.com helo=mail-fx0-f218.google.com
by=trinity.develer.com ident= envfrom= intl=0 id=43D6E1D611E auth= msa=0 ] [
ip=79.22.186.167 rdns=host167-186-dynamic.22-79-r.retail.telecomitalia.it
helo=Home by=mx.google.com ident= envfrom= intl=0
id=2sm12491398fks.42.2010.04.07.09.05.26 auth= msa=0 ]
Apr 9 11:00:11.353 [26652] dbg: metadata: X-Spam-Relays-Internal:
Apr 9 11:00:11.353 [26652] dbg: metadata: X-Spam-Relays-External: [
ip=209.85.220.218 rdns=mail-fx0-f218.google.com helo=mail-fx0-f218.google.com
by=trinity.develer.com ident= envfrom= intl=0 id=43D6E1D611E auth= msa=0 ] [
ip=79.22.186.167 rdns=host167-186-dynamic.22-79-r.retail.telecomitalia.it
helo=Home by=mx.google.com ident= envfrom= intl=0
id=2sm12491398fks.42.2010.04.07.09.05.26 auth= msa=0 ]
BTW, the output of this command does not match PBL. I don't know if it's normal
or not. I'm running through it the mail as found in my Maildir, including full
headers and including SpamAssassin's headers that are already present in it.
# spamassassin -t -D -L < spamtest.txt 2>&1 | grep PBL
#
We don't have any _networks configuration. This is is a stock SA 3.3.1 Fedora
FC11 installation with no manual configuration at all.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs 2 votes for 3.3.2 |needs 1 vote for 3.3.2
--- Comment #26 from Kevin A. McGrail <km...@pccc.com> 2011-05-09 17:02:47 UTC ---
(In reply to comment #25)
> > # GMail should use ESMTPSA to indicate that it is in fact authenticated,
> > # but doesn't.
>
> Tested the patch with the attached sample mail, and with another
> message I received these days from gmail.com - looks fine to me.
>
> trunk:
> # GMail should use ESMTPSA to indicate that it is in fact authenticated,
> # but doesn't.
> $ svn ci -m 'Bug 6403: RCVD_IN_PBL matches legitimate GMail mails sent
> through SMTP (not web)'
> Sending lib/Mail/SpamAssassin/Message/Metadata/Received.pm
> Committed revision 1101045.
>
> +1 for 3.3.2
+1 here as well
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Sidney Markowitz <si...@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sidney@sidney.com
--- Comment #1 from Sidney Markowitz <si...@sidney.com> 2010-04-08 22:46:47 UTC ---
Wouldn't this be taken care of by adding the Google MX servers to the
trusted-networks list?
Do we have a default trusted-network list, similar to a default whitelist? It
seems to me that most sites nowadays would get better results if they could
push the trust path out to mail servers like gmail. Why should every
SpamAssassin administrator have to configure the same thing at each of their
sites?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Henrik Krohns <he...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs 1 vote for 3.3.2 |ready to commit for 3.3.2
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |3.3.2
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Henrik Krohns <he...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hege@hege.li
--- Comment #2 from Henrik Krohns <he...@hege.li> 2010-04-08 23:43:00 UTC ---
Please provide headers and your *_networks configuration. It's impossible to
debug on such vague information. PBL only matches first external relay and this
should not happen unless misconfigured.
spamassassin -t -D -L < testmsg 2>&1 | grep X-Spam-Relays
Sidney, I don't see what trusted networks has got to do with this..
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #28 from Mark Martinec <Ma...@ijs.si> 2011-05-09 18:09:54 UTC ---
3.3:
Bug 6403: GMail should use ESMTPSA to indicate that it is
in fact authenticated, but doesn't"
Sending lib/Mail/SpamAssassin/Message/Metadata/Received.pm
Committed revision 1101128.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P2
Summary|RCVD_IN_PBL matches |[review] RCVD_IN_PBL
|legitimate GMail mails sent |matches legitimate GMail
|through SMTP (not web) |mails sent through SMTP
| |(not web)
Status Whiteboard| |needs 3 votes for 3.3.2
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #23 from Peter Alfredsen <pe...@gmail.com> 2010-05-27 12:52:21 EDT ---
(In reply to comment #22)
> I'm not sure what you mean by "fetching from gmail" in the SMTP/milter context.
>
> The bug depends on your Postfix configuration. The default appears to be
> "wrong" (for spamass-milter) in both Postfix vanilla and in the Fedora RPMs,
> but it's been amended by Debian/Ubuntu. What are you running?
Gentoo. I've added the extra filter macros to postfix and the needed patches to
spamass-milter. gmail is in my trustpath (deliberately). I am fetching from
gmail with getmail and injecting into postfix, which does all the filtering.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #20 from Karsten Bräckelmann <gu...@rudersport.de> 2010-05-27 11:33:33 EDT ---
(In reply to comment #19)
> I think I found what it is going on.
>
> As specified in the bug description, we are running SpamAssassin through
> Postfix + spamass-milter. Spamass-milter adds a custom Received header to the
> message:
Ah, see, that's why UNPARSEABLE_RELAY and spamass-milter in the same context
did sound familiar. Good catch, Giovanni, thanks!
Peter, I assume you are also using spamass-milter? Can you confirm this fixes
it for you, too?
> BTW: the fix to match ESMTPA vs ESMPT for google header still appears a correct
> fix to me, though not the main bug here.
This would only be relevant, if google servers happen to be in ones *_network
settings. And maybe if one pulls directly from google using e.g. fetchmail,
which can lead to the same behavior.
Also, it feels more like a workaround for broken google headers than a fix...
I'm inclined to change the Summary to properly reflect the main issue, so it
can be found easier. But thanks to the proposed patch there are now two bugs
handled in one report. ;)
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #16 from Kevin A. McGrail <km...@pccc.com> 2010-05-25 18:07:17 EDT ---
(In reply to comment #15)
> Created an attachment (id=4753)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4753) [details]
> Example of gmail-authenticated mail
>
> An example mail sent through gmail from an authenticated account.
Fundamentally, RCVD_IN_PBL is a last_external test and therefore shouldn't be
firing on an IP address from the original sender. Deep Header Parsing is known
to cause issues especially if a users is on a DHCP pool that a spammer has
infiltrated.
However, from reviewing the sample, I still don't have evidence of a legitimate
email marked as RCVD_IN_PBL that was sent from gmail.
I also don't understand what gmail is doing that this only affects RCVD_IN_PBL.
This needs more information, still.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #5 from Henrik Krohns <he...@hege.li> 2010-04-09 09:00:24 UTC ---
Please provide your trusted_networks and internal_networks settings also.
And what is the output of:
spamassassin -t -D -L < msg 2>&1 | grep X-Spam-Relays
My 3.3.1 parses the headers correctly:
Apr 9 11:58:17.796 [5840] dbg: metadata: X-Spam-Relays-External: [
ip=209.85.220.218 rdns=mail-fx0-f218.google.com...
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Giovanni Bajo <ra...@develer.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rasky@develer.com
--- Comment #8 from Giovanni Bajo <ra...@develer.com> 2010-04-09 09:21:15 UTC ---
It still does not seem to detect PBL:
# spamassassin -t -D < spamtest.txt 2>&1 | tail -n 15
Content analysis details: (-0.1 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, low
trust
[209.85.220.218 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is freemail (xxxxxxx[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_FRT_POSSIBLE BODY: ReplaceTags: Possible
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
There are many few rules that match here, compared to the matches recorded in
the e-mail's headers. Is it something worth investigating?
If it helps, we're running spamassassin at the SMTP level (Postfix) through the
spamassassin-milter plugin.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #17 from Karsten Bräckelmann <gu...@rudersport.de> 2010-05-26 06:18:57 EDT ---
I don't think this is a SA issue. Even the original reporter cannot reproduce
the bad BL hits, see comment 8 and comment 6. Whatever the cause is, this
happens only at SMTP time in the production environment. This needs more
investigation in that direction.
The patch is only a workaround, but does not solve the issue of checking the
wrong relays.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #15 from Peter Alfredsen <pe...@gmail.com> 2010-04-22 12:11:50 EDT ---
Created an attachment (id=4753)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4753)
Example of gmail-authenticated mail
An example mail sent through gmail from an authenticated account.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Peter Alfredsen <pe...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #4740|0 |1
is obsolete| |
--- Comment #13 from Peter Alfredsen <pe...@gmail.com> 2010-04-18 12:30:27 EDT ---
Created an attachment (id=4745)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4745)
Escape dots with back-slashes
Correctly escape dots with back-slashes.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #24 from Karsten Bräckelmann <gu...@rudersport.de> 2010-05-27 15:49:31 EDT ---
Such a setup will always bite *without* authentication. Regardless whether one
adds the relays in *_networks. SA understands fetchmail (IIRC same for getmail)
headers, and adjusts the trust path accordingly (can be observed in -D
debugging mode).
This usually results in the original sender's IP to be treated as the last
external relay, which in the most common cases happens to be the (possibly
dial-up) end-user IP.
Again, *without* authentication. You'd get ALL_TRUSTED otherwise.
The bad thing here is, that gmail appears to have failed horribly at properly
tagging authenticated submissions. They decided to re-implement IMAP, poorly.
Why should they do better with SMTP? But I digress... ;)
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #18 from Karsten Bräckelmann <gu...@rudersport.de> 2010-05-26 06:32:14 EDT ---
(In reply to comment #16)
> I also don't understand what gmail is doing that this only affects RCVD_IN_PBL.
It doesn't. See the original report header in attachment 4737. Multiple BL
hits, plus RDNS_DYNAMIC, DOS_OUTLOOK_TO_MX and friends.
Specifically note the UNPARSEABLE_RELAY hit, which also is missing from comment
8. It appears the headers of the message checked at SMTP time are not identical
to the sample. Something breaking headers there?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status Whiteboard|needs 3 votes for 3.3.2 |needs 2 votes for 3.3.2
--- Comment #25 from Mark Martinec <Ma...@ijs.si> 2011-05-09 14:47:30 UTC ---
> # GMail should use ESMTPSA to indicate that it is in fact authenticated,
> # but doesn't.
Tested the patch with the attached sample mail, and with another
message I received these days from gmail.com - looks fine to me.
trunk:
# GMail should use ESMTPSA to indicate that it is in fact authenticated,
# but doesn't.
$ svn ci -m 'Bug 6403: RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)'
Sending lib/Mail/SpamAssassin/Message/Metadata/Received.pm
Committed revision 1101045.
+1 for 3.3.2
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@pccc.com
--- Comment #14 from Kevin A. McGrail <km...@pccc.com> 2010-04-22 09:33:25 EDT ---
(In reply to comment #13)
> Created an attachment (id=4745)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4745) [details]
> Escape dots with back-slashes
>
> Correctly escape dots with back-slashes.
The code looks good but I have no examples to work with. Does this need a test
case?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #4 from Giovanni Bajo <ra...@develer.com> 2010-04-09 08:54:22 UTC ---
Created an attachment (id=4737)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4737)
Headers of e-mail
Headers attached. I've just removed personal details of the sender
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #19 from Giovanni Bajo <ra...@develer.com> 2010-05-27 06:37:26 EDT ---
(In reply to comment #18)
> It appears the headers of the message checked at SMTP time are not identical
> to the sample. Something breaking headers there?
I think I found what it is going on.
As specified in the bug description, we are running SpamAssassin through
Postfix + spamass-milter. Spamass-milter adds a custom Received header to the
message:
http://cvs.savannah.gnu.org/viewvc/spamass-milt/spamass-milter.cpp?revision=1.91&root=spamass-milt&view=markup
line 1003:
assassin->output((string)
"Received: from "+macro_s+" ("+macro__+")\r\n\t"+
by "+macro_j+"("+macro_v+"/"+macro_Z+") with "+macro_r+" id
"+macro_i+";\r\n\t"+
macro_b+"\r\n\t"+
"(envelope-from "+assassin->from()+")\r\n");
This is done because when the milter is invoked, Postfix has not yet added its
last Received header (to be fully compatible with sendmail milter protocol).
But: the standard configuration of Postfix does NOT propagate some of the above
macros (substitution strings) needed by the milter to correctly generate the
header. Specifically, the "_" (underscore) macro, which contains the client IP
address and reverse hostname, was missing.
Thus, the received line seen by SpamAssassin (but not available in the headers
because generated on the fly by the milter) was something like:
Received: from nohelo (unknown) by trinity.develer.com (Postfix/) with SMTP
id unknown
This was the line probably causing the UNPARSABLE_RELAY report. At this point,
I suspect that SpamAssassin was simply moving over to the next Received from
header, and thus matching the original dialup <-> gmail header; and since it
did not recognized "ESMTPA" as an authenticated delivery, it started triggering
the PBL/DUL rules.
The fix (mutuated from Debian) is to change the milter configuration in postfix
main.cf by adding this line:
milter_connect_macros = j {daemon_name} v {if_name} _
This tells postfix to also define the "_" macro when invoking the milter; the
resulting Received header is then parsed correctly by SpamAssassin.
BTW: the fix to match ESMTPA vs ESMPT for google header still appears a correct
fix to me, though not the main bug here.
Thanks everybody!
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #22 from Giovanni Bajo <ra...@develer.com> 2010-05-27 12:28:54 EDT ---
(In reply to comment #21)
> (In reply to comment #20)
>
> > Peter, I assume you are also using spamass-milter? Can you confirm this fixes
> > it for you, too?
>
> I wasn't at the time this bug report got filed, but am now. I am not suffering
> from the UNPARSEABLE_RELAY bug, but I am fetching directly from gmail, though.
I'm not sure what you mean by "fetching from gmail" in the SMTP/milter context.
The bug depends on your Postfix configuration. The default appears to be
"wrong" (for spamass-milter) in both Postfix vanilla and in the Fedora RPMs,
but it's been amended by Debian/Ubuntu. What are you running?
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #12 from Mark Martinec <Ma...@ijs.si> 2010-04-12 18:16:10 EDT ---
> Created an attachment (id=4740)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4740) [details]
Btw, not to forget to quote the dots in a fixed part of a regexp.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #21 from Peter Alfredsen <pe...@gmail.com> 2010-05-27 12:12:29 EDT ---
(In reply to comment #20)
> Peter, I assume you are also using spamass-milter? Can you confirm this fixes
> it for you, too?
I wasn't at the time this bug report got filed, but am now. I am not suffering
from the UNPARSEABLE_RELAY bug, but I am fetching directly from gmail, though.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #7 from Henrik Krohns <he...@hege.li> 2010-04-09 09:08:49 UTC ---
Output looks fine, so I'm a bit confused why this is happening. You can run the
same command without -L for networks tests.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] [review] RCVD_IN_PBL matches legitimate GMail mails sent
through SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #27 from Henrik Krohns <he...@hege.li> 2011-05-09 17:50:24 UTC ---
+1 fine with me, it's even tested
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
--- Comment #3 from Sidney Markowitz <si...@sidney.com> 2010-04-09 00:38:52 UTC ---
(in reply to comment #2)
I think it has more to do with reading and responding to bug reports before
I've had my morning coffee than anything regarding trusted networks. Whoops.
Sorry.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6403] RCVD_IN_PBL matches legitimate GMail mails sent through
SMTP (not web)
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6403
Peter Alfredsen <pe...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #4738|0 |1
is obsolete| |
--- Comment #11 from Peter Alfredsen <pe...@gmail.com> 2010-04-12 16:24:58 EDT ---
Created an attachment (id=4740)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4740)
updated fix
Updated patch to use elsif, expanded the regex looking for a legitimate google
id to one that shows no false positives on ~35000 mails from authenticated
mails originating from google after 2007. Extract info from Received header
about authentication method.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.