Doug Otis wrote:
Since *authorization* does not *authenticate* a domain as having
originated a message, this leaves just the IP address of the SMTP client
as a weakly "authenticated origin identifier". The IP address of the
SMTP client is the input for Sender-ID or SPF *authorization*
mechanisms.
Hm... the IP address is authenticated by the TCP session. Next, the
self-styled domain is looked up checking for an authorization for the
given IP address. Up to DNS reliability, a positive result proves the
validity of the domain name, in the sense that the domain admins have
stated that messages originating from the given IP may righteously
claim to originate from that domain. Why wouldn't that make up an
authentication of the given domain name?
Checking the reputation of the "authenticated origin
identifier" determines whether this identifier protects the message
elements used to establish the *authorization* prior to revealing the
*authorization* results.
It is not clear to me what checking would the MUA do in practice.
[...]
In addition, including the IP address of the SMTP client makes the
header less deceptive. Recipients must consider which identifier has
been authenticated. It is the *authenticated* IP address of the SMTP
client that is being *authorized* by Sender-ID or SPF. Using this IP
address to replace the local-part avoids the conditional inclusion of
the local-part that is required by section 2.4.3.
I doubt that displaying "192(_dot_)0(_dot_)2(_dot_)3(_at_)example(_dot_)com" will make the
recipient safer. Users who know what to do with an IP address are also
able to look at the Received or Received-SPF headers directly. MUAs
tend to conceal even true email addresses from end users, for some reason.
This section confuses
authorization with authentication where even local-part authorization
can only be determined after examining internal elements within SPF
records. Tracking the *authorization* role of the local-part is not a
defined output of either authorization mechanism, nor is it safe to
process SPF record local-part macros!
A domain interested in verifying the local part might combine the
"exist" mechanism with a purposely built DNS zone. What's wrong with
processing local macros? I agree that if no local macro has been
processed one can safely consider the local part as not having been
validated. However, the converse statement does not hold. I'd say that
only MTAs whose SPF-checking implementation traces the use of local
macros may conclude that the local part was not specifically checked,
and thence conceal it.
Another not commonly implemented possibility is that a site
dynamically updates its DNS records according to DHCP leases, and
synchronizes the SPF record TTL with the lease duration. How would a
MUA cope with that if, say, it downloads the message on the next day?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf