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

[Alessandro Vesely]

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.example.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.)