Re: [Asrg] Adding a spam button to MUAs

On Fri, 5 Feb 2010, Steve Atkins wrote:

> On Feb 5, 2010, at 4:09 AM, Daniel Feenberg wrote:
>
> > 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.
> POP and IMAP servers don't receive email. If you're planning on 
> mandating that all POP or IMAP servers listen on port 587, that's a 
> fairly big requirement.
Mail to arf(_at_)pop(_dot_)eample(_dot_)com may go to the host named example.com, or it may 
go to a host of any other name given in the MX statement for example.com. 
There is no requirement that pop.example.com host an MTA at all. Am I 
missing something or are you teasing me?
Furthermore, there can be no expectation that all email domains will 
support this protocol - so my expectation is that all email domains that 
wish to support this protocol for users receiving mail from pop or 
imap(_at_)example(_dot_)com must have an MTA somewhere that can accept mail for 
arf(_at_)[pop|imap}.example.com. If there is a domain somewhere that wishes to 
support the protocol, but does not wish to use the naming convention, then 
they would be left out in the cold. I don't see that as a very big 
concern.
The desire to eliminate all naming conventions strikes me as pointless - 
they are widespread and quite helpful in my experience. From localhost to 
127.0.0.1, to postmaster and abuse what is the downside? Someone may wish 
to use "localhost" as a hostname? Did they miss the IETF meeting? Then 
they are out of luck. In any case, at somepoint there has to be a 
convention, all the protocol can do is add levels of indirection.
Daniel Feenberg

> Or are you suggesting something MXish or SRVish (which isn't 
> implausible, though it's got the usual namespace pollution problems to 
> dodge)?
> Cheers,
>  Steve
>
> _______________________________________________
> 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