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:
>  >
>  >> 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
>  >
>
> Nope, I discarded before it got to the mailscanner, before mailscanner
>  even touched it to forward it to the client server, becuase I implement
>  a discard list for known spammers I don't discard stuff I've previously
>  accepted...
>
This simply isn't what you've attested to using in this thread.
What you described was that your clients hosts rejected messages
previously let through by you, messages passed through your
MailScanner cluster, and that you discarded the resulting DSNs.
Now you say you don't do this? And that you (through some PSI-like
method:-) have created a list of "known spammers" that you discard out
of hand, and by that virtue cannot be affected by distributed
attacks/phenomena like the ones I mention?
Either you are changing the subject very deftly, in a manner I'm not
quite picking up, or you are trying very hard to avoid seeing a valid
technical point ... just because it doesn't suit your view of the
world.
Or perhaps I'm missing something vital here, it's been known to happen
that I've been a sloppy reader...:-).

Anyway, I've said it already... Your systems, you do whatever you
like. I just don't think it right... for anyone else;-).

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