Re: [Asrg] Adding a spam button to MUAs

On Thu, 4 Feb 2010, 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 haven't been following this thread very closely, but why not just 
establish a standard role account on the MUAs designated POP or IMAP 
server? Such as arf(_at_)pop(_dot_)example(_dot_)com? It effectively "preconfigures" the 
MUA since "arf" is standard and "example.com" is already known to the MUA. 
The less configuration the better, I think.
I reject arguments that "arf" is English, and that non-english speakers 
need an address consistent with their native tongue - partly because users 
won't need to do the configuration themselves, partly because "arf" isn't 
English, and partly because the argument is just too silly anyway. People 
learn a few words of Italian if they want to play music, and a few words 
of French if they want to cook, they can learn a few words of English if 
they want to compute. I note that the French language standard for 
Fortran-66 was not widespread, even in France.
If someone already has the userid "arf", that is too bad.

> I think this is important because many MUAs receive email from multiple 
> infrastructures, each potentially with their own policies.
The MUA could keep track of the ARF server associated with the current 
POP/IMAP server.
> 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.
> _______________________________________________
> Asrg mailing list
> Asrg(_at_)irtf(_dot_)org
> http://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg