blank "is" report lines in syslog?

[Matt Kettler]

DAve wrote:

>>
>>
>> I for one am SOOO glad spamcop blacklists sites generating backwash.
>> In this day
>> and age blind-accepting mail queues are just as bad a smurf amplifiers.
>> Blacklist them all to hell until they clean up their act.
> 
> 
> We don't blindly accept messages. But we do send a bounce if the mailbox
> doesn't exist, or if the box is overquota, or if the message is too
> large, or delivery fails for any other reason. Some of these bounces
> will be after the connection and the message has been accepted.

Only overquota or "other reason" should be bounced post-accept.

Message to large should be failed at the end of the SMTP data phase.

Nonexistent mailbox should be failed at the SMTP RCPT TO phase.

Anything else is bad practice.

The problem is if you're doing post-delivery bounces for Nonexistent mailboxes,
your server is effectively an open relay that spammers can abuse.

This is the behavior I meant by "blind accepting mail queues".. The server will
blindly accept any message to the local domain, even for nonexistent users.
Spammers can abuse this as a relaying method by sending to a known nonexistent
user. The return-path is the spammers intended recipient. This is called
"reverse NDR" style spam relaying.


If a spammer uses your box for reverse NDR spam relaying, IMHO you're a spam
relay and should be treated the same as an open relay operator.


I know that's a bit harsh, but the reality is that while post delivery bounces
for nonexistent users are RFC legal, so is open relaying. Both are just
insecurity problems and bad practice, but both provide spammers the same tools.

> Email requires post-smtp bouncing, not just because of RFCs, but to work properly. But I won't go further as this has been torched in all directions on many many lists. 

I agree 100%.. We do need post-delivery bouncing.

I just think that post-smtp bouncing should not be used when it could be
prevented by properly validating the recipient mailbox at SMTP time.