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

From: Alessandro Vesely <[email-masked]>
Date: Fri, 01 Mar 2013 19:30:50 +0100

On Fri 01/Mar/2013 08:00:21 +0100 S Moonesamy wrote:
> At 13:53 25-02-2013, Scott Kitterman wrote:
>> 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.
> 
> Are you ok with the above-mentioned approach?

I'm not sure what Scott is planning to come out with.  Some 5598 terms
are not very widespread, and would need to be replaced in contexts
such as, say, a wikipedia article on SPF.  Their extreme use might
lower the comprehensibility/accessibility of the spec, IMHO.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 01 Mar 2013 18:37:51 -0800

On 2/25/2013 1:53 PM, Scott Kitterman wrote:
>> 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.
> 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.

Sounds like a good approach.  Describe a known issue, in terms of the 
behaviors and their effects, without attempting to make normative 
declarations or even recommendations.

In terms of 5598, the label Mediator is defined distinctly as "A 
Mediator forwards a message through a re-posting process." This includes 
"RFC5321.RcptTo:  Set by - Mediator Author".  That sets the stage for 
the problematic interaction with SPF, if the Mediator chooses to set the 
RcptTo to be the address from the original posting.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: S Moonesamy <[email-masked]>
Date: Sat, 02 Mar 2013 00:25:24 -0800

Hi Scott,
>lower the comprehensibility/accessibility of the spec, IMHO.

Could you comment on the above?

Thanks,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 02 Mar 2013 09:11:49 -0500

>Could you comment on the above?

I'm not sure either. I didn't writeit yet.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sat, 02 Mar 2013 07:57:50 -0800

> I'm not sure either. I didn't writeit yet.

If Alessandro wishes to make specific suggestions for specific changes, 
the rest of us will be able to comment.

Absent that, we'd just be guessing.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 03 Mar 2013 07:58:48 +0100

> the rest of us will be able to comment.

That section, currently 10.3.2, looks rather good to me.  If we need to
make it even better, I'd suggest the following changes to the first
paragraph:

* clarify that "email forwarder" is used as a synonym of "forwarding
  service" in this document.

* Drop "Alias" from the section's title.

* Drop citation of RFC 1123, and the term "List", copy and paste Dave's
  explanation instead.

* Separate definition from SPF effect.  Update that "near-universal",
  which was true at the time of writing 4408.

None of those points is essential.  Applying them all might produce an
outcome more or less like so:

10.3.2. Forwarding Services

   Forwarding services, which we also call email forwarders, take mail
   that is received at a mailbox and direct it to some external mailbox.
   [RFC5321] describes this action as an alias expansion.  In terms of
   [RFC5598], the label Mediator is defined distinctly as "A Mediator
   forwards a message through a re-posting process." This includes
   "RFC5321.RcptTo:  Set by - Mediator Author".  At the time of this
   writing, a large number of such services follow the only practice
   described by [RFC5321], which is to use the original "MAIL FROM" of
   a message when re-injecting it for delivery to the external mailbox.
   This means the external mailbox's MTA 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.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Mar 2013 11:00:37 -0800

Hi Scott,
>I'm not sure either. I didn't writeit yet.

Alessandro Vesely suggested some text at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03295.html 
Can that text be used or would you like to suggest text?

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Mar 2013 14:05:50 -0500

> Can that text be used or would you like to suggest text?

I don't think that suggestion really addresses the issue.  I do plan on 
tackling it, possibly this weekend.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 16 Mar 2013 16:01:31 -0400

>    FROM" identity will not, in general, pass authorization.

I think this is now OBE based on me reworking 10.3 with some offlist help from 
Dave.  The text is now much simplified.  I'm also going to fix up Appendix D to 
refer to mediators and not just forwarders.

Here's what I have locally now:

> 10.3.  Mediators
> 
>    Mediators are a type of User actor.[RFC5598].  That is, a mediator
>    takes 'delivery' of a message and posts a 'submission' of a new
>    message.  The mediator can make the newly-posted message be as
>    similar or as different from the original message as they wish.
>    Examples include mailing lists (see [RFC5598] Section 5.3) and
>    ReSenders ([RFC5598] Section 5.2).  This is discussed in [RFC5321],
>    Section 3.9.  For the operation of SPF, the essential concern is the
>    email address in the 5321.MailFrom command for the new message.
>    
>    Because SPF evaluation is based on the IP Address of the "last"
>    sending SMTP server, the address of the mediator will be used, rather
>    than the address of the SMTP server that sent the message to the
>    mediator.  Some mediators retain the email address from the original
>    message, while some use a new address.
>    
>    If the address is the same as for the original message, and the
>    original message had an associated SPF record, then the SPF
>    evaluation will fail unless mitigations such as those described in
>    Appendix D are used.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Mar 2013 13:32:59 +0100

On Sat 16/Mar/2013 21:01:31 +0100 Scott Kitterman wrote:
>> That section, currently 10.3.2, looks rather good to me.  [...]
> 
> I think this is now OBE based on me reworking 10.3 with some
> offlist help from Dave.  The text is now much simplified.

Yes.  Keeping an "also known as forwarders" wouldn't hurt, though.

> I'm also going to fix up Appendix D to refer to mediators and not
> just forwarders.

If I may propose a change to appendix D, that would be to promote its
top-level bullets to proper subsections, and use titles such as
*mitigation that can be operated by the sender*.  The introductory
paragraph could then be reworded like so:

OLD
   There are three places that techniques can be used to ameliorate
   unintended SPF failures with mediators.

NEW
   Each actor can deploy various techniques to ameliorate unintended
   SPF failures when messages are mediated.

Or some such.  Mentioning some valid reasons why an actor cannot do
what the others would expect might refrain people from prompting in
vain.  In particular, SRS deserves both a better presentation and an
argument against it.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Mar 2013 15:27:12 -0400

> vain.  In particular, SRS deserves both a better presentation and an

I find adding the subsections makes it clearer, so I've committed that locally 
for -13.

Scott K