George Hitz wrote on Saturday, December 02, 2006 7:48 AM -0600:
To enable use of my domain in the FROM field regardless of which
ISP I am using , I use the DynDNS SMTP service
"outbound.mailhop.org". I have two such accounts with them as I
have two bona fide usernames.
Newbie question: Is what I call the FROM field, the return-path?
This is important, and I appreciate your asking. The From: address
visible in most email clients is not the same as return-path. The From:
address is actually in the message body and indicates authorship, while
the return-path is in the envelope and is where you send notification of
delivery problems. SPF concerns only the return-path. Following is a
much longer description that provides some background.
Sending a message through SMTP involves two separate stages: the
envelope and the message body. These are directly analogous to the
parts of a postal letter. SMTP is similar to postal mail in the sense
that if a message cannot be delivered, the party identified in the
return address on the envelope receives notification. The addresses
inside the message body can be different than those on the envelope
because they serve different purposes.
In postal mail, there are sender and recipient addresses on both the
envelope and inside the letter, for a total of four general types of
address. The addresses on the envelope specify who to deliver the mail
to and who to return the mail to in case event delivery is impossible.
The letter inside the envelope has sender and recipient addresses that
can be different from those on the envelope. For instance, your
attorney may send you a copy of a letter they sent to someone on your
behalf. The recipient address on the envelope is you and the recipient
address on the letter is the original addressee. Similarly, your
attorney may send you a copy of a letter they received from someone
concerning your affairs. The envelope return address is your attorney
and the inside return address is the original author. Though uncommon,
In general, the four address types have the following functions for both
postal mail and email:
- envelope return address: delivery status notifications
- envelope recipient address: delivery
- inside return address: author
- inside recipient address: addressee
There is one more identity that is important in email but not postal
mail, and that is the delivery agent for each hop in the delivery chain.
The sending MTA presents this to the receiving MTA as an IP address and
HELO identity. Because the recipient must pay to receive email, and
because delivery agents have inconsistent policies, and because email
delivery can pass through multiple hosts, recipients sometimes refuse
all mail that was handled by agents known to deliver forgeries and other
unwanted messages. All postal mail, OTOH, is handled by the post office
end-to-end, is subject to anti-fraud laws that provide some assurance of
sender identity and is paid for by the sender. Recipients of postal
mail have no need for the identity of the postman.
There is another important difference between email and postal mail that
strongly affects address usage. In postal mail, the recipient always
sees the envelope and may not open it if they do not recognize the
return address. That has forced most senders to use their identities or
a general organization identity as return address, even though someone
else could better handle delivery problems. In contrast, an email end
user does not normally see the envelope. The good part is that this
encourages routing delivery problem notifications to automated handlers
that relieve the message author of those headaches, i.e. this mailing
list. The bad part is that without address verification, it facilitates
return-path forgery since the end user doesn't normally see the
envelope.
It gradually became clear that spam is fundamentally a problem of
malicious senders and uncooperative systems administrators evading
responsibility for what they send. Crude reputation systems (DNS
blacklists, or DNSBL's) came about as a method for receiving systems to
force responsibility on senders. However, senders had no simple means
to tell recipients how to distinguish their legitimate messages from
forgeries. Validating sender identities, then, can help control network
abuse. The sender identity to authenticate can be the delivery agent,
which is an individual mail host that may deliver mail for multiple
domains, or a return address that claims a sender domain independent of
delivery agent. Delivery agent identity is inherently known due to the
nature of TCP, however sender domain is not. Of the two sender address
types available, the envelope return address (return-path, envelope
return-path or MAIL FROM: address) has qualities that make it useful to
combat forgery. First, it is a single address, not a list. Second, it
is presented during the envelope stage of SMTP, when the recipient can
still reject a message at low cost.
SPF, however, does not directly validate sender addresses. That
requires strong cryptography and a system to distribute validation
instructions. SPF takes a simpler approach based on the idea that in
the majority of cases, it is good enough to have moderate assurance of
the sender's domain. Specifically, it takes advantage of the fact that,
to a steadily increasing degree, all legitimate outgoing messages for a
domain go through a small number of hosts operating on behalf of the
domain owner. The domain owner also happens to control the domain DNS,
which is an excellent place to publish the list of designated outbound
mail hosts.
--
Seth Goodman
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735