An e-mail address identifies a location to which e-mail messages can be delivered. The term "e-mail address" is also used as the formal pre-registered authoritative electronic mail delivery site for an individual (example: an attorney's e-mail address registered for delivery of proof of service digital copies of legal pleadings). A modern Internet e-mail address (using SMTP or Usenet) is a string of the form jsmith@example.com. It should be read as "jsmith at example dot com". The part before the @ sign is the local-part of the address, often the username of the recipient, and the part after the @ sign is the domain-part which may be a host name or domain name which can be looked up in the Domain Name System to find the mail transfer agent or Mail eXchangers (MXs) accepting e-mail for that address.
The domain name of an e-mail address is often that of the e-mail service, such as Google's Gmail, Microsoft's Hotmail, etc. The domain name can also be the domain name of the company that the recipient represents, or the domain of the recipient's personal site.
Earlier forms of e-mail addresses included the somewhat verbose notation required by X.400, and the UUCP "bang path" notation, in which the address was given in the form of a sequence of computers through which the message should be relayed. This latter was widely used for several years, but was superseded by the generally more convenient SMTP form.
Addresses found in the header fields of e-mail should not be considered authoritative, because SMTP has no generally-required mechanisms for authentication. Forged e-mail addresses are often seen in spam, phishing, and many other internet-based scams; this has led to several initiatives which aim to make such forgeries easier to spot.
To indicate where the message should go, a user normally types the "display name" of the recipient followed by the address specification surrounded by angled brackets, for example: John Smith ap118@example.com.
The domain name of an e-mail address is often that of the e-mail service, such as Google's Gmail, Microsoft's Hotmail, etc. The domain name can also be the domain name of the company that the recipient represents, or the domain of the recipient's personal site.
Earlier forms of e-mail addresses included the somewhat verbose notation required by X.400, and the UUCP "bang path" notation, in which the address was given in the form of a sequence of computers through which the message should be relayed. This latter was widely used for several years, but was superseded by the generally more convenient SMTP form.
Addresses found in the header fields of e-mail should not be considered authoritative, because SMTP has no generally-required mechanisms for authentication. Forged e-mail addresses are often seen in spam, phishing, and many other internet-based scams; this has led to several initiatives which aim to make such forgeries easier to spot.
To indicate where the message should go, a user normally types the "display name" of the recipient followed by the address specification surrounded by angled brackets, for example: John Smith ap118@example.com.
Difficulties with e-mail forwarding
There are some additional details when an e-mail forwarder is involved. Forwarders perform a useful service in allowing you to have one simple permanent address, even if you change jobs or ISPs. List servers perform a similar function, forwarding e-mail to many receivers on behalf of one sender. Forwarders pose no problem for an end-to-end authentication method like DKIM and DomainKeys, as long as the signed message is not modified (some lists do this).
CSV limits its focus to one-hop authentications. SPF and SenderID have in essence the same limitation, they don't work directly behind the "border" ( MX ) of the receiver. For SPF forwarders to third parties could rewrite the Return-Path (MAIL FROM) in a similar way like mailing lists. This approach emulates the SMTP behaviour before RFC 1123 deprecated source routes; for a technical explanation see SRS.
For SenderID, forwarders to third parties and mailing lists are asked to add a Sender: or Resent-Sender: header. For many mailing lists, the former is already the case, but other forwarders avoid any modifications of the mail in addition to the mandatory Received-timestamp line.
Use of a forwarder prevents the receiver from directly seeing the sender's IP address. The incoming IP packets have only the forwarder's IP address. Two solutions are possible if one can trust all forwarders. Either one trusts the forwarder to authenticate the sender, or one trusts the forwarder to at least accurately record the incoming IP address and pass it on, so one can do their own authentication.
The situation gets complicated when there is more than one forwarder. A sender can explicitly authorize a forwarder to send on its behalf, in effect extending its boundary to the public Internet. A receiver can trust a forwarder that it pays to handle e-mail, in effect designating a new receiver. There may be additional "MTA relays" in the middle, however. These are sometimes used for administrative control, traffic aggregation, and routing control. All it takes is one broken link in the chain-of-trust from sender to receiver, and it is no longer possible to authenticate the sender.
Forwarders have one other responsibility, and that is to route Bounce messages (a.k.a. DSNs) in case the forwarding fails (or if it is requested anyway). E-mail forwarding is different from remailing when it comes to which address should receive DSNs. Spam bounces should not be sent to any address that may be forged. These bounces may go back by the same path they came, if that path has been authenticated.
CSV limits its focus to one-hop authentications. SPF and SenderID have in essence the same limitation, they don't work directly behind the "border" ( MX ) of the receiver. For SPF forwarders to third parties could rewrite the Return-Path (MAIL FROM) in a similar way like mailing lists. This approach emulates the SMTP behaviour before RFC 1123 deprecated source routes; for a technical explanation see SRS.
For SenderID, forwarders to third parties and mailing lists are asked to add a Sender: or Resent-Sender: header. For many mailing lists, the former is already the case, but other forwarders avoid any modifications of the mail in addition to the mandatory Received-timestamp line.
Use of a forwarder prevents the receiver from directly seeing the sender's IP address. The incoming IP packets have only the forwarder's IP address. Two solutions are possible if one can trust all forwarders. Either one trusts the forwarder to authenticate the sender, or one trusts the forwarder to at least accurately record the incoming IP address and pass it on, so one can do their own authentication.
The situation gets complicated when there is more than one forwarder. A sender can explicitly authorize a forwarder to send on its behalf, in effect extending its boundary to the public Internet. A receiver can trust a forwarder that it pays to handle e-mail, in effect designating a new receiver. There may be additional "MTA relays" in the middle, however. These are sometimes used for administrative control, traffic aggregation, and routing control. All it takes is one broken link in the chain-of-trust from sender to receiver, and it is no longer possible to authenticate the sender.
Forwarders have one other responsibility, and that is to route Bounce messages (a.k.a. DSNs) in case the forwarding fails (or if it is requested anyway). E-mail forwarding is different from remailing when it comes to which address should receive DSNs. Spam bounces should not be sent to any address that may be forged. These bounces may go back by the same path they came, if that path has been authenticated.
No comments:
Post a Comment