RFC 3848 (ESMTPA / ESMTPSA in Received lines)
David Schweikert
Is support for RFC 3848 planned?
I am trying to figure out how to solve the problem that SpamAssassin at
our site does check the originating IP addresses of mails sent by users
with SMTP AUTH and sometimes gives SPAM-points because they are
dialup adresses (and sometimes blacklisted too). This problem is
described here: http://wiki.apache.org/spamassassin/DynablockIssues
Having RFC-3848 support would mean that the Received headers for
authenticated connections can be distinguished ('ESMTPA' or 'ESMTPSA' in
the line) and ignored by SpamAssassin.
Cheers
David
--
David Schweikert | phone: +41 44 632 7019
System manager ISG.EE | walk: ETH Zentrum, ETL F24.1
ETH Zurich, Switzerland | web: http://people.ee.ethz.ch/dws
mouss
>Hi,
>
>Is support for RFC 3848 planned?
>
>I am trying to figure out how to solve the problem that SpamAssassin at
>our site does check the originating IP addresses of mails sent by users
>with SMTP AUTH and sometimes gives SPAM-points because they are
>dialup adresses (and sometimes blacklisted too). This problem is
>described here: http://wiki.apache.org/spamassassin/DynablockIssues
>
>
configure your trusted_networks (in SA) explicitly and correctly. for
instance
trusted_networks 192.0.2.78 # your public IP
trusted_networks 10.0.0.0/8 #your private network if any
trusted_networks 192.0.2.0/24 #your "internal" newtork if any
...
if that's not enough, then it's an SA bug.
>Having RFC-3848 support would mean that the Received headers for
>authenticated connections can be distinguished ('ESMTPA' or 'ESMTPSA' in
>the line) and ignored by SpamAssassin.
>
>
only if trusted would that be helpful, as anyone can forge received
headers. so you still need the trusted_networks.
David Schweikert
> configure your trusted_networks (in SA) explicitly and correctly. for instance
> trusted_networks 192.0.2.78 # your public IP
> trusted_networks 10.0.0.0/8 #your private network if any
> trusted_networks 192.0.2.0/24 #your "internal" newtork if any
> ...
>
> if that's not enough, then it's an SA bug.
The reason SMTP AUTH is being used it because the client isn't in a
trusted network!
> >Having RFC-3848 support would mean that the Received headers for
> >authenticated connections can be distinguished ('ESMTPA' or 'ESMTPSA' in
> >the line) and ignored by SpamAssassin.
>
> only if trusted would that be helpful, as anyone can forge received
> headers. so you still need the trusted_networks.
SpamAssassin implements this correctly: this information (being
authenticated or not) is only considered for Received lines from
unstrusted IPs to trusted IPs (i.e. clients directly connecting to your
network). Those Received lines are written by your own server...
Wietse Venema
> Hi,
>
> Is support for RFC 3848 planned?
No.
> I am trying to figure out how to solve the problem that SpamAssassin at
> our site does check the originating IP addresses of mails sent by users
> with SMTP AUTH and sometimes gives SPAM-points because they are
> dialup adresses (and sometimes blacklisted too). This problem is
> described here: http://wiki.apache.org/spamassassin/DynablockIssues
This a good illustration of why filtering on IP addresses in RECEIVED
headers is a bad idea. Thanks for pointing me to this resource.
The proposed workaround, labeling the RECEIVED header with SASL
AUTH information is no good; SASL AUTH is needed only for customers
who submit mail from outside without TLS certificate authentication.
A principle in computer security is "do no harm". In this case,
the workaround harms innocent people. Meanwhile the spammers are
laughing all the way to the bank, because none of the above makes
the least difference for them.
> Having RFC-3848 support would mean that the Received headers for
> authenticated connections can be distinguished ('ESMTPA' or 'ESMTPSA' in
> the line) and ignored by SpamAssassin.
Let's spend our energy on fixing the right problem, instead of
building work-around upon work-around for one poorly-devised
anti-spam measure after the other.
That right problem would be a better way to authenticate the sender
domain, instead of the scheme that relies entirely on the last-hop
client IP address/helo information.
Wietse
mouss
>The reason SMTP AUTH is being used it because the client isn't in a
>trusted network!
>
>
I see now...
One way (won't work for everybody) is to use a specific instance (an
MSA) that rewrites the received headers. a bit ugly though. so having
explicit "support" is certainly better.
David Schweikert
> The proposed workaround, labeling the RECEIVED header with SASL
> AUTH information is no good; SASL AUTH is needed only for customers
> who submit mail from outside without TLS certificate authentication.
I guess that you could also mark as 'ESMTPSA' connections from clients
with a TLS certificate...
> A principle in computer security is "do no harm". In this case,
> the workaround harms innocent people. Meanwhile the spammers are
> laughing all the way to the bank, because none of the above makes
> the least difference for them.
I agree with you that the 'RCVD_IN_DYNABLOCK' rule (giving points to for
an IP being a dialup) is probably a bad idea.
Consider however also the other RBLs... Being on a dialup address means
that maybe you get an IP that has been blacklisted because somebody
before you did something bad with that IP (that actually is what
happened to a user of mine). Certainly using that RBL to reject messages
with Postfix would do more harm than giving SPAM points so that the mail
lands in a probably-spam folder, don't you agree?
Postfix knows this information, the question is how to transfer that
information to SpamAssassin so that it can use it.
> Let's spend our energy on fixing the right problem, instead of
> building work-around upon work-around for one poorly-devised
> anti-spam measure after the other.
I believe that RBLs implemented with SpamAssassin are much safer than
using them at the Postfix-level.
> That right problem would be a better way to authenticate the sender
> domain, instead of the scheme that relies entirely on the last-hop
> client IP address/helo information.
That would certainly help.
Jorey Bump
> Is support for RFC 3848 planned?
>
> I am trying to figure out how to solve the problem that SpamAssassin at
> our site does check the originating IP addresses of mails sent by users
> with SMTP AUTH and sometimes gives SPAM-points because they are
> dialup adresses (and sometimes blacklisted too). This problem is
> described here: http://wiki.apache.org/spamassassin/DynablockIssues
>
> Having RFC-3848 support would mean that the Received headers for
> authenticated connections can be distinguished ('ESMTPA' or 'ESMTPSA' in
> the line) and ignored by SpamAssassin.
I'm not sure if it's relevant to your situation, but in my setup,
authenticated users are not checked by SpamAssassin. They use MSA port
587 to submit mail. Even when the recipient is on my server, postfix
delivers without running the message through SA. Would this solve your
problem?
If you must use port 25, you can probably set up another
authentication-only instance of postfix on another IP without SA.
David Schweikert
> I'm not sure if it's relevant to your situation, but in my setup,
> authenticated users are not checked by SpamAssassin. They use MSA port
> 587 to submit mail. Even when the recipient is on my server, postfix
> delivers without running the message through SA. Would this solve your
> problem?
We are running SpamAssassin with procmail (so that users can choose if
they want to run it or not). I see however that your setup solves the
problem, thanks for the suggestion.
Wietse Venema
> On Tue, Oct 25, 2005 at 13:59:10 -0400, Wietse Venema wrote:
> > The proposed workaround, labeling the RECEIVED header with SASL
> > AUTH information is no good; SASL AUTH is needed only for customers
> > who submit mail from outside without TLS certificate authentication.
>
> I guess that you could also mark as 'ESMTPSA' connections from clients
> with a TLS certificate...
That would definitely be the spirit of RFC 3438, although the text
does not seem to acknowledge the existence of other authentication
methods.
o The new keyword "ESMTPSA" indicates the use of ESMTP when both
STARTTLS and SMTP AUTH are successfully negotiated (the
combination of ESMTPS and ESMTPA).
> > A principle in computer security is "do no harm". In this case,
> > the workaround harms innocent people. Meanwhile the spammers are
> > laughing all the way to the bank, because none of the above makes
> > the least difference for them.
>
> I agree with you that the 'RCVD_IN_DYNABLOCK' rule (giving points to for
> an IP being a dialup) is probably a bad idea.
>
> Consider however also the other RBLs... Being on a dialup address means
> that maybe you get an IP that has been blacklisted because somebody
> before you did something bad with that IP (that actually is what
> happened to a user of mine). Certainly using that RBL to reject messages
> with Postfix would do more harm than giving SPAM points so that the mail
> lands in a probably-spam folder, don't you agree?
The problem is to avoid applying the same RBLs to authenticated
users and random spammers.
- This can be encoded in the message (with ESMTPSA etc.) but the
code also needs to do the right thing with non-SASL authentication.
I am pretty much tied up for the coming days, so if someone has
an RFC 3848 patch that supports SASL and TLS I'd welcome it.
- This can be done by invoking different filters (or no filter for
authenticated users). For example by using the submission port for
original submissions and requiring some form of authentication,
ot by making this possible with smtpd_mumble_restrictions.
permit_mynetworks
permit_sasl_authenticated
permit_tls_clientcerts
reject_unauth_destination
reject_rbl_client ...
check_recipient_access static:"filter something:somewhere"
OK, we can't have quotes and spaces there, so it would have to be
an external access map but you get the idea.
Wietse
Robert Felber
> I believe that RBLs implemented with SpamAssassin are much safer than
> using them at the Postfix-level.
Depends how one uses them at the postfix level. Spamers don't actually care
if one reads spam. Nor do virus-sender. The ego-pushing effect for spammers
and virus sender is "denial of services/bandwidth-money" due to
spam/virus-load. SA doesn't target that. Because the damage is done, as soon
as the mail passes the peering router. Greylisting maybe be an option, it
targets zombie hosts only, though.
Exim has the option to give each restriction a point, postfix can provide
weighted restrictions via an policy daemon. Sender auth is hard to realize
though, especially when it shall not break forwarding and the like.
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
Ralf Hildebrandt
> configure your trusted_networks (in SA) explicitly and correctly. for
> instance
> trusted_networks 192.0.2.78 # your public IP
> trusted_networks 10.0.0.0/8 #your private network if any
> trusted_networks 192.0.2.0/24 #your "internal" newtork if any
> ...
>
> if that's not enough, then it's an SA bug.
Obviously, it's not from trusted_networks, but sent from UNTRUSTED
networks via SMTP AUTH!
--
Ralf Hildebrandt (Ralf.Hil...@charite.de) spam...@charite.de
http://www.postfix-book.com/ Tel. +49 (0)30-450 570-155
StGB SS328 Absatz 2.3: Mit Freiheitsstrafe bis zu fünf Jahren oder mit
Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht
Jason Haar
>Postfix knows this information, the question is how to transfer that
>information to SpamAssassin so that it can use it.
>
>
I've been lurking for a while, but this raises something I wanted to
know for other reasons. Can Postfix make available such "meta
information" regarding the relay-status of the client via environment
variables to its filters? Like Qmail does? This exact problem doesn't
happen in Qmail as RELAYCLIENT is always defined when the sender is a>
on a trusted network or b> has authenticated via one of the 10,001 %$#^&
patches it has.
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Wietse Venema
> David Schweikert wrote:
>
> >Postfix knows this information, the question is how to transfer that
> >information to SpamAssassin so that it can use it.
> >
> >
> I've been lurking for a while, but this raises something I wanted to
> know for other reasons. Can Postfix make available such "meta
> information" regarding the relay-status of the client via environment
> variables to its filters? Like Qmail does? This exact problem doesn't
> happen in Qmail as RELAYCLIENT is always defined when the sender is a>
> on a trusted network or b> has authenticated via one of the 10,001 %$#^&
> patches it has.
Have a look at "EXTERNAL COMMAND DELIVERY" in local(8) or
http://www.postfix.org/local.8.html
Wietse