On Feb 4, 2010, at 3:59 PM, Chris Lewis wrote:
John Levine wrote:
In any case it hardly matters because POP3 and IMAP are completely different
protocols with different constituencies. You'd never have a standards effort
that lumps them together in a million years, and even if you did you'd do
nothing more than needlessly confuse the programmers of their respective
code bases.
Actually, we've seen a reasonable suggestion a few messages back that
would work equally well with POP and IMAP: extract a reporting address
from the message and send it an ARF report. It has the admirable
characteristic of being completely agnostic about how the mail is
delivered, since there are plenty of delivery techniques other than
POP and IMAP, such as WebDAV, uucp (still handy for intermittent
connections), fetchmail, and just reading the local mailstore.
If we want to sidestep the issue of how to deal with senders wanting their
FBLs, the very simplest method of all is to have the TiS button send an ARF
to a specific address, and let that address figure out everything else.
I could live with that even in my odd-ball architecture (which probably
resembles other very large infrastructures). I already do that (without the
ARF format), and the recipient address has to be manually configured in the
MUA.
I'd only add that I'd prefer _not_ to have to have the user configure the MUA
where to send the ARFs to. The receiving mail server inserts it. Meaning
that the MUA has to be able to determine it's valid.
I think this is important because many MUAs receive email from multiple
infrastructures, each potentially with their own policies.
If we only support emailed ARFs, the only parameter you need is the address.
This has the advantage of being able to work correctly if the MUA receives
email from several different infrastructures, even if some don't support
reporting.
Even has the ability to work if the receiving mail system can't handle the
ARFs at all, just forward em off to a trusted 3rd party.
+1. This is exactly what I suggested way, way upthread.
All you need to be able to do at the MX level is add a (possibly constant)
header to each inbound email.
There's a subtle implication, which is that if you're stashing the ARF consumer
address in a header, and your MX isn't overwriting (or stripping) that header,
then it's possible that spam reports could be sent to the preferred reporting
address of someone further up the delivery chain. I see this as an advantage,
but it needs to be mentioned.
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg