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
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 22.214.171.124 has
no valid Reverse DNS. Please contact your ISP for further
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