ietf-smtp
[Top] [All Lists]

Re: OT: 5xy - Do we need a "I MEAN IT!" do not retry response code?

2007-05-02 06:12:52

Peter J. Holzer wrote:
On 2007-05-02 05:28:16 -0400, Hector Santos wrote:

My guess is that this is about maintaining the database of mail
addresses, not about sending individual messages.

For the mailing-lists which I maintain manually, I do something very
similar: If I get a bounce, I look at the reason. If its something like
"no such user" I immediately unsubscribe the address from the list; but
it's "mailbox full" or "procmail exited with unknown code 42" or
something like that I assume that the user is going to fix the problem
and unsubscribe them only if the problem persists for a few days.

So that looks like that software is actually trying to clean up the
database with reasonable heuristics.

Right, this emailer made some comments about do manual inspections as you say. Feedback is important to them - that includes irregular bounces.

I didn't catch well what it meant by "hard and soft bounces" and "BounceBack Messages?" Does that main a real accept/bounce transaction or a 5xy response? or both?

I'm not sure either. "hard and soft bounces" could be either 5xx and 4xx
respectively, or a "soft bounce" could be a "couldn't deliver for $n
hours, will keep trying" message.

It kind of sounded to me that hard was "for sure rejects" at the SMTP level, and soft being "Bounceback Messages" or NDNs. But in either case, it tries 3 times before it moves the email address to the do-not-send list. :-(

"BounceBack Messages" are probably NDNs. I find this interesting,
because it means that to use this software (or at least this feature)
the spammer has to use a genuine reverse-path.

It went into great length about CAN-SPAM compliance, using valid return paths for obtain important feedback into its email campaign tracking.

It even showed somewhat of an aggressive position a few times about not tolerating blocks citing CAN-SPAM, that it will carefully scanning their logs for blocks and undetected bounces, contacting operators when they find the blocks.

It had a few other interesting points regarding "Optimizing E-mail Deliverability" delivery, mostly RFC 822 related, this one related to 2821.

Oh hell, maybe others will find the "Spammer Insights" interesting, here's the JangoMail web site.

   http://www.jangomail.com/documents.asp

PS: What attracted me to them was their press release regarding its new DKIM support. All emails will be signed with DKIM now, which should strike a nerve with Dave Crocker (at least it should) because of their erroneous claims such as:

    Email messages signed with DomainKeys and DKIM are guaranteed to
    be unaltered in transit and from the claimed Sender.  They are
    treated differently by receivers like Yahoo! Mail and GMail and
    will help with delivery to the Inbox.

Yeah right, guaranteed?  help with delivery?

Anyway, different WG!

--
HLS