You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Arthur Kerpician <ar...@bluechip.ro> on 2009/04/25 12:34:53 UTC
trust SMTP authenticated users
Hi,
I'm facing the following problem lately. Some of my users are connecting
to the mail server (qmail) through mobile phones and the leased IPs from
the GSM operator are blacklisted in spamhaus and spamcop. So, they are
using the smtp server with spamassassin 3.2.5 but their messages are
marked as spam and not delivered, since the rbl checks are positive.
Is there a way to "trust" smtp authenticated users in SA?
Thanks all,
Arthur
Re: trust SMTP authenticated users
Posted by Rick Macdougall <ri...@ummm-beer.com>.
Magnus Holmgren wrote:
> On lördagen den 25 april 2009, Arthur Kerpician wrote:
>> Hi,
>> I'm facing the following problem lately. Some of my users are connecting
>> to the mail server (qmail) through mobile phones and the leased IPs from
>> the GSM operator are blacklisted in spamhaus and spamcop. So, they are
>> using the smtp server with spamassassin 3.2.5 but their messages are
>> marked as spam and not delivered, since the rbl checks are positive.
>>
>> Is there a way to "trust" smtp authenticated users in SA?
--- ignore this but it may help someone else ---
With tcpserver/rblsmtpd and qmail (and most likely, most other mail
servers as well) there is no way to reject IP's listed in an RBL you are
checking without also blocking authenticated users.
What I would do is run another qmail instance on another port (say 587)
and only allow authenticated users to send through that port and not use
rblsmtpd.
The chkuser patch will allow you to do this.
--- end snip here ---
Emmm, re-reading your post, the messages are coming in BUT marked as
spam in spamassassin.
All you need in that case is to use simscan, which by default, does not
call spamc for authenticated users, is still does call clamd if
configured to do so how ever.
Regards,
Rick
RE: trust SMTP authenticated users
Posted by "Brady A. Tucker" <ba...@itservicestation.com>.
One thing I do is run a separate Daemon with AUTH on alternate ports for
those 'external' users that would fall into that category (and for those
users where standard ports are blocked). That alternate daemon doesn't
run through (in my case) MailScanner/SA and instead just throws it in
the already scanned ready to deliver queue .... don't know if that is an
option for you or not..
-----Original Message-----
From: Adam Katz [mailto:antispam@khopis.com]
Sent: Sunday, May 10, 2009 9:49 PM
To: Spamassassin Users
Subject: Re: trust SMTP authenticated users
Arthur Kerpician wrote:
>> I'm facing the following problem lately. Some of my users are
>> connecting to the mail server (qmail) through mobile phones and the
>> leased IPs from the GSM operator are blacklisted in spamhaus and
>> spamcop. So, they are using the smtp server with spamassassin 3.2.5
>> but their messages are marked as spam and not delivered, since the
>> rbl checks are positive.
>>
>> Is there a way to "trust" smtp authenticated users in SA?
Magnus Holmgren responded:
> It should happen automatically if the users authenticate with SMTP
> AUTH and the MSA signals it in the Received: field (e.g. "Received:
> from ... with ESMTPSA ..." instead of "with ESMTP"), but I don't know
> if Qmail does that
The best solution I've seen for this kind of thing is the POPAuth
plugin, which uses the IMAP/POP authentication tables (as populated for
the old fashioned POP-before-SMTP scheme) to temporarily add senders'
IPs to SpamAssassin's trusted_networks list.
http://wiki.apache.org/spamassassin/POPAuthPlugin
> Otherwise I think you need to let a separate MSA, separate from the
> main MTA and included in trusted_networks but not in
> internal_networks, receive the users' mail, or arrange for a fake
> Received line, simulating this, to be inserted.
Since it is unwise to trust third-party spam/virus detection reports,
the only use for scanning outbound mail is in blocking it (possible
outbreaks, poorly composed announcements, bad jokes) or for statistical
purposes (autolearn). I don't personally view either of those reasons
as terribly worthwhile for my implementation, so I don't scan outgoing
mail.
The issue of scanning /incoming/ mail and parsing internal mail as noted
by Arthur occurs when there is only one mail server in the loop; since
it can't see other relays, SpamAssassin is forced to assume that the
only foreign address it can find is actually the relay. As Magnus
stated, this is best solved by running your outbound SMTP separate from
your incoming MX record (even if on the same server ... just use
different IP addresses and different SMTP server instances).
Re: trust SMTP authenticated users
Posted by Robert Schetterer <ro...@schetterer.org>.
Matus UHLAR - fantomas schrieb:
>> On Mon, May 11, 2009 09:34, Matus UHLAR - fantomas wrote:
>>> But I'd recommend to use that one only if you know that your MTA won't be
>>> able to auth users and put the auth info into Received: headers.
>>> Using SMTP authentication is much much better than pop-before-smtp
>
> On 11.05.09 11:04, Benny Pedersen wrote:
>> POP-before-smtp is okay if remote clients does not sit behind NAT
>
> There may be issue if the IP address changes, e.g. for DHCP, dial-up or DSL
> customer.
>
>> that problem is solved with smtp auth
>
> others are, too. That's why I said that I don't recommend auth using
> pop-before-smtp.
>
pop before smtp has always the security problem
that you relay by ip, if users are nated behind a firewall
the may fake their sender address
so sasl smtp auth is the best solution, and has more option
to reject by matching auth and sender address
after all pop before smtp makes life more easy for some users and setups
but it shouldnt be recommended in all setups these days
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: trust SMTP authenticated users
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> On Mon, May 11, 2009 09:34, Matus UHLAR - fantomas wrote:
> > But I'd recommend to use that one only if you know that your MTA won't be
> > able to auth users and put the auth info into Received: headers.
> > Using SMTP authentication is much much better than pop-before-smtp
On 11.05.09 11:04, Benny Pedersen wrote:
> POP-before-smtp is okay if remote clients does not sit behind NAT
There may be issue if the IP address changes, e.g. for DHCP, dial-up or DSL
customer.
> that problem is solved with smtp auth
others are, too. That's why I said that I don't recommend auth using
pop-before-smtp.
--
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: trust SMTP authenticated users
Posted by Benny Pedersen <me...@junc.org>.
On Mon, May 11, 2009 09:34, Matus UHLAR - fantomas wrote:
> But I'd recommend to use that one only if you know that your MTA won't be
> able to auth users and put the auth info into Received: headers.
> Using SMTP authentication is much much better than pop-before-smtp
POP-before-smtp is okay if remote clients does not sit behind NAT
that problem is solved with smtp auth
--
http://localhost/ 100% uptime and 100% mirrored :)
Re: trust SMTP authenticated users
Posted by Adam Katz <an...@khopis.com>.
> On 10.05.09 22:49, Adam Katz wrote:
>> The best solution I've seen for this kind of thing is the POPAuth
>> plugin, which uses the IMAP/POP authentication tables (as populated for
>> the old fashioned POP-before-SMTP scheme) to temporarily add senders'
>> IPs to SpamAssassin's trusted_networks list.
>>
>> http://wiki.apache.org/spamassassin/POPAuthPlugin
Matus UHLAR - fantomas wrote:
> But I'd recommend to use that one only if you know that your MTA won't be
> able to auth users and put the auth info into Received: headers.
> Using SMTP authentication is much much better than pop-before-smtp
Uh. I see seven emails with the same misunderstanding of what I said.
I never advocated using POP-before-SMTP and POPAuth as a security
tool. The *original* intent of POP-before-SMTP was security, and this
is not my suggested use of the tool at all.
My point was since users are *already* authenticated and Arthur was
unable to verify the authentication in SpamAssassin, he could use
POPAuth to add the users' IPs to trusted_networks.
Re: trust SMTP authenticated users
Posted by Robert Schetterer <ro...@schetterer.org>.
Matus UHLAR - fantomas schrieb:
> On 11.05.09 10:30, Robert Schetterer wrote:
>> if you use spamass-milter patched
>> there is an option no to check sasl authed users
>
> I don't recommend skipping checks of authenticated users. Even they may
> send spam - some malware uses outlook's SMTP code (happened here a few times)
>
> The issue was with authenticated user sending from rbl-listed host, whwere
> the problem lies in MTA not putting authentication info to Received:
> headers, which results in checking of the sending IP in blacklists.
>
> MTA's that support milter (afaik only sendmail and postfix) also support
> putting auth info to headers.
>
jep that works too
but for known spam hashes its possible to reject
them at smtp input level with clamav-milter and sanessecurity antispam dbs
i addition with override spam scan authed users in spamass-milter
youre mostly save, after all false positves may increase support
ever
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: trust SMTP authenticated users
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 11.05.09 10:30, Robert Schetterer wrote:
> if you use spamass-milter patched
> there is an option no to check sasl authed users
I don't recommend skipping checks of authenticated users. Even they may
send spam - some malware uses outlook's SMTP code (happened here a few times)
The issue was with authenticated user sending from rbl-listed host, whwere
the problem lies in MTA not putting authentication info to Received:
headers, which results in checking of the sending IP in blacklists.
MTA's that support milter (afaik only sendmail and postfix) also support
putting auth info to headers.
--
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.
Fighting for peace is like fucking for virginity...
Re: trust SMTP authenticated users
Posted by Robert Schetterer <ro...@schetterer.org>.
Matus UHLAR - fantomas schrieb:
>> Arthur Kerpician wrote:
>>>> I'm facing the following problem lately. Some of my users are
>>>> connecting to the mail server (qmail) through mobile phones and the
>>>> leased IPs from the GSM operator are blacklisted in spamhaus and
>>>> spamcop. So, they are using the smtp server with spamassassin 3.2.5
>>>> but their messages are marked as spam and not delivered, since the
>>>> rbl checks are positive.
>>>>
>>>> Is there a way to "trust" smtp authenticated users in SA?
>> Magnus Holmgren responded:
>>> It should happen automatically if the users authenticate with SMTP
>>> AUTH and the MSA signals it in the Received: field (e.g. "Received:
>>> from ... with ESMTPSA ..." instead of "with ESMTP"), but I don't know
>>> if Qmail does that
>
> On 10.05.09 22:49, Adam Katz wrote:
>> The best solution I've seen for this kind of thing is the POPAuth
>> plugin, which uses the IMAP/POP authentication tables (as populated for
>> the old fashioned POP-before-SMTP scheme) to temporarily add senders'
>> IPs to SpamAssassin's trusted_networks list.
>>
>> http://wiki.apache.org/spamassassin/POPAuthPlugin
>
> But I'd recommend to use that one only if you know that your MTA won't be
> able to auth users and put the auth info into Received: headers.
> Using SMTP authentication is much much better than pop-before-smtp
>
if you use spamass-milter patched
there is an option no to check sasl authed users
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: trust SMTP authenticated users
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
> Arthur Kerpician wrote:
> >> I'm facing the following problem lately. Some of my users are
> >> connecting to the mail server (qmail) through mobile phones and the
> >> leased IPs from the GSM operator are blacklisted in spamhaus and
> >> spamcop. So, they are using the smtp server with spamassassin 3.2.5
> >> but their messages are marked as spam and not delivered, since the
> >> rbl checks are positive.
> >>
> >> Is there a way to "trust" smtp authenticated users in SA?
>
> Magnus Holmgren responded:
> > It should happen automatically if the users authenticate with SMTP
> > AUTH and the MSA signals it in the Received: field (e.g. "Received:
> > from ... with ESMTPSA ..." instead of "with ESMTP"), but I don't know
> > if Qmail does that
On 10.05.09 22:49, Adam Katz wrote:
> The best solution I've seen for this kind of thing is the POPAuth
> plugin, which uses the IMAP/POP authentication tables (as populated for
> the old fashioned POP-before-SMTP scheme) to temporarily add senders'
> IPs to SpamAssassin's trusted_networks list.
>
> http://wiki.apache.org/spamassassin/POPAuthPlugin
But I'd recommend to use that one only if you know that your MTA won't be
able to auth users and put the auth info into Received: headers.
Using SMTP authentication is much much better than pop-before-smtp
--
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.
WinError #98652: Operation completed successfully.
Re: trust SMTP authenticated users
Posted by Adam Katz <an...@khopis.com>.
Arthur Kerpician wrote:
>> I'm facing the following problem lately. Some of my users are
>> connecting to the mail server (qmail) through mobile phones and the
>> leased IPs from the GSM operator are blacklisted in spamhaus and
>> spamcop. So, they are using the smtp server with spamassassin 3.2.5
>> but their messages are marked as spam and not delivered, since the
>> rbl checks are positive.
>>
>> Is there a way to "trust" smtp authenticated users in SA?
Magnus Holmgren responded:
> It should happen automatically if the users authenticate with SMTP
> AUTH and the MSA signals it in the Received: field (e.g. "Received:
> from ... with ESMTPSA ..." instead of "with ESMTP"), but I don't know
> if Qmail does that
The best solution I've seen for this kind of thing is the POPAuth
plugin, which uses the IMAP/POP authentication tables (as populated for
the old fashioned POP-before-SMTP scheme) to temporarily add senders'
IPs to SpamAssassin's trusted_networks list.
http://wiki.apache.org/spamassassin/POPAuthPlugin
> Otherwise I think you need to let a separate MSA, separate from the
> main MTA and included in trusted_networks but not in
> internal_networks, receive the users' mail, or arrange for a fake
> Received line, simulating this, to be inserted.
Since it is unwise to trust third-party spam/virus detection reports,
the only use for scanning outbound mail is in blocking it (possible
outbreaks, poorly composed announcements, bad jokes) or for statistical
purposes (autolearn). I don't personally view either of those reasons
as terribly worthwhile for my implementation, so I don't scan outgoing mail.
The issue of scanning /incoming/ mail and parsing internal mail as noted
by Arthur occurs when there is only one mail server in the loop; since
it can't see other relays, SpamAssassin is forced to assume that the
only foreign address it can find is actually the relay. As Magnus
stated, this is best solved by running your outbound SMTP separate from
your incoming MX record (even if on the same server ... just use
different IP addresses and different SMTP server instances).
Re: trust SMTP authenticated users
Posted by Magnus Holmgren <ho...@lysator.liu.se>.
On lördagen den 25 april 2009, Arthur Kerpician wrote:
> Hi,
> I'm facing the following problem lately. Some of my users are connecting
> to the mail server (qmail) through mobile phones and the leased IPs from
> the GSM operator are blacklisted in spamhaus and spamcop. So, they are
> using the smtp server with spamassassin 3.2.5 but their messages are
> marked as spam and not delivered, since the rbl checks are positive.
>
> Is there a way to "trust" smtp authenticated users in SA?
It should happen automatically if the users authenticate with SMTP AUTH and
the MSA signals it in the Received: field (e.g. "Received: from ... with
ESMTPSA ..." instead of "with ESMTP"), but I don't know if Qmail does that
(the official Qmail isn't exactly known as the most modern mail server).
Otherwise I think you need to let a separate MSA, separate from the main MTA
and included in trusted_networks but not in internal_networks, receive the
users' mail, or arrange for a fake Received line, simulating this, to be
inserted.
--
Magnus Holmgren holmgren@lysator.liu.se
(No Cc of list mail needed, thanks)
"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans