You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2004/11/28 07:05:28 UTC

[Bug 2462] detect SMTP AUTH to avoid dynablock FPs on legit msg submission

http://bugzilla.spamassassin.org/show_bug.cgi?id=2462





------- Additional Comments From spamassassin@dostech.ca  2004-11-27 22:05 -------
Correct me if I'm wrong, but 'changing' the _first_ untrusted relay into a
trusted relay when "(authenticated" is found between the 'from' and 'by' info
should take care of the problem.

We can do this since we (hopefully) trust our own server to only add
'authenticated' when the relay (whether it's an MUA or even another MTA) is in
fact authenticated.

Sendmail and MDaemon adds this authenticated line by default.  I believe Exim
needs to be configured to add the authenticated line.


Example of an auth'd email directly from an MUA to a system's one and only mail
server:

Received: from mycomputer (dynamic-ip.isp.net [1.2.3.4])
        (authenticated user/bits/whatever)
        by ourdomain.com (smtp.ourdomain.com [5.6.7.8])
        with whatever
        for <whoever>; Some Date
From: authenticateduser@wherever.com
To: localuser@ourdomain.com
Date: Whenever
Subject: blah!


You can't forge the above (since you'd only look at the first untrusted relay
received header, which is going to be added by your own server), so long as your
server isn't wide open and authenticating anyone who asks.


>From Justin Mason  2004-03-29 11:26
> There are no other Received hdrs.  By the rules of notfirsthop, we *HAVE* to 
> use that IP for the Dynablock lookup, as you yourself describe.

Of course, since we trust this host authenticated relay we *DO NOT HAVE TO* use
that IP for Dynablock lookup.  We only have to do dynablock lookups when there
is a single received header and that user isn't auth'd since it could be a spam
host zombie/etc connecting directly to our MTA sending mail for us.

In fact, if there's only the single received header (which will be the case most
of the time, and maybe we should only convert the auth'd relay to a trusted
relay if there would normally only be a single relay -- there are cases when
there are multiple relays with the first untrusted one auth'd), ALL_TRUSTED
should fire and we could really short circuit, someday.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.