[milters] Archive

Lists Index Date Thread Search

Article: 1020
From: Taylor, Grant
Date: 2006-07-10 10:49:32 -0400
Subject: Re: Merits of milters

Removal...........: milters-request@milter.info?subject=remove
More information..: http://www.milter.info/#Support

G1OGY (Dave) wrote:
> Perhaps I over-doubled.  
> Spam (c/w forged & incorrect rtn addr) -> TARGET -> DSN (ie:over quota/gone
> -> g1ogy.com MX -> local processing -> mail-store -> DSN invalid user

In this scenario, the inbound (bounce) DSN will be from the Null Reverse Path address,
which Sendmail will (by default) never bounce.  I think one of us is completely mis
understanding the other.  Given the way that this morning is going, it is likely me.

Presume the following scenario:

MAIL FROM:<spoofed_address> TO:<some_address> is sent by spammer
MAIL FROM:<spoofed_address> TO:<some_address> is bounced by receiving server
for <some_address>
MAIL FROM:<> (Null Reverse Path) TO:<spoofed_address> DSN is sent by receiving
server for <some_address> back to <spoofed_address>
MAIL FROM:<> (Null Reverse Path) TO:<spoofed_address> DSN is found to be junk
by receiving server for <spoofed_address> and not accepted in by.
MAIL FROM:<> (Null Reverse Path) TO:<spoofed_address> DSN is dropped by
receiving server for <some_address> as it can not bounce a bounce.

> On the mailstore in the SPAM, SPAM10 or SPAM20 mailboxes (and yes! legit mail 
> with a score of 10+, while not commonplace, does occur for some users)

I too have had valid mail being caught as spam for some reason.  Usually the sender has
done something like use M$ Word to compose HTML, or some other stupidity like that.

>>> Obviously, sendmail is not capable of scrutinising mail
>>> bodies too closely thus the new plan is, in order:
>> What are you wanting / hoping that Sendmail will / would do /
>> scrutinize?  
> I'm not, it won't.

Ok...  From your original wording I mistook it that you were hoping that Sendmail would be
able to do something.  I was just trying to figure out what you were wanting.  But if it
was my misinterpretation...

> I'm not in favour of /dev/null 'cos there's a gotcha there: "YOU deleted ~MY~
> Whereas "I didn't like the look of it so I didn't let it in, 'security'. You
> really doesn't get you much kick back.

Let me rephrase what I'm routing to /dev/null.  Before I even let email in to my new
server I am preforming sender validation.  That is to say that I'm verifying that there is
a server somewhere that is willing to accept a  message for the sending email address
(plus a few other sanity checks).  I also run all my spam tests during the SMTP
Transaction so that I have the ability to refuse to accept a message with a 550-5.7.1
response code if I think that it is SPAM.  This way I am not accepting messages and then
deleting them.  The only thing that I'm doing (arguably some what contradictory to that
last statement) is on my old server forwarding any postmaster@ or abuse@ messages for the
domains that are still on the old box to my main postmaster@ and abuse@ accounts.  So the
only time that I see a double bounce scenario is if a bounce does come in to my old server
to one of these forwarded accounts that is not accepted by my new server.  In this case my
old server can not forw
ard a bounce, nor can it bounce the bounce.  In this rare case, yes I am then sending
those few messages to an account that is routed to /dev/null.  However in monitoring the
accounts for multiple months before setting up the direct route to /dev/null I NEVER saw
any valid messages flowing through that route.  I literally watched multiple thousand back
scatter DSNs flow through and in to a mail box that I was checking before manually
deleting.  I am very comfortable with this method, especially for the short time that I
will still have the old server on line.  On the new server this is not an issue because I
am doing the filtering before the messages are accepted.

Grant. . . .

Lists Index Date Thread Search