Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-21 Thread Scott Kitterman 
On January 21, 2015 5:20:42 PM EST, Anne Bennett  wrote:
>
>Scott Kitterman  writes:
>
>> DMARC takes the SPF result and the Mail From as an input
>> (which in the case of a null Mail From is a synthetic Mail From
>> built using HELO, but that's just a coincidence).  SPF isn't
>> just a result (pass, fail, etc), it also has a domain and a
>> related identity.
>
>... in other words, aside from its presence in the null return
>path case, the HELO identity is *not* used by DMARC.
>
>
>Murray S. Kucherawy  writes:
>
>> I can say that OpenDMARC consumes the Authentication-Results field,
>or the
>> Received-SPF field if the former isn't there, but it prefers a result
>based
>> on MAIL FROM over one based on HELO if both are present.  But it will
>use
>> both.
>
>... in other words, a HELO identity *can* be used by DMARC.
>
>
>Either I'm misunderstanding both of you, or the implementations differ
>on this point.  :-(

They differ, but I think it's mostly a theoretical difference. 

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-21 Thread Scott Kitterman 
On January 21, 2015 5:01:53 PM EST, Franck Martin  
wrote:
>
>
>
>
>- Original Message -
>> From: "Scott Kitterman" 
>> To: dmarc@ietf.org
>> Sent: Tuesday, January 20, 2015 9:36:57 PM
>> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
>> 
>> On January 21, 2015 12:31:45 AM EST, Franck Martin
>
>> wrote:
>> >
>> >- Original Message -
>> >> From: "Scott Kitterman" 
>> >> To: dmarc@ietf.org
>> >> Sent: Tuesday, January 20, 2015 9:02:26 PM
>> >> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at
>it
>> >> 
>> >> On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote:
>> >> > ----- Original Message -----
>> >> > 
>> >> > > From: "Scott Kitterman" 
>> >> > > To: dmarc@ietf.org
>> >> > > Sent: Tuesday, January 20, 2015 2:49:01 PM
>> >> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while
>I'm
>> >at it
>> >> > > 
>> >> > > 
>> >> > > 
>> >> > > 
>> >> > > Last time I had stats, it was about 10% as common as Mail From
>> >oriented
>> >> > > records.  Much less common, but I wouldn't say rare.  When
>done
>> >this way,
>> >> > > there isn't a singe "SPF" result, there are two: SPF/Mail From
>> >and
>> >> > > SPF/HELO. Only SPF/Mail From is relevant to DMARC.
>> >> > 
>> >> > Why do you say that?
>> >> > 
>> >> > DMARC takes the result from SPF (pass/fail/...) and the string
>that
>> >SPF
>> >> > used
>> >> > for this result be it mail from or helo, to check for alignment.
>> >> > 
>> >> > Did I miss something?
>> >> 
>> >> DMARC takes the SPF result and the Mail From as an input (which in
>> >the case
>> >> of
>> >> a null Mail From is a synthetic Mail From built using HELO, but
>> >that's just a
>> >> coincidence).  SPF isn't just a result (pass, fail, etc), it also
>has
>> >a
>> >> domain
>> >> and a related identity.
>> >> 
>> >
>> >If I recall the SPF spec, it specifies a MAIL FROM which is not the
>> >RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo
>based
>> >on which one was used to get the SPF result.
>> >
>> >The original SPF spec is quite confusing on that, at least for me.
>On
>> >senderid, I think they call this field mfrom to avoid confusion.
>> >
>> >It seems weird that the SPF results would depend more on the HELO
>than
>> >the RFC5321.mailfrom because if spammer.com put a SPF then
>> >
>> >mailfrom: secur...@example.com
>> >helo spammer.com
>> >
>> >would seem quite problematic
>> 
>> Which is precisely why I said HELO pass doesn't mean anything. HELO
>is really
>> for rejection on fail.
>> 
>>From http://www.openspf.org/Implementations Mail::SPF has passed the
>test suites
>
>http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm
>"Note: In the case of an empty MAIL FROM SMTP transaction parameter
>(MAIL FROM:<>), you should perform a check with the helo scope
>instead."
>
>I think we are going in circles here.
>
>The SPF spec is not clear or there is a disconnect with what's out
>there, or both...

By design, SPF doesn't go very far into what receivers should do.  Unlike 
DMARC, it actively avoids specifying receiver policy. It's not clear what to do 
because what to do is outside the scope of the specification.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-21 Thread Anne Bennett 

Scott Kitterman  writes:

> DMARC takes the SPF result and the Mail From as an input
> (which in the case of a null Mail From is a synthetic Mail From
> built using HELO, but that's just a coincidence).  SPF isn't
> just a result (pass, fail, etc), it also has a domain and a
> related identity.

... in other words, aside from its presence in the null return
path case, the HELO identity is *not* used by DMARC.


Murray S. Kucherawy  writes:

> I can say that OpenDMARC consumes the Authentication-Results field, or the
> Received-SPF field if the former isn't there, but it prefers a result based
> on MAIL FROM over one based on HELO if both are present.  But it will use
> both.

... in other words, a HELO identity *can* be used by DMARC.


Either I'm misunderstanding both of you, or the implementations differ
on this point.  :-(



Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-21 Thread Franck Martin 




- Original Message -
> From: "Scott Kitterman" 
> To: dmarc@ietf.org
> Sent: Tuesday, January 20, 2015 9:36:57 PM
> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> 
> On January 21, 2015 12:31:45 AM EST, Franck Martin 
> wrote:
> >
> >- Original Message -
> >> From: "Scott Kitterman" 
> >> To: dmarc@ietf.org
> >> Sent: Tuesday, January 20, 2015 9:02:26 PM
> >> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> >> 
> >> On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote:
> >> > - Original Message -
> >> > 
> >> > > From: "Scott Kitterman" 
> >> > > To: dmarc@ietf.org
> >> > > Sent: Tuesday, January 20, 2015 2:49:01 PM
> >> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm
> >at it
> >> > > 
> >> > > 
> >> > > 
> >> > > 
> >> > > Last time I had stats, it was about 10% as common as Mail From
> >oriented
> >> > > records.  Much less common, but I wouldn't say rare.  When done
> >this way,
> >> > > there isn't a singe "SPF" result, there are two: SPF/Mail From
> >and
> >> > > SPF/HELO. Only SPF/Mail From is relevant to DMARC.
> >> > 
> >> > Why do you say that?
> >> > 
> >> > DMARC takes the result from SPF (pass/fail/...) and the string that
> >SPF
> >> > used
> >> > for this result be it mail from or helo, to check for alignment.
> >> > 
> >> > Did I miss something?
> >> 
> >> DMARC takes the SPF result and the Mail From as an input (which in
> >the case
> >> of
> >> a null Mail From is a synthetic Mail From built using HELO, but
> >that's just a
> >> coincidence).  SPF isn't just a result (pass, fail, etc), it also has
> >a
> >> domain
> >> and a related identity.
> >> 
> >
> >If I recall the SPF spec, it specifies a MAIL FROM which is not the
> >RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo based
> >on which one was used to get the SPF result.
> >
> >The original SPF spec is quite confusing on that, at least for me. On
> >senderid, I think they call this field mfrom to avoid confusion.
> >
> >It seems weird that the SPF results would depend more on the HELO than
> >the RFC5321.mailfrom because if spammer.com put a SPF then
> >
> >mailfrom: secur...@example.com
> >helo spammer.com
> >
> >would seem quite problematic
> 
> Which is precisely why I said HELO pass doesn't mean anything. HELO is really
> for rejection on fail.
> 
>From http://www.openspf.org/Implementations Mail::SPF has passed the test 
>suites

http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm
"Note: In the case of an empty MAIL FROM SMTP transaction parameter (MAIL 
FROM:<>), you should perform a check with the helo scope instead."

I think we are going in circles here.

The SPF spec is not clear or there is a disconnect with what's out there, or 
both...

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-21 Thread Hector Santos 

On 1/20/2015 5:54 PM, Anne Bennett wrote:


Franck Martin  writes:


Yes, RFC7208 says evaluate both in parallel, but the result
of an spf=pass/fail is highly constrained on the success or
failure of the MAIL FROM spf test.


Actually, it recommends checking the HELO identity first,
because if you get a definite result from that, you may not
have to evaluate the MAIL FROM identity at all.


However, in practice, optimized receivers will wait for a valid local 
RCPT TO (Forward-path) address before exerting any potentially, high 
overhead, wasteful DNS application queries.


For remote RCPT TO address, this generally requires 
authentication/authorization to relay mail. Under the SUBMIT protocol, 
HELO/EHLO can be enforced.  Our package does not enforce it (it was 
relaxed) for PORT 587 operations because AUTH is required anyway and 
in the SOHO market, with NATs around, it was not always possible to 
put a proper machine client host name for the EHLO/HELO field or the 
Domain IP Literal was incorrect (did not match the connection ip).


But for public port 25 operations, there is a high payoff to wait.  We 
realized a 60% savings in DNS lookups because 60% of the RCPT TO were 
invalid!  SMTP RFC5321 even provides insight into using delay strategies:


   SMTP Section 3.3 Mail Transactions

   .

   Despite the apparent scope of this requirement, there are
   circumstances in which the acceptability of the reverse-path may
   not be determined until one or more forward-paths (in RCPT
   commands) can be examined.  In those cases, the server MAY
   reasonably accept the reverse-path (with a 250 reply) and then
   report problems after the forward-paths are received and
   examined.  Normally, failures produce 550 or 553 replies.


Overall, all specs are just guidelines. You don't have to follow them 
exactly where it doesn't make sense.  A RECOMMEND is functionally 
equivalent to a SHOULD, it is not a MUST.


As long as the end result is the same, we should be generally ok so we 
are basically talking about optimization concepts.


--
HLS


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-21 Thread Hector Santos 

On 1/21/2015 10:50 AM, Michael Jack Assels wrote:

On Tue, 20 Jan 2015 16:14:32 CST,
Franck Martin  wrote:


[...]
Your confusion on HELO is may be related to the fact that the
HELO string is only used when the MAIL-FROM: is empty?

There is some text here:
http://trac.tools.ietf.org/html/rfc7208#section-10.1.3

The HELO string is not evaluated all the time, it is more like
a fall back.


It's already been pointed out that
http://trac.tools.ietf.org/html/rfc7208#section-2.3
RECOMMENDs checking the HELO string first; hence our confusion.


Implementators should know this would be a high DNS waste and overhead 
suggestion.


The optimized approach is to delay any DNS query applications and 
first capture the SMTP process field parameters to determine what 
augmented DNS applications apply, what needs be queried and 
calculated.  For example, SMTP has offered guidance in this area for 
delaying the reverse-path (MAIL FROM) processing until the 
forward-path (RCPT TO)  is known:


   SMTP Section 3.3 Mail Transactions

   .

   Despite the apparent scope of this requirement, there are
   circumstances in which the acceptability of the reverse-path may
   not be determined until one or more forward-paths (in RCPT
   commands) can be examined.  In those cases, the server MAY
   reasonably accept the reverse-path (with a 250 reply) and then
   report problems after the forward-paths are received and
   examined.  Normally, failures produce 550 or 553 replies.

HELO/EHLO has historically been known to be incorrect for many 
reasons.  At best, the receiver can perform a field syntax check 
including a required bracketed IP Domain literal check to make sure it 
matches the connection IP address before doing anything else and 
allowing the next SMTP state to continue.


The reality is that SMTP receivers are not going to know the DMARC 
status of an incoming anonymous client until the DATA payload is 
received.  It doesn't need DMARC information for SPF -ALL rejection 
policies.   SPF -ALL policy SHOULD be processed immediately before 
DATA.   But I think DMARC wants you further delay SPF processing until 
DATA payload is received (for reporting reasons I suppose).


Since it can be potentially high overhead of getting a payload with no 
DMARC information, SPF receivers may not wait until DATA is received 
to process SPF.


Incidentally,  SENDER-ID [1] resolve this DATA overhead potential 
issue with the SUBMITTER optimization [2] where the PRA (Purported 
Responsible Address) [3] was passed to the MAIL FROM state:


  MAIL FROM: SUBMITTER=pra

This tells the SPF processor that the pra DOMAIN is the lookup domain.

DMARC can borrow from such ideas to pass the 5322 Author Domain (DMARC 
domain), and better yet even pass the policy as well to help optimized 
the receiver:


  MAIL FROM:[ DMARC=author-domain[ DMARC.P=reject]]

This DMARC ESMTP idea would probably only work if there is a TRUST 
that the that payload is DKIM signed correctly using the problem 
5322.From address.



--
HLS


[1] https://tools.ietf.org/html/rfc4406
[2] https://tools.ietf.org/html/rfc4405
[3] https://tools.ietf.org/html/rfc4407


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-21 Thread Michael Jack Assels 
On Tue, 20 Jan 2015 16:14:32 CST, 
Franck Martin  wrote:

> [...]
> Your confusion on HELO is may be related to the fact that the
> HELO string is only used when the MAIL-FROM: is empty?
>
> There is some text here:
> http://trac.tools.ietf.org/html/rfc7208#section-10.1.3
> 
> The HELO string is not evaluated all the time, it is more like
> a fall back.

It's already been pointed out that
   http://trac.tools.ietf.org/html/rfc7208#section-2.3
RECOMMENDs checking the HELO string first; hence our confusion.
It'a not difficult to imagine a HELO string that passes SPF but
doesn't align with the RFC5322.From with a MAIL FROM domain that
passes SPF *and* aligns, while the DKIM-Signature validates but
doesn't align.  An implementation of DMARC that follows the SPF
recommendation will, as I understand it, produce [SPF:fail,
DKIM:fail], despite the existence of an SPF-valid MAIL FROM
domain that aligns with the RFC5322.From domain.  It seems
to be the consensus that this would be wrong, and that existing
DMARC implementations don't behave that way.  That's fine by me,
but it needs to be said out loud that DMARC implementations
MUST NOT (SHOULD NOT?) follow rfc7208#section-2.3's
recommendation.

> Also I have trouble to understand why you may be affected by
> your OD? What is the relation between your domain and your OD?
> I suspect this is concordia.ca?

Yes, it's Concordia.ca.  Some details:  Concordia.ca is Concordia
University, while encs.concordia.ca is just the Faculty of
Engineering and Computer Science at Concordia, so it's
appropriate that concordia.ca is the OD.  They've delegated 
encs.concordia.ca to us, and we (ENCS staff) manage it ourselves,
with minimal interaction.

> If you look at the public suffix list, google has put a
> separation at blogspot.com level, so that each hosting domain,
> can be organizationally separated.
> 
> https://publicsuffix.org/list/effective_tld_names.dat

Are you saying that any owner of a registered domain can
arrange to the suffix list on request, thereby allowing
next-level subdomains to be elevated to ODs?  If that's
right, I'd certainly be keen on suggesting to our
concordia.ca colleagues that they do us that favour.

> I would suggest you publish a DMARC record in monitoring mode
> (p=none) so that you get reports (and no impact) and better
> understand your email infrastructure and what needs to be done.

We'll certainly publish a DMARC record with p=none.

Thanks,

MJA

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Scott Kitterman 
On January 21, 2015 12:31:45 AM EST, Franck Martin  
wrote:
>
>- Original Message -
>> From: "Scott Kitterman" 
>> To: dmarc@ietf.org
>> Sent: Tuesday, January 20, 2015 9:02:26 PM
>> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
>> 
>> On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote:
>> > - Original Message -
>> > 
>> > > From: "Scott Kitterman" 
>> > > To: dmarc@ietf.org
>> > > Sent: Tuesday, January 20, 2015 2:49:01 PM
>> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm
>at it
>> > > 
>> > > 
>> > > 
>> > > 
>> > > Last time I had stats, it was about 10% as common as Mail From
>oriented
>> > > records.  Much less common, but I wouldn't say rare.  When done
>this way,
>> > > there isn't a singe "SPF" result, there are two: SPF/Mail From
>and
>> > > SPF/HELO. Only SPF/Mail From is relevant to DMARC.
>> > 
>> > Why do you say that?
>> > 
>> > DMARC takes the result from SPF (pass/fail/...) and the string that
>SPF
>> > used
>> > for this result be it mail from or helo, to check for alignment.
>> > 
>> > Did I miss something?
>> 
>> DMARC takes the SPF result and the Mail From as an input (which in
>the case
>> of
>> a null Mail From is a synthetic Mail From built using HELO, but
>that's just a
>> coincidence).  SPF isn't just a result (pass, fail, etc), it also has
>a
>> domain
>> and a related identity.
>> 
>
>If I recall the SPF spec, it specifies a MAIL FROM which is not the
>RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo based
>on which one was used to get the SPF result.
>
>The original SPF spec is quite confusing on that, at least for me. On
>senderid, I think they call this field mfrom to avoid confusion.
>
>It seems weird that the SPF results would depend more on the HELO than
>the RFC5321.mailfrom because if spammer.com put a SPF then
>
>mailfrom: secur...@example.com
>helo spammer.com
>
>would seem quite problematic

Which is precisely why I said HELO pass doesn't mean anything. HELO is really 
for rejection on fail. 

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Franck Martin 

- Original Message -
> From: "Scott Kitterman" 
> To: dmarc@ietf.org
> Sent: Tuesday, January 20, 2015 9:02:26 PM
> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> 
> On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote:
> > - Original Message -
> > 
> > > From: "Scott Kitterman" 
> > > To: dmarc@ietf.org
> > > Sent: Tuesday, January 20, 2015 2:49:01 PM
> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> > > 
> > > 
> > > 
> > > 
> > > Last time I had stats, it was about 10% as common as Mail From oriented
> > > records.  Much less common, but I wouldn't say rare.  When done this way,
> > > there isn't a singe "SPF" result, there are two: SPF/Mail From and
> > > SPF/HELO. Only SPF/Mail From is relevant to DMARC.
> > 
> > Why do you say that?
> > 
> > DMARC takes the result from SPF (pass/fail/...) and the string that SPF
> > used
> > for this result be it mail from or helo, to check for alignment.
> > 
> > Did I miss something?
> 
> DMARC takes the SPF result and the Mail From as an input (which in the case
> of
> a null Mail From is a synthetic Mail From built using HELO, but that's just a
> coincidence).  SPF isn't just a result (pass, fail, etc), it also has a
> domain
> and a related identity.
> 

If I recall the SPF spec, it specifies a MAIL FROM which is not the 
RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo based on which 
one was used to get the SPF result.

The original SPF spec is quite confusing on that, at least for me. On senderid, 
I think they call this field mfrom to avoid confusion.

It seems weird that the SPF results would depend more on the HELO than the 
RFC5321.mailfrom because if spammer.com put a SPF then

mailfrom: secur...@example.com
helo spammer.com

would seem quite problematic




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Scott Kitterman 
On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote:
> - Original Message -
> 
> > From: "Scott Kitterman" 
> > To: dmarc@ietf.org
> > Sent: Tuesday, January 20, 2015 2:49:01 PM
> > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> > 
> > 
> > 
> > 
> > Last time I had stats, it was about 10% as common as Mail From oriented
> > records.  Much less common, but I wouldn't say rare.  When done this way,
> > there isn't a singe "SPF" result, there are two: SPF/Mail From and
> > SPF/HELO. Only SPF/Mail From is relevant to DMARC.
> 
> Why do you say that?
> 
> DMARC takes the result from SPF (pass/fail/...) and the string that SPF used
> for this result be it mail from or helo, to check for alignment.
> 
> Did I miss something?

DMARC takes the SPF result and the Mail From as an input (which in the case of 
a null Mail From is a synthetic Mail From built using HELO, but that's just a 
coincidence).  SPF isn't just a result (pass, fail, etc), it also has a domain 
and a related identity.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Scott Kitterman 
On Tuesday, January 20, 2015 22:57:34 John Levine wrote:
> >HELO results are unrelated to DMARC.
> 
> Is that still true when the bounce address is empty?  It's fairly common
> to have an NDR with an empty bounce address and
> 
>  From: MAILER-DAEMON@flaky.example
> 
> Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user
> supposed to do?

Subtle point, but that's not a HELO result, that's a Mail From result 
evaluated using a synthetic Mail From based on HELO.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Scott Kitterman 
On Tuesday, January 20, 2015 22:55:58 Terry Zink wrote:
> >7208 actually recommends that the HELO string be evaluated every time.
> >
> > http://trac.tools.ietf.org/html/rfc7208#section-2.3
> 
> They do say to check it both times but I don't agree with the rationale
> provided. Expanding on the excerpt that Laura provided:
> 
> 2.3.  The "HELO" Identity
> 
>It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
>identity but also separately check the "HELO" identity by applying
>the check_host() function (Section 4) to the "HELO" identity as the
>.  Checking "HELO" promotes consistency of results and can
>reduce DNS resource usage.
> 
> [tzink] How does this reduce DNS resource usage? Aren't we now checking two
> domains instead of one?

Note: This point was actively discussed during the SPFbis working group.

HELO records are virtually always very simple: zero or one additional DNS 
lookup.  If you get a fail result and choose to reject as a result, you never 
have to even retrieve the Mail From record, let alone do all the lookups 
triggered by the terms in the record.

This is for SPF on it's own and not particularly relevant if you want to feed 
SPF results into DMARC.

>If a conclusive determination about the
>message can be made based on a check of "HELO", then the use of DNS
>resources to process the typically more complex "MAIL FROM" can be
>avoided.
> 
> [tzink] Disagree here, especially the case of shared hosting environment
> like Office 365. Customers relay spam through us and sometimes that spam
> will fail SPF checks. Yet, if you checked the SPF record on the HELO string
> (e.g., na01-bn1-obe.outbound.protection.outlook.com), that would pass an
> SPF check every time whereas the @paypal.com in the MAIL FROM would fail
> SPF. Seems like you can only be sure you can trust the HELO when you are
> sure the sender locks down the outbound mail infrastructure, and that is
> not the case everywhere.

Agree.  The only definitive result you can get from SPF HELO checks is reject.  
It'll never tell you something is good.

>   Additionally, since SPF records published for "HELO"
>identities refer to a single host, when available, they are a very
>reliable source of host authorization status.  Checking "HELO" before
>"MAIL FROM" is the RECOMMENDED sequence if both are checked.
> 
> [tzink] They are for a single host but not necessarily for a single
> organization or even a series of organizations with the same set of
> policies. It seems like this RFC does not have a mult-tenant hosted
> environment in mind, and that is becoming more common.

It doesn't matter.  The HELO name is (should be) particular to that host so it 
works regardless.  Recall that for SPF there's no notion of alignment so 
there's no requirement that the HELO name have anything to do with any other 
identity in the message.

To read RFC 7208 as intended, you have to forget DMARC exists.  It was written 
to stand alone.  It's up to DMARC to explain how it wants to be built on top 
of SPF.

Scott K

> -- Terry
> 
> > 7208 actually recommends that the HELO string be evaluated every time.
> > http://trac.tools.ietf.org/html/rfc7208#section-2.3
> > 
> > "2.3.  The "HELO" Identity
> > 
>  >  It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
>  >  identity but also separately check the "HELO" identity by applying
>  >  the check_host() function (Section 4) to the "HELO" identity as the
>  >  
> >   .  Checking "HELO" promotes consistency of results and can
> >   reduce DNS resource usage."
> > 
> > laura
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Murray S. Kucherawy 
On Tue, Jan 20, 2015 at 1:44 PM, Anne Bennett 
wrote:

> I apologize for my inadvertently poor timing; I was catapulted
> into all this last week when my parent domain (also my
> Organizational Domain) published an SPF record and a DKIM
> record, and we became concerned that they might implement DMARC,
> which could have a very negative impact on our mail services
> unless we take action quickly and become prepared to publish
> our own DMARC record.  Thus, my sudden plunge into all these
> RFCs and this draft.  :-/
>

Well, shoot.  Timing notwithstanding, I also apologize if I came across as
dismissing your use case as unimportant.  I thought you were merely
providing reviews as an interested party, not actually addressing a
production problem.

Since, as pointed out by Tim Draegen, "DMARC implementations are
> already in the wild and deployed", one would expect to be able
> to determine what those implementations do, based on this spec.
> Sadly this hasn't been possible (so far) for me and my colleague
> Michael Jack Assels, despite our being two fairly smart cookies,
> with nearly a half-century of e-mail experience between us.
>

I can't speak for most of the operators you're probably dealing with, many
of whom have their own implementations.

I can say that OpenDMARC consumes the Authentication-Results field, or the
Received-SPF field if the former isn't there, but it prefers a result based
on MAIL FROM over one based on HELO if both are present.  But it will use
both.

I'm pretty sure Gmail people are on, or at least following, this list;
hopefully someone there will comment.

I want to emphasize that I think that the documents in question
> (at least this draft and RFC7208 - I've barely skimmed RFC6376
> on DKIM yet) individually are well written, but trying to
> understand them in context together is proving to be quite
> a challenge, and the lack of clarity on the HELO issue is
> the biggest part of the problem.
>

This is certainly useful feedback to the WG.  In addition to considering it
as a topic for a Proposed Standard version of the DMARC specification,
there might be a need to explore some kind of interim statement about
what's supposed to happen here (if necessary).


> But on the off-chance that it's not impossible to clarify
> this now, and assuming that my growing suspicion that HELO is
> ignored is correct, then I would propose:
>
> [...]
>

Do people concur with this change, or something close to it?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Franck Martin 
- Original Message -
> From: "John Levine" 
> To: dmarc@ietf.org
> Cc: skl...@kitterman.com
> Sent: Tuesday, January 20, 2015 2:57:34 PM
> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> 
> >HELO results are unrelated to DMARC.
> 
> Is that still true when the bounce address is empty?  It's fairly common
> to have an NDR with an empty bounce address and
> 
>  From: MAILER-DAEMON@flaky.example
> 
> Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user
> supposed to do?
> 

The same as a non DMARC user should do...

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Franck Martin 
- Original Message -
> From: "Scott Kitterman" 
> To: dmarc@ietf.org
> Sent: Tuesday, January 20, 2015 2:49:01 PM
> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> 


> 
> Last time I had stats, it was about 10% as common as Mail From oriented
> records.  Much less common, but I wouldn't say rare.  When done this way,
> there isn't a singe "SPF" result, there are two: SPF/Mail From and SPF/HELO.
> Only SPF/Mail From is relevant to DMARC.

Why do you say that?

DMARC takes the result from SPF (pass/fail/...) and the string that SPF used 
for this result be it mail from or helo, to check for alignment.

Did I miss something?

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread John Levine 
>HELO results are unrelated to DMARC.

Is that still true when the bounce address is empty?  It's fairly common
to have an NDR with an empty bounce address and 

 From: MAILER-DAEMON@flaky.example

Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user
supposed to do?

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Terry Zink 
>7208 actually recommends that the HELO string be evaluated every time. 
> http://trac.tools.ietf.org/html/rfc7208#section-2.3

They do say to check it both times but I don't agree with the rationale 
provided. Expanding on the excerpt that Laura provided:

2.3.  The "HELO" Identity

   It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
   identity but also separately check the "HELO" identity by applying
   the check_host() function (Section 4) to the "HELO" identity as the
   .  Checking "HELO" promotes consistency of results and can
   reduce DNS resource usage.  

[tzink] How does this reduce DNS resource usage? Aren't we now checking two 
domains instead of one?

   If a conclusive determination about the
   message can be made based on a check of "HELO", then the use of DNS
   resources to process the typically more complex "MAIL FROM" can be
   avoided.

[tzink] Disagree here, especially the case of shared hosting environment like 
Office 365. Customers relay spam through us and sometimes that spam will fail 
SPF checks. Yet, if you checked the SPF record on the HELO string (e.g., 
na01-bn1-obe.outbound.protection.outlook.com), that would pass an SPF check 
every time whereas the @paypal.com in the MAIL FROM would fail SPF. Seems like 
you can only be sure you can trust the HELO when you are sure the sender locks 
down the outbound mail infrastructure, and that is not the case everywhere.

  Additionally, since SPF records published for "HELO"
   identities refer to a single host, when available, they are a very
   reliable source of host authorization status.  Checking "HELO" before
   "MAIL FROM" is the RECOMMENDED sequence if both are checked.

[tzink] They are for a single host but not necessarily for a single 
organization or even a series of organizations with the same set of policies. 
It seems like this RFC does not have a mult-tenant hosted environment in mind, 
and that is becoming more common.

-- Terry

> 7208 actually recommends that the HELO string be evaluated every time. 
> http://trac.tools.ietf.org/html/rfc7208#section-2.3
>
> "2.3.  The "HELO" Identity
> 
>
 >  It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
 >  identity but also separately check the "HELO" identity by applying
 >  the check_host() function (Section 4) to the "HELO" identity as the
>   .  Checking "HELO" promotes consistency of results and can
>   reduce DNS resource usage."
>
> laura 
>
> -- 
> Laura Atkins
> Word to the Wise  "The Deliverability Experts!"
> Direct: 650 678-3454  Fax: 650 249-1909
> @wise_laura
> Delivery blog: 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Anne Bennett 

Franck Martin  writes:

> Yes, RFC7208 says evaluate both in parallel, but the result
> of an spf=pass/fail is highly constrained on the success or
> failure of the MAIL FROM spf test.

Actually, it recommends checking the HELO identity first,
because if you get a definite result from that, you may not
have to evaluate the MAIL FROM identity at all.

> I mean, it seems quite rare to find an SPF record on the
> HELO string but not one the MAIL FROM string

I have no stats on how rare it is, but I can show you an
example for one of my home domains:

  # host -t txt quill.porcupine.ca
  quill.porcupine.ca descriptive text "v=spf1 +a -all"

  # host -t txt porcupine.ca
  porcupine.ca descriptive text "v=spf1 +mx ?all"

... that is, if anyone tries to HELO as host "quill" and isn't
coming from my IP address, you can reject that mail out of
hand as a fake ("-all").

However, if the envelope sender is in my domain, then if it
came from my MX, it's almost certainly good (lower its spam
score), but if not, perhaps someone is forwarding their mail,
and I don't want their final receiving ISP to drop my message,
which is why "?all" in that case.

(And yes, forwarded bounce mail originally from my mailer will
fail the "MAIL FROM constructed from HELO" test, but I think I
mostly avoid backscatter, so that's not too serious.)


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Scott Kitterman 
On Tuesday, January 20, 2015 16:38:43 Franck Martin wrote:
> - Original Message -
> 
> > From: "Scott Kitterman" 
> > To: dmarc@ietf.org
> > Sent: Tuesday, January 20, 2015 2:29:10 PM
> > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> > 
> > On Tuesday, January 20, 2015 16:14:32 Franck Martin wrote:
> > > - Original Message -
> > > 
> > > > From: "Anne Bennett" 
> > > > To: "DMARC list" 
> > > > Sent: Tuesday, January 20, 2015 1:44:16 PM
> > > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> > > > 
> > > > 
> > > > Hi, Murray.
> > > > 
> > > > MK> I think all of the points in your three messages are good input
> > > > for a
> > > > more
> > > > MK> solid specification, but the timing is unfortunate as we just got
> > > > MK> publication approval for -12 a week ago.
> > > > 
> > > > I apologize for my inadvertently poor timing; I was catapulted
> > > > into all this last week when my parent domain (also my
> > > > Organizational Domain) published an SPF record and a DKIM
> > > > record, and we became concerned that they might implement DMARC,
> > > > which could have a very negative impact on our mail services
> > > > unless we take action quickly and become prepared to publish
> > > > our own DMARC record.  Thus, my sudden plunge into all these
> > > > RFCs and this draft.  :-/
> > > > 
> > > > MK> Making more changes post-approval
> > > > MK> would probably not be a good idea, and by my reading none of them
> > > > rise
> > > > to MK> the level of being urgent to correct.
> > > > 
> > > > That's certainly not my call to make; I can only give you
> > > > a point of view from a fairly small site (about 10K users),
> > > > where we're not looking to implement any of these mechanisms
> > > > from scratch (we'll use software someone else wrote, mostly),
> > > > but we *do* need to understand the implications of our (or
> > > > our OD's) publishing DNS records for SPF, DKIM, and/or DMARC.
> > > > 
> > > > Since, as pointed out by Tim Draegen, "DMARC implementations are
> > > > already in the wild and deployed", one would expect to be able
> > > > to determine what those implementations do, based on this spec.
> > > > Sadly this hasn't been possible (so far) for me and my colleague
> > > > Michael Jack Assels, despite our being two fairly smart cookies,
> > > > with nearly a half-century of e-mail experience between us.
> > > > 
> > > > I want to emphasize that I think that the documents in question
> > > > (at least this draft and RFC7208 - I've barely skimmed RFC6376
> > > > on DKIM yet) individually are well written, but trying to
> > > > understand them in context together is proving to be quite
> > > > a challenge, and the lack of clarity on the HELO issue is
> > > > the biggest part of the problem.
> > > > 
> > > > 
> > > > We're now resorting to running tests to see how the biggest
> > > > gorilla in this jungle (Google) handles all this.  We've just
> > > > completed an initial set of tests with SPF records only (no
> > > > DMARC), which show that Google uses the MAIL FROM identity but
> > > > seems to ignore the HELO identity even in the absence of DMARC,
> > > > much to our surprise given RFC7208.
> > > > 
> > > > We haven't yet run our with-DMARC tests, though I suspect that
> > > > if Google doesn't look at HELO in a "pure SPF" environment, it
> > > > probably won't use it in the context of DMARC either.
> > > > 
> > > > 
> > > > If indeed it is the case that (at least in the context of
> > > > DMARC) the HELO identity is not normally used, I would hope
> > > > that introducing a small clarification to that effect could
> > > > be done without significantly impeding the progress of this
> > > > draft towards publication.  Mind you, I don't know that the
> > > > publication constraints are, so perhaps my hope is utterly
> > > > in vain!
> > > > 
> > > > But on the off-chance that it's not impossible t

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Scott Kitterman 
On Tuesday, January 20, 2015 14:34:22 Laura Atkins wrote:
> On Jan 20, 2015, at 2:14 PM, Franck Martin  wrote:
> >> But on the off-chance that it's not impossible to clarify
> >> this now, and assuming that my growing suspicion that HELO is
> > 
> >> ignored is correct, then I would propose:
> > Your confusion on HELO is may be related to the fact that the HELO string
> > is only used when the MAIL-FROM: is empty?
> > 
> > There is some text here:
> > http://trac.tools.ietf.org/html/rfc7208#section-10.1.3
> > 
> > The HELO string is not evaluated all the time, it is more like a fall
> > back.
> 
> 7208 actually recommends that the HELO string be evaluated every time.
> http://trac.tools.ietf.org/html/rfc7208#section-2.3
> 
> "2.3.  The "HELO" Identity
> 
> 
>It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
>identity but also separately check the "HELO" identity by applying
>the check_host() function (Section 4) to the "HELO" identity as the
>.  Checking "HELO" promotes consistency of results and can
>reduce DNS resource usage."
> 
> laura

Approximately the same text existed in RFC 4408 2.1:

>It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
>identity, but also separately check the "HELO" identity by applying
>the check_host() function (Section 4) to the "HELO" identity as the
>.

HELO results are unrelated to DMARC.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Franck Martin 




- Original Message -
> From: "Scott Kitterman" 
> To: dmarc@ietf.org
> Sent: Tuesday, January 20, 2015 2:29:10 PM
> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> 
> On Tuesday, January 20, 2015 16:14:32 Franck Martin wrote:
> > - Original Message -
> > 
> > > From: "Anne Bennett" 
> > > To: "DMARC list" 
> > > Sent: Tuesday, January 20, 2015 1:44:16 PM
> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> > > 
> > > 
> > > Hi, Murray.
> > > 
> > > MK> I think all of the points in your three messages are good input for a
> > > more
> > > MK> solid specification, but the timing is unfortunate as we just got
> > > MK> publication approval for -12 a week ago.
> > > 
> > > I apologize for my inadvertently poor timing; I was catapulted
> > > into all this last week when my parent domain (also my
> > > Organizational Domain) published an SPF record and a DKIM
> > > record, and we became concerned that they might implement DMARC,
> > > which could have a very negative impact on our mail services
> > > unless we take action quickly and become prepared to publish
> > > our own DMARC record.  Thus, my sudden plunge into all these
> > > RFCs and this draft.  :-/
> > > 
> > > MK> Making more changes post-approval
> > > MK> would probably not be a good idea, and by my reading none of them
> > > rise
> > > to MK> the level of being urgent to correct.
> > > 
> > > That's certainly not my call to make; I can only give you
> > > a point of view from a fairly small site (about 10K users),
> > > where we're not looking to implement any of these mechanisms
> > > from scratch (we'll use software someone else wrote, mostly),
> > > but we *do* need to understand the implications of our (or
> > > our OD's) publishing DNS records for SPF, DKIM, and/or DMARC.
> > > 
> > > Since, as pointed out by Tim Draegen, "DMARC implementations are
> > > already in the wild and deployed", one would expect to be able
> > > to determine what those implementations do, based on this spec.
> > > Sadly this hasn't been possible (so far) for me and my colleague
> > > Michael Jack Assels, despite our being two fairly smart cookies,
> > > with nearly a half-century of e-mail experience between us.
> > > 
> > > I want to emphasize that I think that the documents in question
> > > (at least this draft and RFC7208 - I've barely skimmed RFC6376
> > > on DKIM yet) individually are well written, but trying to
> > > understand them in context together is proving to be quite
> > > a challenge, and the lack of clarity on the HELO issue is
> > > the biggest part of the problem.
> > > 
> > > 
> > > We're now resorting to running tests to see how the biggest
> > > gorilla in this jungle (Google) handles all this.  We've just
> > > completed an initial set of tests with SPF records only (no
> > > DMARC), which show that Google uses the MAIL FROM identity but
> > > seems to ignore the HELO identity even in the absence of DMARC,
> > > much to our surprise given RFC7208.
> > > 
> > > We haven't yet run our with-DMARC tests, though I suspect that
> > > if Google doesn't look at HELO in a "pure SPF" environment, it
> > > probably won't use it in the context of DMARC either.
> > > 
> > > 
> > > If indeed it is the case that (at least in the context of
> > > DMARC) the HELO identity is not normally used, I would hope
> > > that introducing a small clarification to that effect could
> > > be done without significantly impeding the progress of this
> > > draft towards publication.  Mind you, I don't know that the
> > > publication constraints are, so perhaps my hope is utterly
> > > in vain!
> > > 
> > > But on the off-chance that it's not impossible to clarify
> > > this now, and assuming that my growing suspicion that HELO is
> > 
> > > ignored is correct, then I would propose:
> > Your confusion on HELO is may be related to the fact that the HELO string
> > is
> > only used when the MAIL-FROM: is empty?
> 
> The confusion is that many people think that HELO is only used when Mail From
> is empty.  It's been recommended as a stand alone test in both RFC 4408 and
> that's not changed in RFC 7208.  It's just more obvious now.
> 
> You do use postmaster@$HELO when Mail From is empty, which is relevant to
> DMARC use of SPF results.
> 
> You can also use HELO on it's own, which is not.  SPF pass on the HELO
> identity isn't useful as an accept criteria.  SPF fail on the HELO identity
> can, however, be useful as a reject criteria.
> 
>
Yes, RFC7208 says evaluate both in parallel, but the result of an spf=pass/fail 
is highly constrained on the success or failure of the MAIL FROM spf test.

I mean, it seems quite rare to find an SPF record on the HELO string but not 
one the MAIL FROM string

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Laura Atkins 

On Jan 20, 2015, at 2:14 PM, Franck Martin  wrote:

> 
>> But on the off-chance that it's not impossible to clarify
>> this now, and assuming that my growing suspicion that HELO is
>> ignored is correct, then I would propose:
>> 
> 
> Your confusion on HELO is may be related to the fact that the HELO string is 
> only used when the MAIL-FROM: is empty?
> 
> There is some text here:
> http://trac.tools.ietf.org/html/rfc7208#section-10.1.3
> 
> The HELO string is not evaluated all the time, it is more like a fall back.

7208 actually recommends that the HELO string be evaluated every time. 
http://trac.tools.ietf.org/html/rfc7208#section-2.3

"2.3.  The "HELO" Identity


   It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
   identity but also separately check the "HELO" identity by applying
   the check_host() function (Section 4) to the "HELO" identity as the
   .  Checking "HELO" promotes consistency of results and can
   reduce DNS resource usage."

laura 

-- 
Laura Atkins
Word to the Wise"The Deliverability Experts!"
Direct: 650 678-3454Fax: 650 249-1909
@wise_laura
Delivery blog: 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Scott Kitterman 
On Tuesday, January 20, 2015 16:14:32 Franck Martin wrote:
> - Original Message -
> 
> > From: "Anne Bennett" 
> > To: "DMARC list" 
> > Sent: Tuesday, January 20, 2015 1:44:16 PM
> > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> > 
> > 
> > Hi, Murray.
> > 
> > MK> I think all of the points in your three messages are good input for a
> > more
> > MK> solid specification, but the timing is unfortunate as we just got
> > MK> publication approval for -12 a week ago.
> > 
> > I apologize for my inadvertently poor timing; I was catapulted
> > into all this last week when my parent domain (also my
> > Organizational Domain) published an SPF record and a DKIM
> > record, and we became concerned that they might implement DMARC,
> > which could have a very negative impact on our mail services
> > unless we take action quickly and become prepared to publish
> > our own DMARC record.  Thus, my sudden plunge into all these
> > RFCs and this draft.  :-/
> > 
> > MK> Making more changes post-approval
> > MK> would probably not be a good idea, and by my reading none of them rise
> > to MK> the level of being urgent to correct.
> > 
> > That's certainly not my call to make; I can only give you
> > a point of view from a fairly small site (about 10K users),
> > where we're not looking to implement any of these mechanisms
> > from scratch (we'll use software someone else wrote, mostly),
> > but we *do* need to understand the implications of our (or
> > our OD's) publishing DNS records for SPF, DKIM, and/or DMARC.
> > 
> > Since, as pointed out by Tim Draegen, "DMARC implementations are
> > already in the wild and deployed", one would expect to be able
> > to determine what those implementations do, based on this spec.
> > Sadly this hasn't been possible (so far) for me and my colleague
> > Michael Jack Assels, despite our being two fairly smart cookies,
> > with nearly a half-century of e-mail experience between us.
> > 
> > I want to emphasize that I think that the documents in question
> > (at least this draft and RFC7208 - I've barely skimmed RFC6376
> > on DKIM yet) individually are well written, but trying to
> > understand them in context together is proving to be quite
> > a challenge, and the lack of clarity on the HELO issue is
> > the biggest part of the problem.
> > 
> > 
> > We're now resorting to running tests to see how the biggest
> > gorilla in this jungle (Google) handles all this.  We've just
> > completed an initial set of tests with SPF records only (no
> > DMARC), which show that Google uses the MAIL FROM identity but
> > seems to ignore the HELO identity even in the absence of DMARC,
> > much to our surprise given RFC7208.
> > 
> > We haven't yet run our with-DMARC tests, though I suspect that
> > if Google doesn't look at HELO in a "pure SPF" environment, it
> > probably won't use it in the context of DMARC either.
> > 
> > 
> > If indeed it is the case that (at least in the context of
> > DMARC) the HELO identity is not normally used, I would hope
> > that introducing a small clarification to that effect could
> > be done without significantly impeding the progress of this
> > draft towards publication.  Mind you, I don't know that the
> > publication constraints are, so perhaps my hope is utterly
> > in vain!
> > 
> > But on the off-chance that it's not impossible to clarify
> > this now, and assuming that my growing suspicion that HELO is
> 
> > ignored is correct, then I would propose:
> Your confusion on HELO is may be related to the fact that the HELO string is
> only used when the MAIL-FROM: is empty?

The confusion is that many people think that HELO is only used when Mail From 
is empty.  It's been recommended as a stand alone test in both RFC 4408 and 
that's not changed in RFC 7208.  It's just more obvious now.

You do use postmaster@$HELO when Mail From is empty, which is relevant to 
DMARC use of SPF results.  

You can also use HELO on it's own, which is not.  SPF pass on the HELO 
identity isn't useful as an accept criteria.  SPF fail on the HELO identity 
can, however, be useful as a reject criteria.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Franck Martin 




- Original Message -
> From: "Anne Bennett" 
> To: "DMARC list" 
> Sent: Tuesday, January 20, 2015 1:44:16 PM
> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
> 
> 
> Hi, Murray.
> 
> MK> I think all of the points in your three messages are good input for a
> more
> MK> solid specification, but the timing is unfortunate as we just got
> MK> publication approval for -12 a week ago.
> 
> I apologize for my inadvertently poor timing; I was catapulted
> into all this last week when my parent domain (also my
> Organizational Domain) published an SPF record and a DKIM
> record, and we became concerned that they might implement DMARC,
> which could have a very negative impact on our mail services
> unless we take action quickly and become prepared to publish
> our own DMARC record.  Thus, my sudden plunge into all these
> RFCs and this draft.  :-/
> 
> MK> Making more changes post-approval
> MK> would probably not be a good idea, and by my reading none of them rise to
> MK> the level of being urgent to correct.
> 
> That's certainly not my call to make; I can only give you
> a point of view from a fairly small site (about 10K users),
> where we're not looking to implement any of these mechanisms
> from scratch (we'll use software someone else wrote, mostly),
> but we *do* need to understand the implications of our (or
> our OD's) publishing DNS records for SPF, DKIM, and/or DMARC.
> 
> Since, as pointed out by Tim Draegen, "DMARC implementations are
> already in the wild and deployed", one would expect to be able
> to determine what those implementations do, based on this spec.
> Sadly this hasn't been possible (so far) for me and my colleague
> Michael Jack Assels, despite our being two fairly smart cookies,
> with nearly a half-century of e-mail experience between us.
> 
> I want to emphasize that I think that the documents in question
> (at least this draft and RFC7208 - I've barely skimmed RFC6376
> on DKIM yet) individually are well written, but trying to
> understand them in context together is proving to be quite
> a challenge, and the lack of clarity on the HELO issue is
> the biggest part of the problem.
> 
> 
> We're now resorting to running tests to see how the biggest
> gorilla in this jungle (Google) handles all this.  We've just
> completed an initial set of tests with SPF records only (no
> DMARC), which show that Google uses the MAIL FROM identity but
> seems to ignore the HELO identity even in the absence of DMARC,
> much to our surprise given RFC7208.
> 
> We haven't yet run our with-DMARC tests, though I suspect that
> if Google doesn't look at HELO in a "pure SPF" environment, it
> probably won't use it in the context of DMARC either.
> 
> 
> If indeed it is the case that (at least in the context of
> DMARC) the HELO identity is not normally used, I would hope
> that introducing a small clarification to that effect could
> be done without significantly impeding the progress of this
> draft towards publication.  Mind you, I don't know that the
> publication constraints are, so perhaps my hope is utterly
> in vain!
> 
> But on the off-chance that it's not impossible to clarify
> this now, and assuming that my growing suspicion that HELO is
> ignored is correct, then I would propose:
> 

Your confusion on HELO is may be related to the fact that the HELO string is 
only used when the MAIL-FROM: is empty?

There is some text here:
http://trac.tools.ietf.org/html/rfc7208#section-10.1.3

The HELO string is not evaluated all the time, it is more like a fall back.

Also I have trouble to understand why you may be affected by your OD? What is 
the relation between your domain and your OD? I suspect this is concordia.ca?

If you look at the public suffix list, google has put a separation at 
blogspot.com level, so that each hosting domain, can be organizationally 
separated.

https://publicsuffix.org/list/effective_tld_names.dat

I would suggest you publish a DMARC record in monitoring mode (p=none) so that 
you get reports (and no impact) and better understand your email infrastructure 
and what needs to be done.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-20 Thread Anne Bennett 

Hi, Murray.

MK> I think all of the points in your three messages are good input for a more
MK> solid specification, but the timing is unfortunate as we just got
MK> publication approval for -12 a week ago.

I apologize for my inadvertently poor timing; I was catapulted
into all this last week when my parent domain (also my
Organizational Domain) published an SPF record and a DKIM
record, and we became concerned that they might implement DMARC,
which could have a very negative impact on our mail services
unless we take action quickly and become prepared to publish
our own DMARC record.  Thus, my sudden plunge into all these
RFCs and this draft.  :-/

MK> Making more changes post-approval
MK> would probably not be a good idea, and by my reading none of them rise to
MK> the level of being urgent to correct.

That's certainly not my call to make; I can only give you
a point of view from a fairly small site (about 10K users),
where we're not looking to implement any of these mechanisms
from scratch (we'll use software someone else wrote, mostly),
but we *do* need to understand the implications of our (or
our OD's) publishing DNS records for SPF, DKIM, and/or DMARC.

Since, as pointed out by Tim Draegen, "DMARC implementations are
already in the wild and deployed", one would expect to be able
to determine what those implementations do, based on this spec.
Sadly this hasn't been possible (so far) for me and my colleague
Michael Jack Assels, despite our being two fairly smart cookies,
with nearly a half-century of e-mail experience between us.

I want to emphasize that I think that the documents in question
(at least this draft and RFC7208 - I've barely skimmed RFC6376
on DKIM yet) individually are well written, but trying to
understand them in context together is proving to be quite
a challenge, and the lack of clarity on the HELO issue is
the biggest part of the problem.


We're now resorting to running tests to see how the biggest
gorilla in this jungle (Google) handles all this.  We've just
completed an initial set of tests with SPF records only (no
DMARC), which show that Google uses the MAIL FROM identity but
seems to ignore the HELO identity even in the absence of DMARC,
much to our surprise given RFC7208.

We haven't yet run our with-DMARC tests, though I suspect that
if Google doesn't look at HELO in a "pure SPF" environment, it
probably won't use it in the context of DMARC either.


If indeed it is the case that (at least in the context of
DMARC) the HELO identity is not normally used, I would hope
that introducing a small clarification to that effect could
be done without significantly impeding the progress of this
draft towards publication.  Mind you, I don't know that the
publication constraints are, so perhaps my hope is utterly
in vain!

But on the off-chance that it's not impossible to clarify
this now, and assuming that my growing suspicion that HELO is
ignored is correct, then I would propose:

In section "3.1. Identifier Alignment":

< For example, [DKIM] authenticates the domain that affixed a
< signature to the message, while [SPF] authenticates either
< the domain that appears in the RFC5321.MailFrom portion of
< [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom
< is null (in the case of Delivery Status Notifications).

> For example, [DKIM] authenticates the domain that affixed a
> signature to the message, while [SPF] can authenticate either
> the domain that appears in the RFC5321.MailFrom portion of
> [SMTP], or the RFC5321.EHLO/HELO domain, or both.

In section "3.1.2. SPF-authenticated Identifiers":

< In relaxed mode, the [SPF]-authenticated domain and
< RFC5322.From domain must have the same Organizational Domain.
< In strict mode, only an exact DNS domain match is considered
< to produce identifier alignment.

> In relaxed mode, the [SPF]-authenticated domain and
> RFC5322.From domain must have the same Organizational Domain.
> In strict mode, only an exact DNS domain match is considered
> to produce identifier alignment.
> 
> Note that the HELO identity is not used in the context of
> DMARC (except when required to "fake" an otherwise null
> reverse-path), even though a "pure SPF" implementation
> according to [SPF] would check the HELO domain.

In "4.1. Authentication Mechanisms":

< o  [SPF], which authenticates the domain found in an
<[SMTP] MAIL command when it is the authorized domain.

> o  [SPF], which authenticates the domain found in an
>[SMTP] MAIL command, or the domain found in the
>[SMTP] HELO/EHLO command if the MAIL command has
>a null path.  Note that in contradiction to [SPF],
>in the context of DMARC, the HELO identity is not
>checked (except in the case of a null path).


Even if it turns out to be impossible to make the above changes
before publication, I'd be grateful to the people on this list
for confirming (or disconfirming!) my understanding that HELO
is not used in the context of DMARC (modulo the null path case).


An

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-19 Thread Murray S. Kucherawy 
On Mon, Jan 19, 2015 at 6:30 AM, Tim Draegen  wrote:

> No objection — please do use the WG’s tracker for these items.  Anne’s
> thorough review will be picked up (and not rediscovered!) if we’ve got an
> obvious place to start from.
>

Done for Anne's points, and I'll do so for Jim Fenton's remaining ones as
well.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-19 Thread Murray S. Kucherawy 
On Mon, Jan 19, 2015 at 6:43 AM, Tim Draegen  wrote:

> DMARC implementations are already in the wild and deployed.  Input to the
> existing specification will be largely based on working implementations.
> You might have your own reasons for waiting for this WG to review the DMARC
> base draft, but if you want to provide input based on operational &
> implementation experience, it's probably best to not wait.


Indeed, -12 represents what's been deployed, and that was always the intent
of this ISE submission.  One could thus conclude that it is solid enough
for everyone that has already deployed it, and that's not exactly a small
or obscure list.

Still, as has been said before: If there's more work to be done on this
document, the working group is chartered to generate a Standards Track
version using this document as a starting point once its other deliverables
have been completed.  We can record issues we'd like to see addressed in
the tracker if there are some, and, if and when the WG gets there, we'll be
off to the races.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-19 Thread Tim Draegen 
> On Jan 17, 2015, at 12:00 PM, Hector Santos  wrote:
> 
> I have two concerns.
> 
> It seems you "jumped the gun" to accept the RFC 4408 obsolete idea. Is 7208 
> backward compatible or not?  Does DMARC require 7208 operations or 4408 
> operations?
> 
> And is this -12 publication "worthy" of even considering for implementation?  
> Or should we wait for the more "solid specification?"

Hi Hector, if you review:

  https://www.rfc-editor.org/rfc/rfc7208.txt

..you'll see at the very top "Obsoletes: 4408".  If there are discrepancies 
between 4408 and 7208, it's best to file an errata (erratum?):   
http://www.rfc-editor.org/how_to_report.html

DMARC implementations are already in the wild and deployed.  Input to the 
existing specification will be largely based on working implementations.  You 
might have your own reasons for waiting for this WG to review the DMARC base 
draft, but if you want to provide input based on operational & implementation 
experience, it's probably best to not wait.

=- Tim



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-19 Thread Tim Draegen 
> On Jan 16, 2015, at 11:08 PM, Murray S. Kucherawy  wrote:
> 
> Would the co-chairs object to beginning to track these items using the WG's 
> tracker?  If and when we do decide to crack open the base document for a 
> Proposed Standard revision, we'd already have an inventory of topics to 
> consider.  It would also help to keep the discussion on this list focused on 
> active topics now that the base draft is "done".

No objection — please do use the WG’s tracker for these items.  Anne’s thorough 
review will be picked up (and not rediscovered!) if we’ve got an obvious place 
to start from.

=- Tim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-17 Thread Hector Santos 

I have two concerns.

It seems you "jumped the gun" to accept the RFC 4408 obsolete idea. Is 
7208 backward compatible or not?  Does DMARC require 7208 operations 
or 4408 operations?


And is this -12 publication "worthy" of even considering for 
implementation?  Or should we wait for the more "solid specification?"


--
HLS


On 1/16/2015 11:08 PM, Murray S. Kucherawy wrote:

Hello Anne,

On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett mailto:a...@encs.concordia.ca>> wrote:

Having just spent several hours poring over this document
(-12), I might as well send my additional minor observations.
I suspect that some of you will consider these items trivial,
but they gave me pause as I went back and forth through several
sections of the text to make sure I understood correctly.  So...
[...]


I think all of the points in your three messages are good input for a
more solid specification, but the timing is unfortunate as we just got
publication approval for -12 a week ago.  Making more changes
post-approval would probably not be a good idea, and by my reading
none of them rise to the level of being urgent to correct.

The plan for the DMARC working group is to consider, among other
things, whether it wants to produce a new version of the base document
on the Standards Track (because of its path to publication, -12 will
be Informational).  Your points here are ideal for consideration when
the working group reaches that juncture.

Would the co-chairs object to beginning to track these items using the
WG's tracker?  If and when we do decide to crack open the base
document for a Proposed Standard revision, we'd already have an
inventory of topics to consider.  It would also help to keep the
discussion on this list focused on active topics now that the base
draft is "done".

-MSK


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it

2015-01-16 Thread Murray S. Kucherawy 
Hello Anne,

On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett 
wrote:

> Having just spent several hours poring over this document
> (-12), I might as well send my additional minor observations.
> I suspect that some of you will consider these items trivial,
> but they gave me pause as I went back and forth through several
> sections of the text to make sure I understood correctly.  So...
> [...]
>

I think all of the points in your three messages are good input for a more
solid specification, but the timing is unfortunate as we just got
publication approval for -12 a week ago.  Making more changes post-approval
would probably not be a good idea, and by my reading none of them rise to
the level of being urgent to correct.

The plan for the DMARC working group is to consider, among other things,
whether it wants to produce a new version of the base document on the
Standards Track (because of its path to publication, -12 will be
Informational).  Your points here are ideal for consideration when the
working group reaches that juncture.

Would the co-chairs object to beginning to track these items using the WG's
tracker?  If and when we do decide to crack open the base document for a
Proposed Standard revision, we'd already have an inventory of topics to
consider.  It would also help to keep the discussion on this list focused
on active topics now that the base draft is "done".

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc