Hello!
On Thu, Dec 02, 2004 at 02:21:32PM -0000, Chris Haynes wrote:
Hmm interesting!
This is not the effect that many users of forwarding would expect / want.
They often regard the forward-path as:
1) Confidential and/or,
Doesn't work. If the mail bounces on the second step, the bounce will
contain the target address.
Anyone who deems the forward-path confidential, is probably a bit
delusional, at least if they don't completely change the envelope (but
then they would need to be aware of bounce loop problems, i.e. forwarder
-> target bounces, and if the env-from is rewritten to forwarder, the
bounce will also be forwarded to target [with rewritten env-from] and so
on).
2) Subject to frequent change (Someone on this list reported that he forwards
to
his client-of-the-week's site)
Right.
That's often the sense of a forwarder, to provide an address that will
seldom change when one anticipates that the real target may change more
often.
Or to have representitive mail addresses like info(_at_)some-company which is
forwarded to the current customer relations employee.
I wonder: Do those forwarders who re-use the same mail-from address use this
251
response? Are that RFC-literate?
Ok, let's see what *current* stuff (i.e. not 821 or STD10) says:
: 3.4 Forwarding for Address Correction or Updating
:
: Forwarding support is most often required to consolidate and simplify
: addresses within, or relative to, some enterprise and less frequently
: to establish addresses to link a person's prior address with current
: one. Silent forwarding of messages (without server notification to
: the sender), for security or non-disclosure purposes, is common in
: the contemporary Internet.
:
: In both the enterprise and the "new address" cases, information
: hiding (and sometimes security) considerations argue against exposure
: of the "final" address through the SMTP protocol as a side-effect of
: the forwarding activity. This may be especially important when the
: final address may not even be reachable by the sender. Consequently,
: the "forwarding" mechanisms described in section 3.2 of RFC 821, and
: especially the 251 (corrected destination) and 551 reply codes from
: RCPT must be evaluated carefully by implementers and, when they are
: available, by those configuring systems.
:
: In particular:
:
: * Servers MAY forward messages when they are aware of an address
: change. When they do so, they MAY either provide address-updating
: information with a 251 code, or may forward "silently" and return
: a 250 code. But, if a 251 code is used, they MUST NOT assume that
: the client will actually update address information or even return
: that information to the user.
:
: Alternately,
:
: * Servers MAY reject or bounce messages when they are not
: deliverable when addressed. When they do so, they MAY either
: provide address-updating information with a 551 code, or may
: reject the message as undeliverable with a 550 code and no
: address-specific information. But, if a 551 code is used, they
: MUST NOT assume that the client will actually update address
: information or even return that information to the user.
:
: SMTP server implementations that support the 251 and/or 551 reply
: codes are strongly encouraged to provide configuration mechanisms so
: that sites which conclude that they would undesirably disclose
: information can disable or restrict their use.
So 2821 seems to regard usage of 251/551 as quite optional and sometimes
even advised against.
Kind regards,
Hannah.
PS: and I see that 251/551 *is* supposed to be machine parseable by the
forward-path being in the last position, so that question in my other
mail is answered.