Subject: [spfbis] In support of retaining Received-SPF Header Field

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Apr 2012 18:31:36 -0700

Dear SPFbis WG,

In the minutes, reasons for retaining existing SPF results format were 
promised.  This had been discussed in the past with Murray regarding a 
need for standard formats to retain last-hop IP addresses used to 
associate messages with domains when matches are found within SPF 
records.  The primary contention is only receivers and not recipients 
should need or use this information.  It is often not easy to determine 
last hop IP addresses when messages transverse several MTAs within an 
ADMD.  The preferred result would have been to include the IP address 
seen at the ADMD border used in SPF validation be retained in a defined 
header field format, but this has not occurred with 
Authentication-Results header fields.

I think highly of Murray, but feel strongly about misrepresenting 
security assurances.  The Received-SPF Header Field format has been 
established for a longer period than the Authentication-Results header 
fields, so arguments about defining yet another header field is 
illogical.  SPF helps ADMDs manage message handling exceptions.  Often a 
user obtains messages through several ADMDs.  When users suspect there 
may be a problem, many third-party tools are available to help users 
understand email's fairly opaque header field structures.  For example, 
last-hop addresses might be checked against listings of recently 
compromised servers that may not have been apparent during the initial 
influx of malicious messages.  These types of checks are thwarted or 
made much less reliable when last-hop information is omitted.

It is rather ironic that often the only authenticated identity available 
happens to be the last-hop IP address.  This address is weakly 
authenticated by modern TCP exchanges.  Whenever negative reputation is 
assigned to the identity of a message source, this identity must be 
authenticated or incorrect assignments might unfairly disrupt services.  
Those who manage email have become overly reliant on statistics used to 
determine typical behavior.  Often, these statistics are based upon 
origination of a message assumed to correspond with authorization and 
may even ignore authenticated information that might otherwise quickly 
isolate compromised servers.

When dealing with security, it is important to not squint at the 
differences between authentication and authorization.  Many feel there 
is no reason to make such fine distinctions because it is ONLY email.  
Unfortunately, this attitude about email overlooks its critical role in 
conducting business.  For example, it is common for consumers to receive 
email notifications about pending changes, often in conjunction with a 
provided link.  Telling users how to recognize spoofed messages has not 
worked well.  A third-party solution is often the fastest way to broadly 
improve message protections across a vast array of services.  Often 
those attempting to offer improved security represent different and at 
times competing interests.  It would never be in a users interest to 
adopt result formats aimed at disabling third-party competitors by 
omitting essential information.

Regards,
Douglas Otis