>>>>> "OT" == Omar Thameen <omar@clifford.inch.com> writes:
OT> I assume that sending undeliverable-type messages to the reply-to
OT> address is not RFC compliant. Does anyone know offhand what address
OT> it's _supposed_ to send errors to and what RFC specifies this?
Bounces are supposed to go to the envelope sender, which isn't actually
part of the message. Instead, it's part of the enclosing transaction that
mail servers make to transmit mail. It isn't part of the header of your
message, although the receiving MTA may choose to add it, usually as a
Return-Path: header. The basic concepts are on RFC821:
3.1. MAIL
There are three steps to SMTP mail transactions. The transaction
is started with a MAIL command which gives the sender
identification. A series of one or more RCPT commands follows
giving the receiver information. Then a DATA command gives the
mail data. And finally, the end of mail data indicator confirms
the transaction.
The first step in the procedure is the MAIL command. The
<reverse-path> contains the source mailbox.
MAIL <SP> FROM:<reverse-path> <CRLF>
This command tells the SMTP-receiver that a new mail
transaction is starting and to reset all its state tables and
buffers, including any recipients or mail data. It gives the
reverse-path which can be used to report errors. If accepted,
the receiver-SMTP returns a 250 OK reply.
This is clarified and tightened up in RFC1123, section 5.2.8 and 5.3.3. An
excerpt:
5.3.3 Reliable Mail Receipt
[...]
If there is a delivery failure after acceptance of a message,
the receiver-SMTP MUST formulate and mail a notification
message. This notification MUST be sent using a null ("<>")
reverse path in the envelope; see Section 3.6 of RFC-821. The
recipient of this notification SHOULD be the address from the
envelope return path (or the Return-Path: line). However, if
this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification. If the address is an explicit source route, it
SHOULD be stripped down to its final hop.
Of course, the important part is a SHOULD, which means that folks writing
broken software are even freer to ignore it than a MUST. Lots of software
that ignores these provision uses Reply-To:, which is the source of all of
our warnings.
OT> Is the preferred method of dealing with this to insert a header into
OT> all outgoing messages like X-Loop-Avoid: whatever and then add it to
OT> taboo_header and taboo_body (taboo_body since the offending MTA will
OT> probably quote the message with headers).
Yes, that helps, but you are assuming that the bounces will contain some of
the original message. This is not always the case. The development
version uses checksumming in addition, but even that doesn't trap all
loops.
- J<
References:
|
|
