[milters] Archive

Lists Index Date Thread Search

Article: 1023
From: G1OGY \(Dave\)
Date: 2006-07-10 19:56:30 -0400
Subject: Re: Merits of milters

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

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

Not all of it - 'cos it has all been quite weird.  
And as this conversation is getting a bit circular allow me 
to briefly further describe the situation I found myself in.

From home I run a pair of 'vanity' web sites dedicated to my hobby
and also host for a couple of local (charitable/non-profit) organisations
and another of my (hobby) group.
(What I do for a living is allied, in 'IT', but broader based).

Things chug along here adequately, there is no pressure and mail volumes 
are low, with only 10 users.  I hardly need to touch the kit.

A disk space alarm along with some 'speed' complaints prompted a look at 
the logs and 'root' mail on the MX where I found 5008 (really!) 
"Mail Delivery Subsystem   Postmaster notify: see transcript for details"
messages. In a few days!

I had had the fortunate opportunity of being selected as a return-address for
first, the Wataire spam, then a bunch of porn/click-throughs, then a trojan, 
now more stock spam, Oh! and another pump & dump.  Great!

These were the final 'Postmaster Notify messages' that had been derived, largely
as you suggest BUT (as implied previously) the MX is not the mailstore and
doesn't know who the users are.
So I was getting bounced by myself. (Though I'm sure that there were some that 
came in twice.....)
I had presumed that the MX would re-bounce the mailstore's bounce back to
the bouncing, foreign MAILER-DAEMON (NULL Path) on the basis of, eg:

From: Mail Delivery Subsystem <G-MAILER-DAEMON@pe6100.g1ogy.com>
To: postmaster@pe6100.g1ogy.com
Subject: Postmaster notify: see transcript for details
   1     Shown     13 lines  Text
   2     Shown    379 bytes  Message, "Delivery Status"
   3     Shown    3.5 KB     Message, "Delivery Status Notification (Failure)"
   3.1   Shown      8 lines  Text (charset: unicode-1-1-utf-7)
   3.2   Shown    191 bytes  Message, "Delivery Status"
   3.3   Shown    1.6 KB     Message, "session"
   3.3.1 Shown     23 lines  Text (charset: Windows-1252)

But, having read your explanation, it seems I'm wrong (I've been wrong before,
once) and my MX does not re-send to the original bouncer and I've mis-interpreted 
the 3 Delivery Status stanzas in the summary.

Nevertheless, it has been (as still IS!) highly irritating and milter-null
was, as Anthony explained, the way to deal with it and sent me a pre-release to try.

And it does.

The (original) problem is also exacerbated when the bouncing server (and mine, until your
recent post about `nobodyreturn`) sends
the whole virus-laden mailbomb out with the bounce.  (And then there are those misguided
souls to appear to add a payload of their
own....  but I can understand the frustration)

So I will join you in your mission to encourage EVERYONE set their mailserver's own
flavour of `nobodyreturn`, if you'll accept the
assistance ;)

Thanks for your wisdom


> 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~ mail!?" Whereas "I didn't like the look of it so I
>> didn't let it in, 'security'. You know?" 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