RE: Lost of FPs because of IPs listed in DUL +

[Jens Benecke <je...@spamfreemail.de>]

Chris Thielen wrote:

> Jens Benecke said:
>> Chris Santerre wrote:
>>
>>> WHy would you want to recieve email from dialup IPs??
>>
>> Because otherwise my users would complain. They have dialup IPs. Doh.
>>
>> And because I want to be able to receive mail which went DUL -> ISP1 ->
>> ISP2 -> my server. This currently gets scored by SA which (IMHO) is
>> wrong. 
> 
> Pardon my ignorance, but isn't the scenario above exactly the same as a
> "typical" mail transaction?  

Yes. And if the first IP is listed as an open relay, it gets tagged as SPAM.
Even if the user that has the IP is no open relay, but a _different_ user
that _had_ the (dynamic) IP a couple weeks ago _was_.

That is my problem. It can only be fixed (IMHO) by seperating open relay
lists on dynamic and static IPs.

> From what I understand, SMTP AUTH can be used 
> to allow users to send mail through your server from outside your server's
> configured "trusted" netblocks.  

Yes. And because my "trusted" block consists only of 127.0.0.1, everyone
*has* to use SMTP AUTH or he can't relay.

> However, since your trusted netblock 
> configuration are not visible to the outside world wouldn't an
> authenticated Received list look exactly like a "non-authenticated but
> inside the trusted block" Received list?

No. qmail actually puts "Received ..... by (username@host)" in the headers
if it was authenticated. And all my usernames have a "user@domain"
structure, where "domain" is one of the couple hundred domains I host. So I
have "Received ... by (username@domain@kiste.hitchhikers.de)" in the
headers and that's what I currently look for.

It's weak, I know. But otherwise my users would get punished for using
dynamic IPs, by _my_ spamassassin. (This problem is unrelated to the one I
talked about above, btw). And I don't know how to differentiate between
known SMTP AUTH users using dialup IPs and unknown SMTP users sending via
dialup IPs - yet.
 
>> Unfortunately, qmail doesn't really mark the useage of SMTP AUTH in the

actually, it does (see above) but weakly.
 
> Additionally, even if qmail did indicate that the transaction was via SMTP
> AUTH, SpamAssassin really couldn't trust that information in the Received
> line.  A spammer could simply inject a fake Received line with the AUTH
> markup.  SA really can't trust any headers other than those that the end
> MTA (or any configured trusted servers) have added, right?

Yup.

I need a way to find whether my header is the _first_ Received: header. But
then I'd punish people who have their SMTP local server configured to relay
via mine (which can be perfectly legitimate if they have an account).


-- 
Jens Benecke (jens at spamfreemail.de)
http://www.hitchhikers.de - Europaweite kostenlose Mitfahrzentrale
http://www.spamfreemail.de - 100% saubere Postfächer - garantiert!
http://www.rb-hosting.de - PHP ab 9? - SSH ab 19? - günstiger Traffic

RE: Lost of FPs because of IPs listed in DUL +

[David B Funk <db...@engineering.uiowa.edu>]

On Thu, 5 Feb 2004, Jens Benecke wrote:

> Yes. And if the first IP is listed as an open relay, it gets tagged as SPAM.
> Even if the user that has the IP is no open relay, but a _different_ user
> that _had_ the (dynamic) IP a couple weeks ago _was_.
>
> That is my problem. It can only be fixed (IMHO) by seperating open relay
> lists on dynamic and static IPs.

For your own site you can fix this, create a meta-rule that says:
if RBL_DUL && RBL_PROXY-RELAY then give a negative score to adjust things.

> > Additionally, even if qmail did indicate that the transaction was via SMTP
> > AUTH, SpamAssassin really couldn't trust that information in the Received
> > line.  A spammer could simply inject a fake Received line with the AUTH
> > markup.  SA really can't trust any headers other than those that the end
> > MTA (or any configured trusted servers) have added, right?
>
> Yup.
>
> I need a way to find whether my header is the _first_ Received: header. But
> then I'd punish people who have their SMTP local server configured to relay
> via mine (which can be perfectly legitimate if they have an account).

Just customize your MTA to add a private locally unique header for
SMTP-AUTH connections and either bypass your SA filtering in that case
or trigger a local whitelist score.

If you were using sendmail & milter it would be pretty easy to do, as
the AUTH information is avalable to the milter.


-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

RE: Lost of FPs because of IPs listed in DUL +

[SA-LIST <sa...@vta.com>]

>No. qmail actually puts "Received .....
by (username@host)" in the headers
>if it was authenticated. And all my
usernames have a "user@domain"
>structure, where "domain" is one of the
couple hundred domains I host. So I
>have "Received ... by
(username@domain@kiste.hitchhikers.de)"
in the
>headers and that's what I currently
look for.

>It's weak, I know. But otherwise my
users would get punished for using
>dynamic IPs, by _my_ spamassassin.
(This problem is unrelated to the one I
>talked about above, btw). And I don't
know how to differentiate between
>known SMTP AUTH users using dialup IPs
and unknown SMTP users sending via
>dialup IPs - yet.

>>> Unfortunately, qmail doesn't really
mark the useage of SMTP AUTH in the

>actually, it does (see above) but
weakly.

>> Additionally, even if qmail did
indicate that the transaction was via
SMTP
>> AUTH, SpamAssassin really couldn't
trust that information in the Received
>> line.  A spammer could simply inject
a fake Received line with the AUTH
>> markup.  SA really can't trust any
headers other than those that the end
>> MTA (or any configured trusted
servers) have added, right?

>Yup.

>I need a way to find whether my header
is the _first_ Received: header. But
>then I'd punish people who have their
SMTP local server configured to relay
>via mine (which can be perfectly
legitimate if they have an account).

For any mail SMTP_AUTH'd by your local
system and outbound, you might be
able to set up a separate SMTP deamon
which accepts SMTP_AUTH connections
exclusively, and only relay non-DUL
local trusted networks on your
"original"
SMTP daemon. It seems you're using qmail
( i don't) but with Sendmail and
MIMEDefang
you could pass Sendmamil Macros (such as
${if_addr}) to a filter to determine
how, if , and from where a connection
was authenticated, and use this
information
to adjust the score accordingly. I
suppose you could additionally get
really
creative(?) and mangle the headers of
SMTP_AUTH'd messages so that the
DUL footprints of outbound mail
dissappear to foreign mail systems, but
methinks
that's probably about as Evil as
self-modifying code. :)