OT: Sendmail REJECT or DISCARD preference

Peter Farrow peter at farrows.org
Mon Mar 31 22:54:27 IST 2008


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

P.



More information about the MailScanner mailing list