Re: [Asrg] MUA/Operator reporting address (was Re: Adding a spam button

Dave CROCKER wrote:
> On 2/5/2010 12:01 PM, Chris Lewis wrote:
> > Steve Atkins wrote:
> > > Of those, the only thing that's actually associated with the inbound
> > > mailbox is the incoming mail server.
> > As you suggest, key it to "feedback(_at_)feedback(_dot_)<incoming server name>".
> This covers 3 specific choices, each of which ought to get a bit of discussion.
>
>
> 1. Mailbox name
>
> There is an official list of required/standard email addresses:
>
>     <http://www.ietf.org/rfc/rfc2142.txt>
>
> We should make this exercise be an extension to that.  Offhand, 'feedback' 
> strikes me as too generic, for what is actually a pretty specific function.
> The existing, relevant reserved mailbox string is 'abuse'.  Should this new one 
> be related to it?
That would be okay, but it shouldn't _be_ "abuse".  That's more for 
abuse originating locally, not that originating elsewhere.  We use 
"spam" for spam reporting ;-)
> 2. Sub-domain
>
> Why have a sub-domain?  And to the extent one is needed, why not use the 
> developing convention of an underscore name, such as _report.<domain>?
Sub-domain because presumably you have incoming mail server already, and 
you don't want to standardize on something that will collide with 
existing infrastructure conventions.  Even if it's mail related.
> The address to be used is really an 'attribute' of the main domain, and the 
> underscore convention has developed as a way of defining additional attributes 
> for a domain name.  In addition, the naming convention does not run the risk of 
> colliding with an existing use of sub-domains.
Problem with main domain is trying to figure out what it is, and it may 
not be the registered name.  east.sun.com and west.sun.com may have 
entirely separate infrastructures even if you could derive "sun.com" 
from "blat.for.be.sun.com".  So, it should at worst, be related to the 
naming of the infrastructure you actually use.
> 3. Domain.
>
> Clients currently have two domains to draw from, posting domain and pickup 
> domain.  Choosing incoming probably /is/ best, because that's the place that 
> handed the user the problem message and therefore it's the place that ought to 
> provide the information about where to report problems.
>
> > > The charm of using an MX record to configure this is that the MUA can
> > > do an MX lookup to know whether to show or hide the button. That's
> > > pretty clean, and if I were coding an MUA I'd be happy to do it that
> > > way, but it's not necessarily a _trivial_ thing to add to a codebase,
> > > especially via plugin, so it's worth considering.
> >  From the perspective of code base, checking for an A record for
> > "feedback.<incoming server name>" would be simpler. The MTA doesn't need
> > to use DNS to deliver, and you really don't want the MUA to be
> > establishing direct connections anyway. Fixed route to whereever in the
> > MTA.
> Just to check:  The choice between using an A or an MX is an optimization, 
> rather than strategic, yes?  That is, either is sufficient to the task, so a 
> debate is about better?
There are some specific technical advantages to an A for existance 
(enable TiS button), and MX for routing (where submission server sends 
it).  Doing it that way around minimizes extra work, eg: many MUAs might 
not _have_ MX lookup code, but you know they have to have A lookup, so 
"A" is more convenient for what the MUA needs to do (light up the TiS 
button).  The MX makes MTA routing work perfectly sanely.  The A record 
doesn't even have to point at anything useful, because the MUA doesn't 
have to go there (and may not be able to), just exist.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg