Page History

...

Note: The problem described was fixed in version 3.0.2. However, some MTAs such as Postfix don't support RFC 3848 and will therefore still exhibit the described problem (which you since SpamAssassin won't be able to correct by looking for authentication tokens since there aren't any, at least in Postfix).automatically trust authenticated users if the MTA doesn't leave a supported authentication token in the relay's Received header.

Update Wiki Markup*Update (2006-07-14): Postfix 2.3 includes support* for adding its own style of authentication info to its received headers by setting 'smtpd_sasl_authenticated_header = yes' , which is disabled by default, in your Postfix config. *SpamAssassin 3.1.4* and later includes support for this Postfix auth info. Also see \[http://blog.madduck.net/geek/2006.06.30-postfix-auth-anonymisation this blog post\].Postfix Quickfix: Get latest versions of Postfix (at least 2.3.0) and SpamAssassin (at least 3.1.4) Add smtpd_sasl_authenticated_header = yes to the Postfix config. With that set, SpamAssassin should catch such authenticated emails as ALL_TRUST, bypassing possible SPF and RBL problems.

\["madduck"\]: This will not fix TLS-authenticated sessions. See also \[http://dev.riseup.net/privacy/postfix/ this patch\] which munges the Received headers.  \["DarylOShea"\]: This should work to avoid the Dynablock problem in this specific situation but isn't recommended since it destroys the audit trail provided by the Received headers.

This is another Dynablock-related issue. If:

...

then their message will still be hit by RCVD_IN_DYNABLOCK, because it's an SMTP connection from a DYNABLOCK-listed host, directly to your mail server. SpamAssassin doesn't know that it was an authenticated connection.

To avoid this, you should As a workaround only for MTAs that either don't supply any auth tokens or don't supply auth tokens supported by SpamAssassin (if they're not already supported the devs don't know about them – let us know), you could add a custom , local rule which that matches the Received header format which that your mailserver adds for successfully-authenticated connections. For example, if your mail server adds this line for an authenticated client:

  Received: from 192.168.2.125 (CPE0004e24b9419-CM000a7365d82c.cpe.net.cable.rogers.com
      [63.139.187.25]) (authenticated (0 bits)) by services04.student.cs.uwaterloo.ca
      (8.11.7/8.11.7) with ESMTP id hA41X1B23955 for <recipient@example.org>; Mon,
      3 Nov 2003 20:33:03 -0500 (EST)

Then you should could define a rule like this:

  header LOCAL_AUTH_RCVD    Received =~ /\(authenticated \(\d+ bits\)\) by services04\.student\.cs\.uwaterloo\.ca /

...