Jeff Macdonald wrote:
On Tue, May 10, 2011 at 2:55 PM, Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
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.
I've heard that argument before, in which these help the bad guys. I
honestly think the bad guys already know these details without having
these codes. So yes, it would confirm what they already know. But in
no way do I think this will empower the bad guys.
Well, we don't know either way but we have to presume its available
for someone, somehow or not. You have low margin, high volume spammers
using simple, low to no cost, low compliancy clients who will blast
things regardless of reply codes and you have those who use proper
clients who will naturally follow SMTP and also leverage feedback for
their success reporting. If you read many of the current DMA (Direct
Marketing Association) and related trade groups blogs, eMarketing
recommendations, you will read they have finally learned its better to
prune out the email addresses that don't make it.
The difference with the new X.8.26 is that its not really in the same
category with many of the others as it effects both bad and good. You
have many people in the WG like this one who were totally against GL
and today you find them using it. I was one of them that saw very
quickly of its value.
I do have another update pending incorporating the text that was
suggested before. But it does seem that:
" assigning these codes helps troubleshoot problems and lower
support costs by allowing sending administrators to resolve
many problems themselves."
isn't verbose enough to get the point across to receivers.
Example of the "problems" and how it may lower support cost would be good.
There are some codes there that can help with configuration problems,
like X.8.25, and others that might be related to compliancy, like
x.8.4, .5, .16, .17.
Also, maybe related, yesterday we got a customer (fed/state/city
politics newsletters agency) reporting a problem sending to AOL
addresses with this DSN:
<xxxxx(_at_)aol(_dot_)com>: host xxxx.xx.zzz.aol.com[#.#.#.#] said:
552 5.3.4 E4.3 REQUESTED MAIL ACTION ABORTED: HEADERS EXCEED 32K
BYTES OR
RECORD TOO LONG (in reply to end of DATA command)
It turned out, so it seems, the To: line was huge with hundreds of
continues lines filled with addresses. That could also fall under x.8.5.
Also, one other category (Alert Status) perhaps to consider per code
to provide insight on what codes are good candidate for internal
reporting, feedback to operators, red "alert status", etc, so when the
receiver detecting a reason for example x.8.11, it can provide a
suggestion about the severity of the detection:
Code: | X.8.11
Sample Text: | IDENTITY has been compromised
Alert Status:| HIGH, Operator should be notified
--
Sincerely
Hector Santos
http://www.santronics.com