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