ietf-smtp
[Top] [All Lists]

Re: slight update to draft-macdonald-antispam-registry

2011-05-11 09:13:09

No argument from me here (and your other post). DNS based RBL has been a very controversial issue. But in this day of massive abuse, with not much else to go by, it has help, popular and yes, even hurt legitimate senders.

In my experience though, the good guys generally do make the next move to get it corrected. I never got a call from a bad guy. :)

I think you are right that many of these codes labeled as "Anti-Spam" Extended codes do fall under different categories some which are perfectly reasonable and may reflect a configuration issue, temporary DNS related issues. Just the other day I got a DSN for a list member in our support group send after repeated exhausted attempted where he was the only one issuing a MAIL FROM response:

 C: MAIL FROM:<listadmin(_at_)winserver(_dot_)com>
 S: 452 4.1.0 Policy violation. Your host 208.247.131.9 has
no valid Reverse DNS. Please contact your ISP for further information.

when in fact it does PTR records. So the member hosting system had some temporary DNS issue of course, the member informed and problem fixed. Not quite the right codes IMO, a waste on our system retries, but ultimately resolved.

---

Keith Moore wrote:
On May 10, 2011, at 2:55 PM, Hector Santos wrote:
Finally, this is a subject of opinions.  IMV, the I-D extended responses are 
focused for bad guys rejects, not good guys rejects except for the new X.8.26.

So in general, for my own system, I don't particular like to give bad guys 
"clues" why their transaction failed.  For false positives, it can help the 
support process in a DSN, but for bad guys, its not like they will listen to them anyway 
or even get them or maybe redirected to someone else. They are going to blast away anyway.

So if you can extract how these "bad guy" transaction rejection responses can 
help good guys solve a particular problem, more readers will consider it.

The problem I have with this argument is that blackhole lists, in my 
experience, cause a large number of legitimate messages to fail to be 
delivered.   I don't think it's reasonable to assume that just because a 
message fails some third party's arbitrary criteria, that the problem is with 
the sender (or purported sender) of the message.

In other words, sometimes the "bad guy" is the sender, and sometimes it's the 
blackhole list.

Keith

--
Sincerely

Hector Santos
http://www.santronics.com