At 03:56 AM 2/27/2005 +0100, Frank wrote:
David MacQuigg wrote:
> I think you are confusing me with Dave Crocker
No, don't panic, I'm not that subtle. But you quoted his
mail-arch text, which is incompatible with STD 10 and SPF,
if it still propagates an arbitrary "bounces-to" address.
I'm having trouble with your short ambiguous statements. If by
"propagates" you mean endorses or supports, I don't see that in Crocker's
document. If you mean "still shows an insecure 'bounces-to' address", then
you may be raising a question of factual accuracy, which should be brought
to Crocker's attention. Is his description of current reality correct?
Here is the relevant section from
<http://www.ietf.org/internet-drafts/draft-crocker-email-arch-03.txt>http://www.ietf.org/internet-drafts/draft-crocker-email-arch-03.txt
- Internet Mail Architecture
RFC2821.MailFrom
Set by: Source
This is an end-to-end string that specifies an email address for
receiving return control Notifications, such as "bounces". The
name of this field is misleading, because it is not required to
specify either the author or the agent responsible for submitting
the message. Rather, the agent responsible for submission
specifies the RFC2821.MailFrom address. Ultimately the simple
basis for deciding what address needs to be in the
RFC2821.MailFrom is to determine what address needs to be informed
about transmission-level problems (and, possibly, successes.)
-- Dave
> a clarification of email terminology
It's a new terminology. Some of the terms are "mediator",
"forwarder", and "redirector". I can't say at the moment
which term is the one thing obsoleted by SPF, it was either
"forwarder" or "redirector".
> I highly recommend it as a framework for any discussion of
> email protocols.
So what is the term for "change RCPT-TO and send to another
MX of a 3rd party" ? That's what you normally can't do with
SPF protected mail.
Crocker's explanation of current email architecture doesn't deal
specifically with questions of forgery, but it is clear from the above
definition of the MailFrom identity, that this identity must be preserved
by each Relay from Source to Destination. That's where I am seeing the
vulnerability of SPF. Is it not possible for a Relay to insert whatever
identity it wants the Recipient to think is the original MailFrom identity?
Here is the entire section 6 of Crocker's draft:
6. Security Considerations
This document does not specify any new Internet mail functionality.
Consequently it should introduce no new security considerations.
However its discussion of the roles and responsibilities for
different mail service modules, and the information they create,
highlights the considerable security considerations that must be
present when implementing any component of the Internet mail service.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmq'at'gci-net.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