Subject: draft-fanf-dane-smtp-02
From: Tony Finch <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 31 May 2012 18:39:38 +0100
List-Id: <ietf-smtp.imc.org>

Another version, with less added text this time - I've included a copy of
the change log below. Many thanks to everyone who has taken the time to
read the draft and comment.

     Clarify the wording that describes how a client determines that
     this protocol is in effect.

     Divide the security considerations into sub-sections, and add a
     subsection on denial of service.

     Clarify intro, mentioning TLSA owner name format.

     Extend the scope to cover MTA-to-MTA mail within an ADMD as
     well as between ADMDs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: North 4 or 5, backing northwest 5 or 6. Moderate, occasionally rough
later. Showers. Good.

---------- Forwarded message ----------
Date: Thu, 31 May 2012 10:33:51 -0700
From: [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-fanf-dane-smtp-02.txt

A new version of I-D, draft-fanf-dane-smtp-02.txt has been successfully
submitted by Tony Finch and posted to the IETF repository.

Filename:        draft-fanf-dane-smtp
Revision:        02
Title:           Secure SMTP with TLS, DNSSEC and TLSA records.
Creation date:   2012-05-31
WG ID:           Individual Submission
Number of pages: 13

Abstract:
   SMTP has a STARTTLS extension, but (especially in the case of inter-
   domain mail transfer) it only provides very limited security because
   it does not specify how to authenticate the server&#39;s certificate.
   This memo specifies how TLSA records in the DNS can be used for proper
   SMTP server authentication.

The IETF Secretariat

Date: Thu, 31 May 2012 16:24:25 +0100
From: Tony Finch <[email-masked]>
To: Paul Hoffman <[email-masked]>
cc: IETF DANE WG list <[email-masked]>, [email-masked]
Subject: Re: [dane] draft-fanf-dane-smtp
Sender: [email-masked]

Paul Hoffman <[email-masked]> wrote:
>
> That's incorrect. draft-fanf-dane-smtp is defining the specific use of
> TLSA for _25._tcp.hostname. (It would be good if it said so in the
> Introduction.)

I've added that to my working copy. Thanks for the suggestion.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight, Portland, Plymouth: Southwest 4 or 5, occasionally 6 at first,
becoming variable 3 or 4 later. Slight or moderate. Occasional drizzle, fog
patches. Moderate or good, occasionally very poor.

Subject: Re: [dane] draft-fanf-dane-smtp
From: Paul Hoffman <[email-masked]>
Date: Thu, 31 May 2012 08:05:37 -0700
Cc: [email-masked]
To: IETF DANE WG list <[email-masked]>
Sender: [email-masked]

On May 30, 2012, at 8:43 PM, Matt McCutchen wrote:

> My understanding
> (http://www.ietf.org/mail-archive/web/keyassure/current/msg01215.html)
> is that a TLSA RRset at a given endpoint (DNS name + transport + port)
> is not a guarantee that a TLS service is offered at that endpoint.  It
> only indicates the server certificates to be considered authentic if a
> client wants to attempt a connection to such a TLS service.  

Correct.

> Indeed, an
> organization with an existing private CA may publish may cover its
> entire zone with TLSA RRsets of usage 2 referring to that CA.  And I
> cover all the unused names in mattmccutchen.net with dummy TLSA RRsets
> (SHA256 0000...0000) to ensure that TLS clients will never successfully
> authenticate a TLS service that I do not offer if a MITM attacker tries
> to spoof one into existence with a fraudulent certificate from a public
> CA.

It could do so if it wanted. That doesn't mean it is a good idea to do so.

> A mail client that is already configured to require authenticated TLS
> could certainly use DANE.  But it would be incorrect for a client to
> refuse to deliver insecurely because it found a secure TLSA RRset.  

That's incorrect. draft-fanf-dane-smtp is defining the specific use of TLSA for _25._tcp.hostname. (It would be good if it said so in the Introduction.)

> For
> that kind of logic, we need something like HASTLS.

The second paragraph of the Security Considerations covers this. I think HASTLS might be a good idea, but the IETF still needs to have the discussion of layering of these types of announcements.

> This approach is not going to work.  

It will work fine for everyone who doesn't do the "cover every port and assume that no future protocol will ever define how specific applications will use TLSA".

--Paul Hoffman

Date: Thu, 31 May 2012 16:01:22 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Alessandro Vesely <[email-masked]>, [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

[email-masked] <[email-masked]> wrote:

Thanks again for your helpful comments. We seem to be thinking along
pretty much the same lines.

> > I'll have a look at that. What I had in mind was a Transmitted: trace
> > header that parallels the Received: header, and some new "with protocol"
> > types (e.g. esmtpt) to assert that the client had done some extra
> > checking. But this would add a lot of bloat for one bit of information so
> > perhaps it should just be left in the logs. Dunno.
>
> Well, that really depends on what you mean by "parallel". A field a client can
> insert saying what server it was talking to, what protocol choices were made,
> and so on and so forth, is fine.

Right, that's what I've tried to describe in the -01 version.

> But the minute you try and link the Transmitted: field to the
> corresponding Received: field the client hasn't even seen yet, that's
> not a good idea. There's too much piddling around with headers in
> practice to use such linkages.

Indeed.

> Reusing basic Received: field syntax is also fine, and probably the right
> approach if we are to define such a thing. But I again wonder if this belongs
> in this proposal or would be better off in a separate document.

Yes. I'm still half inclined to rip out the Transmitted: stuff. I mainly
wrote it up as a straw man to see what others think of the idea.

> > Hmm, yes, I should add something about DSNs. Thanks. I think it might be
> > sufficient to register a new MTA-name-type, perhaps "dane".
>
> Ah, that's clever. Avoids the need for a new field. I like it.

... though I wonder if it has interop implications. As far as I know the
only MTA-name-type that has been used is "dns".

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey: Easterly or northeasterly 4 or 5, increasing
6 at times in Rockall. Moderate, occasionally rough in Rockall. Rain at times
in Rockall and Malin, otherwise fair. Moderate or good, occasionally poor in
Rockall and Malin.

Date: Thu, 31 May 2012 15:46:32 +0100
From: Tony Finch <[email-masked]>
To: Matt McCutchen <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [dane] draft-fanf-dane-smtp
Sender: [email-masked]

Matt McCutchen <[email-masked]> wrote:
>
> This approach is not going to work.

I think you mean that you want weaker semantics for SMTP+TLSA than I have
specified. I have deliberately stated that extra semantics apply - in the
intro I wrote:

    As well as its normal function of providing an association
    between a domain name and a certificate, we are also using the
    existance of a TLSA record to signal to the client that it can
    expect a valid server certificate.

I agree that this might be a job for the HASTLS record - I wan't aware of
it. I can change the spec to require another DNS lookup for HASTLS if
others think this is worth doing.

The historical baggage for SMTP and HTTP are rather different so I am not
sure it makes sense to apply an HTTP fix to SMTP. It would add significant
programming and provisioning complexity, and I don't think your use cases
justify it. (For instance, your wildcard TLSA records are useless without
accompanying address or SRV records.) On the other hand perhaps it would
be nice to have better consistency across protocols.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Easterly or northeasterly 5 to 7, increasing gale 8, occasionally
severe gale 9 later in southeast, otherwise mainly northerly 4 or 5,
occasionally 6. Slight or moderate, occasionally rough in southeast. Thundery
showers later in east. Good, occasionally poor in east.

To: Hector Santos <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked], [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: draft-fanf-dane-smtp
Date: Thu, 31 May 2012 10:18:13 +1000
Sender: [email-masked]

In message <[email-masked]>, Hector Santos writes:
> Mark Andrews wrote:
> 
> >> My question is:
> >>
> >> If the client has to be modified to do this extra TLSA check, then why 
> >> not just add login to do a CA 3rd party repository?   Or support OCSP 
> >> (Online Certificate Status Protocol) RFC2560?
> 
> > OCSP is for when the CA knows the CERT is compromised.
> > TLSA, mode X, is to detect mis-issued CERT by some CA.
> > 
> > Different threat models.
> >
> > OCSP are sometimes unreachable even when you have the address and CERT.
> > TLSA records will almost always be available if you can retrieve the addres
> s
> > as they live below the address in the DNS and are usually in the same zone.
> > 
> > Different failure models.
> 
> Yes, but its always been used for whatever the CA responds with and 
> whatever the client decides to do as a negative response, but as the 
> modus operandi has been, a positive response has "trust value."  I've 
> seen it used in cases where a browser check provides a perfect SSL 
> resolution, but with modern browsers having OCSP enabled now, it will 
> provide a failure/security notification to the user.  In the case I 
> recall, a big national chain store purchased a set of wildcard 
> domains, then wanted to add more the same day, and there was a 
> revocation issue that failure when OCSP was enabled.
> 
> So I guess that all falls under a "compromise" threat/failure window.
> 
> >> When change is proposed, then it has to have a payoff.  A client 
> >> trusting a self-signed signature is going to be pre-defined or 
> >> pre-arranged or known upfront.
> > 
> > TLSA, mode Y, allows you to trust the self signed CERT by providing
> > a verifiable secure chain of trust back to a DNS trust anchor rather
> > than a CA trust anchor.
> > 
> 
> Thanks for your comments.
> 
> At best, this proposal offers an easier protocol. But its not ready 
> for prime time until the DNS servers better support unnamed types and 
> across the OS platform board.

Actually I believe it is ready for prime time.

If the DNS servers don't support DNSSEC then the MX, A and AAAA
will come back as insecure unless the administrators of the zones
are insane.

If the DNS servers do support DNSSEC and the MX, A and AAAA answers
come back as secure, then a TLSA lookup should succeed as the TLSA
lookups will be from the same zones as the MX, A and AAAA lookups
or will be in a secure zone beneath the zone that returned these
answers.  All DNSSEC aware servers are required to support unknown
types.  By checking the MX, A and AAAA results you elimitate the
possibility of NOTIMP on the TLSA lookup.

If DNSSEC is being broken then all bets are off.

> I think we would like a SMTP/TLS model where clients support/service 
> the CA market, in the same way Browsers do for SSL/TLS certificates. 
>   I can see an SMTP Server Extension that offers service keywords for 
> the level of enforcement. This may answer one of the lingering 
> questions the DANE-SMTP drafts states that the server has no way to 
> know the client has looked up a TLSA record.
> 
> 
> -- 
> HLS
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Wed, 30 May 2012 17:44:10 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Mark Andrews <[email-masked]>
CC: Tony Finch <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

Mark Andrews wrote:

>> My question is:
>>
>> If the client has to be modified to do this extra TLSA check, then why 
>> not just add login to do a CA 3rd party repository?   Or support OCSP 
>> (Online Certificate Status Protocol) RFC2560?

> OCSP is for when the CA knows the CERT is compromised.
> TLSA, mode X, is to detect mis-issued CERT by some CA.
> 
> Different threat models.
>
> OCSP are sometimes unreachable even when you have the address and CERT.
> TLSA records will almost always be available if you can retrieve the address
> as they live below the address in the DNS and are usually in the same zone.
> 
> Different failure models.

Yes, but its always been used for whatever the CA responds with and 
whatever the client decides to do as a negative response, but as the 
modus operandi has been, a positive response has "trust value."  I've 
seen it used in cases where a browser check provides a perfect SSL 
resolution, but with modern browsers having OCSP enabled now, it will 
provide a failure/security notification to the user.  In the case I 
recall, a big national chain store purchased a set of wildcard 
domains, then wanted to add more the same day, and there was a 
revocation issue that failure when OCSP was enabled.

So I guess that all falls under a "compromise" threat/failure window.

>> When change is proposed, then it has to have a payoff.  A client 
>> trusting a self-signed signature is going to be pre-defined or 
>> pre-arranged or known upfront.
> 
> TLSA, mode Y, allows you to trust the self signed CERT by providing
> a verifiable secure chain of trust back to a DNS trust anchor rather
> than a CA trust anchor.
> 

Thanks for your comments.

At best, this proposal offers an easier protocol. But its not ready 
for prime time until the DNS servers better support unnamed types and 
across the OS platform board.

I think we would like a SMTP/TLS model where clients support/service 
the CA market, in the same way Browsers do for SSL/TLS certificates. 
  I can see an SMTP Server Extension that offers service keywords for 
the level of enforcement. This may answer one of the lingering 
questions the DANE-SMTP drafts states that the server has no way to 
know the client has looked up a TLSA record.

-- 
HLS

To: Hector Santos <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked], [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: draft-fanf-dane-smtp
Date: Wed, 30 May 2012 13:17:56 +1000
Sender: [email-masked]

In message <[email-masked]>, Hector Santos writes:
> 
> Tony Finch wrote:
> > Hector Santos <[email-masked]> wrote:
> >> I guess, if anything else, there are two client suggestions to highlight:
> >>
> >>   - Automated MTA (router)
> >>   - Interactive MUA smtp client
> > 
> > The draft is for inter-domain SMTP so message submission is out of scope.
> > I don't think I can make this clearer.
> > 
> > Tony.
> 
> Oh, so that is what you meant by "inter-domain."   I am not use to 
> using that term within the confines of mail systems but it fits. 
> Other terms are "routers," "relays," etc or just MTA.  I prefer router.
> 
>    Inter-domain SMTP:  SMTP between different ADMDs across the public
>        Internet, where a client sends mail to a publicly-referenced SMTP
>        server.
> 
> I suggest to add an i.e.
> 
>     i.e. a router, relaying MTA, not an MUA with a possible interactive
>          CN vs Host domain checking method where the HUMAN is involved.
> 
> Anyway, ironically, we are having a related thread now in our support 
> forum regarding a sysop asking about self-signed vs CA signed certs.
> 
> My question is:
> 
> If the client has to be modified to do this extra TLSA check, then why 
> not just add login to do a CA 3rd party repository?   Or support OCSP 
> (Online Certificate Status Protocol) RFC2560?

OCSP is for when the CA knows the CERT is compromised.
TLSA, mode X, is to detect mis-issued CERT by some CA.

Different threat models.

OCSP are sometimes unreachable even when you have the address and CERT.
TLSA records will almost always be available if you can retrieve the address
as they live below the address in the DNS and are usually in the same zone.

Different failure models.

> When change is proposed, then it has to have a payoff.  A client 
> trusting a self-signed signature is going to be pre-defined or 
> pre-arranged or known upfront.

TLSA, mode Y, allows you to trust the self signed CERT by providing
a verifiable secure chain of trust back to a DNS trust anchor rather
than a CA trust anchor.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Tue, 29 May 2012 22:12:17 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Finch <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

Tony Finch wrote:
> Hector Santos <[email-masked]> wrote:
>> I guess, if anything else, there are two client suggestions to highlight:
>>
>>   - Automated MTA (router)
>>   - Interactive MUA smtp client
> 
> The draft is for inter-domain SMTP so message submission is out of scope.
> I don't think I can make this clearer.
> 
> Tony.

Oh, so that is what you meant by "inter-domain."   I am not use to 
using that term within the confines of mail systems but it fits. 
Other terms are "routers," "relays," etc or just MTA.  I prefer router.

   Inter-domain SMTP:  SMTP between different ADMDs across the public
       Internet, where a client sends mail to a publicly-referenced SMTP
       server.

I suggest to add an i.e.

    i.e. a router, relaying MTA, not an MUA with a possible interactive
         CN vs Host domain checking method where the HUMAN is involved.

Anyway, ironically, we are having a related thread now in our support 
forum regarding a sysop asking about self-signed vs CA signed certs.

My question is:

If the client has to be modified to do this extra TLSA check, then why 
not just add login to do a CA 3rd party repository?   Or support OCSP 
(Online Certificate Status Protocol) RFC2560?

When change is proposed, then it has to have a payoff.  A client 
trusting a self-signed signature is going to be pre-defined or 
pre-arranged or known upfront.

-- 
HLS

From: [email-masked]
Cc: Tony Finch <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 29 May 2012 16:44:35 -0700 (PDT)
Subject: Re: draft-fanf-dane-smtp
To: Alessandro Vesely <[email-masked]>
Sender: [email-masked]

> On Tue 29/May/2012 15:15:54 +0200 Tony Finch wrote:
> > Alessandro Vesely <[email-masked]> wrote:
> >
> >> Second, for XXX, I'd suggest updating RFC 5451 and extend it as
> >> appropriate. A question is that the client-added header field should be
> >> signed in order to be considered reliable.
> >
> > I'll have a look at that. What I had in mind was a Transmitted: trace
> > header that parallels the Received: header, and some new "with protocol"
> > types (e.g. esmtpt) to assert that the client had done some extra
> > checking. But this would add a lot of bloat for one bit of information so
> > perhaps it should just be left in the logs. Dunno.

> In January, I proposed a similar field (Sent:) for tracking delays,
> and Ned's comment is here:
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04126.html

And that comment still stands. The issue is whether or not there's an
intended coupling of the field. Additional fields are acceptable, but not
when they overlap or interact with an existing field.

> For a bloated debugging functionality, you could also try something
> like dmarc or dkim-reporting...

> > Regarding authenticity of the header, I could say that any DKIM
> > signature should be added after the Transmitted: header. But then you'd
> > have to generate different signatures for each transmission of a message
> > which is not currently the case.
> >
> > But I'm not sure what a server can meaningfully do with knowledge of how
> > much checking an unauthenticated client claimed to perform. At the moment
> > I'm just thinking of this trace information existing for debugging
> > purposes and for deployment tracking and suchlike, so there's no need to
> > be particularly precious about it.

> IMHO, all of the "auth" techniques (SPF, DKIM, ...) are more or less
> in a debugging state, as they are not mandatory and there's no clear
> indication of how to use their results.  This bit would add to that
> sequence the knowledge that the sender considers that MX server
> authoritative.

None of them are mandatory to implement. But there's a lot of room between what
I'd consider debugging and what these things go.

> I'd guess that devising an SMTP extension whereby the client can
> transmit some token that substantiates its claim is not quite what
> you're after, is it?  But there don't seem to be many other means by
> which a publisher of TLSA records can learn whether anybody uses them.

We already have that, more or less: The AUTH parameter on MAIL FROM. Of course
you have to authenticate for real before using it, which is how it should be.

But it isn't the appropriate tool to use in this case.

> >> Unless I'm missing something, the only places where that info is going
> >> to be relevant is if the server rejects the message, if positive DSN was
> >> requested but the server doesn't support it, and if the sending fails
> >> because some of the specified checks failed.  In those cases, the client
> >> can prepare a bounce where the authentication results are reported in
> >> detail.
> >
> > Hmm, yes, I should add something about DSNs. Thanks. I think it might be
> > sufficient to register a new MTA-name-type, perhaps "dane".
> >
> > (So regarding Ned's comment about the need for a general mechanism, I
> > think RFC 3464 is, happily, already sufficiently general.)

> Indeed, that checking is relevant for DSNs.  However, it would be
> overkill to add an extra NOTIFY keyword, e.g. "DANE", for ensuring
> that a report with "Remote-MTA: dane; something" will always be issued.

Especially since that would have to be a separate extension, and then you run
into all the fun and games associated with the various cases where the
extension isn't present at some point.

				ned

From: [email-masked]
Cc: Alessandro Vesely <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 29 May 2012 15:38:30 -0700 (PDT)
Subject: Re: draft-fanf-dane-smtp
To: Tony Finch <[email-masked]>
Sender: [email-masked]

> Alessandro Vesely <[email-masked]> wrote:
> >

> Thanks for your helpful review.

> > I'm not into DANE or DNSSEC, but AIUI there's some over-constraining
> > in Section 3.  The spec requires that the whole list of MXes is
> > secure, while it could be enough that the selected record is.

> The DNS deals with RRsets as a unit, not as individual records. Because of
> this there is no way for a domain's MXs to have inconsistent security
> states. See RFC 2181 section 5 for more.

> > For example, if a domain sets up a dummy backup MX that should work as a
> > sort of honeypot, it might want to deliberately omit to add security
> > features to its setup while still allowing secure mail delivery on their
> > main MX.

> That is allowed, because there's no coupling between the MX targets, so
> they can individially have TLSA and/or DNSSEC or not. There's a paragraph
> about this in the security considerations section, which I am going to
> expand because this area is fairly subtle.

I don't think that's quite what was being suggested. My understanding was that
by omitting the signature on some of the MXes, you could produce different
behavior depending on whether on not a client only uses secured MXes.

I don't think it's a useful feature, my understanding (now confirmed by you)
is that DNSSEC doesn't support that, and I also think, per my preceeding
messages, that if it were possible it would cause more problems than it solves.

> > Second, for XXX, I'd suggest updating RFC 5451 and extend it as
> > appropriate. A question is that the client-added header field should be
> > signed in order to be considered reliable.

> I'll have a look at that. What I had in mind was a Transmitted: trace
> header that parallels the Received: header, and some new "with protocol"
> types (e.g. esmtpt) to assert that the client had done some extra
> checking. But this would add a lot of bloat for one bit of information so
> perhaps it should just be left in the logs. Dunno.

Well, that really depends on what you mean by "parallel". A field a client can
insert saying what server it was talking to, what protocol choices were made,
and so on and so forth, is fine. But the minute you try and link the
Transmitted: field to the corresponding Received: field the client hasn't even
seen yet, that's not a good idea. There's too much piddling around with headers
in practice to use such linkages.

Reusing basic Received: field syntax is also fine, and probably the right 
approach if we are to define such a thing. But I again wonder if this belongs
in this proposal or would be better off in a separate document.

> Regarding authenticity of the header, I could say that any DKIM
> signature should be added after the Transmitted: header. But then you'd
> have to generate different signatures for each transmission of a message
> which is not currently the case.

Not to mention that the signature cannot be generated in advance and would have
to be computed during dequeue processing. In regards to signing at this point,
had DKIM's canonicalization/hashing mechanisms been designed differently and had
different signature algorithm choices been made, this might, and I emphasize
might, be technically feasible. But they weren't, so it isn't.

I'm also not wild about extending the usage of DKIM past the use cases it  was
designed for, and this seems to me to be doing that.

I also have to question why signature coverage is needed in this case. The
entire point of this mechanism is to insure that the client is talking securely
to the right server. So the presumption is the message cannot have been
tampered with in transit. And that leaves the client. If the server trusts the
client, then it can trust the uppermost Transmitted: field, signed or not If it
doesn't, then having the untrusted client add an untrusted signature adds...
what exactly?

> But I'm not sure what a server can meaningfully do with knowledge of how
> much checking an unauthenticated client claimed to perform. At the moment
> I'm just thinking of this trace information existing for debugging
> purposes and for deployment tracking and suchlike, so there's no need to
> be particularly precious about it.

Exactly.

> > Unless I'm missing something, the only places where that info is going
> > to be relevant is if the server rejects the message, if positive DSN was
> > requested but the server doesn't support it, and if the sending fails
> > because some of the specified checks failed.  In those cases, the client
> > can prepare a bounce where the authentication results are reported in
> > detail.

> Hmm, yes, I should add something about DSNs. Thanks. I think it might be
> sufficient to register a new MTA-name-type, perhaps "dane".

Ah, that's clever. Avoids the need for a new field. I like it.

> (So regarding Ned's comemnt about the need for a general mechanism, I
> think RFC 3464 is, happily, already sufficiently general.)

With the "dane;" MTA name type approach, agreed. That's absolutely where
it belongs.

				Ned

Date: Tue, 29 May 2012 21:33:09 +0100
From: Tony Finch <[email-masked]>
To: [email-masked], [email-masked]
Subject: draft-fanf-dane-smtp-01
Sender: [email-masked]

I have uploaded a revised version. I am rather unsure about
sections 4 and 5 so all cheers and jeers welcome, especially
if backed up with some kind of reasoning :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames: Variable 3 or 4. Smooth or slight. Fog patches developing,
occasional rain. Moderate or good, occasionally very poor.

---------- Forwarded message ----------
Date: Tue, 29 May 2012 13:22:40 -0700
From: [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-fanf-dane-smtp-01.txt

A new version of I-D, draft-fanf-dane-smtp-01.txt has been successfully
submitted by Tony Finch and posted to the IETF repository.

Filename:        draft-fanf-dane-smtp
Revision:        01
Title:           Secure inter-domain SMTP with TLS, DNSSEC and TLSA records.
Creation date:   2012-05-29
WG ID:           Individual Submission
Number of pages: 11

Abstract:
   SMTP supports STARTTLS for inter-domain mail transfer, but it only
   provides very limited security because the server&#39;s certificate
   cannot be authenticated.  This memo specifies how TLSA records in the
   DNS can be used for proper MX target server authentication.

The IETF Secretariat

Date: Tue, 29 May 2012 18:42:11 +0200
From: Alessandro Vesely <[email-masked]>
To: Tony Finch <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

On Tue 29/May/2012 15:15:54 +0200 Tony Finch wrote:
> Alessandro Vesely <[email-masked]> wrote:
> 
>> Second, for XXX, I'd suggest updating RFC 5451 and extend it as
>> appropriate. A question is that the client-added header field should be
>> signed in order to be considered reliable.
> 
> I'll have a look at that. What I had in mind was a Transmitted: trace
> header that parallels the Received: header, and some new "with protocol"
> types (e.g. esmtpt) to assert that the client had done some extra
> checking. But this would add a lot of bloat for one bit of information so
> perhaps it should just be left in the logs. Dunno.

In January, I proposed a similar field (Sent:) for tracking delays,
and Ned's comment is here:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04126.html

For a bloated debugging functionality, you could also try something
like dmarc or dkim-reporting...

> Regarding authenticity of the header, I could say that any DKIM
> signature should be added after the Transmitted: header. But then you'd
> have to generate different signatures for each transmission of a message
> which is not currently the case.
> 
> But I'm not sure what a server can meaningfully do with knowledge of how
> much checking an unauthenticated client claimed to perform. At the moment
> I'm just thinking of this trace information existing for debugging
> purposes and for deployment tracking and suchlike, so there's no need to
> be particularly precious about it.

IMHO, all of the "auth" techniques (SPF, DKIM, ...) are more or less
in a debugging state, as they are not mandatory and there's no clear
indication of how to use their results.  This bit would add to that
sequence the knowledge that the sender considers that MX server
authoritative.

I'd guess that devising an SMTP extension whereby the client can
transmit some token that substantiates its claim is not quite what
you're after, is it?  But there don't seem to be many other means by
which a publisher of TLSA records can learn whether anybody uses them.

>> Unless I'm missing something, the only places where that info is going
>> to be relevant is if the server rejects the message, if positive DSN was
>> requested but the server doesn't support it, and if the sending fails
>> because some of the specified checks failed.  In those cases, the client
>> can prepare a bounce where the authentication results are reported in
>> detail.
> 
> Hmm, yes, I should add something about DSNs. Thanks. I think it might be
> sufficient to register a new MTA-name-type, perhaps "dane".
> 
> (So regarding Ned's comment about the need for a general mechanism, I
> think RFC 3464 is, happily, already sufficiently general.)

Indeed, that checking is relevant for DSNs.  However, it would be
overkill to add an extra NOTIFY keyword, e.g. "DANE", for ensuring
that a report with "Remote-MTA: dane; something" will always be issued.

Date: Tue, 29 May 2012 14:15:54 +0100
From: Tony Finch <[email-masked]>
To: Alessandro Vesely <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

Alessandro Vesely <[email-masked]> wrote:
>

Thanks for your helpful review.

> I'm not into DANE or DNSSEC, but AIUI there's some over-constraining
> in Section 3.  The spec requires that the whole list of MXes is
> secure, while it could be enough that the selected record is.

The DNS deals with RRsets as a unit, not as individual records. Because of
this there is no way for a domain's MXs to have inconsistent security
states. See RFC 2181 section 5 for more.

> For example, if a domain sets up a dummy backup MX that should work as a
> sort of honeypot, it might want to deliberately omit to add security
> features to its setup while still allowing secure mail delivery on their
> main MX.

That is allowed, because there's no coupling between the MX targets, so
they can individially have TLSA and/or DNSSEC or not. There's a paragraph
about this in the security considerations section, which I am going to
expand because this area is fairly subtle.

> Second, for XXX, I'd suggest updating RFC 5451 and extend it as
> appropriate. A question is that the client-added header field should be
> signed in order to be considered reliable.

I'll have a look at that. What I had in mind was a Transmitted: trace
header that parallels the Received: header, and some new "with protocol"
types (e.g. esmtpt) to assert that the client had done some extra
checking. But this would add a lot of bloat for one bit of information so
perhaps it should just be left in the logs. Dunno.

Regarding authenticity of the header, I could say that any DKIM
signature should be added after the Transmitted: header. But then you'd
have to generate different signatures for each transmission of a message
which is not currently the case.

But I'm not sure what a server can meaningfully do with knowledge of how
much checking an unauthenticated client claimed to perform. At the moment
I'm just thinking of this trace information existing for debugging
purposes and for deployment tracking and suchlike, so there's no need to
be particularly precious about it.

> Unless I'm missing something, the only places where that info is going
> to be relevant is if the server rejects the message, if positive DSN was
> requested but the server doesn't support it, and if the sending fails
> because some of the specified checks failed.  In those cases, the client
> can prepare a bounce where the authentication results are reported in
> detail.

Hmm, yes, I should add something about DSNs. Thanks. I think it might be
sufficient to register a new MTA-name-type, perhaps "dane".

(So regarding Ned's comemnt about the need for a general mechanism, I
think RFC 3464 is, happily, already sufficiently general.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey, Fair Isle, Faeroes: Easterly 4 or 5 in south Bailey, otherwise
variable 3 or 4. Slight or moderate. Occasional rain. Moderate or good.

Date: Tue, 29 May 2012 13:04:09 +0100
From: Tony Finch <[email-masked]>
To: Hector Santos <[email-masked]>
cc: James Cloos <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dane] draft-fanf-dane-smtp
Sender: [email-masked]

Hector Santos <[email-masked]> wrote:
>
> If a TLSA record allows for an server authorized association of the
> CN=secure.winserver.com with the connecting host name, then I can see some
> worth in this dane-smtp proposal - from the client POV seeking a higher level
> of security.

Of course you can do that. You just have to ensure the names match, i.e.
the MX target and TLSA owner have to match the certificate.

The final version of this draft will probably have how-to appendix along
the lines of draft-ietf-dane-protocol appendix A.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
East Viking, North Utsire, South Utsire: Northerly or northwesterly 4 or 5,
increasing 6 for a time. Moderate, occasionally rough. Fair. Good.

Date: Tue, 29 May 2012 12:59:25 +0100
From: Tony Finch <[email-masked]>
To: Hector Santos <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

Hector Santos <[email-masked]> wrote:
>
> I guess, if anything else, there are two client suggestions to highlight:
>
>   - Automated MTA (router)
>   - Interactive MUA smtp client

The draft is for inter-domain SMTP so message submission is out of scope.
I don't think I can make this clearer.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Cromarty, Forth, Tyne, Dogger: Variable 3 or 4. Slight or moderate. Occasional
rain. Moderate or good, occasionally poor later.

Date: Tue, 29 May 2012 12:54:48 +0100
From: Tony Finch <[email-masked]>
To: James Cloos <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [dane] draft-fanf-dane-smtp
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1870870024-887428266-1338292345=:10076
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <[email-masked]>

James Cloos <[email-masked]> wrote:
>
> I've read the draft now.  It looks good.

Thanks.

> =A73 specifies that the hostname MUST be in the cert as an DNS-ID and
> also MAY be there as a CN-ID.

That is basically adapting what RFC 6125 says to the specifics of SMTP,
i.e. subsetting the possible identities (omitting SRV etc.). Perhaps I
ought to make the DNS-ID a SHOULD rather than MUST to follow RFC 6125
more exactly.

Tony.
--=20
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover, Wight, Portland, Plymouth: Variable 3 or 4. Smooth or slight=
=2E
Fog patches. Moderate, occasionally very poor.
--1870870024-887428266-1338292345=:10076--

Date: Sun, 27 May 2012 19:08:25 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: James Cloos <[email-masked]>
CC: Tony Finch <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dane] draft-fanf-dane-smtp
Sender: [email-masked]

James Cloos wrote:
> I've read the draft now.  It looks good.
> 
> §3 specifies that the hostname MUST be in the cert as an DNS-ID and
> also MAY be there as a CN-ID.
> 
> I suspect there are enough MXs in use still using certs generated (with
> long validity periods) which were genreated back when only CN was used
> for the dns names.

How this this apply to use usage of global wildcard certs? in 
additional, not a CA wildcard signed cert, but a unique domain?

For example, I use secure.winserver.com for our HTTPS (web site) SSL 
for eCommence mainly, but since the FTP, SMTP, POP, NNTP and TELNET 
servers is running on the same machine so I use the same cert for 
their TLS capabilities or specific implicit SSL ports, if any, as well.

If a TLSA record allows for an server authorized association of the 
CN=secure.winserver.com with the connecting host name, then I can see 
some worth in this dane-smtp proposal - from the client POV seeking a 
higher level of security.

-- 
HLS

Date: Sun, 27 May 2012 18:44:47 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Finch <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

Tony Finch wrote:
> I have just submitted an I-D describing how to use DANE with SMTP. All
> comments welcome.

Hi Tony,

I think an example should be added to make it clear what an possible 
implementator would be considering.  Showing maybe where similar 
idea(s) is applied now.

So if I read your document right, please correct, this would be akin 
to a BROWSER (interactive client) doing a "Common Name" check.

If so, I seem to recall some SMTP clients, interactive clients as with 
a MUA, also doing a popup for the user, but I may lumping that with 
our own wcSMTPJr client we provide as a command line tool for sending 
a message, usually for testing. which has an option to check the 
"common name" is the same as the host provide to connect.

Here an example run:

D:\local> wcsmtpuser /site:mail.winserver.com

wcSmtpUser 3.1 (c) 2004-2010 SSI (/? for help)
- ini file     : wcsmtpuser.ini
- ini section  : mail.winserver.com
- server name  : mail.winserver.com
- user name    : hector.santos
- use ssl      : YES
- auth method  : 1

* connecting to 208.247.131.9:25
S: 220-winserver.com Wildcat! ESMTP Server v6.4.454.1 ready
S: 220-************** WARNING:  FOR AUTHORIZED USE ONLY! 
**********************
S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY 
COMPUTERS    *
S: 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE 
UNSOLICITED *
S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT 
ACCESS *
S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. 
         *
S: 220 
************************************************************************
C: EHLO hdev20.santronics.com
S: 250-winserver.com, Pleased to meet you.
S: 250-SIZE 10240000
S: 250-8BITMIME
S: 250-SUBMITTER
S: 250-ETRN
S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
S: 250-AUTH=LOGIN
S: 250-HELP
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
** SSL Negotiated session
** Certicate Information File: secure.winserver.com.cert
** CERT Common Name : secure.winserver.com
** CERT Organization: secure.winserver.com
** CERT Valid Until : Dec 27 18:55:51 2012 GMT (Days Left: 214)
** CA Country       : US
** CA Organiziation : GoDaddy.com, Inc.
** CA Common Name   : Go Daddy Secure Certification Authority
!! connection domain : mail.winserver.com
!! common name       : secure.winserver.com
!! Certificate CONNECTION DOMAIN and COMMON NAME mismatch! Accept? Yes 
or No?

My MX is mail.winserver.com but I have been using our 
secure.winserver.com sub-domain for the SSL certificate.

wcSMTPjr has three options (per host section):

    Cert.Expired.Allow=0          # cert expiration check
    Cert.NoMatch.Server.Allow=0   # CN vs connecting host check
    Cert.NoMatch.Host.Allow=1     # CN vs PTR records of IP check

So if the above make sense, how does this DANE-SMTP proposal help me, 
as an example like including the TLSA record that needs to be created?

I guess, if anything else, there are two client suggestions to highlight:

   - Automated MTA (router)
   - Interactive MUA smtp client

Like RFC5321 provides insight here, only with an MUA-SMTP client can 
you do "human" confirmation checks or graceful aborts without losing 
the message.  The MUA-SMTP client may fail to send the message if any 
55x is issued, like with a RCPT TO command.  But with a MTA router, it 
continues.

Make sense?

Thanks

-- 
HLS

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sun, 27 May 2012 11:05:59 -0700 (PDT)
Subject: Re: draft-fanf-dane-smtp
To: Alessandro Vesely <[email-masked]>
Sender: [email-masked]

> > This is about securing the transmission path. Authentication is only incidental
> > to that. And in any case, the only identity that's "authenticated" here is that
> > of the receiving server, and that's supposed to end up in the Received: field
> > the server adds anyway.
> >
> > I'm afraid I really don't see the point.

> For one thing, the fact that the client took the trouble to deal with
> authenticating the MX should probably increase the worthiness of the
> message.

Not when you have to take the client's word for it.

> However, DNSSEC and TLSA lookups, as well as RFC 6125
> validation are carried out by the client alone.  The server has no way
> to know it.  In particular, it won't be able to highlight the client's
> quality in the Received: field.

And that's exactly the point. I see no case where it makes sense for the client
to insert this field into a message as it is being relayed.

> Unless I'm missing something, the only places where that info is going
> to be relevant is if the server rejects the message, if positive DSN
> was requested but the server doesn't support it, and if the sending
> fails because some of the specified checks failed.

Now you're talking about a very different situation. In this case it is
completely inappropriate to insert a field (any field) into the returned
content part of the DSN. It was never part of the message that the client was
submitting/relaying, and that's what is supposed to go there.

That said, this information does make sense to include in the structured return
result part of the DSN - it is in fact an elaboration on the existing
Reporting-MTA field, in that it tells you how you got to the point of talking
to that MTA.

But this is not what Authentication-Results fields are for. Again, this is not
an authentication operation per se. You really need to define a new field for
this information. How-I-Got-To-The-Reporting-MTA is probably unacceptable -;),
so it needs to be something more like Reporting-MTA-Authorization.

I also see no reason why this should be restricted to this particular proposal.
DANE is one way of making sure you're talking to the right server, but it is
hardly the only one. DNSSEC plus traditional certificate hierarchy
authorization also falls into this class, and so do things like using a
IPSEC-secured link, or for that matter a physically secured link. If we're
going to define such a field it needs to cover more ground than DANE.

> In those cases,
> the client can prepare a bounce where the authentication results are
> reported in detail.  For rejection, for example, the author might
> consume such info and be able to attribute some value to the reason
> why the message was rejected, based on the knowledge that it was
> indeed done by a server entitled to do so.

They're not really authentication results, but yes, a mechanism to report
this would be handy in some cases.

The real question is whether or not this should be in this document. Since such
a mechanism really needs to be more general, I'm inclined to say no.

> Normally, the work done for securing the transmission path is not
> noticeable.  Some more visibility, in return for the trouble, would
> seem to be in order.

I agree, but the question is where to make it visible and in what form.
I think the proposal to make it visible in DSNs has merit, but again,
it's a more general thing than the current document.

				Ned

Date: Sun, 27 May 2012 12:01:20 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

On Sat 26/May/2012 21:49:20 +0200 ned+ietf-smtp wrote:
> 
>> I just trust your word on this.
> 
> You probably shouldn't. My understanding of DNSSEC is pretty superficial.

Mine is much less than that :-/  IMHO, with all due respect for
DNSSEC, there's much more to dig with spades before mail admins can
efficaciously fence with foils.

>>> RFC 5451 is about communicating *authentication* results. This use of DANE is
>>> about making mail transport more robust. These are very different things and
>>> mixing them is inappropriate.
> 
>> The only difference I see[*] is that the client authenticates the
>> server rather than the opposite way around.  Indeed, several
>> considerations in RFC 5451, in articular Section 7.1, assume that the
>> authentication server is on the server side of the SMTP transmission.
>> This shouldn't strike down the field format, though.
> 
> This is about securing the transmission path. Authentication is only incidental
> to that. And in any case, the only identity that's "authenticated" here is that
> of the receiving server, and that's supposed to end up in the Received: field
> the server adds anyway. 
> 
> I'm afraid I really don't see the point.

For one thing, the fact that the client took the trouble to deal with
authenticating the MX should probably increase the worthiness of the
message.  However, DNSSEC and TLSA lookups, as well as RFC 6125
validation are carried out by the client alone.  The server has no way
to know it.  In particular, it won't be able to highlight the client's
quality in the Received: field.

Unless I'm missing something, the only places where that info is going
to be relevant is if the server rejects the message, if positive DSN
was requested but the server doesn't support it, and if the sending
fails because some of the specified checks failed.  In those cases,
the client can prepare a bounce where the authentication results are
reported in detail.  For rejection, for example, the author might
consume such info and be able to attribute some value to the reason
why the message was rejected, based on the knowledge that it was
indeed done by a server entitled to do so.

Normally, the work done for securing the transmission path is not
noticeable.  Some more visibility, in return for the trouble, would
seem to be in order.

From: James Cloos <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] draft-fanf-dane-smtp
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2012 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sat, 26 May 2012 20:13:45 -0400
Lines: 17
Sender: [email-masked]

I've read the draft now.  It looks good.

�3 specifies that the hostname MUST be in the cert as an DNS-ID and
also MAY be there as a CN-ID.

I suspect there are enough MXs in use still using certs generated (with
long validity periods) which were genreated back when only CN was used
for the dns names.

Should the draft allow either-or?  Or is there too much precedent in the
TLS specs to allow that in a new rfc?

Otherwise it looks spot on.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sat, 26 May 2012 12:49:20 -0700 (PDT)
Subject: Re: draft-fanf-dane-smtp
To: Alessandro Vesely <[email-masked]>
Sender: [email-masked]

> On Sat 26/May/2012 16:03:11 +0200 ned+ietf-smtp wrote:
> >
> >> I'm not into DANE or DNSSEC, but AIUI there's some over-constraining
> >> in Section 3.  The spec requires that the whole list of MXes is
> >> secure, while it could be enough that the selected record is.
> >
> > That's simply not true. The security of the entire set is essential, since
> > without you have no way of knowing if additional records of equal or  lower
> > priority were present. As such, failure to secure the entire set opens the door
> > to redirection and/or service denial attacks.

> Even if the attack succeeded in causing a devious path, the sender
> would still have transmitted the message to a valid, secure host.
> Isn't that enough for tagging that single transmission "secure"?

Secure in the sense that the message cannot be tampered with or observed, yes,
but there's more to security than that. An unauthorized redirection might cause
a significant increase in message latency or might even allow the message to be
blocked completely. (Paths to different MXes often have very different
characteristics. In fact that's one of the main reasons for using MX records.)

> > Furthermore, I don't believe DNSSEC can actually be used this way. One of the
> > design goals of DNSSEC is to minimize or eliminate the need for on-line
> > signing, which is both computatonally expensive as well as requiring that the
> > DNS server have ongoing access to private keys. As such, it's my understanding
> > (I'm only superficially familar with DNSSEC) that records are signed in groups.

> I just trust your word on this.

You probably shouldn't. My understanding of DNSSEC is pretty superficial.

> >> Second, for XXX, I'd suggest updating RFC 5451 and extend it as
> >> appropriate.
> >
> > RFC 5451 is about communicating *authentication* results. This use of DANE is
> > about making mail transport more robust. These are very different things and
> > mixing them is inappropriate.

> The only difference I see[*] is that the client authenticates the
> server rather than the opposite way around.  Indeed, several
> considerations in RFC 5451, in articular Section 7.1, assume that the
> authentication server is on the server side of the SMTP transmission.
> This shouldn't strike down the field format, though.

This is about securing the transmission path. Authentication is only incidental
to that. And in any case, the only identity that's "authenticated" here is that
of the receiving server, and that's supposed to end up in the Received: field
the server adds anyway. 

I'm afraid I really don't see the point.

				Ned

Date: Sat, 26 May 2012 20:52:19 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

On Sat 26/May/2012 16:03:11 +0200 ned+ietf-smtp wrote:
> 
>> I'm not into DANE or DNSSEC, but AIUI there's some over-constraining
>> in Section 3.  The spec requires that the whole list of MXes is
>> secure, while it could be enough that the selected record is.
> 
> That's simply not true. The security of the entire set is essential, since
> without you have no way of knowing if additional records of equal or  lower
> priority were present. As such, failure to secure the entire set opens the door
> to redirection and/or service denial attacks.

Even if the attack succeeded in causing a devious path, the sender
would still have transmitted the message to a valid, secure host.
Isn't that enough for tagging that single transmission "secure"?

> Furthermore, I don't believe DNSSEC can actually be used this way. One of the
> design goals of DNSSEC is to minimize or eliminate the need for on-line
> signing, which is both computatonally expensive as well as requiring that the
> DNS server have ongoing access to private keys. As such, it's my understanding
> (I'm only superficially familar with DNSSEC) that records are signed in groups.

I just trust your word on this.

>> Second, for XXX, I'd suggest updating RFC 5451 and extend it as
>> appropriate.
> 
> RFC 5451 is about communicating *authentication* results. This use of DANE is
> about making mail transport more robust. These are very different things and
> mixing them is inappropriate.

The only difference I see[*] is that the client authenticates the
server rather than the opposite way around.  Indeed, several
considerations in RFC 5451, in articular Section 7.1, assume that the
authentication server is on the server side of the SMTP transmission.
This shouldn't strike down the field format, though.

[*] My short-sightedness may well be caused by my ignorance of DANE.

From: [email-masked]
Cc: [email-masked]
Date: Sat, 26 May 2012 07:03:11 -0700 (PDT)
Subject: Re: draft-fanf-dane-smtp
To: Alessandro Vesely <[email-masked]>
Sender: [email-masked]

> On Fri 25/May/2012 19:15:36 +0200 Tony Finch wrote:
> >
> > I have just submitted an I-D describing how to use DANE with SMTP. All
> > comments welcome.

> Two comments:

> I'm not into DANE or DNSSEC, but AIUI there's some over-constraining
> in Section 3.  The spec requires that the whole list of MXes is
> secure, while it could be enough that the selected record is.

That's simply not true. The security of the entire set is essential, since
without you have no way of knowing if additional records of equal or  lower
priority were present. As such, failure to secure the entire set opens the door
to redirection and/or service denial attacks.

Furthermore, I don't believe DNSSEC can actually be used this way. One of the
design goals of DNSSEC is to minimize or eliminate the need for on-line
signing, which is both computatonally expensive as well as requiring that the
DNS server have ongoing access to private keys. As such, it's my understanding
(I'm only superficially familar with DNSSEC) that records are signed in groups.

> For
> example, if a domain sets up a dummy backup MX that should work as a
> sort of honeypot, it might want to deliberately omit to add security
> features to its setup while still allowing secure mail delivery on
> their main MX.

Here you're envisioning an application that DNSSEC was never intended to
support. New secondary applications are OK as long as they don't infere with
the primary application a service was intended to provide. But that's exactly
what this does.

> Second, for XXX, I'd suggest updating RFC 5451 and extend it as
> appropriate.

RFC 5451 is about communicating *authentication* results. This use of DANE is
about making mail transport more robust. These are very different things and
mixing them is inappropriate.

				Ned

Date: Sat, 26 May 2012 13:51:37 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

Sorry for replying to myself, I was in a hurry....

On Sat 26/May/2012 10:57:46 +0200 I wrote:
> 
> Second, for XXX, I'd suggest updating RFC 5451 and extend it as
> appropriate.

A question is that the client-added header field should be signed in
order to be considered reliable.  This wouldn't be a problem, in
principle.  However, that's not how DKIM is usually implemented.
(Otherwise, it wouldn't be problematic to learn whether the server
supports 8bitmime or smtputf8.)

Are there use cases where delivery /has/ to be secure?  Courier-MTA
sports a "SECURITY" extension that does so [*].  But even in that
case, having a signed field is quite complicated.  Perhaps, DKIM
signers should have a sign-again parameter that directs them to undo
the signing they just did (the sending client just has to notice it)
and redo it on a slightly varied message --quite inefficient.

[*] http://www.courier-mta.org/draft-varshavchik-security-smtpext.txt

Date: Sat, 26 May 2012 10:57:46 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

On Fri 25/May/2012 19:15:36 +0200 Tony Finch wrote:
> 
> I have just submitted an I-D describing how to use DANE with SMTP. All
> comments welcome.

Two comments:

I'm not into DANE or DNSSEC, but AIUI there's some over-constraining
in Section 3.  The spec requires that the whole list of MXes is
secure, while it could be enough that the selected record is.  For
example, if a domain sets up a dummy backup MX that should work as a
sort of honeypot, it might want to deliberately omit to add security
features to its setup while still allowing secure mail delivery on
their main MX.

Second, for XXX, I'd suggest updating RFC 5451 and extend it as
appropriate.

Date: Fri, 25 May 2012 19:45:57 +0100
From: Tony Finch <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: draft-fanf-dane-smtp
Sender: [email-masked]

Ned Freed <[email-masked]> wrote:

> Just read through it. I think the approach is correct

Thanks for the quick review :-)

> You might want to put something in the security considerations section
> about the trust involved when you have a signed MX pointing to a
> secondary outside your ADMD.

A good suggestion, thanks again.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet, Irish Sea, Shannon: Easterly or northeasterly 5 to 7,
occasionally gale 8. Moderate or rough. Thundery showers. Moderate or good,
occasionally poor.

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 25 May 2012 11:38:54 -0700 (PDT)
Subject: Re: draft-fanf-dane-smtp
To: Tony Finch <[email-masked]>
Sender: [email-masked]

Just read through it. I think the approach is correct, in particular the
choice to put the TLSA at the server host name level rather than the mail
domain level is the correct one. As you explain in Appendix A, this is the
only way it can work given the use of cross-ADMD MXes for things like
secondary service.

You might want to put something in the security considerations section about
the trust involved when you have a signed MX pointing to a secondary outside 
your ADMD.

				Ned

> I have just submitted an I-D describing how to use DANE with SMTP. All
> comments welcome.

> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> Hebrides, Bailey: Northeasterly in Hebrides at first, otherwise southeasterly
> 4 or 5. Slight or moderate. Fog patches. Moderate, occasionally very poor.

> ---------- Forwarded message ----------
> Date: Fri, 25 May 2012 10:10:23 -0700
> From: [email-masked]
> To: [email-masked]
> Subject: New Version Notification for draft-fanf-dane-smtp-00.txt

> A new version of I-D, draft-fanf-dane-smtp-00.txt has been successfully submitted by Tony Finch and posted to the IETF repository.

> Filename:	 draft-fanf-dane-smtp
> Revision:	 00
> Title:		 Secure inter-domain SMTP with TLS, DNSSEC and TLSA records.
> Creation date:	 2012-05-25
> WG ID:		 Individual Submission
> Number of pages: 8

> Abstract:
>    SMTP supports STARTTLS for inter-domain mail transfer, but it only
>    provides very limited security because the server&#39;s certificate
>    cannot be authenticated.  This memo specifies how TLSA records in the
>    DNS can be used for proper MX target server authentication.

> The IETF Secretariat

Date: Fri, 25 May 2012 18:15:36 +0100
From: Tony Finch <[email-masked]>
To: [email-masked], [email-masked]
Subject: draft-fanf-dane-smtp
Sender: [email-masked]

I have just submitted an I-D describing how to use DANE with SMTP. All
comments welcome.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: Northeasterly in Hebrides at first, otherwise southeasterly
4 or 5. Slight or moderate. Fog patches. Moderate, occasionally very poor.

---------- Forwarded message ----------
Date: Fri, 25 May 2012 10:10:23 -0700
From: [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-fanf-dane-smtp-00.txt

A new version of I-D, draft-fanf-dane-smtp-00.txt has been successfully submitted by Tony Finch and posted to the IETF repository.

Filename:	 draft-fanf-dane-smtp
Revision:	 00
Title:		 Secure inter-domain SMTP with TLS, DNSSEC and TLSA records.
Creation date:	 2012-05-25
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   SMTP supports STARTTLS for inter-domain mail transfer, but it only
   provides very limited security because the server&#39;s certificate
   cannot be authenticated.  This memo specifies how TLSA records in the
   DNS can be used for proper MX target server authentication.

The IETF Secretariat

Date: Wed, 23 May 2012 13:18:56 -0400
From: John C Klensin <[email-masked]>
To: Hector Santos <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>
cc: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

Hector,

Three very quick observations about this:

(1) Doesn't work end-to-end.  If any relaying is involved, the
odds that the relay knows enough about the delivery server to
reliably make this commitment on its behalf are not high.

(2) For a number of technical reasons, I'd recommend thinking
about parameters or a separate command rather than changing the
"TO" argument to something else.  If nothing else, the extension
model has been extensively tested for parameters and new
commands and is basically fail-safe.  I don't have any reason to
believe that one could change "TO:" or "FROM:" in the RCPT or
MAIL commands without encountering new and quite interesting
bugs in one system or another.

(3) IMO, we need to keep in mind that every extension has costs.
While Robert has explained what he is trying to do, no one has
offered a persuasive argument that it is important enough to
justify trying to change huge numbers of MUAs and MTAs to make a
heuristic that would work slightly better in some cases.   In
particular, a command variation would not help the recipient
determine the difference between "no intentional BCC" and
"sender doesn't support this mechanism for telling the recipient
that a BCC is present".  One could improve that situation by
having the sender use a MAIL parameter with semantics of "if
there are BCCs among the recipients, I promise to tell you" as
well as the RCPT parameter (or other option) but it is
questionable whether even that would make this valuable enough
to be worth the effort.

best,
   john

--On Wednesday, May 23, 2012 10:06 -0400 Hector Santos
<[email-masked]> wrote:

> 
> Hector Santos wrote:
> 
>> According to the TBIRD test, it stripped the BCC, and used
>> one  transaction (with two RCPT TO). I just did the test with
>> OE, and the  same happen.
>> 
>> Our PX MUA creates two messages, one with the special privacy
>> note.  I  don't see off hand how this can be otherwise be
>> done currently today  without some new IETF MSA proposal that
>> the source MUA is aware of. If  its going to use a single
>> transaction with multiple RCPT TO lines, the  RCPT TO: needs
>> an attribute or a new command - RCPT BCC: or something  like
>> that.
>> 
>> But the fact that its one transaction, to me, the design
>> assumption by  these MUA is that the backend is not expected
>> to do anything here, and  its doesn't expect the MSA to
>> reconstruction the distribution list. That  would be a major
>> flaw here when it comes to the BCC.
> 
> Hmmm, I am just thinking, we can have a backward compatible
> method to support a RCPT BCC: command.
> 
> For example:
> 
>     C: MAIL FROM:< user1 @ domain1.com>
>     S: 250 OK
>     C: RCPT TO:<user2 @ domain2.com>
>     S: 250 OK
>     C: RCPT BCC:<user3 @ domain3.com>
> 
> Two responses:
> 
>     S: 250 OK - will MARK message.
>     S: 500 command not understood
> 
> If the MSA provides a positive response, then the MUA is does
> not have to send a 2nd message.  The MSA will add a special
> note and/or maybe add back the BCC to the header so that at
> least the end-point MUA will see the BCC in the mail view
> header display.
> 
> If the MSA provides a negative response, especially 500, then
> the MUA now knows it will need to send a 2nd transaction with
> a special note to the message or perhaps keeps the BCC in the
> header.
> 
> It all seems doable. The question I will consider is whether
> keeping the BCC in the special message only good enough for
> the end targets to realize it is special.

Date: Wed, 23 May 2012 10:06:17 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

Hector Santos wrote:

> According to the TBIRD test, it stripped the BCC, and used one 
> transaction (with two RCPT TO). I just did the test with OE, and the 
> same happen.
> 
> Our PX MUA creates two messages, one with the special privacy note.  I 
> don't see off hand how this can be otherwise be done currently today 
> without some new IETF MSA proposal that the source MUA is aware of. If 
> its going to use a single transaction with multiple RCPT TO lines, the 
> RCPT TO: needs an attribute or a new command - RCPT BCC: or something 
> like that.
> 
> But the fact that its one transaction, to me, the design assumption by 
> these MUA is that the backend is not expected to do anything here, and 
> its doesn't expect the MSA to reconstruction the distribution list. That 
> would be a major flaw here when it comes to the BCC.

Hmmm, I am just thinking, we can have a backward compatible method to 
support a RCPT BCC: command.

For example:

    C: MAIL FROM:< user1 @ domain1.com>
    S: 250 OK
    C: RCPT TO:<user2 @ domain2.com>
    S: 250 OK
    C: RCPT BCC:<user3 @ domain3.com>

Two responses:

    S: 250 OK - will MARK message.
    S: 500 command not understood

If the MSA provides a positive response, then the MUA is does not have 
to send a 2nd message.  The MSA will add a special note and/or maybe 
add back the BCC to the header so that at least the end-point MUA will 
see the BCC in the mail view header display.

If the MSA provides a negative response, especially 500, then the MUA 
now knows it will need to send a 2nd transaction with a special note 
to the message or perhaps keeps the BCC in the header.

It all seems doable. The question I will consider is whether keeping 
the BCC in the special message only good enough for the end targets to 
realize it is special.

-- 
HLS

Date: Wed, 23 May 2012 09:50:45 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

Hector Santos wrote:
> 
> The point is that AFAIK for a long time, the way it worked for most 
> systems, the BCC is stripped and two mail streams are sent.  (I am going 
> to do a test with my TBIRD shortly to confirm, but I use to use OE and 
> it was the same way.)
> 
> That means the end-point MUA will never really know unless:
> 
>   - The BCC is kept in the 2nd Private Stream Only,
> 
>   - A special top note is written making the reader aware of the
>     privacy nature.
> 

According to the TBIRD test, it stripped the BCC, and used one 
transaction (with two RCPT TO). I just did the test with OE, and the 
same happen.

Our PX MUA creates two messages, one with the special privacy note.  I 
don't see off hand how this can be otherwise be done currently today 
without some new IETF MSA proposal that the source MUA is aware of. 
If its going to use a single transaction with multiple RCPT TO lines, 
the RCPT TO: needs an attribute or a new command - RCPT BCC: or 
something like that.

But the fact that its one transaction, to me, the design assumption by 
these MUA is that the backend is not expected to do anything here, and 
its doesn't expect the MSA to reconstruction the distribution list. 
That would be a major flaw here when it comes to the BCC.

-- 
HLS

Date: Wed, 23 May 2012 06:42:55 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Robert A. Rosenberg" <[email-masked]>
CC: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

On 5/22/2012 8:45 PM, Robert A. Rosenberg wrote:
>The only way I can see for
> the MUA to detect this is to look for me in the To and Cc headers and
> not finding me there (and not finding a List-ID) to issue the warning.

This is the same configuration of information that occurs when you 
receive mail from mailing lists that do not use the List-ID field.

Hence, your heuristic will fail some/much of the time.

Since you are describing a user interface 'warning', as the action to 
take, it might tolerate some failures, depending upon the percentage and 
rate of failure.  There is also the question of whether such a warning 
message would have any efficacy for regular users.  There's good 
indication that it would not.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

Date: Wed, 23 May 2012 08:45:28 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC: [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

Robert,

When I added this special note to our MUA (PX - Platinum Xpress) it 
was due because there was no current way to get this information to 
the BCC target. Since the PX MUA was specifically written for sysops, 
this activity would be higher than normal and it was important any BCC 
would get a top-posting note.   MIME was not an issue at the time.  It 
was all pure text.

Even if there was a IETF proposal, it would be for the new stuff, and 
you could not take a chance any IETF protocol level support not be 
available, so the PX MUA had to do it.

I don't see how it be done without the sending, mail creation MUA have 
some knowledge about it or knowledge the backend will do it.  That is 
why in my last post, I winged it with using a SMTP extension proposal 
using a BLIND keyword.

   The BLIND[=options]

   NOTE - MSA router MAY add the "This is blind copy" body text
   BCC  - MSA router MAY add the 5322.BCC for the blind recipient only.

   none - MSA router decides.
           - For MIME mail, assume BLIND=BCC
           - For text/plain simple mail, assume BLIND=NOTE

The point is that AFAIK for a long time, the way it worked for most 
systems, the BCC is stripped and two mail streams are sent.  (I am 
going to do a test with my TBIRD shortly to confirm, but I use to use 
OE and it was the same way.)

That means the end-point MUA will never really know unless:

   - The BCC is kept in the 2nd Private Stream Only,

   - A special top note is written making the reader aware of the
     privacy nature.

I don't know if this answers your questions. I am just looking at the 
technical aspects of it on how to technically implement it today.  No 
matter what, BCC targets must be made aware somehow so they they don't 
mistakenly reply to all and that can only be done at the source today 
(or the client MUA is 100% aware of its backend server MSA is going to 
this work).

-- 
HLS

Robert A. Rosenberg wrote:
> 
> At 16:14 -0400 on 04/15/2012, Robert A. Rosenberg wrote about Re: 
> "proper" handling of BCC:
> 
>> At 10:04 -0500 on 03/01/2012, Hector Santos wrote about Re: "proper" 
>> handling of BCC:
>>
>>> There is also the consideration regarding displaying.  The MUA may 
>>> want to inform the BCC recipient to the privacy nature of the message:
>>>
>>>     NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN 
>>> THE
>>>     TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS MESSAGE.
>>
>> Query - For issuing this message, how do you determine that the 
>> recipient is getting a copy of the message without being listed in a 
>> To or Cc header due to being BCC'ed or being subscribed to a mailing 
>> list (or do you treat a mailing list received copy as a BCC'ed copy)?
>>
>> I ignore the case of being listed in a To or Cc as a suppressed 
>> address (ie: Group-Name:add1, add2, etc. ;) since the existence of a 
>> group-name:; comment implies a hidden BCC list.
> 
> I asked this question over a month ago and there were a number of 
> replies which branched off from my query but did not answer it (due to 
> misunderstanding my question or shoving the support onto the MSA).
> 
> Thus I will ask it and try to be more explicit in what I want to 
> understand.
> 
> The situation is that I have just received a normal message with NO 
> explicit indication that I was BCC'ed in the message body or via a 
> header. IOW: I am not listed in the supplied TO or CC header (although I 
> may be listed in a Received For clause if I am the only recipient in my 
> domain).
> 
> This BCC delivery would be due to being listed in the BCC header by the 
> sender, being listed in a Group-name:address-1, address-2,etc.; address 
> in the To or Cc header (shown in the received message as Group-name:;), 
> or being sent the message by a mailing list. As I state, I will ignore 
> the mailing list delivery as non-BCC (assuming that there is a List-ID 
> header to flag this) and ask ONLY about the other two which are true 
> cases of being BCC'ed.
> 
> With that out of the way, I am reading a received message and want my 
> MUA to warn me that replying will expose to whoever I reply to via 
> Reply-To-All (ie: The To,Cc,From/Sender addresses) that I received a 
> copy (even though not listed as To or Cc). Note that this is a warning 
> that the MUA sends me when I try to queue/send the reply.
> 
> My question is how would it decide that I should be warned in lieu of 
> the message actually getting queued/sent. I will assume a sanity-check 
> that the warning should NOT be raised if the message being replied to 
> has a List-ID header (ie: It is OK to reply to mailing list messages 
> since if you only want to lurk/monitor you should be cognizant of the 
> fact the message came from a mailing list and it is your fault for 
> responding if you do not want to indicate you are subscribed). Thus we 
> are talking about only true BCC'ed messages. The only way I can see for 
> the MUA to detect this is to look for me in the To and Cc headers and 
> not finding me there (and not finding a List-ID) to issue the warning.
> 
> 
> 

Date: Wed, 23 May 2012 01:48:21 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

--On Tuesday, May 22, 2012 23:45 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

>...
> The situation is that I have just received a normal message
> with NO explicit indication that I was BCC'ed in the message
> body or via a header. IOW: I am not listed in the supplied TO
> or CC header (although I may be listed in a Received For
> clause if I am the only recipient in my domain).
> 
> This BCC delivery would be due to being listed in the BCC
> header by the sender, being listed in a Group-name:address-1,
> address-2,etc.; address in the To or Cc header (shown in the
> received message as Group-name:;), or being sent the message
> by a mailing list. As I state, I will ignore the mailing list
> delivery as non-BCC (assuming that there is a List-ID header
> to flag this) and ask ONLY about the other two which are true
> cases of being BCC'ed.

There is another case, which is that of a non-enumerated group,
i.e., something like "Group-name:;" rather than
"Groupd-name:address...;".  This could lead to a long
philosophical discussion, but I'd argue that your receiving a
message in which your Group syntax is used but your address does
not appear explicitly is a lot more like a mailing list
situation than list a Bcc, except that "List-*" headers would
not be generated unless there is a mailing list involved too.
If you have headers of, e.g., 

   To: [email-masked], Somegroup:;
   cc: [email-masked]

then presence of a set of List-& header fields would normally
indicate that you got the message from the list (warning, there
are a few edge cases that aren't hard to construct as well as
list expanders that don't put in List-* header fields) that make
that test less than 100% reliable).  Assuming that
[email-masked] is not an alias pointing to you, the
absence of List-* headers would indicate either that your are a
member of "Somegroup" or that the message was a bcc to you.

Note also that

   To: [email-masked], Somegroup:;
   cc: Big-list: [email-masked];

is also permitted.  Some would claim that its semantics are
exactly the same as the example above, others might try to
attribute meaning to the explicit use of group syntax.  I have
no idea whether systems that generate "List-* header fields
would consider them different or not.

> With that out of the way, I am reading a received message and
> want my MUA to warn me that replying will expose to whoever I
> reply to via Reply-To-All (ie: The To,Cc,From/Sender
> addresses) that I received a copy (even though not listed as
> To or Cc). Note that this is a warning that the MUA sends me
> when I try to queue/send the reply.

In the examples above, you need worry only about joe-blow and
the mailing list, since the group cannot be replied to and will
be dropped, often without warning, by most MUAs (the others will
get confused).  I also note that, unless the membership of the
mailing is available to all list members or perhaps the public,
the cases of "replying to a Bcc" and "replying to a message
delivered via the list" are not as different as you might
assume.  In both cases, you are disclosing the fact that you
have received the message to people who might not have any other
way to know that.  You sort of cover this below, but I want to
avoid any possible misunderstanding.

> My question is how would it decide that I should be warned in
> lieu of the message actually getting queued/sent. I will
> assume a sanity-check that the warning should NOT be raised if
> the message being replied to has a List-ID header (ie: It is
> OK to reply to mailing list messages since if you only want to
> lurk/monitor you should be cognizant of the fact the message
> came from a mailing list and it is your fault for responding
> if you do not want to indicate you are subscribed). Thus we
> are talking about only true BCC'ed messages. The only way I
> can see for the MUA to detect this is to look for me in the To
> and Cc headers and not finding me there (and not finding a
> List-ID) to issue the warning.

If there is no empty group syntax (for which "(undisclosed
recipients)" is a popular surrogate) and you trust the "List-*"
heuristic, then yes, that works and is the closest approximation
you can get.  In practice, there is no way to know with complete
certainty.  If an empty group --which, again, is not a bcc--
although you might consider it equivalent for your purposes-- is
present, then the distinction you are trying to make is pretty
hopeless.

Moving back to some of the answers that you don't believe are
relevant to your question, this situation is precisely why
senders who want to warn about inadvertent disclosure of bcc
recipients either insert explicit warnings into the first text/
body part or use a "forward"-like mechanism to send the original
message to the bcc recipient in encapsulated form (maybe also
with a warning).

    john

Date: Tue, 22 May 2012 23:45:07 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: "proper" handling of BCC
Sender: [email-masked]

At 16:14 -0400 on 04/15/2012, Robert A. Rosenberg wrote about Re: 
"proper" handling of BCC:

>At 10:04 -0500 on 03/01/2012, Hector Santos wrote about Re: "proper" 
>handling of BCC:
>
>>There is also the consideration regarding displaying.  The MUA may 
>>want to inform the BCC recipient to the privacy nature of the 
>>message:
>>
>>     NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN THE
>>     TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS MESSAGE.
>
>Query - For issuing this message, how do you determine that the 
>recipient is getting a copy of the message without being listed in a 
>To or Cc header due to being BCC'ed or being subscribed to a mailing 
>list (or do you treat a mailing list received copy as a BCC'ed copy)?
>
>I ignore the case of being listed in a To or Cc as a suppressed 
>address (ie: Group-Name:add1, add2, etc. ;) since the existence of a 
>group-name:; comment implies a hidden BCC list.

I asked this question over a month ago and there were a number of 
replies which branched off from my query but did not answer it (due 
to misunderstanding my question or shoving the support onto the MSA).

Thus I will ask it and try to be more explicit in what I want to understand.

The situation is that I have just received a normal message with NO 
explicit indication that I was BCC'ed in the message body or via a 
header. IOW: I am not listed in the supplied TO or CC header 
(although I may be listed in a Received For clause if I am the only 
recipient in my domain).

This BCC delivery would be due to being listed in the BCC header by 
the sender, being listed in a Group-name:address-1, address-2,etc.; 
address in the To or Cc header (shown in the received message as 
Group-name:;), or being sent the message by a mailing list. As I 
state, I will ignore the mailing list delivery as non-BCC (assuming 
that there is a List-ID header to flag this) and ask ONLY about the 
other two which are true cases of being BCC'ed.

With that out of the way, I am reading a received message and want my 
MUA to warn me that replying will expose to whoever I reply to via 
Reply-To-All (ie: The To,Cc,From/Sender addresses) that I received a 
copy (even though not listed as To or Cc). Note that this is a 
warning that the MUA sends me when I try to queue/send the reply.

My question is how would it decide that I should be warned in lieu of 
the message actually getting queued/sent. I will assume a 
sanity-check that the warning should NOT be raised if the message 
being replied to has a List-ID header (ie: It is OK to reply to 
mailing list messages since if you only want to lurk/monitor you 
should be cognizant of the fact the message came from a mailing list 
and it is your fault for responding if you do not want to indicate 
you are subscribed). Thus we are talking about only true BCC'ed 
messages. The only way I can see for the MUA to detect this is to 
look for me in the To and Cc headers and not finding me there (and 
not finding a List-ID) to issue the warning.

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sun, 06 May 2012 22:52:21 -0700 (PDT)
Subject: Re: bogus SPF deployment survey
To: Alessandro Vesely <[email-masked]>
Sender: [email-masked]

> On Tue 01/May/2012 13:20:13 +0200 ned+ietf-smtp wrote:
> >
> >> Even if it's a test system or a home system, the way you deploy
> >> that protocol reveals your personal preferences and attitudes
> >> toward it.
> >
> > I'm sorry, but that's just not true. Like most of the other people
> > on this list, I'm a developer, and as such I deploy things for
> > reasons having nothing whatsoever to do with my personal
> > preferences for how an email server should be run. Additionally, my
> > experience is routinely based on feedback I get from customers
> > *when they are having problems*. It is a rare customer indeed that
> > calls up and says, "We deployed such and such and it is working
> > fine".

> Oh well, yes, attitudes related to your customers' needs may obfuscate
> your personal preferences, for some time.  My questions assume that
> respondents hadn't modified their settings for a good deal of time,
> which might be false in some cases.  Whether you're happy or
> dissatisfied, free or compelled, stable or ever-changing, you answers
> would have reflected some kind of tendency.

> I may admit it's not very accurate, but the point, IMHO, is to grasp
> which is true among "(almost) nobody does that", "there's a small but
> non-negligible cluster of operators who'd do that", and "that's being
> done by a considerable amount of people".

But why settle for an extremely small and biased set of responses when a
different set of questions to the same audience can tap into much  more useful
and relevant information?

Again, you're talking to people who implement and deploy email software here.
So why not ask:

(1) Whether or not their products support SPF, and why.
(2) If they implemented SPF, what the customer response has been.
(3) What interoperability problems have shown up.

I note that this is close to the set of questions we ask when trying to assess
interoperability. There are good reasons for having setttled on this approach.

Now, if I had to answer these myself, I'd say:

(1) We have built in support for both SPF and SRS in our product. We
    implemented both in anticpation of customer requests, not because of them.

(2) We have observed relatively little interest in using our SPF support,
    considerably more in SRS. In and of itself this would seem to indicate
    that SPF is seen less as a useful thing and more as problem to work around.

    There are, however, additional factors in play that would tend not to
    support any such conclusion. One is that we typically don't hear from
    people who deploy something without incident, and SPF is easy to set up
    whereas SRS is a bit tricky. Another is that there was a substantial bug
    in our SRS implementation (my fault), whereas the only bug I recall in our
    SPF implementation was one having to with IPv6, which due to the level of
    deployment of IPv6 for mail service had little if any effect.

    And probably most important of all, it's entirely possible that sites
    are relying on SPF support that's built into whatever AS/AV software they
    are using, making our support of it irrelevant. OTOH, it's also possible
    sites are content with the non-SPF filtering these packages provide and
    don't care about SPF at all. There's just no way for us to tell.

(3) We have not observed any interoperability problems with either SPF or SRS,
    unless you count the problems SPF causes that SRS solves.

I've included SRS here because I think mitigation strategies for the issues
SPF causes are highly relevant to the question of whether or not SPF should
be placed on the standards track.

> >> IMHO, omitting to take the survey, you --in general, non responders--
> >> just express lack of interest in SPF.  Am I wrong?
> >
> > Yes, you are completely wrong.

> Do you mean on your case in particular or on why, in general, few
> people respond to that survey?

You're wrong in concluding that a failure to respond to your survey indicates a
lack of interest in SPF. And since several people agreed with my original
posting on this, I don't think I'm alone in this.

> >>> If you want to ask questions of an audience of implementors, I
> >>> suggest that you ask them what kind of support for SPF do they
> >>> provide in their products and perhaps what they know (or don't
> >>> know) about actual customer usage of those features.
> >>
> >> Agreed, if I had been more clever I'd have done that.  But then,
> >> those who would have taken the burden to answer such more lengthy
> >> questions are probably participating in SPFBIS already.  My
> >> questions are easier to ask as well as to answer.
> >
> > And that's 0 for 3. I am comprehensively well versed in what
> > features our product has, including the parts of the product I
> > didn't write, because I am constantly answering complicated
> > questions about how to accomplish various things using our
> > product's capabilities.
> >
> > Similarly, I am constantly receiving and assessing information
> > from customers about problems they are having as well as what
> > additional capabilities they want. This is how I decide what
> > features to add, remove, or enhance.
> >
> > Since I think about this stuff all the time, it is trivial for me
> > to regurgitate some subset of it when asked.

> I believe that's true for you personally, as your helpfulness can be
> readily evinced by your patience in going along with my ruminations on
> this subject --thank you for that, btw.  However, I doubt anyone at,
> say, Microsoft would ever consider such questions, let alone reply to
> them.

That may or may not be true, but there are plenty of email vendors besides
Microsoft.

> As I said, I'm not clever enough to do that.  I'd need real
> assistance to carry it out.  I'm open to proposals...

I thought I made a fairly specific proposal in my original response, but
I've firmed it up here. See above.

				Ned

Date: Tue, 01 May 2012 14:44:31 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: bogus SPF deployment survey
Sender: [email-masked]

On Tue 01/May/2012 13:20:13 +0200 ned+ietf-smtp wrote:
> 
>> Even if it's a test system or a home system, the way you deploy
>> that protocol reveals your personal preferences and attitudes
>> toward it.
> 
> I'm sorry, but that's just not true. Like most of the other people
> on this list, I'm a developer, and as such I deploy things for
> reasons having nothing whatsoever to do with my personal
> preferences for how an email server should be run. Additionally, my
> experience is routinely based on feedback I get from customers
> *when they are having problems*. It is a rare customer indeed that 
> calls up and says, "We deployed such and such and it is working
> fine".

Oh well, yes, attitudes related to your customers' needs may obfuscate
your personal preferences, for some time.  My questions assume that
respondents hadn't modified their settings for a good deal of time,
which might be false in some cases.  Whether you're happy or
dissatisfied, free or compelled, stable or ever-changing, you answers
would have reflected some kind of tendency.

I may admit it's not very accurate, but the point, IMHO, is to grasp
which is true among "(almost) nobody does that", "there's a small but
non-negligible cluster of operators who'd do that", and "that's being
done by a considerable amount of people".

>> IMHO, omitting to take the survey, you --in general, non responders--
>> just express lack of interest in SPF.  Am I wrong?
> 
> Yes, you are completely wrong.

Do you mean on your case in particular or on why, in general, few
people respond to that survey?

>>> If you want to ask questions of an audience of implementors, I
>>> suggest that you ask them what kind of support for SPF do they
>>> provide in their products and perhaps what they know (or don't
>>> know) about actual customer usage of those features.
>> 
>> Agreed, if I had been more clever I'd have done that.  But then,
>> those who would have taken the burden to answer such more lengthy
>> questions are probably participating in SPFBIS already.  My
>> questions are easier to ask as well as to answer.
> 
> And that's 0 for 3. I am comprehensively well versed in what
> features our product has, including the parts of the product I
> didn't write, because I am constantly answering complicated
> questions about how to accomplish various things using our
> product's capabilities.
> 
> Similarly, I am constantly receiving and assessing information
> from customers about problems they are having as well as what
> additional capabilities they want. This is how I decide what
> features to add, remove, or enhance.
> 
> Since I think about this stuff all the time, it is trivial for me 
> to regurgitate some subset of it when asked.

I believe that's true for you personally, as your helpfulness can be
readily evinced by your patience in going along with my ruminations on
this subject --thank you for that, btw.  However, I doubt anyone at,
say, Microsoft would ever consider such questions, let alone reply to
them.  As I said, I'm not clever enough to do that.  I'd need real
assistance to carry it out.  I'm open to proposals...