It seems I need to re-confirm this group's consensus on a point of the
draft as it proceeds through IESG evaluation.
The scope of this work has always been pretty narrow: We take the output
of message authentication methods and relay them to MUAs so they can make
their own filtering decisions based on those results. None of the
implementations in the four years of this work has found a need to deviate
from that practise, so that really does define the scope of this work.
It has been suggested that an MUA might wish to make further evaluations
based upon the IP address of the MTA relaying the message in to the border
MTA and, therefore, this specification should enable that by including the
relaying IP address as detected by the border along with all of the other
result data. That information could then be compared to blacklists or
whitelists, used to query reputation, etc. by the MUA displaying the
message.
To me, this clearly contradicts the deployed experience (i.e. nobody does
this now) which this draft describes, and it also seems to me there are
several technical concerns with enabling this, not the least of which is a
resource amplification issue (e.g. one message going to 100 users means
100 MUAs will now do further message evaluation work, rather than doing
all of that work once at the border).
The specification as it stands is pretty clear in terms of its scope,
namely the deployment experience to date. Given that and the fact that
it's extensible (so this could be added later if it's actually useful),
I've been arguing the position that this isn't a good thing to add to the
draft at this stage. If someone really feels this would be a useful
extension and wishes to deploy it, a new method could be registered which
provides it.
What does the group think?
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html