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