Subject: [yam] Issue #10: RFC 5321 3.9: add tiny subsection

From: SM <[email-masked]>
Date: Sun, 06 Dec 2009 01:53:19 -0800

Hello,

There is a proposal to rename Section 3.9 of RFC 5321 to "Forwarding" 
(Issue #10) and to add a "Backup MX" subsection.  I do not support 
this change as:

  (i) It would be a significant change to Section 3.9 between the 
Draft and Full Standard.

  (ii) There isn't any relationship between "Backup MX" and "Forwarding".

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 06 Dec 2009 17:59:01 +0100

> (Issue #10) and to add a "Backup MX" subsection.  I do not support this 
> change as:
> 
>  (i) It would be a significant change to Section 3.9 between the Draft 
> and Full Standard.

Yes, it would. However, it implies no protocol changes. In addition, 
it would be a really tiny subsection.

>  (ii) There isn't any relationship between "Backup MX" and "Forwarding".

I agree that "Backup MX" is a poor title, and I apologize for having 
transferred it as-is from my notes to this list. Its most notable 
defect is that it does not include smart hosts nor other servers along 
the outgoing path. I'd amend the tentatively proposed titles to be

   Forwarding
     Relaying   <-- "Backup MX" was here
     Aliases
     Mailing lists

The relationship among these server's activities may now be clearer.

The subsection would be tiny because relaying is already explained in 
Section 3.6. It should just say that the envelope addresses are left 
intact. Since envelope addresses are the point of Section 3.9, such a 
simple observation would make it complete in this respect.

---

From: SM <[email-masked]>
Date: Sun, 06 Dec 2009 11:41:19 -0800

Hi Alessandro,
>it would be a really tiny subsection.

It's easier to compare the various iterations of the specification if 
you have, for example:

RFC 2821 - 3.10 Mailing Lists and Aliases

RFC 5321 - 3.9.  Mailing Lists and Aliases

Section 3.4 is titled "Forwarding for Address Correction or 
Updating".  The tiny change you suggested might end up causing confusion.

>defect is that it does not include smart hosts nor other servers 
>along the outgoing path. I'd amend the tentatively proposed titles to be
>
>   Forwarding

Quoting Section 3.4:

   "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 a
    current one."

What does "Forwarding" have to do with mailing lists?  What is the 
relationship between "Forwarding" and Relaying?

Aliases and mailing lists are about address expansion.  That's also 
the point of Section 3.9.

>The subsection would be tiny because relaying is already explained 
>in Section 3.6. It should just say that the envelope addresses are 
>left intact. Since envelope addresses are the point of Section 3.9, 
>such a simple observation would make it complete in this respect.

I am not convinced that the group would be convinced with the tiny 
argument. :-)  Even if it implies no protocol changes, you still have 
to ensure that the text is in line with what is being said in other sections.

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Sun, 06 Dec 2009 13:35:00 -0800 (PST)

> to ensure that the text is in line with what is being said in other sections.

What I'm not seeing in any of this is a compelling case that making such a
change will make the document any clearer. The original rationale given
was a sort of symmetry argument: First a section on transfer where the
envelope addresses don't change, then one where the recipient changes, then
one where both the recipient and originator change.

Even if I were to grant that there's a close equivalency between backup MX
handling and alias expansion - which I don't - what was the confusing aspect
of this and how does this change help eliminate that confusion?

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 Dec 2009 11:50:16 +0100

>> Updating".  The tiny change you suggested might end up causing confusion.

A .forward is not actually an alias, in facts. However, 3.9.1 
doesn't say what reply code should be returned (250 or 251) for 
aliases, and an implementation may accept foreign addresses for 
aliasing. Does _this_ cause confusion?

>>     to establish addresses to link a person's prior address with a

IMHO, support for changing address is inadequate in most 
implementations.

> handling and alias expansion - which I don't - what was the confusing 
> aspect of this and how does this change help eliminate that confusion?

Recovering a sound definition of the term "forwarding" is the main 
purpose for that change.

One common facet among foreign backup MXes, address changes, aliases 
expansions, and mailing list is that they treat personally 
identifiable information, namely the substituted email addresses. 
Most implementations don't comply with the spirit of privacy laws, 
in that they don't allow the owners of that data to inquiry or 
change it directly. Obviously, I don't think that it would be savvy 
or feasible to embrace privacy laws into the RFC. However, I note 
that although most privacy laws have been formalized after SMTP, 
they are based on the same common sense as RFC 821. Noncompliance 
apparently stems from the introduction of virtual users, and 
obscurely-subscribed mailing lists (a.k.a. spam).

If 5321bis could factor the circumstances where possible 
infringements may formally occur, it might be easier to define some 
SMTP extension, add-on protocol, or mixture thereof in order to fix 
that. For an underdeveloped attempt see http://fixforwarding.org

---

From: SM <[email-masked]>
Date: Mon, 07 Dec 2009 08:03:21 -0800

Hi Alessandro,
>aliasing. Does _this_ cause confusion?

Please see Section 3.4 for a discussion of the 251 code.  Section 3.9 
begins with:

   "An SMTP-capable host SHOULD support both the alias and the list
    models of address expansion for multiple delivery."

There is also:

   "An important mail facility is a mechanism for multi-destination
    delivery of a single message, by transforming (or "expanding" or
    "exploding") a pseudo-mailbox address into a list of destination
    mailbox addresses."

>Recovering a sound definition of the term "forwarding" is the main 

Are you sure that fits under Section 3.9?

>that. For an underdeveloped attempt see http://fixforwarding.org

That's a creative way to start a discussion about that four letter word. :-)

Regards,
-sm

---

From: Ned Freed <[email-masked]>
Date: Mon, 07 Dec 2009 10:00:00 -0800 (PST)

> A .forward is not actually an alias, in facts.

I never said anything about .forward files - nor did I say what you quote
above, sm did.

> However, 3.9.1

Not in my experience, no.

> Recovering a sound definition of the term "forwarding" is the main

That presupposes the existing definition is unsound. I disagree that it is.

> change it directly.

Even if I grant that there's a sufficiently serious issue with control over
forwarding entries by the recipient of that entry that work needs to be done to
solve - which I absolutely do not believe to be the case - what I'm misssing
here is even the remotest scintilla of justification for bringing this up in
the context of 5321bis.

If you want to make a proposal regarding changing how forwarding works, you
need to do it the old fashioned way - write a draft describing the problem and
your porposed solution, and then see if you can get sufficient support for your
idea  for it to be placed on the standards track.

You don't do it by engaing in some sort of wierd gambit involving changing the
definition of forwarding.

> Obviously, I don't think that it would be savvy

> that. For an underdeveloped attempt see http://fixforwarding.org

Or it might not. Your crystal ball must be very clear indeed to be able
to predict how such a change would affect such a proposal.

In any case, I've made my position clear - I'm opposed to this particular
change.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 08 Dec 2009 09:08:07 +0100

> Are you sure that fits under Section 3.9?

No, it's a tentative guess. That section currently contributes to 
make it ill-defined. Eliding the term or replacing it with "mailing 
lists" may better that state of affairs with minimal changes. 
Alternatively, slightly restructuring the section may be an occasion 
to reword it and also restate the concept of forwarding and its 
implications.

---

From: SM <[email-masked]>
Date: Tue, 08 Dec 2009 14:51:19 -0800

Hi Alessandro,
At 00:08 08-12-2009, Alessandro Vesely wrote:
>to reword it and also restate the concept of forwarding and its implications.

 From Section 2.1:

   "In other words, message transfer can occur in a single connection
    between the original SMTP-sender and the final SMTP-recipient, or can
    occur in a series of hops through intermediary systems."

I gather that you are viewing "forwarding" as when the final 
SMTP-recipient being changed by an intermediary system.  In technical 
terms, we could have different types of forwarding; for example the 
address correction in Section 3.4.  Section 3.7.2 also discusses 
about forwarding where the message goes through a gateway.  From an 
implementation perspective, we might talk about aliases, as mentioned 
in Section 3.9.1, or the .forward which can be set by a 
user.  There's also the case of this mailing list which forwarded 
your message to me.  Section 3.9.2 refers to that as "redistribution".

The main problem doesn't seem to be with forwarding; it's more about 
the return path and/or authorization.  It's up to the WG to determine 
whether restating all that would be a minimal change.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 09 Dec 2009 16:38:39 +0100

Hi SM,
you wrote:
> SMTP-recipient being changed by an intermediary system.

These cases are interesting for privacy issues. Since it is legally 
different if I send to a list rather than type or select from my 
personal address book each recipient, one may warn that by changing 
envelope addresses an intermediary server may violate the final 
recipients' privacy. Would that belong to the Security Considerations 
section, then?

> In technical 
> address correction in Section 3.4.  Section 3.7.2 also discusses about 
> forwarding where the message goes through a gateway.  From an 
> implementation perspective, we might talk about aliases, as mentioned in 
> Section 3.9.1, or the .forward which can be set by a user.  There's also 
> the case of this mailing list which forwarded your message to me.  
> Section 3.9.2 refers to that as "redistribution".

In plain English, any hop should be considered a case of SMTP 
forwarding, with the possible exception of gateways which, by their 
nature, talk SMTP on one side only. Out of SMTP scope, "forwarding" 
also means users manually resubmitting messages.

> The main problem doesn't seem to be with forwarding; it's more about the 
> return path and/or authorization.  It's up to the WG to determine 

You mean SPF authorization?

Return-path discussions are often cluttered with source routes issues. 
IMHO the full standard should consider source routes an historical 
oddment that nobody cares about, any more. Cleaning that up might not 
be a minimal change, but would improve readability.

---

From: SM <[email-masked]>
Date: Wed, 09 Dec 2009 16:31:11 -0800

Hi Alessandro,
At 07:38 09-12-2009, Alessandro Vesely wrote:
>recipients' privacy. Would that belong to the Security 
>Considerations section, then?

There is some discussion about information disclosure in Section 
7.  Please don't read this as meaning that the section should be or 
not be changed.

>You mean SPF authorization?

I mean authorization in general terms.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 11 Dec 2009 14:54:24 +0100

SM wrote:
> There is some discussion about information disclosure in Section 7.  
> Please don't read this as meaning that the section should be or not be 
> changed.

FWIW, assuming the definition of forwarding has been amended, issues 
related to section 3.9 could be addressed there like so:

  7.x Privacy violations on forwarding

  Since mailbox addresses are Personally Identifiable Information,
  a.k.a. Personal Data, applications SHOULD track additions to aliases
  and lists used in forwarding as described in section 3.9, possibly
  retaining evidence of mailboxes' owners consent. The data model
  SHOULD be designed so as to allow meaningful write-access control.

That's not meant to be taken literally, just the idea.

> I mean authorization in general terms.

Section 7.1 castigates various authentication schemes, but does not 
mention that forwarders may need to tweak their configuration options 
or make specific arrangements in order to avoid rejections.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 Dec 2009 12:47:29 -0800

Hi Alessandro,
>That's not meant to be taken literally, just the idea.

As I mentioned previously, I logged Issue #10 using the message you 
posted at http://www.ietf.org/mail-archive/web/yam/current/msg00164.html

Could you please clarify what text in RFC 5321 should be changed in 
regards to Issue #10 and suggest what the new text should be?

Regards,
S. Moonesamy
YAM WG Secretary

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 12 Dec 2009 19:28:04 +0100

Hi!
> regards to Issue #10 and suggest what the new text should be?

This might just be

  3.9.0 Plain forwarding
  Plain forwarding implies both the envelope originator and recipient
  addresses fields are left intact. The message is transmitted to the
  next hop.

I agree some confusion may arise because of the "forwarding" versus 
"forwarding or delivering" --which may be dealt with by skipping a 
transaction-- but beware of the "forwarded or redistributed" in the 
current text... I'd propose a replacement for the first two paragraphs 
of section 3.9 as follows:

  When a message is sent to a forwarded address (also called an
  "exploder", or  a "pseudo-mailbox"), copies are forwarded to each
  target mailbox in the expanded set. In case the resulting target
  address corresponds to a local mailbox, servers MAY skip an SMTP
  transaction and just deliver a copy of the message to the relevant
  mailbox. When replacing an envelope recipient address with multiple
  target addresses, servers SHOULD simply utilize the expanded set;
  application of heuristics or other matching rules to eliminate some
  addresses, such as that of the originator, is strongly discouraged.

  Existing header fields (RFC 5322 [4]) MUST be left intact; in
  particular, the "From" field is unaffected. Forwarding across
  different domains may be frustrated by policies aimed at transport
  level integrity (see Section 7.1). Hosts MAY go along adding header
  fields, choosing an adequate expansion method, and using supported
  extensions as required.

Again, that text is just for the WG to consider the changes:

* header fields, e.g. signatures, may be added on forwarding,
* expansion does not necessarily imply multiple delivery,
* forwarding may break recipient's policies,
* terminology...

Finally, several mailers replace the 5322.To field. Shouldn't this be 
mentioned? Or, why do we consider the header at all?

---

From: S Moonesamy <[email-masked]>
Date: Sat, 12 Dec 2009 12:41:52 -0800

Hi Alessandro,
At 10:28 12-12-2009, Alessandro Vesely wrote:
>current text... I'd propose a replacement for the first two 
>paragraphs of section 3.9 as follows:
>

I'll add the above text to Issue #10.

>Finally, several mailers replace the 5322.To field. Shouldn't this 
>be mentioned? Or, why do we consider the header at all?

The following is an individual comment.  There is a discussion of 
changes by a SMTP server in Section 3.7.1, Section 3.7.4 and Section 
6.4.  Section 3.9 mentions a requirement for the message header 
section.  There is also some text in Section 7.2 about attempts to 
deduce relationships between the envelope and the header section and 
use them to alter the header section of the message for delivery.

Regards,
S. Moonesamy
YAM WG Secretary