OT: Sendmail REJECT or DISCARD preference

[Steve Campbell]

Peter Farrow wrote:
> Matt Kettler wrote:
>> 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.
>>
>>
>>
>>
>>
> Well, actually my practical experience says exactly the opposite, I 
> have quite an extensive evolved access list on my sendmail MTA with 
> over 1000 discards in it.  Once this was implemented it greatly 
> reduced to cr*p that was ending up in the postmaster addresses.  So I 
> still disagree, discard works best for me across my enterprise, 
> however I would add that my enterprise is probably atypical to most in 
> that I process nearly a million emails per week....
>
> All this discussion has certainly made me think again about it so its 
> not all bad...
>
> Regards
>
> Pete

Pete,

I have to agree with you on your "thinking" part. I sort of ask this 
question originally to verify what I thought I knew to be fact, but as 
usual, I'm having to rethink my conceptual ideas.

I did try to change all of my DISCARDs to REJECTs to see if there was an 
immediate difference. I seem to have a small problem of slowness 
whenever I get bombarded with hundreds of spams. Today was a good day to 
test my changes, as I had quite a few in incoming, and was already 
monitoring my LA. I was hoping to see my backup of incoming messages 
drop a little faster along with a reduced LA once I used REJECT based on 
the fact that I would spend less time on new emails arriving for the 
incoming queue. After rehashing the access file, it showed no 
improvement, so I'm not sure whether there is an advantage or not, so I 
changed them all back to DISCARDs. Only for the simple reason that 
Friday is not a good day to make changes and leave for the weekend.

I have to thank everyone, though, for all of the thought provoking ideas.

Steve