On Dec 8, 2009, at 9:35 PM, John R. Levine wrote:
Most web mail systems have a spam or junk button that lets a user report
unwanted mail to his ISP. The ISP does whatever it does, typically tune
their spam filters, and perhaps send a feedback report if the message is from
someone with whom they have an FBL agreement.
Lots of us don't use web mail. We use POP or IMAP to pick up our mail, and
SUMBIT to send it. How would we add a spam button in our MUAs work?
An obvious approach would be to pack up the message in an ARF report and mail
it somewhere. I don't think that would work, because MUAs these days can
handle multiple inbound and outbound accounts, with the various accounts only
loosely connected. I have users who pick up their mail here, but send via
their ISP's mail server and vice versa. If you were to send the report via
SMTP you might well send it to someone who'd never seen the message before.
So the report needs to be tied to the inbound account. For IMAP accounts, a
simple approach is to have an IMAP spam folder, and move the message there.
AOL does this in their IMAP access, so I suppose that makes it a de-facto
standard.
It's also already supported by some MUAs. Mail.app for one. Sorta.
POP is harder, since there's nothing I can see that would obviously do the
trick. If you could assume that the message was still on the server, you
could have a JUNK command that provided the UIDL of the message to report,
but in typical POP setups, the messages are downloaded and deleted from the
server before the user sees them. The alternative is to add a command to
upload the junk message, e.g.
JUNK
+OK send the message
blah blah copy of downloaded message blah blah
.
+OK junk reported
That's workable, although it's slow since it has to upload the entire
message, and it may be hard for MUAs to implement since they often add
annotations to the downloaded messages that would confuse the server if
handed back.
Yet another possibility would be a command for the POP server that provides
an address to which to the MUA can send an ARF report, keeping in mind that
the report may take a roundabout route if the MUA is set up to use someone
else's SUBMIT server. The address would presumably be obscure and time
limited, with the user's mailbox somehow encoded into it, so that the server
can recognize the report when it arrives, and to limit the chances of random
spam that happens to arrive at the reporting addresses being misinterpreted
as a junk report.
Any bright ideas? Is there a way to make this work with POP that isn't an
utter kludge?
The general purpose way would be for the receiving MX to embed a reporting
address in a message header such that the MUA would then forward the message to
when the user hit the button. The only functionality it requires from the MUA
is the ability to send email, which almost all MUAs already support.
A small amount of cryptography can make that immune against most failure modes.
The only obvious flaw is that if the MX doesn't support whatever header is
added it would be possible for the original sender to add that header to the
mail they send, meaning that a sender can have recipients send spam reports
from MX operators that don't support the protocol sent directly to them, rather
than to the MX operator.
That's not actually a flaw, I don't believe. Rather it's a fairly significant
advantage, in that it allows FBL consumers who are sending email to opt-in to
an ad-hoc feedback loop from their recipients. Yet it also allows MX operators
to override that by removing the header, or by replacing it with their own FBL
reporting address instead - without the MUA needing any special knowledge, nor
more than a few tens of lines of additional code to support.
It'd mostly be a slight variant on the List-Unsubscribe: header.
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg