diff options
| author | Matěj Cepl <mcepl@cepl.eu> | 2023-01-02 22:54:56 +0100 |
|---|---|---|
| committer | Matěj Cepl <mcepl@cepl.eu> | 2023-05-25 10:56:00 +0200 |
| commit | 974100c32e45bd07ced44e9b179558a184fbb7d7 (patch) | |
| tree | 15b074939ef241436822bc31af57032b276183a9 /docs/djb-envelope.html | |
| parent | ed0912fb0f3d34e28d9a2ea392103a937f91bba9 (diff) | |
| download | pygn-974100c32e45bd07ced44e9b179558a184fbb7d7.tar.gz | |
Convert documentation from .maff to plain HTML.
Diffstat (limited to 'docs/djb-envelope.html')
| -rw-r--r-- | docs/djb-envelope.html | 98 |
1 files changed, 98 insertions, 0 deletions
diff --git a/docs/djb-envelope.html b/docs/djb-envelope.html new file mode 100644 index 0000000..e6e4bcf --- /dev/null +++ b/docs/djb-envelope.html @@ -0,0 +1,98 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> +<html><head> +<meta http-equiv="content-type" content="text/html; charset=windows-1252"></head><body> +<a href="http://cr.yp.to/djb.html">D. J. Bernstein</a> +<br><a href="http://cr.yp.to/mail.html">Internet mail</a> +<br><a href="http://cr.yp.to/immhf.html">Internet mail message header format</a> +<h1>Envelope information: Return-Path, Received</h1> +<h2><a name="return-path"></a>Return-Path</h2> +The value of a Return-Path field is +<a href="http://cr.yp.to/immhf/token.html">tokenizable</a>. +It shows the return path of the message, +i.e., the address that +<a href="http://cr.yp.to/im/responsibility.html">bounces</a> will be sent to. +It is either +(1) a <tt><</tt> token followed by a <tt>></tt> token, +indicating an empty return path, or +(2) +a <a href="http://cr.yp.to/immhf/addrlist.html#bracketed">bracketed address</a>. +Two examples: +<pre> Return-Path: <> + Return-Path: <God@heaven.af.mil> +</pre> +<p> +Messages transmitted through +<a href="http://cr.yp.to/smtp.html">SMTP</a> generally do not have Return-Path fields; +the return path is transmitted out-of-band +in the SMTP MAIL request. +When a message is stored in a mailbox, +the return path is stored in a Return-Path field. +If the message is then retrieved (e.g., through POP) +and sent through another SMTP hop, +the Return-Path is removed and the return path is again sent out-of-band. +</p><p> +Some mailers, +in violation of RFC 1123, fail to record the return path of a message. +Subsequent bounces +are sent to an invented return path, +typically the header From address. +This behavior is a disaster for mailing-list messages, +where the correct return path is the mailing list manager, +and the From address is an innocent subscriber +who has no way to remove bad addresses from the mailing list. +Every mailer is +<a href="http://cr.yp.to/im/responsibility.html">responsible</a> +for using the correct return path. +</p><h2><a name="received"></a>Received</h2> +In theory, the value of a Received field is +<a href="http://cr.yp.to/immhf/token.html">tokenizable</a>. +It contains +<ol> +<li>optionally, a <tt>"from"</tt> atom followed by an +<a href="http://cr.yp.to/immhf/addrlist.html#encoded-domain">encoded domain name</a>; +</li><li>optionally, a <tt>"by"</tt> atom followed by an encoded domain name; +</li><li>optionally, a <tt>"via"</tt> atom followed by another atom; +</li><li>zero or more of the following: a "with" atom followed by another atom; +</li><li>optionally, an <tt>"id"</tt> atom followed by either (1) an atom +or (2) a <tt><</tt> token, an +<a href="http://cr.yp.to/immhf/addrlist.html#encoded-address">encoded address</a>, +and a <tt>></tt> token; +</li><li>optionally, a <tt>"for"</tt> atom followed by an encoded address; +</li><li>a semicolon; and +</li><li>a +<a href="http://cr.yp.to/immhf/date.html#timestamp">timestamp</a>. +</li></ol> +Each SMTP server +adds a Received field to the top of each incoming message, +giving details of how it received the message, +most importantly the client's IP address: +<pre> Received: from mail-relay.af.mil (127.193.178.241) + by silverton.berkeley.edu with SMTP; 4 May 1998 14:57:55 -0000 + Received: (qmail 2227 invoked from network); 4 May 1998 14:57:37 -0000 + Received: from heaven.af.mil (127.193.178.247) + by mail-relay.af.mil with SMTP; 4 May 1998 14:57:37 -0000 +</pre> +In practice, +SMTP servers put all sorts of badly formatted information into Received lines. +It is probably best for readers +to treat everything before the final semicolon as unstructured text, +purely for human consumption. +<p> +A few SMTP servers don't even format the date correctly. +For example: +</p><pre> Received: by MicroMailer 3.50a on Wednesday, 24 January 1996, 17:15:16 EST + (WRONG) +</pre> +Invalid Received fields are also produced by the cucipop POP server. +<h2><a name="hop-counting"></a>Hop counting</h2> +Most SMTP servers refuse messages with ``too many'' Received fields. +For example, sendmail is typically configured to refuse messages +with more than 25 Received fields. +qmail refuses messages with more than 100 Received or Delivered-To fields. +Some messages legitimately have 20 or more Received fields. +<p> +Hop counting is a last-resort method of preventing loops: +a message will bounce if it passes through too many SMTP servers. + + +</p></body></html>
\ No newline at end of file |