On Wednesday 09 December 2009 05:35:03 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.
When setting up mail server IMAP & POP3 settings there could be 'Spam
reporting' options available - for IMAP this would presumably be the folder
where junk is placed to be reported; for POP3 this might just be a checkbox to
say that a JUNK command is implemented as John suggests.
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.
An MTA providing a junk/spam reporting function might choose to keep [a copy
of] all messages for at least a few days so that UIDLs refer to messages
available to the MTA. This has the advantages,
- The MTA wouldn't have to remove any headers added by the MUA
- No significant bandwidth is required to communicate the UIDL (contrast
this to the MUA having to send a message back to the MTA)
Perhaps MTAs that wish to provide spam reporting functionality should be
required to keep [a copy of] messages for a few days, probably separate from
the users' mailbox/folders view so that users/MTAs can still DELEte messages
etc.
If a JUNK command comes in after the MTA's copy of the message has been
deleted the command can just be ignored - most JUNK commands can be expected
to be received within a few days of the user downloading the corresponding
messages; or better still the MTA can inform the MUA whether it's been able to
successfully find the corresponding message and report it / unsubscribe it etc.
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.
I don't like this idea because of the waste of bandwidth (users may not
appreciate sending back a large message if their upload bandwidth is low
compared to their downstream - e.g. ADSL)
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?
cheers,
Andrew.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg