Subject: Re: [spfbis] #56: Section 9.2.2 Forwarding Services and Aliases

From: S Moonesamy <[email-masked]>
Date: Sat, 16 Feb 2013 08:05:05 -0800

Hello,
At 00:09 06-09-2012, spfbis issue tracker wrote:
>#56: Section 9.2.2 Forwarding Services and Aliases
>
>  Message posted by Dave Crocker on 5 Sept 2012:
>
>  3.  Section 9.2.2 Forwarding Services and Aliases
>
>  The introductory paragraph summarizes the concept and cites RFC1123 and
>  RFC5321.
>
>  With respect to mailing lists and aliases, RFC 5321 updates RFC 1123. The
>  reference to RFC 1123 should therefore be dropped.
>
>  However the general RFC5321 Section 3.9, Mailing Lists and Aliases, is
>  also rather problematic, with normative requirements that do not match
>  industry practice and some terminology that also differs from common
>  usage. So reference to RFC5321 concerning mailing lists and aliases
>  unfortunately invites confusion.
>
>  Since the draft's discussion is non-normative and since the draft is
>  already liberally drawing from RFC 5598, I suggest that all reference and
>  background to Mailing Lists and Aliases be based on RFC 5598 (which is
>  also considerably more detailed on these topics than RFC 5321...)
>
>  In contrast, the draft's discussion of SPF issues in the presence of
>  mediators:
>
>          "[RFC1123] and [RFC5321] describe this action as an "alias" rather
>  than a "mail list"."
>
>  appears useful, although it appears to cover both mailing list and
>  aliasing issues, not just aliasing, as constrained by the section
>  containing the discussion.

Note that I only took a quick look at the mailing list archive before 
writing this message.  The text is currently in Section 10.3 of 
draft-ietf-spfbis-4408bis-10.

I didn't see any discussion about Issue #56.  There was quite a lot 
of discussion about "Forwarding".  I have to look at the issue in 
terms of how to resolve it.  Dave Crocker suggested an 
alternative.  The discussion could start from there.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 16 Feb 2013 11:43:38 -0500

>alternative.  The discussion could start from there.

#55 and #56 are closely related. http://www.ietf.org/mail-archive/web/spfbis/current/msg03172.html got no response that I saw.   Perhaps we could start from there?

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Sat, 16 Feb 2013 08:53:59 -0800

Hi Scott,
At 08:43 16-02-2013, Scott Kitterman wrote:
>#55 and #56 are closely related. 
>http://www.ietf.org/mail-archive/web/spfbis/current/msg03172.html 
>got no response that I saw.   Perhaps we could start from there?

Thanks for the link.  It sounds like a good starting point to me.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Sun, 17 Feb 2013 08:39:36 -0800

> #55 and #56 are closely related. http://www.ietf.org/mail-archive/web/spfbis/current/msg03172.html got no response that I saw.   Perhaps we could start from there?

OK.

Alas, the result is no better than the previous draft.

As we all know, Mediators impose an inherent and fundamental problem for 
path-based mechanisms like SPF.  As such, I believe any discussion about 
them needs to be especially careful and thorough.

Starting with that text in the latest draft:

>
> 10.3. Mediators
>
>
>    Broadly speaking, there are two types of mediating ADMDs that can
>    affect SPF deployment of other ADMDs: mailing lists (see [RFC5598]
>    Section 5.3) and ReSenders ([RFC5598] Section 5.2).

RFC5598 characterizes ADMDs as "administrative" actors.  Mediators are a 
sub-class of "user" actors.  The distinction between the User and MHS 
actors, versus Administrative, is that the first two cover classic email 
component functionality, while ADMD covers matters of authority, 
responsibility and control.  Note, for example, that the document's 
discussion of Administrative Actors (Section 2.3) does not have 
sub-sections describing functional components, but does have a bullet 
list discussing some ADMD roles.

I'm being pedagogical about this because the development of that 
discussion in RFC 5598 wasn't straightforward and it's worth a bit of 
effort, to see what might make the section's distinctions more clear.

Anyhow,  Mediators are a type of User actor.  That is, a mediator takes 
'delivery' and post 'submissions'.  As such, they are legitimately free 
(authorized) to make the newly-posted message be as similar or as 
different from the message they received as they wish.  In contrast, 
MHS-level components are highly constrained in the modifications that 
are permitted.

So much for pedagogy.  As for the actual text:

    mediating ADMDs-> mediating actors

"SPF deployment of other ADMDs."  I don't know what that text means.

> 10.3.1. Mailing Lists
>
>
>    Mailing lists have to be aware of how they re-inject mail that is

We've developed a fondness in IETF specs to offer anthropomorphic 
reference about software, often in place of actually specifying 
substance.  Mailing lists aren't aware; but much worse is that the 
sentence does not provide any clear implementation or operation 
directive.  In operational terms, what would such 'awareness' mean?  I 
don't know.

To the extent that the purpose of the sentence is to highlight 
implications or dangers, then state them concretely.  Such a notice to 
potential developers and operators can be useful.

>    sent to the list.  Mailing lists MUST comply with the requirements in
>    [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that

My previous note made specific recommendations about these references 
and suggested an alternative.  My reasoning was/is very simple:  these 
existing references do not represent current operational realities. 
(Actually they never did, I believe.)

>    the reverse-path MUST be changed to be the mailbox of a person or

Avoid re-stating normative text from a spec.  It's an opportunity to 
introduce deviation.  In addition. this particular mandate is a good 
example of the problem(s) with RFC5321/1123; they don't reflect 
operational realities.

Worse, it's an attempt to impose very specific normative behavior on a 
community that has shown a very strong resistance to such efforts. 
Hence it's a futile exercise that will lull the reader into thinking 
that something useful has been specified.  Whatever is written, it needs 
to attend to likely outcomes.  Getting conformance on this particular 
point has long been demonstrated to not be one of them.

>    other entity who administers the list.  Whereas the reasons for
>    changing the reverse-path are many and long-standing, SPF adds
>    enforcement to this requirement.

Best I can suggest is to cast this segment of text as a non-normative 
comment about SPF's adding to the list of benefits in changing the 
return address.

>
>    In practice, almost all mailing list software in use already complies

Does it?  What is the basis for this claim?

I'm pressing the question because this is a statistic with potentially 
enormous operational import for SPF...

>    with this requirement.  Mailing lists that do not comply might
>    encounter problems depending on how access to the list is restricted.
>    Such lists that are entirely internal to a domain (only people in the
>    domain can send to or receive from the list) are not affected.
>
> 10.3.2. Forwarding Services and Aliases
>

RFC 5598 uses the words 'forward' and 'forwarding' but not the term or 
definition of 'forwarding service'.  (FWIW, on review I suspect the text 
in RFC 5598 could be significantly improved, concerning the terms 
'forward' and forwarding... )  RFC 5598 refrained from using them as a 
labels -- it only uses them as part of sentences, rather than as 
distinctive terms -- because the word 'forward' has a variety of common 
uses in email discussion and, therefore, is too generic to be precise.

Broadly, I think the label "Mediator" is meant here, but Alias is a 
sub-case.  Intro paragraph to Section 5 of RFC5598: "A Mediator forwards 
a message through are-posting process."

It is likely to be counter-productive for the current draft to invent a 
new term and proceed to offer it's own definition.  This probably is not 
-- and I believe should not be -- the intent, but I think it's the 
reality of the current text.

Probably the simplest change is to make the text be something like:

    10.3.2  Mediators

      Per RFC 5598 [Section 5), a Mediator takes formal delivery of a
      message and then forwards it to some new address. Mailing lists
      and Aliasing are examples.

>    direct it to some external mailbox.  At the time of this writing, the
>    near-universal practice of such services is to use the original "MAIL

    At the time of this writing, many instances of such services use the 
original "MAIL From" address when...

>    FROM" of a message when re-injecting it for delivery to the external
>    mailbox.  [RFC1123] and [RFC5321] describe this action as an "alias"
>    rather than a "mail list".  This means the external mailbox's MTA

    external mailbox's -> new address's

>    sees all such mail in a connection from a host of the forwarding
>    service, and so the "MAIL FROM" identity will not, in general, pass
>    authorization.
>
>    Appendix D provides some operational suggestions to adapt these
>    services to an SPF-aware environment.

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Feb 2013 19:05:59 +0100

Just mumbling on the term "Mediator"... apologies for being lengthy

On Sun 17/Feb/2013 17:39:36 +0100 Dave Crocker wrote:
> definition of 'forwarding service'.  (FWIW, on review I suspect the
> text in RFC 5598 could be significantly improved, concerning the terms
> distinctive terms -- because the word 'forward' has a variety of
> common uses in email discussion and, therefore, is too generic to be
> precise.

Yes, forwarding is also used to refer to the "Fwd:" client's action.
For a server, the same verb can signify store-and-forward with no
changes at all, as well as "Alias" or "List" processing.  Ambiguity is
further exasperated by the sentence:

 Note that the key difference between handling aliases (Section 3.9.1)
 and forwarding (this subsection) is the change to the backward-
 pointing address in this case.

That text appears verbatim in Section 3.9.2 as well as in Section 4.4
of RFC 5321.

Notwithstanding all that ambiguity, the term is widely used.

> sub-case.  Intro paragraph to Section 5 of RFC5598: "A Mediator
> forwards a message through are-posting process."
> 
> 
> It is likely to be counter-productive for the current draft to invent
> a new term and proceed to offer it's own definition.  This probably is
> not -- and I believe should not be -- the intent, but I think it's the

That's already the title of Section 10.3.  BTW, the term "Mediator" is
not less ambiguous.  Googling for "Mediator" and "SMTP", a good deal
of the pages I found seem to use the term referring to a software
pattern, whereby a mediator is a sort of behavioral wrapper around
another piece of software.  A few software products are actually
baptized with that name.

Maybe it's me, since I didn't speak this language in the cradle, but
it seems that text talking about Mediators in the sense of email-arch
needs to explicitly refer to RFC 5598 to be unambiguous.  IMHO,
Section 5 of RFC 5598 describes an interesting concept and makes an
architectural point well, but it fails to supply a useful, general
purpose term.

The term "forwarding" seems to be well defined in the I-D.  It is
neither an "Alias", since it targets an external address, nor a
"ReSender", since it may keep the envelope sender intact.  It is not
exactly a new term, e.g. Patrik Fältström used it in his presentation
http://csrc.nist.gov/spam/paf.pdf in 2004, and it was written exactly
as "forwarding services" in the mailflows diagram that has been
standing out at openspf.org for years.  Lacking a better term, I'd
stick to it:  "SPF breaks mediators" would never mean the same thing.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 23 Feb 2013 18:37:57 -0500

On Sunday, February 17, 2013 08:39:36 AM Dave Crocker wrote:

Thanks for the feedback.  I agree that we need to get this right.  I'm pulling 
out one bit of commentary for further discussion.  The rest need discussion 
too, but focusing one bit first ...

> enormous operational import for SPF...

The basis for the claim is a combination of personal experience and 
recollections of previous discussions of the topic.  I'm currently subscribed 
to dozens of mailing lists and have been using mailing lists for almost two 
decades.  I do not recall the last time I saw a mailing list that did not 
retransmit using it's own Mail From/Return Path.  I'm surprised this question 
is even controversial.  In a nearly a decade of work on SPF I don't recall an 
issue with this ever coming up.

Does anyone have experience with mailing lists that don't use their own Mail 
From/Return Path?  How would they possibly do subscriber management if they 
don't get the bounces?

Perhaps I misunderstand your point here?

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sat, 23 Feb 2013 22:39:37 -0500

> Perhaps I misunderstand your point here?

Not to dwell much on it, overall, there are several kinds of "mailing 
list."  One that is a basic expansion and can be done at the SMTP level, 
the payloads is not altered (just standard trace lines added); One where 
there is a List Management Software/Server (MLS) with special list agent 
addresses; and then you have like this one news letter customer we have 
who uses EUDORA and they manage their addresses book A.K.A. "MAILING 
LIST" from there.  Supposedly its because of an old school expensive 
newsletter publishing package they have that hooks up with EUDORA.  
Believe me, I've tried to get them to use a real mailing list package.  
Anyway, in this case, their 5321.MailFrom and 5322.From is a real 
person, not some automated list admin/error/ return/bounce MAILER DAEMON 
address mixed in with a real from person.

I think SPF described the List Management Software/Servers types and I 
think in this case, it is "more" correctly stated and well understood 
too.   It may wish to describe the "other" forms because its quite 
possible to have simple expansions at the SMTP level where it internally 
turns around and just blast outbound mail. No headers or body is 
altered. No hard rule here what the return path should be.   RFC6377 
touches base with types but more from a point of view of DKIM and body 
changes that affect signatures, but not so much about return paths are 
used (unless it is considering Sender: changes).

SPF is about the return path (envelope level domains) - no mas, so in my 
view, keep the focus with this and possibly just talk about any 
redistribution mail bot or logic needs to take into account the return 
path domain and IP SPF relationship when redistributing mail.  A MLS 
(Mailing List Server) does in general have a special List Agent for 
bounces and returns, but it doesn't have to be for all the different 
kinds of "mailing list" methods.

--
HLS

---

From: S Moonesamy <[email-masked]>
Date: Mon, 25 Feb 2013 13:12:58 -0800

Hello,

This is an individual comment.  From Section 10.3.1 of 
draft-ietf-spfbis-4408bis-11:

  "Mailing lists have to be aware of how they re-inject mail that is
   sent to the list."

What is the meaning of "mailing lists" in the above?

The reason I am asking that question is to clarify what the working 
group is talking about.  It may then be easier to resolve Issue #56.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Feb 2013 16:35:20 -0500

> group is talking about.  It may then be easier to resolve Issue #56.

Dave also commented on this.  We are currently communicating via a mailing 
list.  This area of text still needs work.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 25 Feb 2013 13:41:14 -0800

> issue with this ever coming up.

On reflection, I withdraw the question, because it takes the concern 
about the document in the wrong direction:  This is a protocol spec, not 
an opererations guideline that might permit citing heuristics.

The current text asserts a useful heuristic, but "violations" of the 
heuristic are not violations of protocol.

> Perhaps I misunderstand your point here?

My core point is that mailing lists are not required to create a new 
rfc5321.mailfrom address, but it they don't, SPF breaks (absent 
registration of the mediator in the SPF record.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Feb 2013 16:53:44 -0500

On Monday, February 25, 2013 01:41:14 PM Dave Crocker wrote:
> > recollections of previous discussions of the topic.  I'm currently
> > subscribed to dozens of mailing lists and have been using mailing lists
> > for almost two decades.  I do not recall the last time I saw a mailing
> > list that did not retransmit using it's own Mail From/Return Path.  I'm
> > surprised this question is even controversial.  In a nearly a decade of
> > work on SPF I don't recall an issue with this ever coming up.
> 

What if we redo this section in terms of mediators that change mail from to 
something local to the mediator and mediators that leave it unchanged?  I 
think that is the key point and while one can make generalizations about which 
types of mediators do what, it may work better to write about this topic 
primarily in terms of how mediators behave relative to mail from than what 
type of mediator they are.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Mon, 25 Feb 2013 14:15:26 -0800

At 13:41 25-02-2013, Dave Crocker wrote:
>about the document in the wrong direction:  This is a protocol spec, 
>not an opererations guideline that might permit citing heuristics.

There are issues which can be non-issues, depending on the path 
taken, e.g. protocol specs.

Scott Kitterman posted a suggestion at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03287.html 
There won't be any progress if there aren't any comments from working 
group participants.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 28 Feb 2013 23:00:21 -0800

Hi Alessandro,
>type of mediator they are.

Are you ok with the above-mentioned approach?

Regards,
S. Moonesamy