OT: Sendmail REJECT or DISCARD preference

[Glenn Steen]

On 31/03/2008, Peter Farrow <peter at farrows.org> wrote:
> Glenn Steen wrote:
>  > On 31/03/2008, Peter Farrow <peter at farrows.org> wrote:
>  >
>  >> Matt Kettler wrote:
>  >>  > Peter Farrow 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.
>  >>  >>
>  >>  >> The mailer daemon on the client server rejects the email, (I am the
>  >>  >> postmaster for my clients Linux server) with user unknown,
>  >>  >
>  >>  >
>  >>  > Well, duh. That's because the REJECT isn't being implemented at the
>  >>  > MX, but a downstream server.
>  >>  >
>  >>  > In order to avoid the postmaster issue you *MUST* implement this at
>  >>  > all of the MXes for the domain.
>  >>  >
>  >>  > Of course it will cause the problem if a downstream server does a
>  >>  > REJECT, because it's being REJECTED after your server accepted it.
>  >>  >
>  >>  > However, this doesn't make REJECT bad, it just means the REJECT needs
>  >>  > to be implemented on YOUR server, not your clients.
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>
>  >> So *duh* no config error then.....
>  >>
>  > Please keep this civil, Matt&Peter.
>  >
>  >
>  >>  And thus having a valid postmaster address makes the final machine RFC
>  >>  compliant,  which means that you won't end up on blacklists like
>  >>  RFC-ignorant...
>  >>
>  > ?
>  > Sorry, but I fail to see what this has to do with your issues.
>  > Please read my previous post. It is meant in as a very friendly nudge
>  > to do the right thing.
>  >
>  >
>  >>  As I was saying in this scenario a discard is far superior, because, as
>  >>  I am paid to do I keep the rubbish from even reaching the client as I
>  >>  said in the first place, and, as I have 100's of client servers after my
>  >>  cluster of mailscanners its not feasible nor what the clients what to be
>  >>  configured the same as everyone else.
>  >>
>  > No, the only correct solution for you does not contain any such
>  > "streamlining" of configuration. All that is needed is for your
>  > cluster to call ahead to each individual receiving server (the ones at
>  > your customers;-) to ascertain that they will in fact accept these
>  > messagees for these recipients... It might not core terminally
>  > misconfigured (client) mailstore systems, but ... it will cut it down
>  > enormously. And your MailScanner systems will have less messages to
>  > wade through. All in all, correctly done, recipient address
>  > verification will earn you money. And your clients will not even know
>  > that you do it, unless they are log jockeys/junkies (like us:-).
>  > At least consider the possibility that we might have a clue here;-).
>  >
>  >
>  >>  So, in short DISCARD it is then.
>  >>
>  > Nope.
>  >
>  >
>  >>  Glad you got there in the end...  :-P
>  >>
>  > Still not there :-D
>  >
>  > Cheers
>  >
>
>  >>>And your MailScanner systems will have less messages to
>  >>>wade through
>
>
> When I discard it never reaches the MailScanner its done at MTA level...so there is no wading here...
>
Yes there is.
You accepted the first message, the one later rejected. You passed
that through MailScanner. You passed it on to your "unsuspecting
client", who _then_ rejected it.
If you had called ahead _prior_ to passing the first message
intoMailScanner you would've avoided ever handling the message....
Past the initial reject.
So you spend a few resources, you gain a lot of resources (never
used.... Remember that MailScanner is pretty hungry, compared to an
address verification call).
When you get hammered with a so-called dictionary attack, joe-job or
whatever... this will count.

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