You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Rainer Fügenstein <rf...@oudeis.org> on 2014/01/31 15:24:37 UTC
regexp for SMTP AUTH
hi,
mails delivered via sendmail SMTP AUTH contain a Received: header like this:
Received: from [192.168.5.238] (xyz.example.com [90.217.201.80])
(authenticated bits=0)
by myserver.mydomain.at (8.13.8/8.13.8) with ESMTP id s0VE3Iwj027715
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <me...@home.org>; Fri, 31 Jan 2014 15:03:19 +0100
could anyone here help with a rule that matches this header, please? I
tried for quite some time now but can't get it done :-(
important parts to match are "(authenticated bits=\d+)" and
"myserver.mydomain.at"
thank you.
Re: regexp for SMTP AUTH
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>MUf> This was the point. If the line that should be matched with the rule is the
>MUf> first one, AND the check is done before MTA adds Received: line (which is
>MUf> case when the milter is used), this is an issue of the intermediate program
>MUf> that feeds mail to spamassassin.
>
>MUf> Now, Rainer, can you confirm this is the case?
On 07.02.14 15:11, Rainer Fügenstein wrote:
>what I can tell is the following:
>- spamass-milter 0.3.1 is in use. this seems to be the most current
>version.
>- if I understand this conversation correctly: the line
>
> "Received: from [192.168.5.238] (xyz.example.com [90.217.201.80])"
>
>has already been passed to spamassassin (or been "virtually created"
>when the regex rules are applied, but the following lines
>
> (authenticated bits=0)
> by myserver.mydomain.at (8.13.8/8.13.8) with ESMTP id s0VEsVIv028654
> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
>
>haven't. does this make sense? is this how SA is implemented?
It's the whole _first_ multi-line Received: header (pardon - not line) that
is faked by spamass-milter when passing to spamd and the one you see is
added by sendmail later. So, spamd apparently sees something different than
you do.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton
Re[2]: regexp for SMTP AUTH
Posted by Rainer Fügenstein <rf...@oudeis.org>.
MUf> This was the point. If the line that should be matched with the rule is the
MUf> first one, AND the check is done before MTA adds Received: line (which is
MUf> case when the milter is used), this is an issue of the intermediate program
MUf> that feeds mail to spamassassin.
MUf> Now, Rainer, can you confirm this is the case?
what I can tell is the following:
- spamass-milter 0.3.1 is in use. this seems to be the most current
version.
- if I understand this conversation correctly: the line
"Received: from [192.168.5.238] (xyz.example.com [90.217.201.80])"
has already been passed to spamassassin (or been "virtually created"
when the regex rules are applied, but the following lines
(authenticated bits=0)
by myserver.mydomain.at (8.13.8/8.13.8) with ESMTP id s0VEsVIv028654
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
haven't. does this make sense? is this how SA is implemented?
I'll enable spamass-milter debug output and see if I can make any
sense of it.
cu
--- NOT sent from an iPhone
Re: regexp for SMTP AUTH
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>>>>header MY_AUTH ALL =~ /\(authenticated
>>>>bits=\d+\)\s+by\s+myserver.mydomain.at/
>>On 31.01.14 16:58, Rainer Fügenstein wrote:
>>>thanks. looks plausible, but doesn't work, unfortunately. I figured out
>>>that rules matching the first line work, but rules for lines 2+ never
>>>match, regardless of \n \s etc.
>On Thu, 6 Feb 2014, Matus UHLAR - fantomas wrote:
>>isn't this the first Received: header? spamd may not receive it when MTA
>>first transfers message to SA and THEN adds the Received: header...
>>e.g. milter behaves like this
On 06.02.14 13:52, David B Funk wrote:
>Any worthwhile milter for SA needs to syntesize a "Received:" header to mimic
>what the MTA will add to the processed message. Problem can be with the accuracy
>of that syntesized header. If the milter author didn't know to check the auth
>status of the message s/he may not have added a representation of it to the
>header passed on to SA thus SA had no way to know that the message was authed.
>(seem to remember this exact issue with an early incarnation of
>'spamass-milter' ).
This was the point. If the line that should be matched with the rule is the
first one, AND the check is done before MTA adds Received: line (which is
case when the milter is used), this is an issue of the intermediate program
that feeds mail to spamassassin.
Now, Rainer, can you confirm this is the case?
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Support bacteria - they're the only culture some people have.
Re: regexp for SMTP AUTH
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Thu, 6 Feb 2014, Matus UHLAR - fantomas wrote:
>>> header MY_AUTH ALL =~ /\(authenticated
>>> bits=\d+\)\s+by\s+myserver.mydomain.at/
>
> On 31.01.14 16:58, Rainer Fügenstein wrote:
>> thanks. looks plausible, but doesn't work, unfortunately. I figured out
>> that rules matching the first line work, but rules for lines 2+ never
>> match, regardless of \n \s etc.
>
> isn't this the first Received: header? spamd may not receive it when MTA
> first transfers message to SA and THEN adds the Received: header...
> e.g. milter behaves like this
Any worthwhile milter for SA needs to syntesize a "Received:" header to mimic
what the MTA will add to the processed message. Problem can be with the accuracy
of that syntesized header. If the milter author didn't know to check the auth
status of the message s/he may not have added a representation of it to the
header passed on to SA thus SA had no way to know that the message was authed.
(seem to remember this exact issue with an early incarnation of
'spamass-milter' ).
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: regexp for SMTP AUTH
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> header MY_AUTH ALL =~ /\(authenticated
>> bits=\d+\)\s+by\s+myserver.mydomain.at/
On 31.01.14 16:58, Rainer Fügenstein wrote:
>thanks. looks plausible, but doesn't work, unfortunately. I figured out
>that rules matching the first line work, but rules for lines 2+ never
>match, regardless of \n \s etc.
isn't this the first Received: header? spamd may not receive it when MTA
first transfers message to SA and THEN adds the Received: header...
e.g. milter behaves like this
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?
Re: regexp for SMTP AUTH
Posted by Rainer Fügenstein <rf...@oudeis.org>.
bowie, matus,
> header MY_AUTH ALL =~ /\(authenticated
> bits=\d+\)\s+by\s+myserver.mydomain.at/
thanks. looks plausible, but doesn't work, unfortunately. I figured out
that rules matching the first line work, but rules for lines 2+ never
match, regardless of \n \s etc.
> I think this is what X-Spam-Relays-Trusted pseuo-header is for... It
just has different form and the auth info should be already there
parsed...
the header in question is not recognized by SA by default, therefore the
need for an additional rule. if that's what you mean.
this is how the while header looks like:
Return-Path: <me...@home.org>
Received: from [192.168.5.238] (xyz.example.com [90.217.201.80])
(authenticated bits=0)
by myserver.mydomain.at (8.13.8/8.13.8) with ESMTP id s0VEsVIv028654
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <me...@home.org>; Fri, 31 Jan 2014 15:54:32 +0100
Message-ID: <52...@home.org>
Date: Fri, 31 Jan 2014 15:54:21 +0100
From: Rainer Fügenstein <me...@home.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.2.0
MIME-Version: 1.0
To: me@home.org
Subject: [SPAM] test 7
Content-Type: multipart/mixed; boundary="----------=_52EBB928.6342004E"
Content-Transfer-Encoding: 7bit
X-Spam-Flag: YES
X-Spam-Status: Yes, score=5.1 required=5.0 tests=BAYES_50,RCVD_IN_PBL,
RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,TO_NO_BRKTS_DYNIP autolearn=no
version=3.3.1
X-Spam-Level: *****
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
myserver.mydomain.at
Re: regexp for SMTP AUTH
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On 1/31/2014 9:24 AM, Rainer Fügenstein wrote:
>>mails delivered via sendmail SMTP AUTH contain a Received: header like this:
>>
>>Received: from [192.168.5.238] (xyz.example.com [90.217.201.80])
>> (authenticated bits=0)
>> by myserver.mydomain.at (8.13.8/8.13.8) with ESMTP id s0VE3Iwj027715
>> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
>> for <me...@home.org>; Fri, 31 Jan 2014 15:03:19 +0100
>>
>>could anyone here help with a rule that matches this header, please? I
>>tried for quite some time now but can't get it done :-(
>>
>>important parts to match are "(authenticated bits=\d+)" and
>>"myserver.mydomain.at"
On 31.01.14 09:41, Bowie Bailey wrote:
>header MY_AUTH ALL =~ /\(authenticated
>bits=\d+\)\s+by\s+myserver.mydomain.at/
>
>Note that this is a spoofable rule. Anyone can add a fake header to
>their message containing this string and it will match.
>
>(rule is off the top of my head and untested)
I think this is what X-Spam-Relays-Trusted pseuo-header is for...
It just has different form and the auth info should be already there
parsed...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
Re: regexp for SMTP AUTH
Posted by Bowie Bailey <Bo...@BUC.com>.
On 1/31/2014 9:24 AM, Rainer Fügenstein wrote:
> hi,
>
> mails delivered via sendmail SMTP AUTH contain a Received: header like this:
>
> Received: from [192.168.5.238] (xyz.example.com [90.217.201.80])
> (authenticated bits=0)
> by myserver.mydomain.at (8.13.8/8.13.8) with ESMTP id s0VE3Iwj027715
> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
> for <me...@home.org>; Fri, 31 Jan 2014 15:03:19 +0100
>
> could anyone here help with a rule that matches this header, please? I
> tried for quite some time now but can't get it done :-(
>
> important parts to match are "(authenticated bits=\d+)" and
> "myserver.mydomain.at"
>
> thank you.
>
>
header MY_AUTH ALL =~ /\(authenticated
bits=\d+\)\s+by\s+myserver.mydomain.at/
Note that this is a spoofable rule. Anyone can add a fake header to
their message containing this string and it will match.
(rule is off the top of my head and untested)
--
Bowie