mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] More A-R bits...

2010-04-05 11:38:09
On 02/Apr/10 20:40, Murray S. Kucherawy wrote:
 * DKIM-Reputation. I currently get

This could be done in a separate registration draft as well if you don't want 
to wait for the output of a working group.  I don't think it's appropriate 
right now because of the low adoption of it (you're the first case I've heard 
of that's using it!).

IMHO, a single document that collects various amendments/ additions to 
RFC 5451 would be more practical from a reader POV. Hence, I'd prefer 
that. However, WG chartering issues may suggest otherwise...

 * Ditto for ADSP.

RFC5617 registered ADSP.

Ooops, I'd missed that too. At a quick glance, I don't like its 
Section 5.3: it has no examples and formally just says "contents of 
the [RFC5322] From: header field, with comments removed". It is 
ambiguous whether any display names should be retained rather than 
reporting just the relevant addr-spec. It is also ambiguous what to 
report in the presence of multiple mailboxes or obs-stuff in that field.

 * "Report-To" (or "Reportable", or "Abuse-Report-To") as an additional 
Authentication-Result method whereby the MTA responsible for receiving the 
message conveys that, based on other methods and any additional knowledge 
internal to the MTA, that host will accept an ARF for this message. The 
syntax may be something like

    Authentication-Results: resp-mta.example.com;
      report-to: abuse;

 to mean<abuse(_at_)resp-mta(_dot_)example(_dot_)com>, which would be 
assumed by default in case resp-mta.example.com is an SMTP host (MX/A/AAAA).
 Variations?

I think this is probably an overloading of the purpose of this header field.  
I'd rather see a new one created, or an internal method for making that 
address available to clients (perhaps via IMAP CAPABILITIES and/or the POP 
equivalent).

This has been extensively discussed in the ASRG list, see 
http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs for a 
summary. One of the proposals was to just use the default abuse-box at 
that authserv-id's,  but it's too rigid. More flexibility can be 
obtained by specifying a method. However, a syntax for it has not been 
explicitly devised.

Although it may seem an overload, the semantics of "host responsible 
for receiving a message", as well as the required treatment, provide 
for a perfect match between a trusted Abuse Report target and the 
Authentication Results provider. (The initials also match.)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 

<Prev in Thread] Current Thread [Next in Thread>