Subject: Re: [spfbis] #4: RFC 4408 Section 4.1

From: S Moonesamy <[email-masked]>
Date: Mon, 27 Feb 2012 16:26:22 -0800

At 13:01 07-02-2012, spfbis issue tracker wrote:
>#4: RFC 4408 Section 4.1
>
>  Message from Hector Santos on 5 Feb 2012:
>
>  This may need a charter change/adjustment, but I would like to proposed
>  section 4.1 be updated to support RFC 4405 by adding an optional
>  [submitter] argument to the check_host() function model:
>
>      4.1.  Arguments
>
>      The check_host() function takes these arguments:
>
>      <ip>     - the IP address of the SMTP client that is emitting the
>                 mail, either IPv4 or IPv6.
>
>      <domain> - the domain that provides the sought-after authorization
>                 information; initially, the domain portion of the "MAIL
>                 FROM" or "HELO" identity.
>
>  |   [submitter] - RFC4409, SUBMITTER keyword passed to the "MAIL FROM"
>
>
>
>  Our SMTP server does not directly support SENDER-ID. However, our SPF
>  implementation indirectly supports SENDER-ID via the RFC4405 SUBMITTER
>  keyword, if any. Our SPF check_host() process model is:
>
>      result = check_host(ip, domain [, submitter])
>
>
>  IMO, while we may not to get into SENDER-ID discussions for SPFBIS, the WG
>  should not exclude the possibility for any industry support for SUBMITTER
>  and it should be discussed as as realistic possibility to be part of the
>  check_host() arguments. If you agree, it should be included in updating
>  SPF-BIF.

[snip]

>Ticket URL: <http://trac.tools.ietf.org/wg/spfbis/trac/ticket/4>

Please comment on the above issue.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2012 19:38:30 -0500

On Monday, February 27, 2012 04:26:22 PM S Moonesamy wrote:
> >  |   
> >  |   [submitter] - RFC4409, SUBMITTER keyword passed to the "MAIL
> >  |   FROM"
> >  
> >  IMO, while we may not to get into SENDER-ID discussions for SPFBIS,
> >  the WG should not exclude the possibility for any industry support
> >  for SUBMITTER and it should be discussed as as realistic possibility
> >  to be part of the check_host() arguments. If you agree, it should be
> >  included in updating SPF-BIF.
> 
> [snip]
> 

It's out of scope.  SUBMITTER is a Sender ID concept unrelated to SPF.  The 
only purpose SUBMITTER serves is to give an advance look at PRA prior to going 
to DATA.  It's inextricably linked to Sender ID and has no purpose in an SPF 
context.

While there are no doubt proprietary systems that support SUBMITTER, AFAIK 
there's no open source implementation which suggests to me that the interest 
in it was very narrow in any case.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Feb 2012 00:52:37 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Monday, February 27, 2012 4:39 PM
> To: [email-masked]
> Subject: Re: [spfbis] #4: RFC 4408 Section 4.1
> 
> It's out of scope.

+1.  So sayeth the charter:

	Changes to the SPF specification will be limited to the correction
	of errors, removal of unused features, addition of any enhancements
	that have already gained widespread support, and addition of
	clarifying language.

Adding SUBMITTER as an optional parameter to check_host() falls within none of those clauses.

(The SUBMITTER data we have so far is, however, important to the eventual "conclusion of the experiment" discussion we need to have.)

-MSK

---

From: Dotzero <[email-masked]>
Date: Mon, 27 Feb 2012 20:14:36 -0500

> (The SUBMITTER data we have so far is, however, important to the eventual "conclusion of the experiment" discussion we need to have.)

I agree with others that this should be considered out of scope
(ruling from the chairs please).

Mike

---

From: Hector Santos <[email-masked]>
Date: Mon, 27 Feb 2012 20:32:28 -0500

> to DATA.  It's inextricably linked to Sender ID and has no purpose in an SPF 

-1, see below.

> in it was very narrow in any case.

Enable the SUBMITTER SMTP extension in your SMTP server and there is 
clear evidence of wide client support.

To integrators, when both identities are presented and both are 
different, a query is done either 5321.MAILFROM done and/or for 
5321.MAILFROM SUBMITTER domain.

Actions possible in SPF-BIS:

1) Provide semantics for clients to IGNORE SUBMITTER domains presented.

2) Provide logic to described how to handle it when they are different.

If #1 is chosen, then the fate of the 4405/4406 protocols has been 
predetermined for abandonment.  If abandonment is the charter goal, 
then #1 or nothing needs be stated which the latter leaving it 
ambiguous form for system integrators of both protocols.

In other words, if there is a possibility 4405/4406 is not going to be 
abandoned, then SPF-BIS has a clear role to consider it.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2012 01:43:15 -0000

>Please comment on the above issue.

It's a terrible idea.  I encourage you to close the ticket.

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 28 Feb 2012 09:14:00 +0100

On 2/28/12 1:26 AM, S Moonesamy wrote:

[...]

> Please comment on the above issue.
Out of scope.

/rolf

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Feb 2012 09:40:23 +0100

On 28/Feb/12 01:38, Scott Kitterman wrote:
> [...]  The only purpose SUBMITTER serves is to give an advance look
> at PRA prior to going to DATA.  It's inextricably linked to Sender
> ID and has no purpose in an SPF context.

+1, SPF already has two identities --mfrom and helo-- that may
complement one another.  (By analogy, DKIM has SDID and AUID.)

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Feb 2012 05:10:15 -0500

> complement one another.  (By analogy, DKIM has SDID and AUID.)

SIDF/SUBMITTER offered the 3rd identity - PRA.   I don't see it as out 
of scope if the charter includes consideration for the fate of 
4405/4406/4407.

FYI, I found this section on Google Book "Microsoft Exchange Server 
2010 Unleashed"

http://books.google.com/books?id=8VC9LKT4rrwC&pg=PT501&lpg=PT501&ots=z3jeJ1ltR5&dq=SMTP+Servers+supporting+RFC+4405

     SPF only need three piece of information to work:

     o The domain in the From address in the message headers
     o The purported IP address of the email server that sent the message
     o The HELO or EHLO parameter of the server that sent the message

This is pretty wide spread.