Martin, Thanks for your comments.
At 07:36 PM 2/21/2005 -0500, Martin G. Diehl wrote:
David MacQuigg wrote:
[snip]
> 2) The results of the authentication must be pre-pended to
> the headers of the incoming mail, making it available for
> all subsequent receivers.
> 3) Neither the incoming headers nor the body of a message
> must be disturbed. We don't want to interfere with other
> protocols that might use a digital signature.
We don't want to interfere with replies to the message either.
Agreed.
[snip]
> Here is my proposed new header to meet these requirements:
>
> Authenticate: SPF1 [<IP Address>] <senders-domain> PASS
[snip]
> After these four items, we could have any number of
> non-standardized parameters
Why non-standardized?
The less there is to argue about, the more likely we will see a standard
sometime soon. These four items seem to be the minimum necessary to convey
authentication results to receivers downstream. Additional parameters
could arguably improve the security, ease storage requirements, or
whatever, but that is where the never-ending debates will start. Everyone
will have a different opinion on which headers to include in a hash
code. It's hard to argue over whether the IP Address should have curly
brackets or square.
There will be some irreconcilable and unavoidable differences, even over
these four simple items. For example, how do we chose the <senders-domain>
from all the available headers and SMTP commands? By standardizing just a
format for the result, the details can be different for each protocol, and
still a bare-minimum mail-receiver program, working without proprietary
algorithms, could do something useful with the result.
IMO, to be anti-Spoofing, it must have a time stamp and an
public key encrypted hash ... just like SRS has defined.
We've got to use words like must very carefully. What spoofing would these
two items prevent that could not be prevented by other means?
Maybe there could be a recommended position or keyword for common items
like hash codes, but the details of what's in the code would be
protocol-specific.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq at gain.com * *
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com