Subject: Re: [ietf-dkim] Consensus check: Domain Existence Check

From: Scott Kitterman <[email-masked]>
Date: Mon, 2 Jun 2008 16:06:33 -0400

On Thursday 29 May 2008 05:45, Stephen Farrell wrote:
> There has been considerable debate in the past few weeks regarding the
> need for a check for domain existence in ADSP.
...
> b. Modify, i.e. keep, but with a different set of records.  It was
> suggested that the current NXDOMAIN is incorrect, and that MX, A, and
> AAAA records for the domain should be queried, with the existence of
> any of these records indicating a domain that is potentially used for
> email. If we have consensus for this option, then we may well need a
> subsequent poll to decide the details.

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Tue, 03 Jun 2008 15:28:49 -0700

Good summary, Tony.  Here's my perspective:

Tony Hansen wrote:
> Tony Hansen wrote:
>   
>>     *	levine-adsp-00 provides a superset of methods for *how* to 
>> determine if the domain exists: the NXDOMAIN test and the "check MX & 
>> A/AAAA" method from SMTP. It leaves it up to the implementation to 
>> choose the algorithm that works best for it.
>>     

While I agree that, in practice, either practice is "good enough", I 
don't see a good reason for specifying two different ways of doing this 
test.  The closest to this that I have seen is Tony Finch's comment that 
there might be some resolvers that don't distinguish NXDOMAIN from (for 
example) a no-data result, but I haven't seen anyone cite an example of 
this so I don't know whether this is a hypothetical or real consideration.

Since ADSP is a security-related specification (or, at least, this is a 
WG in the Security Area), I think it's beneficial to be as precise as 
possible about how the ADSP Check is done.

-Jim

---

From: John Levine <[email-masked]>
Date: 4 Jun 2008 14:02:53 -0000

>>> choose the algorithm that works best for it.

What I should have said was that recipients MUST do the NXDOMAIN check
and SHOULD do the more comprehensive 2821 check.  It's SHOULD since it
is my impression that many MTAs do it anyway, so there's no incremental
cost.

This gives senders a baseline that they know receivers will do, and if
the receivers are more sceptical, that doesn't hurt the senders.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Wed, 04 Jun 2008 17:39:17 +0200

John Levine wrote:
>>>> determine if the domain exists: the NXDOMAIN test and the "check MX&

That would be fine.

Eliot

---

From: Dave Crocker <[email-masked]>
Date: Wed, 04 Jun 2008 09:14:52 -0700

> is my impression that many MTAs do it anyway, so there's no incremental

In the interest of accuracy:

   I have been probing some email receive-side folk, about their call-back or 
verification steps like this that they conduct.  Generally, the range of tests 
is of these types.

    Unfortunately, it is rarely based on the rfc2822.From field.  It is, 
instead, typically based on rfc2821.mailfrom.

So we need to be careful about assuming that any of these tests are likely to 
be "free".  In fact, one bit of feedback I got was explicit about these 
additional tests as costing too much.  They had tried and found they added too 
much delay.

FWIW.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 4 Jun 2008 10:46:18 -0700

On Jun 4, 2008, at 9:14 AM, Dave Crocker wrote:
>   I have been probing some email receive-side folk, about their call- 
> back or verification steps like this that they conduct.  Generally,  
> the range of tests is of these types.
>
>    Unfortunately, it is rarely based on the rfc2822.From field.  It  
> is, instead, typically based on rfc2821.mailfrom.
>
> So we need to be careful about assuming that any of these tests are  
> likely to be "free".  In fact, one bit of feedback I got was  
> explicit about these additional tests as costing too much.  They had  
> tried and found they added too much delay.

Dave,

This touches a significant issue.  The rfc2822.From fields may contain  
addresses that will _not_ resolve any DNS resource records for  
protocols other than SMTP.  For example, Microsoft Exchange was  
initially based upon X.400 recommendations in the 1980s by the  
Consultative Committee of International Telephone and Telegraph  
(CCITT), now known as Telecommunications Standardization Sector of the  
International Telecommunication Union (ITU-T).  As a result, use of X. 
400 addresses means it is fairly common to find email-address domains  
that do not exist whatsoever within DNS.  An NXDOMAIN result with  
respect to an X.400 MS Exchange email-address is completely meaningless.

Although your attempt to better define the ADSP draft's abstract  
represents an improvement, this abstract still misses this extremely  
important point (made in the otis-dkim-adsp draft).  While DKIM might  
be used by many different protocols, it is _not_ practical to offer  
protection based upon the use of DNS for non-public exchange  
protocols.  Nor is it logical to assume that a domain will implement  
DKIM for _all_ exchange protocols, especially when DKIM becomes  
considered essential only for the public SMTP exchange.

With respect to ADSP, the WG must stop pretending ADSP can apply to  
protocols as broadly as DKIM might.  ADSP MUST be narrowly defined as  
only pertaining to SMTP message exchanges!  Otherwise, ADSP becomes  
disruptive when misapplied at an MUA accepting messages carried over  
different protocols.  MUAs might be able mitigate some disruption by  
making ADSP optional.  The optional nature of ADSP could apply to all  
messages handled by the MUA, or more ideally, as an exception limited  
to specific email-address domains.

-Doug

---

From: "J D Falk" <[email-masked]>
Date: Wed, 4 Jun 2008 13:58:05 -0400

> the receivers are more sceptical, that doesn't hurt the senders.

+1

> additional tests as costing too much.  They had tried and found they added too

Too much delay for too little benefit, most likely.  That balance seems
likely to change once more high-value domains sign with DKIM and use one of
the strict ADSP assertions.

-- 
J.D. Falk
Return Path

Work with me!
http://www.returnpath.net/careers/

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 04 Jun 2008 12:21:10 -0500

+1

Arvel

---

From: SM <[email-masked]>
Date: Wed, 04 Jun 2008 13:11:18 -0700

>instead, typically based on rfc2821.mailfrom.

Most MTAs do not perform any existence test on the RFC2822 From 
field.  It's not a "free" test.  Any test would be a RFC 2822 
operation based on RFC 2821 rules or whatever rules the Working Group 
agrees upon.

Regards,
-sm

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 05 Jun 2008 12:23:03 +0100

> respect to an X.400 MS Exchange email-address is completely meaningless.

Then please could you provide us with a full example that could actually  
happen, starting from an X.400 email that somehow got tranformed into an  
RFC 2822 object that contained unresolvable domains, and which yet managed  
to acquire a DKIM signature (not necessarily by anything in the From  
header) and was also capable of being replied to by its recipient.

If such a beast can exist, then we need to take note of it, but i am not  
aware that it could exist.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jun 2008 11:41:34 -0700

On Jun 5, 2008, at 4:23 AM, Charles Lindsey wrote:

>> This touches a significant issue.  The rfc2822.From fields may  
>> contain addresses that will _not_ resolve any DNS resource records  
>> for protocols other than SMTP.  For example, Microsoft Exchange was  
>> (CCITT), now known as Telecommunications Standardization Sector of  
>> the International Telecommunication Union (ITU-T).  As a result,  
>> use of X.400 addresses means it is fairly common to find email- 
>> address domains that do not exist whatsoever within DNS.  An  
>> NXDOMAIN result with respect to an X.400 MS Exchange email-address  
>> is completely meaningless.
>
> Then please could you provide us with a full example that could  
> actually happen, starting from an X.400 email that somehow got  
> tranformed into an RFC 2822 object that contained unresolvable  
> domains, and which yet managed to acquire a DKIM signature (not  
> necessarily by anything in the From header) and was also capable of  
> being replied to by its recipient.
>
> If such a beast can exist, then we need to take note of it, but i am  
> not aware that it could exist.

Many companies use MS Exchange rather than normal SMTP servers.  MS  
Exchange permits creation of mail addresses unreachable by SMTP, since  
these domains may only exist through an internal X.400 assignment.   
While some companies find this a desirable feature, it is often a PITA  
for users of this service.  While a parent domain may wish to assert  
ADSP practices, MS Exchange related email sub-domains can be created  
for various purposes without publishing _any_ record within DNS.  The  
MUA will therefore receive a mixture of SMTP and MS Exchange messages,  
but this would only create a problem with specific domains for users  
of the MS Exchange service.

One common solution is to forward out of MS Exchange to an SMTP  
server, but where the "special" sub-domains within the company's email  
are then unable to receive an SMTP response.  In my case, there are  
also many parent domains within various TLDs to examine as well.   
Asking how these messages receive a DKIM signature misses the point.   
There would be little value using DKIM for messages normally  
restricted to a corporate MS Exchange.

ADSP should be defined as offering practices for SMTP, and not MS  
Exchange, Lotus Notes, NNTP, etc.  Protocol gateways will be impaired  
by an application of ADSP that preclude acceptance from domains not  
supporting SMTP.  When an Author Domain asserts even a CLOSED  
practice, a protocol gateway problem can not be mitigated by only  
testing for NXDOMAIN when a bridged protocol has not implemented  
DKIM.  Receiving messages from protocols other than SMTP requires  
exceptions be made when applying ADSP.  In any case, ADSP can not be  
universally applied at the MUA.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 5 Jun 2008 21:49:49 +0200

Douglas Otis wrote:

> MS Exchange, Lotus Notes, NNTP, etc.

Whatever MS Exchange and Fidonet might do, the From: addresses in
RFC.ietf-usefor-usefor are precisely what RFC 2822 says.  It's not
the job of ADSP to solve MS Exchange or Fidonet issues, these nets
have their own standards, and gateways are always a tricky issue.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jun 2008 15:11:25 -0700

> have their own standards, and gateways are always a tricky issue.

Agreed.  However, ADSP must limit the scope of the practice.  DKIM is  
unlikely adopted by all transports whenever ADSP indicates adoption by  
SMTP.  ADSP must clearly state the transport.  ADSP can not ignore the  
transport in the same manner as RFC2822 and RFC4871 have.  Unlike a  
syntax specification, a practice must be specific about the transport  
used.

RFC2822 Scope statement:
,---
|... This standard applies only to the format and some of the semantics
|of message contents.  It contains no specification of the information
|in the envelope.
|
|However, some message systems may use information from the contents
|to create the envelope.  It is intended that this standard facilitate
|the acquisition of such information by programs. ...
'___

While RFC2822 does not define the transport protocol and related name  
space applied to the From: header, the reference to the envelope is  
specified by RFC2821 which indicates a basic desire to facilitate  
SMTP.  Is it beyond SMTP receivers' prerogative to impose an  
additional requirement that creation of envelopes based upon From:  
headers be assured by the presence of resource records specified by  
RFC2821?  It should be possible to specify an RFC2821 support  
requirement, provided SMTP receivers are adequately made aware of  
potential conflicts with other transport protocol gateways, while also  
offering possible mitigation strategies.  Clearly, such requirements  
can never be a MUST, although when validating the absence of an ADSP  
assertion, verifying SMTP support should be a SHOULD.

-Doug

---

From: Damon <[email-masked]>
Date: Thu, 5 Jun 2008 17:41:37 -0400

OK. Now that isn't going to happen. Let's be realistic.
Anything short of aliens landing in Miami is going to get something
like this into or out of Lotus Notes some time this century. (And
sadly I am being realistic here)
Saying that we ignore these systems because they haven't followed the
rules just disenfranchised a large enough piece of the pie for this
scheme to be called unworkable.

Regards,
Damon

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 6 Jun 2008 01:30:29 +0200

Douglas Otis wrote:

> Agreed.  However, ADSP must limit the scope of the practice.

Okay, so apparently we agree that noting say "gbl" addresses
as "nomailfqdn" and then reject or even discard them is a bad
idea.  (I'm not sure if "gbl" is the correct example, please
correct me if it's beside your point.)

However we're here deep in "receiver policy" territory again,
as nice as an X.400 address might be, I don't wish to get it
in my inbox, because I'd have no clue how to reply - without
reading old Mixer RFCs, which would be cheating, not what an
ordinary user does.

To take something less exotic, IIRC the drafts don't discuss
domain literals at the moment.  For an "nxdomain" check this
could be addressed by stating "n/a".

For John's more elaborated "nomailfqdn" check it could be 
either solved as "a domain literal is *of course* no FQDN",
or by saying "a domain literal *of course* is an A or AAAA".

I'd prefer "no FQDN" and let the receiver decide what to do
with it, because the technical details of which A or AAAA 
are plausible public addresses (not 127.0.0.1 etc.) are no
topic for ADSP.  But maybe it is as simple as two normative
references, and after all it still boils down to "let the
receiver decide".

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jun 2008 17:38:08 -0700

On Jun 5, 2008, at 2:41 PM, Damon wrote:

> OK. Now that isn't going to happen. Let's be realistic. Anything  
> short of aliens landing in Miami is going to get something like this  
> into or out of Lotus Notes some time this century. (And sadly I am  
> being realistic here)
> Saying that we ignore these systems because they haven't followed  
> the rules just disenfranchised a large enough piece of the pie for  
> this scheme to be called unworkable.

Precautions required for non-SMTP transport may involve the imposition  
of domain specific exceptions.  In cases where there might be a mix of  
private/public name space, the exceptions would be only for a few  
specific domains.  Such an effort does not seem impractical,  
especially when such domains are likely well known by the enterprise  
making use of non-SMTP transports.  Domains desiring that their NNTP  
messages can carried over SMTP via a protocol gateway may find greater  
acceptance by accommodating SMTP responses against their domain.  In  
most cases, this is likely already the case.  Establishing provisions  
for such exceptions seems realistic.  It would be true that without an  
exception provision, validating the absence of ADSP records may  
disrupt the exchange of non-SMTP messages, such as those for MS  
Exchange.

However, validating the absence of ADSP records for a domain is:

1) not required.

2) not needed for private messages from known sources exchanged over  
non-SMTP transport.

3) likely already accommodated by SMTP as an alternative transport.

This is not attempting to disenfranchise any non-SMTP transport.   
However, ADSP should be upfront about the potential disruption it may  
cause when provisions for exceptions are not available.  A disruption  
of non-SMTP transport conversions will be caused when either  
validating the absence of ADSP records or by imposing a CLOSED practice.

The DKIM WG has a few choices:

A) State that ADSP only applies to SMTP and indicate ADSP does not  
prevent sub-domain related abuse.  This approach should also  
specifically exclude attempts at validating the absence of ADSP  
records.  (An approach that several have suggested.)

B) State that the absence of ADSP records should be validated by the  
presence of SMTP resource records.  This approach offers significant  
and immediate benefits, however this also necessitates a means to make  
domain specific exceptions.

C) Don't state what transport is involved, and then suggest the  
absence of ADSP records might be validated by either the presence of  
SMTP resource records or the lack of NXDOMAIN.  This approach offers  
few benefits, fails to confirm SMTP support, and fails to clarify what  
exceptions would be needed to prevent the disruption of non-SMTP  
transport.

Either A or B approach would be okay.  Attempting approach C has the  
potential of truly disenfranchising several non-SMTP transport users.   
It seems approach C is now being attempted by the WG ADSP draft.   
IMHO, approach B offers the greatest benefit over the long term.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 5 Jun 2008 20:24:44 -0700

On Jun 5, 2008, at 4:30 PM, Frank Ellermann wrote:

> Okay, so apparently we agree that noting say "gbl" addresses as  
> "nomailfqdn" and then reject or even discard them is a bad idea.   
> (I'm not sure if "gbl" is the correct example, please correct me if  
> it's beside your point.)

Sorry, the term "gbl" eludes me.  A scheme that refuses messages based  
upon NXDOMAIN or the lack of SMTP discovery records would be a bad  
idea without also incorporating a domain specific mitigation  
strategy.  A mitigation strategy could be to make exceptions for non- 
SMTP domains.  Exceptions would be made by transports and MUAs  
accepting messages from non-SMTP transports.  These exceptions would  
likely represent fairly simple and small domain or address list.

> However we're here deep in "receiver policy" territory again, as  
> nice as an X.400 address might be, I don't wish to get it in my  
> inbox, because I'd have no clue how to reply - without reading old  
> Mixer RFCs, which would be cheating, not what an ordinary user does.

Mailbox addresses must conform to the syntax specified by RFC2822.   
Exceptions could be based upon specific domains that might be assigned  
by X.400 rather than DNS, for example.  An ability to make exceptions  
is needed for users making use of non-SMTP transport and non-DNS name  
space.

> To take something less exotic, IIRC the drafts don't discuss domain  
> literals at the moment.  For an "nxdomain" check this could be  
> addressed by stating "n/a".

Unless messages from "n/a" domains are not accepted, ADSP would be  
unable to prevent sub-domain abuse.  When ADSP adds an absence  
validation requirement, then messages handled by MS Exchange may be  
disrupted.  Nevertheless, it should be a small matter to impose an  
exception for their own domains, provided of course the transport  
supports a means to make these exceptions.

> For John's more elaborated "nomailfqdn" check it could be  either  
> solved as "a domain literal is *of course* no FQDN", or by saying "a  
> domain literal *of course* is an A or AAAA".

John's draft offers a mode that provides fewer benefits where SMTP  
support is not confirmed by the added overhead, nor is the transport  
specified.

The otis-dkim-adsp draft leaves out AAAA records.  Mandating presence  
of either an MX or A record at this time should not be disruptive,  
however the AAAA record exclusion affords IPv6 hosts greater  
protection from SMTP related undesired traffic.  Once again, the AAAA  
record exclusion also requires a means to make an exception for  
crucial systems.

Our bad actor tracking system observes millions of new IP addresses  
becoming briefly active every hour. These addresses then go dormant  
for very long periods of time.  With hundreds of millions of addresses  
within their control, about 40 million bad actor controlled sources  
make SMTP transactions within any given hour.  A mandate to publish MX  
records can reduce the level of undesired and potentially dangerous  
levels of traffic imposed on non-SMTP domains when spoofed as an email  
source.  By having vast numbers of Bots, both spam and malware quickly  
become a unique product generated for each receiver.  A strategy that  
depends upon content filtering is doomed.  However, source validation  
and behaviour tracking remains viable.

Even here, ADSP is making a tragic mistake.  Binding the local-part to  
the Author Key domain disallows opaque local-part identifiers that  
might track access accounts rather than users by name.  It is not  
practical for DKIM signatures to link local-parts with each user.   
Ascribing the signer as an identity that includes the local-part  
parameter unfortunately prevents a practical use of DKIM for tracking  
intra-domain abuse without needlessly violating user privacy or  
freedom.  The work-around requires multiple signatures be applied  
whenever DKIM affirms on whose behalf the message was signed when the  
identifier does not match the From header.

> I'd prefer "no FQDN" and let the receiver decide what to do with it,  
> because the technical details of which A or AAAA are plausible  
> public addresses (not 127.0.0.1 etc.) are no topic for ADSP.  But  
> maybe it is as simple as two normative references, and after all it  
> still boils down to "let the receiver decide".

The Internet and SMTP is under siege.  If DKIM is to have merit, it  
should be part of a comprehensive strategy.  With DKIM, both receivers  
and senders should be be able block bad actors infiltrating domains  
using standardized conventions.  At every level of security, simple  
standardized message passing is needed.  SMTP and similar approaches  
must be employed in a secure fashion.  These solutions likely  
represent a critical aspect for future designs.

A message transport should verify support of the transport protocol by  
purported originators before proceeding with a large number of  
transactions.  A means to make exceptions is also essential, since DNS  
failure must be tolerated for crucial systems.  The ability to make  
exceptions also supports a mix of non-SMTP traffic within SMTP as well.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 06 Jun 2008 10:44:58 +0100

> of the MS Exchange service.

Will you please answer the question I asked, which was for an example of  
an actual message and how it would appear at various stages as it passed  
through a mail system from the point where it was originated (and  
hopefully signed) to the point where it needed to be verified.

I have no idea what MS Exchange does, and after reading your gobbledegook  
I am still no wiser.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jun 2008 10:51:42 -0700

On Jun 6, 2008, at 2:44 AM, Charles Lindsey wrote:

>> Exchange permits creation of mail addresses unreachable by SMTP,  
>> since these domains may only exist through an internal X.400  
>> assignment.  While some companies find this a desirable feature, it  
>> is often a PITA for users of this service.  While a parent domain  
>> may wish to assert ADSP practices, MS Exchange related email sub- 
>> domains can be created for various purposes without publishing  
>> _any_ record within DNS.  The MUA will therefore receive a mixture  
>> of SMTP and MS Exchange messages, but this would only create a  
>> problem with specific domains for users of the MS Exchange service.
>
> Will you please answer the question I asked, which was for an  
> example of an actual message and how it would appear at various  
> stages as it passed through a mail system from the point where it  
> was originated (and hopefully signed) to the point where it needed  
> to be verified.
>
> I have no idea what MS Exchange does, and after reading your  
> gobbledegook I am still no wiser.

MS Exchange initially utilized X.400 name space.  As far as DKIM or  
SMTP is concerned, this name space is _not_ within DNS.  Company  
Example sets up internal forums using X.400 assignments to address  
them.  Some members of company Example prefer their messages forwarded  
to SMTP accounts.  The forwarding technique permits standardized  
access to mail.  Perhaps it would be better to say there are many  
reasons.  Once members of company Example forwards mail, then a  
message such as:

From: Conductor Bill <[email-masked]>
To: Staff <[email-masked]>
Subject: We Think we can.

may be sent.

When receivers examine the From: email-address "Conductor Bill <[email-masked] 
 >", while Example.com might exist due to their employee email- 
addresses supporting SMTP being "[email-masked]", they may  
discover "Lionel.Example.com" does not exist within DNS at all.   
"Lionel.Example.com" may only exist as an X.400 assignment within MS  
Exchange.  This should not be surprising, since Microsoft retrofitted  
both DNS and SMTP into their OS.  This means a check for any record  
might return NXDOMAIN, and there not be any A, AAAA, or MX records  
either.  In other words, in order for members of company Example to  
respond to Conductor Bill, they will need to VPN into their office  
network, use Outlook web access, or use some method that permits  
negotiation with Example's MS Exchange connector.

I hope the example helps.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 9 Jun 2008 11:11:33 -0700

The issue raised was _not_ specifically about X.400 address space  
(intended not to overlap with that used by DNS).  MS Exchange permits  
use of proxy addresses defined as SMTP name space with an assignment  
process facilitating a mixed name space that is _not_ done using DNS.   
As a result, it is not unusual to find what might appear to be a  
normal SMTP addresses handled by a corporate MS Exchange without there  
being any related records existing within DNS.  Organizations making  
use of this assignment facility may find message acceptance of some  
forwarded messages disrupted by what amounts to an ADSP domain  
validation test.  It remains important to be specific about the  
transport protocol pertaining to ADSP.

To handle situations dealing with crucial systems or where there are  
non-DNS assignments, a mitigation strategy making domain or address  
specific exceptions seems necessary.  An alternative solution would be  
to abandon any validations related to DNS.  As such, ADSP would not  
prevent sub-domain abuse.  Either SMTP validity checks are advocated,  
or sub-domain practice assertions should be abandoned.   Use of a  
prefix for a TXT record will not permit a safe discovery algorithm  
where domain validity does not play a critical role.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 16 Jun 2008 10:23:05 +0100

On Fri, 13 Jun 2008 18:32:07 +0100, Douglas Otis <[email-masked]>  
wrote:

> A Practice should be defined by its specification to cover specific
> transport protocols when being asserted by transmitting domains.  It
> is unreasonable to suggest all transport protocols that might ever use
> DKIM must employ DKIM at the same level before an ADSP assertion can
> be made.  When only SMTP messages uniformly employ DKIM, then defining
> ADSP as only covering SMTP permits an assertion specific to messages
> introduced by the domain over SMTP. ...

But it also permits every scammer to pretend that his messages were not  
really SMTP messages at all, and thus to have them passed through  
Verifiers unscathed.

Thus if we do as you proposes (which seems to be to omit the domain  
existence check) then there will be no point whatsoever in deploying ADSP  
at all. However, it seems that the consensus is that such a check is  
essential (there is room for discussion for its details), and hence your  
idea is already rejected by this WG - unless you can come up with a way of  
avoiding this problem.

> ...  The assertion would be silent as
> to whether NNTP might employ DKIM, for example.

It nothing to do with whether NNTP employs DKIM. If someone writes a  
Usenet with article (unsigned) with
     From: [email-masked]
(which is quite a common practice to avoid scraping of the address by  
spammers), and if that messages is subsequently gatewayed into email  
(again a fairly common practice), then a vigilant email Verifier is likely  
to discard it. I see no way to avoid that, and it is the price we have to  
pay for better security in the email world.

As a slight amelioration of that position, i mungers could be persuaded to  
write their From addresses as
     From: [email-masked]
(which I would regard as best practice anyway), then verifiers might be  
permitted to pass that case.
>
> Discerning whether a message was "intended" to be carried by SMTP
> remains a problem for receivers.

Indeed. But if you cannot provide a method for such discernment, then we  
are forced to assume that they _were_ so intended, otherwise ADSP is  
useless.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Jun 2008 10:36:57 -0700

On Jun 13, 2008, at 1:17 AM, Charles Lindsey wrote:

> On Wed, 11 Jun 2008 18:06:57 +0100, Douglas Otis <dotis@mail- 
> abuse.org>
> wrote:
>
>
>> Which TLDs should be ignored?  Imposing SMTP domain requirements will
>> likely reveal a need to make many exceptions.  Do you agree there
>> should be a means for making exceptions?  Whether making address
>> assignments exclusively within MS Exchange is considered stupid (and
>> you'll find agreement there), imposing a requirement that email-
>> addresses must be valid (in some manner) changes SMTP
>> interoperability.  As it is now, recipients will normally see these
>> messages (which may not expect a response), and might even be
>> considered an alternative to the use of "do-not-reply@" local-parts.
>
> You may ignore any TLD not recognized by ICANN (for that purpose, all
> national TLDs are deemed so recognized).

The domains being ignored can _not_ be based upon it not having a  
valid TLD.  This would permit bad actors a means to employ look-alike  
spoofing.  Their spoofs might use ACE-labels for example, or things  
like ".C0M".

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 13 Jun 2008 09:17:18 +0100

On Wed, 11 Jun 2008 22:52:12 +0100, Douglas Otis <[email-masked]>
wrote:

> Disagree.  Unlike DKIM (RFC4871) where use is self evident, a practice
> assertion must declare which transport protocol is covered.  Otherwise
> it is impossible to discern specifically what is being asserted.  Are
> messages signed for SMTP, or NNTP, for example.

But you still have not explained, despite being asked repeatedly, how that
question is to be answered for a particular message.

If the message arrives at the Verifier via SMTP, is it an SMTP message, or
is it not? And if not, how is the Verifier supposed to know?

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 13 Jun 2008 09:17:48 +0100

So you may ignore *.invalid, *,local, *.foobar ...

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 12 Jun 2008 03:07:04 +0200

Douglas Otis wrote:

 [skipping the parts we have now repeated often enough]
> After all, the goal is to finish the ADSP, ASAP.  : )

Sometimes I wonder what the goal here is.  Looking into 
http://tools.ietf.org/html/draft-kucherawy-dkim-reporting
it reinvents RFC 3834 without referencing it, it has a
reference to RFC 1894 obsoleted by RFC 3464 *five*
years ago, and still talks about ASP instead of ADSP.

Using [FWS] in DNS records is also broken by design,
unless the goal is "experimental" havoc.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Jun 2008 02:12:55 -0700

On Jun 11, 2008, at 6:07 PM, Frank Ellermann wrote:

> Sometimes I wonder what the goal here is.  Looking into http://tools.ietf.org/html/draft-kucherawy-dkim-reporting 
>  it reinvents RFC 3834 without referencing it, it has a reference to  
> RFC 1894 obsoleted by RFC 3464 *five* years ago, and still talks  
> about ASP instead of ADSP.
>
> Using [FWS] in DNS records is also broken by design, unless the goal  
> is "experimental" havoc.

Adding to this, Murray Kucherawy's draft captures the i= (identity)  
parameter and a worthless s= (selector) parameter.  The s= parameter  
offers little value since the d= (key domain) parameter is missing.   
Only the d= parameter (upon which the s= parameter rests) represents a  
domain validated by a verified signature.  An identity parameter can  
include any number of virtual or wildcard domains below a key domain.   
The d= (key domain) ensures reputations consolidate upon a controlling  
entity.  Basing reputation upon either the i= or the s= parameters  
would permit senders an easy ability to fabricate an infinite number  
of such tokens.  Such diversity will thwart efforts at establishing  
reputations.  Basing reputation upon the key domain essentially means  
a sales department can not spam with impunity while using the same key  
domain.  This has been clarified in the otis-dkim-adsp draft.

Restricting the i= in the ADSP draft is also a mistake.  When a domain  
attempts to accurately indicate on whose behalf the signature was  
added, the identity might not be that of the Author.  In which case,  
even signing all messages would not satisfy a CLOSED ADSP practice.   
It should be possible for the identity included within the signature  
to be opaque and perhaps derived from an account granted access, and  
not necessarily be either ambiguous or affirm the identity of the  
Author.  Otherwise, the only work around for remaining compliant  
involves adding multiple signatures.  Necessitating ambiguous (on  
behalf of) signatures will also thwart dealing effectively with intra- 
domain abuse.  When unrestricted signatures are added to a message,  
receiving hosts should expect the message conforms to the key domain's  
governance.

Excluding the i= parameter as a component of ADSP compliance ensures  
greater interoperability when DKIM signing is by MTAs.  However,  
messages signed with g= restricted keys should not be accepted when  
the identity within the signature is not that of the Author.  Refusals  
of local-part restricted messages should not be conditioned upon  
receiving hosts first obtaining an ADSP records.  Local-part  
restricted keys permit signing on behalf of a specific identity, where  
this identity should always represent that of the Author.  Otherwise,  
not imposing this limitation as a general rule allows circumvention of  
the anti-spoofing protections being sought.  This is an issue  
independent of ADSP as well.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 12 Jun 2008 11:38:40 +0100

On Wed, 11 Jun 2008 13:49:08 +0100, <[email-masked]> wrote:

>  "what do you want the Verifier to do? " anything he wants to with the  
> understanding he has the equivalent of an unsigned message.

No, that won't do. If you have an unsigned message, you want to know  
whether or not it has an ADSP record that says it should have been signed.

So, in the current proposals:
    if (message lacks valid signature) {
       if (author domain exists &&
            does not have an ADSP record || ADSP record is strict/whatever)  
{
          discard/mark/whatever message
       } else {
          let it through
       }
    }

Anything less than that leaves a gaping hole through which all scammers  
will immediately go. "Anythjng less than that" includes hiving it off to a  
separate draft.

>
> non-SMTP domain is the same as a non tcpip domain, no records associated  
> with the protocol

But DNS records, where they exist, are not "associated with the protocol"  
(well some of them, where there is an MX record, might be).

So all SMTP-domains are tcpip-domains, but the converse is not true.

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 21 Jun 2008 20:23:04 +0100

On Fri, 20 Jun 2008 15:13:38 +0100, Douglas Otis <[email-masked]>  
wrote:

> On Jun 20, 2008, at 4:18 AM, Stephen Farrell wrote:
>
>> Charles Lindsey wrote:

>>> I would suggest all that is needed in the present draft is a
>>> statement that the existence check MAY be omitted in the case of
>>> TLDs that are known not to exist in the global DNS system,
>>
>> I guess I'm not seeing any support for this, so if folks do want to
>> include it,  then they ought say so. Otherwise, I think this thread
>> should be done,
>
> ...  Should we follow Charles advice
> and add "Please review RFC2606 partial list and be aware some other
> email-address domains may not exist within DNS, where not having DNS
> entries or by bridging protocols into SMTP may place those messages in
> peril."

But that is NOT what Charles is advising. I am merely suggesting that  
Verifiers MAY omit the existence check for reasons of that nature. That  
leaves the door open to specify something more specific in the future.

If we leave it as it is (MUST do that check - always) then a few cases  
such as you have described may fail to get through. Since you are the one  
worrying about those cases, it is your problem. Persomally I could live  
with it either way.

As our chair has pointed out, nobody else seems to share your particular  
concerns.