OT: Sendmail REJECT or DISCARD preference

[Matt Kettler]

Peter Farrow wrote:
> 
> 
> Steve Campbell wrote:
>> Since we're hitting the access file pretty hard today, I thought I'd 
>> ask a question about what most might put in there.
>>
>> I typically use the DISCARD parameter instead of the REJECT, with the 
>> reason being I don't want to add to the trash on the web. What do most 
>> use here and am I correct in thinking that DISCARD is less bandwidth 
>> and CPU intensive?

DISCARD is more CPU and resource intensive, as it occurs after the DATA phase. 
You have to recieve the whole message to DISCARD it.

REJECT occurs prior to the completion of the SMTP transfer, generally at the 
RCPT TO: command. If you can do it here, this is a *MUCH* better idea.

>>
>> Thanks for any thoughts.
>>
>> Steve
>>
> 
> DISCARD every time... because if its spoofed you'll only get it back in 
> your postmaster account....

Um, this is rejecting during the SMTP session, not bouncing after delivery. The 
two concepts are very different.

If you REJECT at the sendmail layer, a SMTP 550 is generated and the sending 
server will get it in THEIR postmaster box (assuming that it really is a server. 
if it's a spambot it vanishes into the ether). It will not end up in your 
postmaster box. Ending up in your postmaster box is what happens when you bounce 
email on a post-delivery basis, which is not the same as REJECT.

Bouncing is stupid, rejecting with a 5xx error at the SMTP layer is not.

Quite frankly REJECT is the proper and best behavior. It does not generally 
create backscatter, and when it does, all the backscatter is sourced by the 
single server that is sourcing or relaying the spam. Bots won't backscatter at 
all with rejects, as they don't retry or queue mail.

Rejecting reduces the typical DDoS nature of backscatter to a single-source 
problem that can easily be handled by blacklisting the server that's the spam 
source. (unlike post delivery bouncing, those messages will come from servers 
all over the world)


Rejecting also has exactly the same consequences as email being sent to an 
invalid recipient and having your mailserver 550 that. This is normal, and how 
nearly every intelligent SMTP server (baring unpatched qmail) behaves.