Re: Comments requested on recent appeal to the IESG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.0.2.3@xxxxxxxxxxx" 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]