OT: Sendmail REJECT or DISCARD preference

[Peter Farrow]

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...


P.