Ian Eiloart wrote:
This is one reason to support an IMAP extension.
There's no reason not to. The important thing to realize at this stage
is the basic principles an implementation of a "standard spam button"
thing should support: multiple reporting mechanisms, specifiable
destinations, and a couple flavours of content.
Discussions over whether there should be IMAP, POP, SMTP, NTP, DNS,
HTTP, NNTP, or whatever mechanisms is largely irrelevant at this stage.
A recognition that there should be provision for more than one is the
useful bit. The important bit right now is the signalling and things
like, who can specify, whether one can override, whether multiple
destinations is desired.
> If the communication is between the authenticated user and the
> IMAP server, then there doesn't seem to be room for abuse of the
> abuse reporting mechanism.
Given the rise of AUTH hijacking in current use for spamming, you have
to pay attention even here, and I'm sure the miscreants will come up
with something. Senders would like to be able to specify. Meaning that
the local report destination has to be able to handle that forwarding.
Meaning there are potential vulnerabilities.
Eg: scum spammer inserting instructions to forward complaints as a DOS
to an innocent third party.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg