OT: Sendmail REJECT or DISCARD preference

Glenn Steen glenn.steen at gmail.com
Mon Mar 31 19:44:48 IST 2008


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
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se


More information about the MailScanner mailing list