ietf-asrg
[Top] [All Lists]

Re: [Asrg] Mailing list signup handshakes

2008-11-29 12:31:58

On Nov 29, 2008, at 9:20 AM, Michael Thomas wrote:


Even if you could do something clever here, would it make much if
any operational difference? I got the impression from Mark Delany at
Y! that mailing list traffic is a drop in a very large ocean. I'm guessing
that bulk mail is probably higher but still pretty much noise level to
large providers.

Without explicit whitelisting in place, wanted bulk mail (mostly
broadcast mail) is one of the biggest components of false positives
in spam filters (due to both traffic patterns and content).

Large providers expend quite a lot of effort to ensure delivery of
wanted bulk mail. If there were a magic wand they could wave
that would make all that free (or at least trivially automatable) then
they'd leap at it. That doesn't mean there's huge pent-up demand
for it, as the manual whitelisting approach mostly works, but there's
not total disinterest either.

Cheers,
  Steve



     Mike


Alessandro Vesely wrote:
John Levine wrote:
I'm asking because I see no means for automated registration of
opt-ins. Am I missing something?

Nope.  This is another interesting question that could benefit from
some research.

If recipient systems had some way to know what bulk mail their users
had asked for, there would be all sorts of benefits. They could skip
the spam filtering for the requested mail, know when to display an
unsubscribe button vs. a spam button, and probably more that doesn't
immediately occur to me.

Yup, it could be web2 enabled -contrast that to, say, unsubscribe URLs, whose unspecified behavior may include human interaction.

But it's tricky, since there is little standardization among signups
(particularly when one party is handling signups or sending for
another) and it's hard to come up with something with usable human
factors to verify that a putative signup actually happened. I hope we can all agree that the Windows Vista approach of asking "Is this OK?"
every two minutes isn't it.

IMHO, it might be triggered at the SMTP forwarding level: An MTA knows it is replacing or exploding the recipient, and it may learn that the target MTA supports signup handshakes from its EHLO response. At that point it should lookup a local database to learn if it has already done the handshake, if it is currently underway, or if it may be initiated right now. In the first case (already), the db lookup may yield an id/passwd pair to use with SMTP AUTH.

Doing the handshake may bring some advantages and imply some responsibilities. Thus, a well designed solution allows to negotiate a convenient forwarding agreement(*). Otherwise, the MTA just forwards the message as it has always done. After postmasters upgrade their servers with a software that implements that mechanism, subscriptions will automatically start to be traced on new messages.

[*] http://fixforwarding.org/wiki/forwarding_agreement
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg

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