You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Louis Guillaume <lo...@zabrico.com> on 2010/07/07 23:45:25 UTC
Re: SA checking of authenticated users' messages
On 6/10/10 11:27 AM, Greg Troxel wrote:
>>> (spamass-milter doesn't tell SA about auth) ==> [
>>> rbl checks run against authenticated user's IP address
>>> lack of ALL_TRUSTED for authenticated user's mail
>>> ]
>>>
>>
>> That last one seems to be my problem. Does the patch fix this? I'll
>> try updating and see what happens.
>
Hi Again!
I just need to clarify one thing that's not clear to me in re-reading
our thread from the other day: Is there a work-around for this?
My users are getting restless. Everytime their ISP changes their IP
address I have to whitelist them!
Louis
Re: SA checking of authenticated users' messages
Posted by Patrick Ben Koetter <p...@state-of-mind.de>.
* Daniel McDonald <da...@austinenergy.com>:
> > I just need to clarify one thing that's not clear to me in re-reading
> > our thread from the other day: Is there a work-around for this?
>
> Usually, you listen for end-users on the submission port, and don't filter
> it for spam, just auth.
I recommend using the submission port AND filter, but not too strict. The
rationale is to ensure deliverablity by checking for spamminess on your own
side before someone else would reject the message.
p@rick
--
state of mind
Digitale Kommunikation
http://www.state-of-mind.de
Franziskanerstraße 15 Telefon +49 89 3090 4664
81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
Re: SA checking of authenticated users' messages
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>>> > > (spamass-milter doesn't tell SA about auth) ==> [
>>> > > rbl checks run against authenticated user's IP address
>>> > > lack of ALL_TRUSTED for authenticated user's mail
>>> > That last one seems to be my problem. Does the patch fix this? I'll
>>> > try updating and see what happens.
> On Wed, 7 Jul 2010, Louis Guillaume wrote:
>> I just need to clarify one thing that's not clear to me in re-reading
>> our thread from the other day: Is there a work-around for this?
>> My users are getting restless. Everytime their ISP changes their IP
>> address I have to whitelist them!
On 08.07.10 10:21, Charles Gregory wrote:
> Uh, I missed the original thread, so maybe this was explained, but why
> aren't the users sending mail through their ISP's SMTP server?
apparently they are his (louis') customers and use mail address directed to
his mailserver. In that case they should also use his SMTP server for
outgoing mail.
--
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.
Save the whales. Collect the whole set.
Re: SA checking of authenticated users' messages
Posted by Charles Gregory <cg...@hwcn.org>.
On Wed, 7 Jul 2010, Louis Guillaume wrote:
>> > > (spamass-milter doesn't tell SA about auth) ==> [
>> > > rbl checks run against authenticated user's IP address
>> > > lack of ALL_TRUSTED for authenticated user's mail
>> > That last one seems to be my problem. Does the patch fix this? I'll
>> > try updating and see what happens.
> Hi Again!
> I just need to clarify one thing that's not clear to me in re-reading our
> thread from the other day: Is there a work-around for this?
> My users are getting restless. Everytime their ISP changes their IP address I
> have to whitelist them!
Uh, I missed the original thread, so maybe this was explained, but why
aren't the users sending mail through their ISP's SMTP server?
Presuming there is a good answer for this, then, have you considered just
whitelisting based on the user's "From:" header? There's a trick to it:
90% of the time, spammers have a harvested address, but *don't* have the
NAME portion of the user's "From:" header.
So build a rule that matches their WHOLE 'From:' header, like this:
header LOC_FROMOURUSER From =~ /^User Name <th...@example.com>/
Notice the absence of the coomnly usd 'i' flag on the regex.
If they have quotes around their name, include them in the regex.
The entire line shuold *exactly* match what the user's MUA generates.
The only thing that messes this up is when users have the annoying habit
of changing their 'name' on their mail....
Naturally, there is a small risk of having a spammer send a message with
exactly that header, but really, how many of those will there be?
- Charles
Re: SA checking of authenticated users' messages
Posted by Greg Troxel <gd...@ir.bbn.com>.
Cedric Knight <ce...@gn.apc.org> writes:
> On 07/07/10 23:26, Greg Troxel wrote:
>>
>> Louis Guillaume <lo...@zabrico.com> writes:
>>> I just need to clarify one thing that's not clear to me in re-reading
>>> our thread from the other day: Is there a work-around for this?
>>>
>>> My users are getting restless. Everytime their ISP changes their IP
>>> address I have to whitelist them!
>>
>> I think there are currently only two viable approaches:
>>
>> arrange not to pass authenticated mail to spamass-milter
>>
>> change postfix and/or spamass-milter to insert a line in the
>> pseudoheader saying the mail was authenticated, so the ALL_TRUSTED
>> test fires and not the RBL checks. This is some twitchy code to
>> write, but I suspect it isn't really that hard.
>
> I don't think Louis has said what MTA is involved, but if it's Postfix
> 2.3 or later, you just add the following line to main.cf:
>
> smtpd_sasl_authenticated_header = yes
>
> And SA should then put all relays in X-Spam-Relays-Trusted and add
> ALL_TRUSTED (about -1.8 points) and not do any RBL checks. It's the RBL
> checks that could be the major problem because client IPs are naturally
> listed in DULs, and look like dynablocks.
I have that, and that indeed causes postfix to put in the
authenticated-user header and SA processes it.
The problem is with spamass-milter. spamass-milter generates a
synthetic Received: line for the message arriving, trying to be similar
to the Received: line that the MTA will add when the message is actually
received, so that SA can process the message normally. The synthetic
Received: line just needs to be similar to what postfix inserts with
smtpd_sasl_authenticated_header=yes. This isn't wicked hard - it's just
that no one has written the code, plus spamass-milter upstream seems to
be dead.
Re: SA checking of authenticated users' messages
Posted by Cedric Knight <ce...@gn.apc.org>.
On 07/07/10 23:26, Greg Troxel wrote:
>
> Louis Guillaume <lo...@zabrico.com> writes:
>> I just need to clarify one thing that's not clear to me in re-reading
>> our thread from the other day: Is there a work-around for this?
>>
>> My users are getting restless. Everytime their ISP changes their IP
>> address I have to whitelist them!
>
> I think there are currently only two viable approaches:
>
> arrange not to pass authenticated mail to spamass-milter
>
> change postfix and/or spamass-milter to insert a line in the
> pseudoheader saying the mail was authenticated, so the ALL_TRUSTED
> test fires and not the RBL checks. This is some twitchy code to
> write, but I suspect it isn't really that hard.
I don't think Louis has said what MTA is involved, but if it's Postfix
2.3 or later, you just add the following line to main.cf:
smtpd_sasl_authenticated_header = yes
And SA should then put all relays in X-Spam-Relays-Trusted and add
ALL_TRUSTED (about -1.8 points) and not do any RBL checks. It's the RBL
checks that could be the major problem because client IPs are naturally
listed in DULs, and look like dynablocks.
However, some other checks may still run with ALL_TRUSTED and I found
the following kind of thing helped:
ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
meta TRUST_SHORTCIRCUIT (ALL_TRUSTED)
score TRUST_SHORTCIRCUIT -5.0
tflags TRUST_SHORTCIRCUIT nice
priority TRUST_SHORTCIRCUIT -1000
shortcircuit TRUST_SHORTCIRCUIT on
endif
So you don't necessarily need to separate inbound and outbound ports or
IP addresses, although if you're designing a system from scratch you
probably would.
If some people are using pop-before-smtp there's the POPAuth plugin
which adds the authenticated client IP addresses to trusted_networks
(although in that case be careful of mail 2 web services like Google and
now Hotmail).
Were you using amavis with a single MX, an alternative is a postfix
kludge to separate incoming and authenticated mail to run different
amavis policy banks (e.g. authenticated virus check and DKIM signing;
incoming virus and spam check). See
http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim-postfix-dual-path
I don't know about doing this in MTAs other than postfix.
HTH
C
Re: SA checking of authenticated users' messages
Posted by Greg Troxel <gd...@ir.bbn.com>.
Louis Guillaume <lo...@zabrico.com> writes:
> On 6/10/10 11:27 AM, Greg Troxel wrote:
>
>>>> (spamass-milter doesn't tell SA about auth) ==> [
>>>> rbl checks run against authenticated user's IP address
>>>> lack of ALL_TRUSTED for authenticated user's mail
>>>> ]
>>>>
>>>
>>> That last one seems to be my problem. Does the patch fix this? I'll
>>> try updating and see what happens.
>
> I just need to clarify one thing that's not clear to me in re-reading
> our thread from the other day: Is there a work-around for this?
>
> My users are getting restless. Everytime their ISP changes their IP
> address I have to whitelist them!
I think there are currently only two viable approaches:
arrange not to pass authenticated mail to spamass-milter
change postfix and/or spamass-milter to insert a line in the
pseudoheader saying the mail was authenticated, so the ALL_TRUSTED
test fires and not the RBL checks. This is some twitchy code to
write, but I suspect it isn't really that hard.
Re: SA checking of authenticated users' messages
Posted by Daniel McDonald <da...@austinenergy.com>.
On 7/7/10 4:45 PM, "Louis Guillaume" <lo...@zabrico.com> wrote:
> On 6/10/10 11:27 AM, Greg Troxel wrote:
>
>>>> (spamass-milter doesn't tell SA about auth) ==> [
>>>> rbl checks run against authenticated user's IP address
>>>> lack of ALL_TRUSTED for authenticated user's mail
>>>> ]
>>>>
>>>
>>> That last one seems to be my problem. Does the patch fix this? I'll
>>> try updating and see what happens.
>>
>
>
> Hi Again!
>
> I just need to clarify one thing that's not clear to me in re-reading
> our thread from the other day: Is there a work-around for this?
Usually, you listen for end-users on the submission port, and don't filter
it for spam, just auth.
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281