OT: Sendmail REJECT or DISCARD preference

[Glenn Steen]

On 31/03/2008, Peter Farrow <peter at farrows.org> wrote:
> Matt Kettler wrote:
>  > Peter Farrow wrote:
>  >> Matt Kettler wrote:
>  >>> Peter Farrow wrote:
>  >>>
>  >>>>> Steve.
>  >>>> If you reject,  and its spoofed you'll get it back anyway, so you
>  >>>> end up receiving and then storing it in the postmaster address, it
>  >>>> is always best to discard in this scenario...or even worse bouncing
>  >>>> it again
>  >>>>
>  >>>
>  >>> Stop confusing REJECT with post delivery bouncing :) See my other
>  >>> post in this thread.
>  >> I am talking about sendmail access file entries at the MTA level....
>  >> nothing else...my point is the general notice supplied in the REJECT
>  >> directive often ends up coming back round...I've seen it many times..
>  >
>  > That's exactly what I'm talking about. I've got several such entries,
>  > and I've never seen any of them come back. ever.
>  >
>  > There's something seriously wrong with your mailserver if this is
>  > happening.
>
> This is how it works:
>
>  Someone sends a spoofed spam email to one of my clients the other side
>  of my mailscanner, but they get the address wrong.
Why did you accept this mail for relay in the first place?
This is where you go wrong, all the rest is purely your own fault...
If one were in the blame-game:-):-).
I'm not, I'm more interrested in you getting this right, and beleive
me... this will make a marked difference for you.
The problem is simple: You are the public MX for these customers, but
you don't know their "email address universe". You need setup a method
that ensure you do.

Since you have a multitude of customers with diverse mailservers,
probably a very varying level of competence (theirs, not yours:-) etc,
it's probably not feasible to use specific methods like an access or
relay recipient map file. You'll have to resort to addre4ss
verification by way of a call-ahead. How to do this varies a bit
depending on your MTA.
Please note that this is _recipient_ verification, not sender
verification. Fortunately, free tools like smf-sav can do this for
sendmail... others (like postfix) have builtin abilities.

Without proper verification, you will indeed be "inundated" with
backscatter to backscatter... And rightly so. Using DISCARD is simply
wrong. It's the ostrich approach to the problem:-).

>  The mailer daemon on the client server rejects the email, (I am the
>  postmaster for my clients Linux server) with user unknown,
>
>  -- But the address is spoofed so it goes back to the wrong person (back
>  scatter), The mail system rejects the back scatter for various reasons
>  (user known mailbox full etc etc etc) so this bounce comes back to the
>  postmaster of the client machine which goes to my postmaster mailbox.
>
>  If I simply DISCARD the email at the mailscanner the process is stopped
>  completely.
Yes. But the process should never have started in the first place.
This explains the difference in view Matt Kettler expreses vis-a-vis
your view.

>  If the mailer daemon REJECTS the message on the mailscanner or the
>  client server,  I get it in the postmaster mailbox as per the reason
>  above because I am also the postmaster there as well...
You should REJECT the first unknown recipient. Then there will be no
following problems to solve.
And that one need be a REJECT if you care anything for the RFCs. If
that one is a DISCARD you have taken complete responsibility for that
message, and need inform the recipient that you have done so... Which
might be OK in some situations (log summary enough? OK!), but not so
in others. Your suituation will of course be different from mine, but
I caqn (by law, not RFC;-) never do such a thing.


>  So DISCARD is the best way forward.
Nope. You are dead wrong on this account.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se