blank "is" report lines in syslog?

[DAve]

If I had someone to just stand behind me and beat me on the head with a 
bat, I could save all this typing, and I would never have to answer the 
phone. The result at the end of my day, would be the same.

Matt Kettler wrote:
> 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.
> 
>