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