Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt

From: [email-masked]
Date: Sat, 15 Feb 2014 01:03:19 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : A NULL MX Resource Record for Domains that Accept No Mail
        Authors         : John Levine
                          Mark Delany
	Filename        : draft-ietf-appsawg-nullmx-00.txt
	Pages           : 5
	Date            : 2014-02-14

Abstract:
   When the 5321.MailFrom domain in an e-mail message has a DNS MX
   Resource Record (RR), it is making an explicit statement that it is
   willing to accept email.  However, when the domain has just a DNS A
   or AAAA RR, there mail clients cannot easily tell whether the domain
   accepts mail, as many hosts on the Internet advertise an A or AAAA RR
   regardless of whether they want to accept email.

   The NULL MX RR formalizes the existing mechanism by which a domain
   announces that it accepts no mail.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-nullmx/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-nullmx-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Franck Martin <[email-masked]>
Date: Wed, 19 Feb 2014 15:42:14 -0600 (CST)

This draft requires current filtering solutions to change behavior. The presence of an MX will indicate the domain is emailable (cf spamassassin rules) until the software is changed to recognize the 0. We will have different behavior while this is getting implemented. 

The same functionality can be achieved with

example.com "v=SPF1 -all"
*.example.com "v=SPF1 -all"

Which would cover also any subdomain and will not have different interpretation while being deployed.

----- Original Message -----
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Sent: Saturday, February 15, 2014 1:03:19 AM
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt

Abstract:

---

From: Ned Freed <[email-masked]>
Date: Wed, 19 Feb 2014 13:51:32 -0800 (PST)

> This draft requires current filtering solutions to change behavior. The
> presence of an MX will indicate the domain is emailable (cf spamassassin rules)
> until the software is changed to recognize the 0. We will have different
> behavior while this is getting implemented.

The domain validity check is extremely weak to begin with. And given the speed
at which such rules have to evolve for other reasons, even if you think this
deserves consideration - which I don't - it's a miniscule  factor in the
overall scheme of AS/AV solutions.

> *.example.com "v=SPF1 -all"

It's not even remotely the same functionality. The point of the nullmx 
mechanism is to inform agents *sending* messages to the domain that there's
no point in even bothering making a connection. To the best of my knowlege
nobody looks at SPF records for domain before attempting to send mail to them.

> interpretation while being deployed.

If you're seriously proposing that SMTP clients start looking at SPF records,
that a MAJOR change that would be a major PITA to get deployed.

				Ned

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "John Levine" <[email-masked]>
Date: 19 Feb 2014 22:34:11 -0000

>example.com "v=SPF1 -all"

You might want to reread the draft, in particular Section 5, and
reconsider that claim.

Also, as the draft explains in Section 1, the point of nullmx is
basically to undo the default to A/AAAA hack for domains with A/AAAA
records that don't accept mail.  Even if Spamassassin and other spam
filters don't add rules to look for MX . they're no worse off than
they are now.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Wed, 19 Feb 2014 17:51:32 -0600 (CST)

----- Original Message -----
> From: "Ned Freed" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Sent: Wednesday, February 19, 2014 1:51:32 PM
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt
> 

It is in spamassassin and others, not sure the word miniscule "apply" here. Furthermore anything that weakens anti-spam measure should not be encouraged by a body like IETF, which wants to increase the security of the Internet.

> nobody looks at SPF records for domain before attempting to send mail to

Well, in another RFC, every domain should have an abuse@ and postmaster@ this domain. This seems in conflict.

> that a MAJOR change that would be a major PITA to get deployed.
same as implementing this, it is a NS record lookup and special processing.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Feb 2014 18:01:29 -0800

Review of:   A NULL MX Resource Record for Domains that Accept No Mail
I-D:         draft-ietf-appsawg-nullmx-00
Review by:   D. Crocker
Date:        19 Feb 2014

Summary:

      Internet mail transport address discovery relies on a default 
fallback use of the DNS A/AAAA record.  This overloads the semantics of 
the record, causing attempts to send mail to hosts that do not support 
mail receipt.  There is enough email traffic suffering this problem to 
warrant fixing.  The NULL MX draft defines a means for a domain name to 
explicit declare that it is not valid to use it as an email address.

      The defined mechanism is simple and easy to implement.  It seems 
likely to be quite useful.

      The specification document's writing is a bit rough and could 
benefit from some improvement.  This is only an editorial issue for the 
document, with no changes needed in the technical content.

Detailed Comments:

>     Abstract
>    willing to accept email.

The phrasing of this implies that the fact that it's a mailfrom address 
is somehow at the core of the problem or the mechanism here.  It isn't.

>   However, when the domain has just a DNS A

I suggest a re-casting, along the lines of:

      Internet mail determines the address of a receiving server through 
the DNS, first by looking for an MX record and then by looking for an 
A/AAAA record, which provides a fallback default.  Unfortunately this 
means that the A/AAAA record is taken as a mail server address even when 
that address does not accept mail.  An ability to explicitly announce 
that mail is not supported permits significant operational efficiencies.

> 1.  Introduction
>
>    This document formally defines the "NULL MX" as a simple mechanism by
>    which a domain can indicate that it will never accept email.
>
>    SMTP clients have a prescribed sequence for resolving how to deliver
>    email to a domain.  Section 5 of [RFC5321] covers this in detail, but
>    in essence the SMTP client first looks up a DNS MX RR and if that is
>    not found it falls back to looking up a DNS A or AAAA RR.

Suggest adding:

     Hence this overloads an email service semantic onto a DNS record 
with a a different primary mission.

>
>    Many domains do not accept email, but do have A or AAAA records.  If
>    they have no MX records, senders will attempt to deliver mail to
>    those A or AAAA records.

Swap the above 2 sentences:

      A domain has no MX records, senders will attempt to deliver mail to
     the hosts at the domain's A or AAAA record's addresses. However
     many domains do not accept email.

> 2.  SMTP server benefits
>
>    Being able to detect domains that never accept email offers many
>    resource savings to an SMTP server.  In the first instance, it can
>    choose to reject email during the SMTP conversation that does not
>    present a deliverable 5321.MailFrom domain.

As phrased this seems to mean that having no mailfrom address will cause 
a delivery failure.  Perhaps you mean something like:

       In the first instance, it can choose to reject incoming email, 
during the SMTP conversation, which contains a 5321.MailFrom domain that 
explicitly does not accept mail.

>    In the second instance, if an SMTP server accepts an email, it can be
>    confident that an attempt to send a non-delivery email will likely be
>    answered by another SMTP server.

I don't understand this sentence.

I also don't understand the term "non-delivery email".  	

>  This greatly helps to reduce non-
>    delivery queues.  This contrasts greatly with the current situation
>    where a non-delivery email for, e.g., www.example.net, will sit in
>    the queue for a full queue lifetime as SMTP connection attempts to
>    www.example.net simply time out.
>
> 3.  Parallel Considerations
>
>    Clearly the perpetrators of abusive mail can adapt such that the
>    "vast class of email" that this mechanism helps identify, simply move
>    over to using 5321.MailFrom domains that have valid MX RRs.

This sentence has an unstated premise that won't be obvious to some 
readers.  Perhaps:

    Senders of abusive email often use addresses with domain names that 
do not accept mail.

> 4.  The NULL MX Resource Record
>
>    To indicate that a domain never accepts email, it advertises a single
>    MX RR with a RDATA section consisting of preference number 0, and a
>    dot, i.e., the DNS root, as the mail exchanger domain, to denote that
>    there exists no mail exchanger for a domain.  (The DNS root is not a
>    valid host name, which avoids any possibility that a NULL MX record
>    could be confused with an ordinary MX record.)
>
>    The interpretation of a NULL MX RR only applies when the domain has a
>    single MX RR.  If a domain advertises multiple MX RRs including a
>    NULL MX, the interpretation is as described in RFC5321.

How will this record be interpreted, by a client that has not been 
modified to recognize the semantics defined her?

> 5.  Domains that do not send mail
>
>    An SMTP server when presented with an "I never accept email" MX might
>    decline to accept such email as it knows that a response or non-
>    delivery notice will never be accepted, and that legitimate mail
>    rarely comes from domains that do not accept replies.

This sentence is difficult to parse.  Also, I suspect it is meant to be 
specific to an invalid mailfrom case, but it doesn't say that.

>    SMTP servers that reject mail because a MAIL FROM domain has a NULL
>    MX record should use a 550 reply code.

    should -> SHOULD

>    Although NULL MX often suggests that a domain sends no mail, it does
>    not say so explicitly.  Operators may want to publish SPF [RFC4408]
>    -ALL policies to make an explicit statement.

"often suggest"?  Huh?  Do you mean:

     A domain that does not accept mail, as declared by NULL MX, often 
will also not send mail.  However this is only a likelihood.  In order 
to make an explicit declaration that the domain is not valid in the 
rfc5321.mailfrom command, operators can publish SPF [RFC4408] -ALL policies.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 20 Feb 2014 06:13:08 +0000

> -----Original Message-----
> From: apps-discuss [mailto:[email-masked]] On Behalf Of
> Dave Crocker
> Sent: Wednesday, February 19, 2014 9:01 PM
> To: [email-masked]
> Subject: [apps-discuss] Review of: draft-ietf-appsawg-nullmx-00
> 
>       Internet mail transport address discovery relies on a default fallback use
> of the DNS A/AAAA record.  This overloads the semantics of the record,
> causing attempts to send mail to hosts that do not support mail receipt.
> There is enough email traffic suffering this problem to warrant fixing.  The
> NULL MX draft defines a means for a domain name to explicit declare that it
> is not valid to use it as an email address.
> 
>       The defined mechanism is simple and easy to implement.  It seems likely
> to be quite useful.
> 
>       The specification document's writing is a bit rough and could benefit from
> some improvement.  This is only an editorial issue for the document, with no
> changes needed in the technical content.
> 
> 
> 
> Detailed Comments:
> 
> >     Abstract
>  >
> The phrasing of this implies that the fact that it's a mailfrom address is
> somehow at the core of the problem or the mechanism here.  It isn't.
> 
> 

I suppose that to be precise, the assertion is that it does not accept mail for the TTL of the published NULL MX record. Never is a long time.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 20 Feb 2014 10:05:07 +0100

On Thursday, February 20, 2014 12:51:32 AM CEST, Franck Martin wrote:
> Well, in another RFC, every domain should have an abuse@ and 
> postmaster@ this domain. This seems in conflict.

I can't remember what RFC that was, but I do seem to remember the 
requirement itself, and that it pertained to domains that have mail 
service. It did not require e.g. [email-masked] to exist, or 
[email-masked] (the domain in which google's load balancers live).

This applies, in pratice, to all protect-our-trademarks domains and to 
various intermediate things.

Arnt

---

From: t.petch <[email-masked]>
Date: Thu, 20 Feb 2014 11:06:56 +0000

---- Original Message -----
From: "Arnt Gulbrandsen" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 20, 2014 9:05 AM
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-nullmx-00.txt

> [email-masked] (the domain in which google's load balancers live).

RFC1123 for postmaster
RFC2142 for abuse

Tom Petch

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 20 Feb 2014 12:36:28 +0100

> RFC1123 for postmaster

   A host that supports a receiver-SMTP MUST support the reserved
   mailbox "Postmaster".

> RFC2142 for abuse

   organizations which support email exchanges with the
   Internet are encouraged to support AT LEAST each mailbox name for
   which the associated function exists

Ie. there is no conflict with the nullmx draft. (And, honestly, it would be 
strange to discover a conflict after ten years of deployment.)

Arnt

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 20 Feb 2014 05:40:18 -0800

On Wed, Feb 19, 2014 at 6:01 PM, Dave Crocker <[email-masked]> wrote:
>     A domain that does not accept mail, as declared by NULL MX, often will
> also not send mail.  However this is only a likelihood.  In order to make an
> explicit declaration that the domain is not valid in the rfc5321.mailfrom
> command, operators can publish SPF [RFC4408] -ALL policies.

I'd be even more explicit to ensure conformity of intent throughout
this document and the implications for receivers that are listed
throughout:

"A domain that does not accept mail, as declared by NULL MX, SHOULD
not send mail and SHOULD never be seen in 5321.Mailfrom and 5322.From
fields. Operators can also publish SPF (RFC4408(bis?)) -ALL policies."

--Kurt Andersen

---

From: Simon Perreault <[email-masked]>
Date: Thu, 20 Feb 2014 08:59:33 -0500

Le 2014-02-19 18:51, Franck Martin a écrit :
> It is in spamassassin and others, not sure the word miniscule "apply" here.

Spamassassin updates its rules nightly. Other products do similar
things. So not a problem IMHO.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Feb 2014 06:01:17 -0800

> fields. Operators can also publish SPF (RFC4408(bis?)) -ALL policies."

+1

However a minor quibble caused by 'be seen' -- since they can't control 
spoofing -- prompts me to suggest more finicky language that I think is 
both more general and more specific:

      "When a domain is listed as not accepting mail, as declared by a 
NULL MX record, it also SHOULD NOT be authorized for use in any email 
address or or domain field. That is, if it is not used for receiving 
mail it is best not to use it with any other email function.  Operators 
can also publish SPF (RFC4408(bis?)) -ALL policies."

d/

---

From: "John Levine" <[email-masked]>
Date: 21 Feb 2014 07:27:24 -0000

>can also publish SPF (RFC4408(bis?)) -ALL policies."

I'm sympathetic to the intent, but I worry about the subtle changes to
5321 that this implies.  Ned can probably think of six obscure but
legitimate services that would break.

I'm more inclined to note that for spam filtering purposes, many
servers don't accept mail from domains they can't reply to, so if you
want your mail delivered, MX . is probably not what you meant.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 21 Feb 2014 00:17:12 -0800

On Thu, Feb 20, 2014 at 6:01 AM, Dave Crocker <[email-masked]> wrote:

>      "When a domain is listed as not accepting mail, as declared by a NULL
> MX record, it also SHOULD NOT be authorized for use in any email address or
> or domain field. That is, if it is not used for receiving mail it is best
> not to use it with any other email function.  Operators can also publish
> SPF (RFC4408(bis?)) -ALL policies."
>

Better, but I find the use of "authorized" to be dodgy.  I suggest
s/authorized for use in/used in/.

Also, to quibble about 2119 language: Since SHOULD NOT has been chosen
here, under what circumstances might one legitimately deviate from that
advice?  This seems like MUST NOT territory to me.

-MSK

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 21 Feb 2014 09:54:51 +0100

+1

Arnt

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Feb 2014 06:44:00 -0800

On 2/21/2014 12:17 AM, Murray S. Kucherawy wrote:
> On Thu, Feb 20, 2014 at 6:01 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> NULL MX record, it also SHOULD NOT be authorized for use in any
> email address or or domain field. That is, if it is not used for
> receiving mail it is best not to use it with any other email
> function. Operators can also publish SPF (RFC4408(bis?)) -ALL
> policies."
>

Except that 'authorized' is the essential point, to distinguish between
legitimate uses and spoofing, etc. uses.  The word 'legitimate' doesn't
work well here. So 'authorized' seems the next closes.

There are three essential problems with the original wording. The first
is that domains don't 'send' mail. Also the word 'send' is frankly
ambiguous in its own right here. And lastly is that the stricture needs
to cover keep the domain name out of a number of different fields.

> Also, to quibble about 2119 language: Since SHOULD NOT has been
> chosen here, under what circumstances might one legitimately deviate
> from that advice?  This seems like MUST NOT territory to me.

I copied the normative from the original, and -- wait for it -- don't
have an opinion on the choice.

On 2/20/2014 11:27 PM, John Levine wrote:
> I'm sympathetic to the intent, but I worry about the subtle changes
> to 5321 that this implies.  Ned can probably think of six obscure but

I've no idea what 'changes' are meant, and since they are stated, can't
respond.  My own reading of both the original text and my proffered
replacement is that they don't change 5321 at all.

> want your mail delivered, MX . is probably not what you meant.

Something along those lines sounds like useful explanatory text.

By narrowly citing replying, it excludes exclusion from other places
such as Received header fields.  That might be ok, but it's worth being
clear about it now.

That's why my suggested text was indiscriminate:  if you declare you
don't use it for 'sending' then keep it the heck out of /all/ places in
email-related processing fields.

d/

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Feb 2014 15:24:48 +0000

> email-related processing fields.

I think it would be wrong to go that far. You need to make a distinction
between mail domains and host names. Domains in Received: and Message-ID:
headers are host names, not mail domains, so it should be OK for them to
be null MX domains.

For instance, an admin might want to set up null MX records for client
machines to indicate that they don't run MTAs. When a user runs an MUA on
one of these client machines, their message submissions will contain the
client machine host name in a Received: header and possibly also the
Message-ID header.

(Real world example: eng.cam.ac.uk, though they use a sinkhole MTA rather
than null MX records.)

A null MX record should just imply that an email address is invalid if
it uses that domain.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South-east Iceland: Cyclonic in south at first, otherwise northeasterly, 6 to
gale 8, occasionally severe gale 9 at first. Very rough or high, becoming
rough or very rough. Rain or squally showers. Moderate or good, occasionally
poor.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Feb 2014 07:33:41 -0800

Tony,

Thanks for working this through more carefully than I had.  I agree with 
your assessment.

A version of your first paragraph would be worth including in the 
document, I think, to help educate the reader.

And your ending sentence is particularly nice, as a specification of the 
assertion that needs to be made, IMO.

d/

---

From: "John R Levine" <[email-masked]>
Date: 21 Feb 2014 11:19:40 -0500

> replacement is that they don't change 5321 at all.

In RFC 5321 sec 4.5.5 on null reverse-path it says:

    All other types of messages (i.e., any message which is not required
    by a Standards-Track RFC to have a null reverse-path) SHOULD be sent
    with a valid, non-null reverse-path.

That's the only text I can find that puts any conditions on reverse-path. 
Like I said, it's tacky to use a bounce address that isn't deliverable but 
it's always been valid, and spam filtering heuristics that use various 
sorts of DNS (or worse) callbacks to check its validity have been out of 
scope of 5321.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 21 Feb 2014 10:43:49 -0800

> to cover keep the domain name out of a number of different fields.

My problem is that "SHOULD NOT be authorized for use" is a concept that
exists entirely inside the ADMD creating the content; it points to
something that's not subject to interoperability.  "SHOULD NOT be used", by
contrast, is something that a receiver can evaluate.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Feb 2014 11:57:59 -0800

On 2/21/2014 10:43 AM, Murray S. Kucherawy wrote:
> On Fri, Feb 21, 2014 at 6:44 AM, Dave Crocker <[email-masked]
> something that's not subject to interoperability.  "SHOULD NOT be used",
> by contrast, is something that a receiver can evaluate.

We've all locked into some interesting linguistic challenges, though 
they seem to be getting cast in terms of a kind of email protocol challenge.

To start:  I'm not trying to change any existing email standards and 
don't think the current topic will do that.,

Rather, I'm trying to do two other things.  One is to distinguish 
between activities authorized by the domain owner, versus those outside 
of the owner's control.  And then to suggest proscription of what the 
domain owner authorizes for use.

Simply put:  If one publishes a NULL MX for the name, one shouldn't use 
that domain for an email address anywhere.  (Tony's language was good 
for that I think.)  And I've no idea whether should or must should be 
used -- and don't much care.

But the linguistic wrinkle is that those nasty spoofers are sitting out 
there, getting in the way of generic language like "should not be used".

d/

---

From: Ned Freed <[email-masked]>
Date: Sat, 22 Feb 2014 19:23:57 -0800 (PST)

> It is in spamassassin and others,

Along with hundreds of other tests, rules, criteria, etc. etc.

> not sure the word miniscule "apply" here.

You're right - I was being overly generous by calling it minescule. Of no
real consequence would be a lot closer to the mark.

> Furthermore anything that weakens anti-spam measure should not be encouraged by
> a body like IETF, which wants to increase the security of the Internet.

Sorry, that's nothing short of absurd. There are a myriad of antispam 
mechanisms in play - so many that pretty much every action we take in regards
to email is going to have some impact somewhere.

Just to point out the elephant in the corner here, it's obvious that increased
use of end-to-end security is likely to have a seriously detrimental impact on
various antispam measures. Does this translate to such work being off the table
for the IETF. Clearly not.

> domain. This seems in conflict.

Others have pointed out that those other RFCs only apply to domains that
actually run mail servers.

> same as implementing this, it is a NS record lookup and special processing.

Incorrect. This is an added check of the result from the MX lookup that's
already being performed by every SMTP client out there. No additional lookups
are required.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Tue, 25 Feb 2014 14:30:40 -0500

At the end of the day, this is a proposed optimization and enhancement 
to the MX record protocol handling logic.  On the publishing side, it 
can ultimately change/add new protocol rules and guidelines:

   - Mail Domains MUST have MX preference non-zero values (PREF != 0)
   - Non-Mail Domains SHOULD have MX preference zero values (PREF == 0)

For PREF!=0, the MUST is best to avoid NULL MX compliant systems 
skipping mail deliveries.  If we allow a SHOULD, then the domain is 
open to false positive mail non-deliveries.

For PREF==0, a SHOULD allows the outbound mail framework to decide how 
to best handle the mail delivery; a) by supporting this NULL MX 
proposal which will short circuit the delivery attempt and/or b) 
supporting the "Status Quo" of continuing to attempt to connect to 
what is probably a non-existing server.

A domain declaring a MX with PREF == 0 could be declaring to the mail 
client world to avoid connecting to this host, but this waste and 
redundancy overhead is absorb in modern systems and thus is a 
non-issue for the most part.   In our system, the domain will be 
permanently blocked after all attempts have been exhausted. It takes 
operator intervention to remove this auto-pilot block -- a rare 
procedure.  So while the idea sounds simple, it may not be a simple 
implementation nor simple deployment (turning it on for updates).

But it is an optimization to the MX logic and should be described as 
such avoiding the highly subjective reasonings dealing with mail 
filtering, anti-spam, reputation, etc.

-- 
HLS

On 2/21/2014 2:57 PM, Dave Crocker wrote:
> between activities authorized by the domain owner, versus those
> outside of the owner's control.  And then to suggest proscription of
> what the domain owner authorizes for use.
>
> Simply put:  If one publishes a NULL MX for the name, one shouldn't
> use that domain for an email address anywhere.  (Tony's language was
> good for that I think.)  And I've no idea whether should or must
> should be used -- and don't much care.
>
> But the linguistic wrinkle is that those nasty spoofers are sitting
> out there, getting in the way of generic language like "should not be
> used".
>
> d/
>
>