[Top] [All Lists]

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

2011-05-11 05:37:15

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

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[#.#.#.#] said:
    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


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>