ietf-smtp
[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis [...]

2008-01-25 01:39:09

Mark Martinec wrote:
On Thursday 24 January 2008 09:55:41 Alessandro Vesely wrote:
Assuming that SMTP doesn't need to delve into boundaries and complex
network topologies, the best it can do is to refer to current best
practices. E.g, like so:
    To expand an alias, the recipient mailer replaces the recipient
    address in the envelope with each of the expanded addresses in
    turn. Trace information SHOULD be removed and the envelope sender
    address SHOULD be changed according to local forwarding policies,
    or left intact in case of lack thereof.

If by 'Trace information' you mean a Return-Path, that is fine,
but the text needs to say so. The 'Trace information' also covers
the Received header fields, which must not be deleted!

That's fine for me as well. Would the text resulting after
s/Trace information/Return-Path/ be acceptable?

The resulting text permits SPF-compliant mail forwarding.
However, the section title is just "Alias." Forwarding is
mentioned in section 3.4. (Forwarding for Address Correction or
Updating.) That section also refers to local policies, calling
them "configuration mechanisms", but doesn't say anything about
the envelope.

The next section, 3.9.2 (List) notes that the key difference
is the change to the backward-pointing address. That would not
be exact any more.

IMHO, a consistent change should affect all of section 3.9
(Mailing Lists and Aliases), beginning with its title, and
previous sections on relaying (3.4 and 3.6) would implicitly
or explicitly refer to this one. Should I post a tentative
text?

On a stylistic note, section 3.6.3 (Message Submission Servers
as Relays) introduces a mail submission protocol which, after
the additions in subsequent versions of the document, sounds
somewhat redundant:

   A standardized mail submission protocol has been developed
   that is gradually superseding practices based on SMTP
   (see RFC4409 [24]).

In addition, that text may result in an endless loop when
RFC4409, section 3.1. (Submission Identification) says that
"The protocol used is ESMTP, with additional restrictions or
allowances as specified here." I'd replace that text with

   Additional restrictions or allowances w.r.t. the practices
   described here are specified in the mail submission protocol
   (see RFC4409 [24]).