Discussion:
Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
(too old to reply)
John C Klensin
2014-07-17 17:39:53 UTC
Permalink
--On Thursday, July 03, 2014 12:03 -0700 The IESG
The IESG has received a request from the Applications Area
- 'A NULL MX Resource Record for Domains that Accept No Mail'
<draft-ietf-appsawg-nullmx-05.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send
2014-07-17.
Hi. For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful. I see it as another step, albeit a small one, in
the direction of prioritizing the prevention of unwanted
messages or connections over successful delivery of legitimate
messages. I continue to believe that prioritization is
undesirable, at least without fundamentally converting the email
infrastructure to an "acknowledge on delivery because there is
no expectation of successful deliveries" one rather than the
current protocols, which focus on notifications for
non-delivery. That is not a strong technical objection and is
definitely not intended to be an argument against publication if
the IESG concludes that there is community consensus for doing
this, especially since, of the changes that could be motivated
as above, this is one of the more benign.

Hope, it would be better if the specification were historically
accurate and accurate about the protocols it cites.

The last sentence of the second paragraph of Section 5
("Security Considerations") of the spec says:

"The normal way to send mail for which a sender wants no
responses remains unchanged, by using an empty
RFC5321.MailFrom address."

First, two issues of terminology:

(1) RFC 5321 does not contain or specify notations like
"RFC5321.MailFrom". That notation was introduced in RFC 5598, a
document that was approved as Informational with a consensus
that, IIR, included some significant desire that it not be
normative or casually treated as normative. If this
specification wants to use that notation, that is fine. But it
should include an explicit note to that effect in its
introduction or a Terminology section, not bury a "(see
[RFC5598] for the definitions of these terms)" reference in a
parenthetical note in Section 4.1 and then expect readers who
are looking specifically at other sections to pick up on it.

I believe that the RFC Editor's principle is that, if particular
terminology is needed to correctly understand a specification,
then the reference to the document that defines that terminology
is normative. In this particular case, it seems inconsistent to
consider 2119 normative and 5598 informative since both are used
to define terminology without which the document cannot be
correctly understood.

(2) Second, RFC 5321 does not contain a concept that it calls an
"empty address". The terminology it does use is "null
reverse-path" (See RFC 5321, Section 3.7). Subject to the
above, if the authors want to say "null address in
RFC5321.MailFrom", I don't think that is sufficiently confusing
to be a problem. But "empty address" could be construed as
MAIL FROM:
in the envelope with nothing following it, and that would be bad
news.


More important, however, RFC 5321 specifies the use of a null
reverse path only for delivery failure and status notifications
and message disposition notifications (see Section 4.5.5 of RFC
5321) and constrains the recipient address to be used. That
section also 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."

So. there isn't any "The normal way to send mail for which a
sender wants no responses" -- RFC 5321 and other specs
significantly constrain the cases in which null reverse-paths
may be used. If this specification intends that notifications
that are generated in response to a null MX record, then that
needs to be made an explicit requirement to conform with the
language of RFC 5321.



Some additional observations that suggest this document needs
additional work before approval, probably with an intervening
additional Last Call:

(a) Sloppy DNS terminology has been the source of many problems
(see recent discussions of "dotless domains" in
draft-klensin-dotless-terminology-harmful; "hostname" used to
describe a DNS entry that contains an address RR, a DNS entry
where the owner also owns at least one address RR, and the first
(leftmost) component of an FQDN (with additional ambiguity as to
whether a zone break is implied); and considerable confusion
about terms like "resolver". Whether the IETF steps forward to
try to clean up previous messes or not, it certainly should not
countenance making things worse.

Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
MX Resource Record". There is only an MX Resource Record that
this specification proposes to use with a convention involving
specific content in the DATA. One could call that many things,
but "NULL MX Resource Record" isn't one of them.

I strongly recommend that, in the spirit of the cross-area
review we talk so much about, the IESG refer this document to
DNSOP for a careful terminology check and not approve and
publish it (or its successor) until that WG has affirmatively
signed off on the terminology used. In particular, in addition
to expressing an opinion on calling "NULL MX" a Resource Record,
DNSOP should contemplate such sentences as "A domain MUST NOT
advertise multiple MX RRs including a NULL MX" in a DNS
terminology and confusion context. Because DNSOP has no
identified milestones, such a review should be able to get at
least as high priority as anything else it is working on. :-(

(b) I think I know what the second paragraph of 4.1 in intended
to convey but I have now read it several times and can't be sure
that it what is says. The parenthetical terminology note
doesn't help with readability but the problem exists even
without it.

(c) In 4.2, to my aging eyes and using fonts designed for
readability rather than high discrimination, the last "or" and
the "rather than" appear to be identical. The difference is
that the first one uses digit-one instead of the letter-l in
"example". "examp1e.com" (with the digit) is a registered
domain name and not on the IETF list of domain names that are
reserved for and allowed in examples. SO I recommend (and I
think IETF policy requires) that the example be changed and that
any similar valid one be better explained. That paragraph
should also, IMO, explicitly point out that the claimed
advantages exist only if the holders of the domains that are the
targets of the "mistranscribed or misunderstood" names actively
cooperate in establishing these records. Experience indicates
that many such domains are registered with the express intent of
capturing and taking advantages of mistakes; owners of such
domains would have negative incentive to cooperate.

(d) It seems to me that the cases this proposal addresses are
special enough that a dedicated Extended Status Code would be in
order. Instead, the document specifies the highly generic 5.1.2
(even those the RFC 3463 definition of X.1.2 includes "incapable
of accepting mail" and "invalid for mail" (which don't mean
quite the same thing). Especially since there is not an
easily-located WG discussion, the document should at least
explain its choice.

(e) The issues identified above aside, the explanation in the
second paragraph of Security COnsiderations (Section 5) is
unsatisfying. If a domain is configured so that some sending
hosts don't receive and some receiving hosts don't send, the
model specified in this document may simply be inappropriate and
shouldn't be used lest it cause lost messages. Why can't that
simply be said, and said clearly (probably in another section
referenced from this one.

regards,
john
Dave Crocker
2014-07-17 20:59:54 UTC
Permalink
Post by John C Klensin
Hi. For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful.
Since I'm the doc shepherd:

I have not seen statements by others indicating that the
specification is 'distasteful', although there have been some that
seemed to confuse its functionality with that of SPF.

Feel free to cite the specific comments by others that classed this
as distasteful or the equivalent.
Post by John C Klensin
I see it as another step, albeit a small one, in
the direction of prioritizing the prevention of unwanted
messages or connections over successful delivery of legitimate
messages.
A statement of "I don't do X" does not 'prioritize' anything.

The use of information that says "target address Y will not work because
there is not receiver at Y's domain" does not 'prioritize' anything.

The specification is nothing more than a vastly more efficient form of
getting an SMTP 550 Requested action not taken: mailbox unavailable,
except that it is even better than that, because it also precludes
waiting days to discover that there's no service to supply even that
error message.
Post by John C Klensin
Hope, it would be better if the specification were historically
accurate and accurate about the protocols it cites.
You do not clearly indicate any historical inaccuracy at issue.
Post by John C Klensin
The last sentence of the second paragraph of Section 5
"The normal way to send mail for which a sender wants no
responses remains unchanged, by using an empty
RFC5321.MailFrom address."
(1) RFC 5321 does not contain or specify notations like
"RFC5321.MailFrom". That notation was introduced in RFC 5598, a
document that was approved as Informational with a consensus
that, IIR, included some significant desire that it not be
normative or casually treated as normative. If this
First, so what?

Second, a review of the IETF mailing list archive about the document's
Last Call, in May of 2009, shows a nicely solid pattern of support for
the document's publication. Strange that you would call it into
question at this point.
Post by John C Klensin
specification wants to use that notation, that is fine. But it
should include an explicit note to that effect in its
introduction or a Terminology section, not bury a "(see
[RFC5598] for the definitions of these terms)" reference in a
parenthetical note in Section 4.1 and then expect readers who
are looking specifically at other sections to pick up on it.
If you want specific text changes, please suggest specific text changes.

Please do not formulate a requirement for change in a fashion that
leaves the authors having to guess whether it will satisfy you.
Post by John C Klensin
I believe that the RFC Editor's principle is that, if particular
terminology is needed to correctly understand a specification,
then the reference to the document that defines that terminology
is normative. In this particular case, it seems inconsistent to
consider 2119 normative and 5598 informative since both are used
to define terminology without which the document cannot be
correctly understood.
So, you are suggesting that RFC 5598 be a normative reference here?
Post by John C Klensin
(2) Second, RFC 5321 does not contain a concept that it calls an
"empty address". The terminology it does use is "null
reverse-path" (See RFC 5321, Section 3.7). Subject to the
above, if the authors want to say "null address in
RFC5321.MailFrom", I don't think that is sufficiently confusing
to be a problem. But "empty address" could be construed as
in the envelope with nothing following it, and that would be bad
news.
So you are suggesting:

empty RFC5321.MailFrom address
->
null ("<>") reverse-path, per 3.6.3 and 6.1 of RFC 5321
Post by John C Klensin
More important, however, RFC 5321 specifies the use of a null
reverse path only for delivery failure and status notifications
and message disposition notifications (see Section 4.5.5 of RFC
5321) and constrains the recipient address to be used. That
section also 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."
And here I was, thinking that "SHOULD" means it is ok /not/ to do what
is being directed, if you have a good reason. Oh, wait...
Post by John C Klensin
Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
MX Resource Record". There is only an MX Resource Record that
this specification proposes to use with a convention involving
specific content in the DATA. One could call that many things,
but "NULL MX Resource Record" isn't one of them.
By my reading of that section, it is defining the term, if only by
virtue of the way it is used in the name of that section.

Perhaps your confusion would be resolved if the term had a comma in it,
so: NULL, MX Record?

In other words, NULL is an adjective within the term.

If you would prefer a different term, please suggest one.
Post by John C Klensin
(b) I think I know what the second paragraph of 4.1 in intended
to convey but I have now read it several times and can't be sure
that it what is says. The parenthetical terminology note
doesn't help with readability but the problem exists even
without it.
Take a look at the sub-section's title. Note that the first paragraph
reviews benefits for an SMTP client and then note that the second
paragraph extends into talking about a particular benefit for a
receiving SMTP server, per the section's title.

NullMX allows a receiving SMTP server to detect when a return-path
address uses a domain name that does not receive mail. Hence, at
submission time, the receiving server can reject such messages.
Post by John C Klensin
(e) The issues identified above aside, the explanation in the
second paragraph of Security COnsiderations (Section 5) is
unsatisfying. If a domain is configured so that some sending
hosts don't receive and some receiving hosts don't send, the
model specified in this document may simply be inappropriate and
shouldn't be used lest it cause lost messages. Why can't that
simply be said, and said clearly (probably in another section
referenced from this one.
How would that be better than what is in the current draft?

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Mark Andrews
2014-07-17 23:35:17 UTC
Permalink
Post by Dave Crocker
Post by John C Klensin
Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
MX Resource Record". There is only an MX Resource Record that
this specification proposes to use with a convention involving
specific content in the DATA. One could call that many things,
but "NULL MX Resource Record" isn't one of them.
By my reading of that section, it is defining the term, if only by
virtue of the way it is used in the name of that section.
Perhaps your confusion would be resolved if the term had a comma in it,
so: NULL, MX Record?
In other words, NULL is an adjective within the term.
If you would prefer a different term, please suggest one.
A better description of the record is "No Service MX Record" or "No
Service Offered MX Record".

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org
Sandy Wills
2014-07-17 23:56:48 UTC
Permalink
Post by Mark Andrews
A better description of the record is "No Service MX Record" or "No
Service Offered MX Record".
As a clear statement of policy, the latter is preferable.

Those two can easily be construed to mean different things. The
former may mean a current temporary condition "Yes we have no email
service here today, please check back tomorrow". The latter is clearly
a policy statement "We don't do no stinking email here".

Sandy Wills
(semi-inactive lurker)
--
Unable to locate coffee.
Operator halted.
Pete Resnick
2014-07-22 13:27:43 UTC
Permalink
This message is admittedly 4 days too late. In my opinion, we area
directors got caught out not paying attention and did not act to address
problematic behavior on this list in a reasonable amount of time, and
haven't been doing so for some time. The IESG is taking this ongoing
behavior seriously, and you'll see some discussion in the next few days
about how we intend to address it. But this particular thread had some
serious misbehavior, that behavior came from senior members of the
community, and it needs to be called out in particular.[1]

Of course we need to learn to focus our review comments and discussions
at Last Call, we need to make concrete and constructive suggestions for
changes (preferably supplying text), and when we respond to reviews we
should filter superfluous commentary and solicit specific
recommendations where they were missing. But this is general advice and
not an issue of the kind of misconduct I'm referring to. The problem in
this thread came when, instead of constructively responding to the
initial posting and simply filtering out non-constructive comments, the
responses and continuing conversation served to *raise* the temperature
instead of lowering it. Engaging in sarcasm, belittling of comments,
baiting rhetorical questions, and aggressive (whether directly or
passive-aggressive) commentary drives some folks away from the
discussion (or participation in general), causes other folks to think
that it's acceptable behavior, and causes further discussion to degrade.

Luckily this thread seems to have converged, and I think it would be
terribly unproductive to argue about the merits and demerits of this
particular thread on this list, but this kind of behavior needs to stop.
That requires everyone to commit to trying harder to engage civilly, and
to not tolerate misbehavior. That doesn't mean that you should take it
upon yourself to police and control other people's behavior; that only
serves to compound the problem. But if discussions are not being
appropriately moderated, you should bring that to the attention of the
ADs; we are committing to making sure that things improve.

pr

[1] You may react to this by saying, "There has been far worse behavior
on this list in recent years. Why pick on this particular thread?" The
answer is, we have to start somewhere, and it happens that several
people, including some of the participants in this thread, made specific
complaints about his particular case.
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
Murray S. Kucherawy
2014-07-17 21:38:12 UTC
Permalink
[dropping dnsop]
Post by Dave Crocker
Post by John C Klensin
Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
MX Resource Record". There is only an MX Resource Record that
this specification proposes to use with a convention involving
specific content in the DATA. One could call that many things,
but "NULL MX Resource Record" isn't one of them.
By my reading of that section, it is defining the term, if only by
virtue of the way it is used in the name of that section.
Perhaps your confusion would be resolved if the term had a comma in it,
so: NULL, MX Record?
In other words, NULL is an adjective within the term.
If you would prefer a different term, please suggest one.
I mentioned this to one of the co-authors privately, but since you just
reminded me of it, I'll mention it here too:

The use of NULL (i.e., in all-caps) makes me think of it more as either an
acronym or a mnemonic. For example, in C, the special pointer with address
zero is written in prose as "the null pointer", but in source code simply
as "NULL". Since this draft is more prose than code, my sensibilities
would prefer it be written as "null" in this document rather than "NULL".
In its current form, I might expect to find a special RR type definition
for NULL MX and/or corresponding definitions in the appropriate C header
files.

This is not a major point since I'm the only one to mention it so far, but
there you have it.

-MSK
John C Klensin
2014-07-17 22:49:22 UTC
Permalink
--On Thursday, July 17, 2014 14:38 -0700 "Murray S. Kucherawy"
Post by Murray S. Kucherawy
Post by Dave Crocker
Post by John C Klensin
Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a
"NULL MX Resource Record". There is only an MX Resource
Record that this specification proposes to use with a
convention involving specific content in the DATA. One
could call that many things, but "NULL MX Resource Record"
isn't one of them.
By my reading of that section, it is defining the term, if
only by virtue of the way it is used in the name of that
section.
Perhaps your confusion would be resolved if the term had a
comma in it, so: NULL, MX Record?
In other words, NULL is an adjective within the term.
I don't want to get into grammatical hair-splitting if that can
be avoided, but the current construction names an RR type that
doesn't exist and punctuation doesn't help. As I said, if we
didn't already have a use problem with DNS terminology, it would
be a non-issue.
Post by Murray S. Kucherawy
Post by Dave Crocker
If you would prefer a different term, please suggest one.
That particular problem would be easily solved by saying

"MX Resource Record with a null value"

or even

"MX Resource Record that, by convention, points at the root"

The latter is a little long for a section title, but it exactly
reflects what is going on. I would still like a consensus
opinion from DNSOP both generally and for the specific reason
that a reasonable person might assume that a resource record
with a null value would have an empty DATA field, not one with a
value, even a value pointing informally at the root, so the
question of whether the DNS Experts find "null value"
problematic is actually important. I can't remember whether
resource records with a zero-length DATA field are even allowed,
but we should know for certain before throwing terms like "null
value" around. And, whether this document can, procedurally,
define "null value" as meaning something different from what it
might mean elsewhere in the DNS (were that the case) that would
be, IMO, a Really Bad Idea.
Post by Murray S. Kucherawy
I mentioned this to one of the co-authors privately, but since
The use of NULL (i.e., in all-caps) makes me think of it more
as either an acronym or a mnemonic. For example, in C, the
special pointer with address zero is written in prose as "the
null pointer", but in source code simply as "NULL". Since
this draft is more prose than code, my sensibilities would
prefer it be written as "null" in this document rather than
"NULL". In its current form, I might expect to find a special
RR type definition for NULL MX and/or corresponding
definitions in the appropriate C header files.
Yes, exactly. That isn't, IMO, the problem, but it certainly
makes it worse (more confusing). See above.
Post by Murray S. Kucherawy
This is not a major point since I'm the only one to mention it
so far, but there you have it.
Consider it as getting an extra mention. Ultimately, the text
should be clear whether caps are used or not, but the use of the
caps in these contexts doesn't make things any easier.

john
Douglas Otis
2014-07-19 14:03:14 UTC
Permalink
Post by John C Klensin
--On Thursday, July 17, 2014 14:38 -0700 "Murray S. Kucherawy"
Post by Murray S. Kucherawy
Post by Dave Crocker
Post by John C Klensin
Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a
"NULL MX Resource Record". There is only an MX Resource
Record that this specification proposes to use with a
convention involving specific content in the DATA. One
could call that many things, but "NULL MX Resource Record"
isn't one of them.
By my reading of that section, it is defining the term, if
only by virtue of the way it is used in the name of that
section.
Perhaps your confusion would be resolved if the term had a
comma in it, so: NULL, MX Record?
In other words, NULL is an adjective within the term.
I don't want to get into grammatical hair-splitting if that can
be avoided, but the current construction names an RR type that
doesn't exist and punctuation doesn't help. As I said, if we
didn't already have a use problem with DNS terminology, it would
be a non-issue.
Post by Murray S. Kucherawy
Post by Dave Crocker
If you would prefer a different term, please suggest one.
That particular problem would be easily solved by saying
"MX Resource Record with a null value"
or even
"MX Resource Record that, by convention, points at the root"
Agreed.

Null as a term is misleading since these MX record contain an a value that simply won't resolve an address because it points to root.

Although first used in defining SRV RR where:
"A Target of "." means that the service is decidedly not available at this domain."

Perhaps using the term 'nullified' as in Nullified MX record would be closer to what this is attempting to communicate. It also seems unlikely anyone would feel a need to capitalize Nullified because it looks like a defined language variable.

If only RFC2782 said "A Target of "." means that the service has been nullified and declared not available at this domain."
Regards,
Douglas Otis
Post by John C Klensin
The latter is a little long for a section title, but it exactly
reflects what is going on. I would still like a consensus
opinion from DNSOP both generally and for the specific reason
that a reasonable person might assume that a resource record
with a null value would have an empty DATA field, not one with a
value, even a value pointing informally at the root, so the
question of whether the DNS Experts find "null value"
problematic is actually important. I can't remember whether
resource records with a zero-length DATA field are even allowed,
but we should know for certain before throwing terms like "null
value" around. And, whether this document can, procedurally,
define "null value" as meaning something different from what it
might mean elsewhere in the DNS (were that the case) that would
be, IMO, a Really Bad Idea.
Post by Murray S. Kucherawy
I mentioned this to one of the co-authors privately, but since
The use of NULL (i.e., in all-caps) makes me think of it more
as either an acronym or a mnemonic. For example, in C, the
special pointer with address zero is written in prose as "the
null pointer", but in source code simply as "NULL". Since
this draft is more prose than code, my sensibilities would
prefer it be written as "null" in this document rather than
"NULL". In its current form, I might expect to find a special
RR type definition for NULL MX and/or corresponding
definitions in the appropriate C header files.
Yes, exactly. That isn't, IMO, the problem, but it certainly
makes it worse (more confusing). See above.
Post by Murray S. Kucherawy
This is not a major point since I'm the only one to mention it
so far, but there you have it.
Consider it as getting an extra mention. Ultimately, the text
should be clear whether caps are used or not, but the use of the
caps in these contexts doesn't make things any easier.
john
John C Klensin
2014-07-19 16:09:08 UTC
Permalink
--On Saturday, July 19, 2014 07:03 -0700 Douglas Otis
Post by Douglas Otis
Post by John C Klensin
Post by Dave Crocker
If you would prefer a different term, please suggest one.
That particular problem would be easily solved by saying
"MX Resource Record with a null value"
or even
"MX Resource Record that, by convention, points at the
root"
Agreed.
Null as a term is misleading since these MX record contain an
a value that simply won't resolve an address because it points
to root.
"A Target of "." means that the service is decidedly not
available at this domain."
Trying to do fine editing on the IETF list is rarely productive
so, if this level of tuning is important (I think some of it
is), perhaps the document should be returned to the WG --with
all of the issues on the table that were apparently not raised
before Last Call-- and Last Called again when it is really
ready. Personally, I find symptoms that choices of string,
choices of response code, details of terminology, DNS impact,
etc., were not sorted out in the WG beyond repetitions of
statements like "this has been done since 2006 and no major
issues have appeared", troubling in and of themselves. To me,
the IETF adds value when those discussions occur both intra-area
and cross-area. If that value isn't wanted, or isn't wanted
beyond an editorial check, I'm not sure why we should be
investing the resources. YMMD, of course.

But, since I'm writing this note anyway, let me suggest that it
would be entirely reasonable (maybe not ideal, but reasonable)
to be very clear in the document about what is going on, perhaps
with the language I suggested and Doug likes, but then to point
out that the mechanism has been known as "null MX" or "nullMX"
for some years and that usage will undoubtedly continue. Such a
statement could even survive a change of what goes into the DATA
field should that otherwise be desired. If people want to refer
to this as "nullMX", that is probably no worse than an obscure
acronym or abbreviation. It is also very different from the
term I objected to that started this because "NULL MX Resource
Record" is rather clearly DNS-incorrect and misleading.

john
Nico Williams
2014-07-17 22:27:59 UTC
Permalink
Post by John C Klensin
- 'A NULL MX Resource Record for Domains that Accept No Mail'
<draft-ietf-appsawg-nullmx-05.txt> as Proposed Standard
When I first saw this and your reply I thought "what the heck is he
talking about, it's so obviously a good idea". Then I read sections 4.3
and 5. Now I join the objection chorus.
Post by John C Klensin
Hi. For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful. I see it as another step, albeit a small one, in
the direction of prioritizing the prevention of unwanted
messages or connections over successful delivery of legitimate
messages. I continue to believe that prioritization is
undesirable, at least without fundamentally converting the email
infrastructure to an "acknowledge on delivery because there is
no expectation of successful deliveries" one rather than the
current protocols, which focus on notifications for
non-delivery. [...]
I think what you're objecting to is the section 4.3 and related text
that conflates "does not accept e-mail" with "does not send e-mail". If
so I agree. The two assertions *must* be separable! And preferably the
two assertions should be separate both, in terms of mechanism and
specification.

Assuming this conflation were fixed or the "does not send e-mail" text
removed, nothing in the remainder of the draft prevents notifications
for non-deliveries. Indeed, the "does not accept e-mail" assertion
[greatly] optimizes the case where the target domain does not accept
incoming e-mail -- a very desirable feature, and one worth standardizing
without any relation to "does not send e-mail" assertions.

I especially reject the first sentence of the third paragraph of section
4.3: regardless of the truth of that statement, it is insufficient to
draw the inference "does not accept e-mail implies does not send
e-mail".
Post by John C Klensin
The last sentence of the second paragraph of Section 5
"The normal way to send mail for which a sender wants no
responses remains unchanged, by using an empty
RFC5321.MailFrom address."
+1, but I think this should all be fixed by removing section 4.3 and any
remnant of the conflation of "does not accept" with "does not send"
e-mail. That is my preferred resolution.

I strongly recommend splitting this into two I-Ds, or at the very least
section 4.3 and related text into a top-level section. The "does not
send e-mail" assertion *must not* be the same as the "does not accept
e-mail".

Nico
--
Tony Finch
2014-07-18 10:53:00 UTC
Permalink
Post by Nico Williams
I think what you're objecting to is the section 4.3 and related text
that conflates "does not accept e-mail" with "does not send e-mail".
Section 4.3 describes what is already done by existing implementations of
this spec.

Exim in its default configuration validates the domain part of email
addresses and will reject mail if the sending domain does not exist or if
its MX records point to nonexistent hosts. Exim also recognizes null MX
records and suppresses the target A and AAAA lookups and treats the domain
as invalid. However the null MX logic is just an optimization: Exim's
validation logic would get the same result if it tried to do the A and
AAAA lookups and found that . does not have any addresses.

Postfix does the same if you use the reject_unknown_sender_domain option.

There are good reasons for rejecting mail from invalid domains, e.g.
because you would not be able to send a delivery failure report.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Biscay: Variable 3 or 4. Slight or moderate. Thundery showers later. Good,
occasionally poor later.
Ned Freed
2014-07-18 15:06:34 UTC
Permalink
Post by Tony Finch
Post by Nico Williams
I think what you're objecting to is the section 4.3 and related text
that conflates "does not accept e-mail" with "does not send e-mail".
Section 4.3 describes what is already done by existing implementations of
this spec.
Exim in its default configuration validates the domain part of email
addresses and will reject mail if the sending domain does not exist or if
its MX records point to nonexistent hosts. Exim also recognizes null MX
records and suppresses the target A and AAAA lookups and treats the domain
as invalid. However the null MX logic is just an optimization: Exim's
validation logic would get the same result if it tried to do the A and
AAAA lookups and found that . does not have any addresses.
Postfix does the same if you use the reject_unknown_sender_domain option.
FWIW, the equivalent option in the Oracle MTA is called mailfromdnsverify.
Post by Tony Finch
There are good reasons for rejecting mail from invalid domains, e.g.
because you would not be able to send a delivery failure report.
Yep. I believe setting this option is fairly common.

Ned
Nico Williams
2014-07-17 22:38:51 UTC
Permalink
The IESG has received a request from the Applications Area Working Group
- 'A NULL MX Resource Record for Domains that Accept No Mail'
<draft-ietf-appsawg-nullmx-05.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
beginning of the Subject line to allow automated sorting.
Abstract
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 as a fallback. Unfortunately this means that the A/
AAAA record is taken to be mail server address even when that address
does not accept mail. The NULL MX RR formalizes the existing
mechanism by which a domain announces that it accepts no mail, which
permits significant operational efficiencies.
So far so good, but the abstract does not mention that the I-D conflates
"does not accept e-mail" assertions with "does not send e-mail". That
is a big deal, and it must at the very least be mentioned in the
abstract.

"Does not accept e-mail" assertions are a highly desirable optimization
for the delivery of non-derlivery notifications. I see absolutely no
reason to conflate "does not accept" with "does not send", either in
mechanism or RFC.

Indeed, as the I-D mentions, the SPF already provides a method for
asserting "does not send e-mail". By encouraging the inference "does
not accept implies does not send" this I-D leaves us with no mechanism
by which to indicate "does not accept but does send".

Consider automated job ("cron") e-mail. There may be no return path.
But the received headers allow the recipient to find the source of the
e-mail and fix whatever problem might need fixing. Causing such e-mail
to not be delivered would be a serious problem.

Please do not publish this I-D as-is. Please remove the "does not
accept" -> "does not send" inference and mechanism from the text.
Otherwise this I-D will likely cause harm.

Nico
--
Nico Williams
2014-07-18 16:16:32 UTC
Permalink
It's been pointed out that senders must be willing to receive bounces.
I withdraw my objection.

Nico
--
Viktor Dukhovni
2014-07-18 01:01:55 UTC
Permalink
Post by John C Klensin
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send
2014-07-17.
Hi. For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful. I see it as another step, albeit a small one, in
the direction of prioritizing the prevention of unwanted
messages or connections over successful delivery of legitimate
messages.
In find nullmx on the contrary far less objectionable than all
other anti-abuse measures. I just designates non-sending domains,
via a simple low cost mechanism. It is already reasonably widely
in use even without a formal standard, based on the prior draft
revisions. There is nothing here that is about silent discard of
mail by remote domains. The origin domain declares non-sending of
mail and receiving systems are free to reject forgeries.

It is certainly far less damaging than DMARC.
Post by John C Klensin
That is not a strong technical objection and is
definitely not intended to be an argument against publication if
the IESG concludes that there is community consensus for doing
this, especially since, of the changes that could be motivated
as above, this is one of the more benign.
Thanks. The subsequent technical comments are generally sound and
should be addressed.
Post by John C Klensin
(d) It seems to me that the cases this proposal addresses are
special enough that a dedicated Extended Status Code would be in
order. Instead, the document specifies the highly generic 5.1.2
(even those the RFC 3463 definition of X.1.2 includes "incapable
of accepting mail" and "invalid for mail" (which don't mean
quite the same thing). Especially since there is not an
easily-located WG discussion, the document should at least
explain its choice.
This is likely already practiced, and is clear enough in practice.
Keep in mind that there are no legitimate senders of mail blocked
by nullmx rejection, so the DSN status codes are of little interest
to anyone but the bad guys.

The primary use for nullmx is parked domains. At previous employer
we configured thousands of parked domains with nullmx RRs.
--
Viktor.
Dave Crocker
2014-07-18 01:06:42 UTC
Permalink
Post by Viktor Dukhovni
In find nullmx on the contrary far less objectionable than all
other anti-abuse measures.
Although it has some utility for anti-abuse, it is not an anti-abuse
mechanism. It is of more general benefit.
Post by Viktor Dukhovni
I just designates non-sending domains,
No, it designates non-/receiving/ domains:

Abstract:

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

d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Hector Santos
2014-07-18 15:16:00 UTC
Permalink
Null mx would be a plug and play logical signal, condition to stop, preempt, do not queue, skip the outbound "send mail" process for the email domain because this proposal says its an indicator there would be no listening server ip available. In other words, it's an optimizer. It would be networking waste to do make the call. The issue I have are false positives. Do we know for a fact, there are no legitimate mx records with explicit preference zero settings with legitimate ip receivers? Should we believe them?

I might suggest a better algorithm where a first time attempt is made to double check if there is no legitimate ip or server to connect to. A implicit mx attempt is already done to block the domain by our software and tony also mentioned the same in Exim. I assume it is a long time common thing. I think I can say for a support fact that there are false positives, but maybe not significant to not kill the idea of a single shot attempt. I think the "dynamic DNS domain" services are some of the main reasons for intermittent errors. The few times over the years were handled manually when reported. The pref equal zero offers a new rule to avoid the single shot attempt. But I am not sure if it's worth the coding change the avoid the outbound mail attempt. Note, I know in our software we reduced the TCP/IP timeout from a default if about 30 secs to 10 secs depending on the socket stack so it's less of a loading/performance concerns.

--
Hector Santos
http://www.santronics.com
Post by Dave Crocker
Post by Viktor Dukhovni
In find nullmx on the contrary far less objectionable than all
other anti-abuse measures.
Although it has some utility for anti-abuse, it is not an anti-abuse
mechanism. It is of more general benefit.
Post by Viktor Dukhovni
I just designates non-sending domains,
"The NULL MX RR formalizes the existing
mechanism by which a domain announces that it accepts no mail,"
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
John C Klensin
2014-07-18 02:50:41 UTC
Permalink
--On Friday, July 18, 2014 01:01 +0000 Viktor Dukhovni
Post by Viktor Dukhovni
Post by John C Klensin
(d) It seems to me that the cases this proposal addresses are
special enough that a dedicated Extended Status Code would be
in order. Instead, the document specifies the highly generic
5.1.2 (even those the RFC 3463 definition of X.1.2 includes
"incapable of accepting mail" and "invalid for mail" (which
don't mean quite the same thing). Especially since there is
not an easily-located WG discussion, the document should at
least explain its choice.
This is likely already practiced, and is clear enough in
practice. Keep in mind that there are no legitimate senders of
mail blocked by nullmx rejection, so the DSN status codes are
of little interest to anyone but the bad guys.
In an odd way, your comment above illustrates the reason I think
an extended status code would be useful and why I'm concerned
that this draft might not have received adequately broad review.
If the use of nullmx were confined to parted domains, I would
agree with you and not see a problem. But the document doesn't
say that -- from reading it, one could get the impression that
it is being recommended for the domain associated with any
system that doesn't expect to receive mail. That leads into
some of the other cases, including the large mail operator whose
sending and receiving hosts are separate, as discussed earlier
and, e.g., some interesting questions about what happens if,
despite what it says in the document, multiple MX records are
configured only one of which has "." as the data. In some of
those cases, the cause of rejection might be an operational
configuration error, not an error on the part of the sender.
For such cases (including the examp1e.com one) details status
codes could be a big advantage.
Post by Viktor Dukhovni
The primary use for nullmx is parked domains. At previous
employer we configured thousands of parked domains with nullmx
RRs.
I'm not recommending this but, if the documents said "this is
for parked domains, for any other cases, the structure is
outdated and SHOUDL NOT be used except under special
circumstances and with adequate explanation.

john
Dave Crocker
2014-07-18 03:09:12 UTC
Permalink
Post by John C Klensin
I'm not recommending this but, if the documents said "this is
for parked domains,
You mean, like www.ietf.org, which is never a legitimate email target
hostname, but is rather easily specified in error?

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
John C Klensin
2014-07-18 11:58:05 UTC
Permalink
--On Thursday, July 17, 2014 20:09 -0700 Dave Crocker
Post by Dave Crocker
Post by John C Klensin
I'm not recommending this but, if the documents said "this is
for parked domains,
You mean, like www.ietf.org, which is never a legitimate email
target hostname, but is rather easily specified in error?
Dave,

Please see the first part of that sentence, i.e., "I'm not
recommending this". The note to which I was responding appeared
to me to have the premise "this is mostly for parked domains"
and appeared to reason on that basis. There is certainly no
doubt that it is useful for the type of parked to which I
believe he was referring, independent of whether one believes
that is the primary use. I believe that the author of that note
is both competent and sincere and deserved a response on that
same basis. I was temporarily accepting his premise, following
it to what seemed to be its implications, and suggesting that,
if it were the case, then some things would be different and a
slightly different approach would be in order.

If you find a flaw in that style of reasoning, please explain.

To repeat what I said initially and which I hoped was clear in
the original wording: I have some concerns about this mechanism,
especially when it is used with domains that may appear in
backward-pointing addresses (see Tony Finch's recent note about
the reasons for doing that), I do not oppose its approval ("its"
referring to the mechanism) [1]. However, I think the document
needs work -- particularly in the areas of problematic
terminology (with "NULL MX Resource Record" in the document
title, section title, and elsewhere being an important
illustration), explanation of likely issues and how they should
be handled (with systems with separated sending and receiving
hosts as a case of particular importance), some document
organization issues (e.g., buried terminology definitions and
issues in Security Considerations that really deserve separate
treatment), and so on.

I don't consider any of those issues earthshaking, they just
suggest the draft needs a little work before it is approved.

For the sake of clarity because most of what I've written in the
last few weeks seems, from your remarks, to have been
incomprehensible, the list of items mentioned above are just
examples. The absence of something from that list that appears
in my original posted review on this draft does not indicate
I've lost interest in it, merely that I did not include it in
the illustrative examples above.

If some part of that is still difficult for you to understand,
please just tell me what it was and I will try to clarify. My
hope is that we are all working together to improve this (and
other) specifications, rather than trying to accomplish
something (I am disinclined to speculate on what) by
discrediting postings that try to identify issues.

best,
john

[1] You also questioned my "distasteful" remark on the basis,
IIR, that no one else had said so. While there have been some
recent trends toward organizing groups to propose or comment on
some actions (trends that I believe are inconsistent with IETF
principles about individual participation, but YMMD), I've never
been aware that one was required to demonstrate support for a
position or comment before making it, especially on an IETF Last
Call. I had not intended to explain the reason for my distaste
because I think it a distraction from getting this spec to an
appropriate quality level. However, because your remarks appear
to call for it, I believe (in agreement with what this document
just about says) that this mechanism is a back-door workaround
to requiring MX records for any host that is willing to accept
incoming email. Such a requirement would be architecturally
reasonable and would permit some nuance that MX records pointing
to the root do not such as allowing address records to be for
empty reverse path notification messages but not normal ones
with usable reverse paths (not saying that would be a good idea,
only mentioning the possibility). Several WGs and document
review discussions have rejected the approach of imposing that
requirement, probably for good reasons even though we might have
been able to work out a plan for deprecating the fallback with
sufficient notice. While some of us started writing SMTP
server simulators that would simply generate 5xy replies as soon
as someone tried to open a port 25 connection and installing
them on machines that did not accept mail, there is an apparent
consensus that remedy is inadequate because of the retry
problem. With one of those solutions rejected and the other
judged inadequate, the current mechanism is a reasonable
candidate for the best approach for dealing with the issues.
That doesn't mean I have to like it or think it is
architecturally elegant. Hence "distaste".
Dave Crocker
2014-07-18 12:08:52 UTC
Permalink
Post by John C Klensin
I believe (in agreement with what this document
just about says) that this mechanism is a back-door workaround
to requiring MX records for any host that is willing to accept
incoming email.
It says and implies no such thing. Nor does it move us towards that.

Suggesting otherwise sounds odd, given that you say you don't object to
the mechanism.

The document formalizes an existing practice. We sometimes do that in
the IETF.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Mark Andrews
2014-07-18 03:26:11 UTC
Permalink
There are lots of machines which do not have the SMTP port configured
yet have A or AAAA records resulting in a implicit MX record and
week+ long no delivery notifications.

Just about everyone with a outsourced HTTP service needs to be able
to stop MTAs sending to email to the outsourced service. MUA's
could also lookup the MX RRset and issue a error without talking
to the MSA.

I can remember adding a null SMTP service back in the early 90's
that just 500'd all connection attempts to deal with all the miss
directed email accidently sent to desktop machines that I never
wanted to receive email even if they emitted it. This was much
better than having to chase down "why didn't xxxx get my email, I
sent it yyy days ago". The immediate bounce is important and getting
it a close to the sender as possible is important as it reduces the
chance that it will be dropped / missed.

The alternative to this is to remove the implicit MX record
construction from SMTP and make the presence of MX records manditory
for SMTP. I'm sure there will be many more complaints about doing
that than adding a explict no service record.

As for this along with other explict mx records. I would say to
ignore this record in the M[TU]A. Zone checking tools could warn
/ error if this is present. UPDATE could reject adding records if
there would be this and another record. Name servers could be
configured to warn / reject zones which have this and other MX
records.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org
John Levine
2014-07-18 04:06:23 UTC
Permalink
Post by Mark Andrews
There are lots of machines which do not have the SMTP port configured
yet have A or AAAA records resulting in a implicit MX record and
week+ long no delivery notifications.
Right. That's exactly, precisely, the problem that null MX is
intended to address.
Post by Mark Andrews
The alternative to this is to remove the implicit MX record
construction from SMTP and make the presence of MX records mandatory
for SMTP. I'm sure there will be many more complaints about doing
that than adding a explicit no service record.
That would be fine with me, but I hear it's 30 years too late, even for IPv6.

R's,
John
Ted Lemon
2014-07-18 11:50:28 UTC
Permalink
Post by Mark Andrews
There are lots of machines which do not have the SMTP port configured
yet have A or AAAA records resulting in a implicit MX record and
week+ long no delivery notifications.
Just about everyone with a outsourced HTTP service needs to be able
to stop MTAs sending to email to the outsourced service. MUA's
could also lookup the MX RRset and issue a error without talking
to the MSA.
I must be missing something here. You're saying you want me to set up a null MX for all my hosts to prevent someone else's MTA having undeliverable mail sitting in the queue for a week? Why would I care about your MTA's queue? Why would this issue even be on my radar?

The second example you give, stopping mail being delivered to the web server, is actually served better by setting up a proper MX that directs the mail to the right server. Does an HTTP server really care about the occasional SYN to port 25?

I'm not against this draft moving forward, but I find these use cases somewhat puzzling.
Tony Finch
2014-07-18 12:42:38 UTC
Permalink
I must be missing something here. You're saying you want me to set up a
null MX for all my hosts to prevent someone else's MTA having
undeliverable mail sitting in the queue for a week? Why would I care
about your MTA's queue? Why would this issue even be on my radar?
More likely you want to avoid undeliverable mail on your own mail server
queues, so that you don't get complaints from your users about mail
disappearing.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
FitzRoy: Cyclonic 4 or 5, increasing 6 at times. Moderate. Thundery showers.
Good, occasionally poor.
John Levine
2014-07-18 14:44:47 UTC
Permalink
Post by Ted Lemon
I must be missing something here. You're saying you want me to set up a null MX for all my hosts to
prevent someone else's MTA having undeliverable mail sitting in the queue for a week? Why would I care
about your MTA's queue? Why would this issue even be on my radar?
To get a definitive answer, you'd have to ask some of the many people who already
implement null MX. In my case, it's partly because my own users mistype names
and the typos happen to be names that resolve in my DNS, and partly because people
write and say "sorry, I wrote to ask where to send your $50,000 check and I just
saw that I mistyped your address a week ago."
Post by Ted Lemon
The second example you give, stopping mail being delivered to the web server, is actually served better
by setting up a proper MX that directs the mail to the right server. Does an HTTP server really care
about the occasional SYN to port 25?
Well, OK. What would be the proper MX for mail sent to ***@www.ietf.org ?

R's,
John
Ted Lemon
2014-07-18 14:46:53 UTC
Permalink
divertimento% dig mx ietf.org

; <<>> DiG 9.8.3-P1 <<>> mx ietf.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44344
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ietf.org. IN MX

;; ANSWER SECTION:
ietf.org. 494 IN MX 0 mail.ietf.org.

;; Query time: 100 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Fri Jul 18 10:46:25 2014
;; MSG SIZE rcvd: 47
John Levine
2014-07-18 17:50:29 UTC
Permalink
Perhaps this will alleviate some confusion.

* All this draft does is define an MX that says "you can't send mail
here." It's intended for domains that handle no mail at all, but get
mail anyway due to typos or brain-os. There's no hidden agenda.
Really.

* It has been widely implemented in Exim, Postfix and other MTAs for
nearly a decade. If there were severe damage, we'd probably have
noticed by now. The fact that it's widely implemented suggests that
people find it useful.

* The part in the draft about sending and receiving was confusing
and unhelpful, so I rewrote it. Now it says you SHOULD NOT send mail
from a domain that publishes null MX. This is both on principle,
don't send mail if you don't want an answer, and practice, since many,
many MTAs reject mail from domains without a resolvable mail server.
(Remember, SHOULD NOT means don't do this if you want to interoperate.)

R's,
John
ned+
2014-07-18 17:58:51 UTC
Permalink
Post by John Levine
Perhaps this will alleviate some confusion.
* All this draft does is define an MX that says "you can't send mail
here." It's intended for domains that handle no mail at all, but get
mail anyway due to typos or brain-os. There's no hidden agenda.
Really.
* It has been widely implemented in Exim, Postfix and other MTAs for
nearly a decade. If there were severe damage, we'd probably have
noticed by now. The fact that it's widely implemented suggests that
people find it useful.
* The part in the draft about sending and receiving was confusing
and unhelpful, so I rewrote it. Now it says you SHOULD NOT send mail
from a domain that publishes null MX. This is both on principle,
don't send mail if you don't want an answer, and practice, since many,
many MTAs reject mail from domains without a resolvable mail server.
(Remember, SHOULD NOT means don't do this if you want to interoperate.)
The closest existing code is 5.4.4 Unable to route:

The mail system was unable to determine the next hop for the
message because the necessary routing information was
unavailable from the directory server. This is useful for both
permanent and persistent transient errors.

A DNS lookup returning only an SOA (Start of Administration)
record for a domain name is one example of the unable to route
error.

But this isn't quite right, because this is for when there's no relevant DNS
information at all. And for diagnostic purposes it makes sense to be able to
distinguish "no entry in DNS" from "DNS says host doesn't accept mail"

Which is what I was trying to say; this really deserves a new 5.4.x code.
As for text, how about:

X.4.8 Destination does not accept mail

The directory server has returned an indication that the
next hop is incapable of accepting mail.

In the case of a DNS lookup, this can be indicated through the
use of a null MX entry [this rfc].

Or something along those lines. (8 may not be the right code, but it what
the IANA registry says is correct.)

Ned
John R Levine
2014-07-18 19:02:58 UTC
Permalink
Post by ned+
Which is what I was trying to say; this really deserves a new 5.4.x code.
X.4.8 Destination does not accept mail
The directory server has returned an indication that the
next hop is incapable of accepting mail.
In the case of a DNS lookup, this can be indicated through the
use of a null MX entry [this rfc].
OK with me if it's OK with everyone else.

Meta-question: this code would presumably also apply for domains that
don't exist or have no records (NXDOMAIN or NOERROR with no answers.) I
am not eager to do yet another draft, but it's more generally applicable
than for null MX.

Regards,
John Levine, ***@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
Dave Cridland
2014-07-18 19:39:49 UTC
Permalink
Post by John R Levine
Meta-question: this code would presumably also apply for domains that
don't exist or have no records (NXDOMAIN or NOERROR with no answers.) I am
not eager to do yet another draft, but it's more generally applicable than
for null MX.
Wouldn't that be the 5.4.4 that Ned mentioned? It seemed to mean "No idea
how to route there".

Whereas 5.4.8 is "explicitly does not handle mail".

Dave.
Tony Finch
2014-07-18 19:43:18 UTC
Permalink
What's wrong with 5.1.2 and 5.1.8 ?

X.1.2 Bad destination system address

The destination system specified in the address does not exist
or is incapable of accepting mail. For Internet mail names,
this means the address portion to the right of the "@" is
invalid for mail. This code is only useful for permanent
failures.

X.1.8 Bad sender's system address

The sender's system specified in the address does not exist or
is incapable of accepting return mail. For domain names, this
means the address portion to the right of the "@" is invalid
for mail.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Trafalgar: West or southwest 4 or 5. Slight or moderate. Thundery showers in
north. Good, occasionally poor in north.
John R Levine
2014-07-18 19:52:24 UTC
Permalink
Post by Tony Finch
What's wrong with 5.1.2 and 5.1.8 ?
X.1.2 Bad destination system address
The destination system specified in the address does not exist
or is incapable of accepting mail. For Internet mail names,
invalid for mail. This code is only useful for permanent
failures.
X.1.8 Bad sender's system address
The sender's system specified in the address does not exist or
is incapable of accepting return mail. For domain names, this
for mail.
Those look right to me. Will adjust accordingly.

Regards,
John Levine, ***@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
ned+
2014-07-18 20:14:04 UTC
Permalink
Post by Tony Finch
What's wrong with 5.1.2 and 5.1.8 ?
X.1.2 Bad destination system address
The destination system specified in the address does not exist
or is incapable of accepting mail. For Internet mail names,
invalid for mail. This code is only useful for permanent
failures.
X.1.8 Bad sender's system address
The sender's system specified in the address does not exist or
is incapable of accepting return mail. For domain names, this
for mail.
Wrong group of codes. Those are status for mail systems to return, not
the routing layer.

Ned
Tony Finch
2014-07-18 20:34:11 UTC
Permalink
Post by ned+
Post by Tony Finch
What's wrong with 5.1.2 and 5.1.8 ?
X.1.2 Bad destination system address
The destination system specified in the address does not exist
or is incapable of accepting mail. For Internet mail names,
invalid for mail. This code is only useful for permanent
failures.
X.1.8 Bad sender's system address
The sender's system specified in the address does not exist or
is incapable of accepting return mail. For domain names, this
for mail.
Wrong group of codes. Those are status for mail systems to return, not
the routing layer.
The point of null MX records it to explicitly say the address is invalid,
so an address status would seem to make sense.

X.1.XXX Addressing Status

The address status reports on the originator or destination
address. It may include address syntax or validity. These
errors can generally be corrected by the sender and retried.

An invalid address isn't a problem with the DNS itself.

X.4.XXX Network and Routing Status

The networking or routing codes report status about the
delivery system itself. These system components include any
necessary infrastructure such as directory and routing
services. Network issues are assumed to be under the control
of the destination or intermediate system administrator.

Looking through the X.4.X codes, I can't tell whet is the distinction
between 5.1.2 and 5.4.4. The text for X.4.4 has a weird description of a
nodata / nxdomain response, which is exactly the same as "does not exist"
under X.1.2.

A DNS lookup returning only an SOA (Start of Administration)
record for a domain name is one example of the unable to route
error.

There's evidently a lot of overlap and lack of precision in how these
codes are defined and used so I don't think it matters in practice what
this draft picks.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Viking, North Utsire, South Utsire: Variable, mainly northerly or
northeasterly 3 or 4, veering easterly 4 or 5 later. Slight. Fog patches
developing. Good, occasionally very poor.
ned+
2014-07-18 21:18:58 UTC
Permalink
Post by Tony Finch
Post by ned+
Post by Tony Finch
What's wrong with 5.1.2 and 5.1.8 ?
X.1.2 Bad destination system address
The destination system specified in the address does not exist
or is incapable of accepting mail. For Internet mail names,
invalid for mail. This code is only useful for permanent
failures.
X.1.8 Bad sender's system address
The sender's system specified in the address does not exist or
is incapable of accepting return mail. For domain names, this
for mail.
Wrong group of codes. Those are status for mail systems to return, not
the routing layer.
The point of null MX records it to explicitly say the address is invalid,
so an address status would seem to make sense.
No, the point is to say that a host is invalid.
Post by Tony Finch
X.1.XXX Addressing Status
The address status reports on the originator or destination
address. It may include address syntax or validity. These
errors can generally be corrected by the sender and retried.
An invalid address isn't a problem with the DNS itself.
Neither is a NXDOMAIN error, and that's in the 4.z group.
Post by Tony Finch
X.4.XXX Network and Routing Status
The networking or routing codes report status about the
delivery system itself. These system components include any
necessary infrastructure such as directory and routing
services. Network issues are assumed to be under the control
of the destination or intermediate system administrator.
Looking through the X.4.X codes, I can't tell whet is the distinction
between 5.1.2 and 5.4.4. The text for X.4.4 has a weird description of a
nodata / nxdomain response, which is exactly the same as "does not exist"
under X.1.2.
Again, it's a question of what component is involved. 4.x codes are
for directory services external to the mail system, 1.x is for the mail
system itself.

Which admittedly leaves LDAP in a bit of an odd position. Oh well.
Post by Tony Finch
A DNS lookup returning only an SOA (Start of Administration)
record for a domain name is one example of the unable to route
error.
There's evidently a lot of overlap and lack of precision in how these
codes are defined and used so I don't think it matters in practice what
this draft picks.
On the contrary, it matters because the DNS changes constantly, and
the code may be all you have telling you what the condition was that
caused the bounce.

Ned
Tony Finch
2014-07-18 21:46:05 UTC
Permalink
Post by ned+
Post by Tony Finch
Post by ned+
Wrong group of codes. Those are status for mail systems to return, not
the routing layer.
The point of null MX records it to explicitly say the address is invalid,
so an address status would seem to make sense.
No, the point is to say that a host is invalid.
If you can't use them when the DNS says a mail domain is invalid then I
don't understand if it ever makes sense to use 5.1.2 or 5.1.8.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
South-east Iceland: Southeasterly 4 or 5. Moderate. Occasional rain. Good,
occasionally poor.
ned+
2014-07-19 00:08:23 UTC
Permalink
Post by Tony Finch
Post by ned+
Post by Tony Finch
Post by ned+
Wrong group of codes. Those are status for mail systems to return, not
the routing layer.
The point of null MX records it to explicitly say the address is invalid,
so an address status would seem to make sense.
No, the point is to say that a host is invalid.
If you can't use them when the DNS says a mail domain is invalid then I
don't understand if it ever makes sense to use 5.1.2 or 5.1.8.
You don't have a way of declaring a domain as invalid at the MTA level? The
Oracle MTA has at least five different ways that can be configured without any
recourse to a directory server. And we absolutely do return 5.2.1 in such
cases.

And ask yourself this: Given that the null MX mechanism wasn't part of the
picture when these codes were developed, and given null MX is the only (AFAIK)
DNS-based mechanism with these semantics, why was the code even defined? Also
remember that the attitude in those days (wrongly, IMO) to be parsimonous
with code allocation.

Absent a DNS-based mechanism, the best that could be done to address this
problem was either to MX such hosts to an MTA which was configured to reject
them, or run a stub SMTP server on the host itself that returns a 521 error as
the banner a la RFC 1846. In either of those cases a 5.1.2 code would be
appropriate.

Ned
Tony Finch
2014-07-19 13:09:24 UTC
Permalink
Post by ned+
Post by Tony Finch
Post by ned+
Post by Tony Finch
Post by ned+
Wrong group of codes. Those are status for mail systems to return, not
the routing layer.
The point of null MX records it to explicitly say the address is invalid,
so an address status would seem to make sense.
No, the point is to say that a host is invalid.
If you can't use them when the DNS says a mail domain is invalid then I
don't understand if it ever makes sense to use 5.1.2 or 5.1.8.
You don't have a way of declaring a domain as invalid at the MTA level?
Yes, but it doesn't make much sense to me to draw an arbitrary line
somewhere on the spectrum between a configuration file, a configuration
table, a configuration database, or getting configuration from LDAP or
DNS, and say that one one side of the line it is an address-related
failure and on the other it is a routing or directory related failure.
In some MTAs, you find out whether an address is valid by trying to route
it.
Post by ned+
And ask yourself this: Given that the null MX mechanism wasn't part of the
picture when these codes were developed, and given null MX is the only (AFAIK)
DNS-based mechanism with these semantics, why was the code even defined?
At least some MTAs in the mid 1990s would treat a mail domain as invalid
if its DNS was set up incorrectly, e.g. MX points to this machine but this
machine isn't configured to handle the domain, or MX does not exist in a
part of the DNS where the postmaster has forbidden fallback-to-A.
Post by ned+
Absent a DNS-based mechanism, the best that could be done to address this
problem was either to MX such hosts to an MTA which was configured to reject
them, or run a stub SMTP server on the host itself that returns a 521 error as
the banner a la RFC 1846. In either of those cases a 5.1.2 code would be
appropriate.
Why not a 5.3.X (mail system status) code?

The problem here is that someone writing a specification for a status code
can't choose which sub-code to use based on just RFC 3463 since the
categories overlap and their descriptions are too abstract to make it
clear how to resolve the overlaps. (Another example: why are message size
limits a "mail system status" not a "message content status"? You have to
read between the lines to conclude that X.6.X is exclusively for MIME.)
And you can't use your practical experience of MTA architecture since
implementations differ a lot and the codes are evidently not based on a
sufficiently universal model.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Southwest Forties, Cromarty, Forth: Easterly 4 or 5, increasing 6 or 7 for a
time, veering southerly or southwesterly later. Slight or moderate,
occasionally rough later in Cromarty. Thundery showers, fog patches later.
Moderate or poor, occasionally very poor later.
ned+
2014-07-19 14:49:03 UTC
Permalink
Post by Tony Finch
Post by ned+
Post by Tony Finch
Post by ned+
Post by Tony Finch
Post by ned+
Wrong group of codes. Those are status for mail systems to return, not
the routing layer.
The point of null MX records it to explicitly say the address is invalid,
so an address status would seem to make sense.
No, the point is to say that a host is invalid.
If you can't use them when the DNS says a mail domain is invalid then I
don't understand if it ever makes sense to use 5.1.2 or 5.1.8.
You don't have a way of declaring a domain as invalid at the MTA level?
Yes, but it doesn't make much sense to me to draw an arbitrary line
somewhere on the spectrum between a configuration file, a configuration
table, a configuration database, or getting configuration from LDAP or
DNS, and say that one one side of the line it is an address-related
failure and on the other it is a routing or directory related failure.
In some MTAs, you find out whether an address is valid by trying to route
it.
I quite simply disagree. To me it makes a hell of a lot of sense to draw a line
between errors caused by stuff under the control of my administrative domain
and stuff that isn't.

This is especially true of the DNS, where an error right now may not occur
later, and there's nothing logged locally to indicate the change.

I don't even want to think about how many hours I've spent personally trying to
sort out some obscure problem that was made obscure by it not being clear that
the error condition originated from the DNS.
Post by Tony Finch
Post by ned+
And ask yourself this: Given that the null MX mechanism wasn't part of the
picture when these codes were developed, and given null MX is the only (AFAIK)
DNS-based mechanism with these semantics, why was the code even defined?
At least some MTAs in the mid 1990s would treat a mail domain as invalid
if its DNS was set up incorrectly, e.g. MX points to this machine but this
machine isn't configured to handle the domain, or MX does not exist in a
part of the DNS where the postmaster has forbidden fallback-to-A.
Unless there's some indication that the existence of that practice was a factor
in the design - and I'm pretty sure it wasn't - I fail to see the point.
Post by Tony Finch
Post by ned+
Absent a DNS-based mechanism, the best that could be done to address this
problem was either to MX such hosts to an MTA which was configured to reject
them, or run a stub SMTP server on the host itself that returns a 521 error as
the banner a la RFC 1846. In either of those cases a 5.1.2 code would be
appropriate.
Why not a 5.3.X (mail system status) code?
Perhaps because none of those codes are appropriate?
Post by Tony Finch
The problem here is that someone writing a specification for a status code
can't choose which sub-code to use based on just RFC 3463 since the
categories overlap and their descriptions are too abstract to make it
clear how to resolve the overlaps. (Another example: why are message size
limits a "mail system status" not a "message content status"? You have to
read between the lines to conclude that X.6.X is exclusively for MIME.)
And you can't use your practical experience of MTA architecture since
implementations differ a lot and the codes are evidently not based on a
sufficiently universal model.
I agree that the categories in general overlap and that some of the
descriptions are unclear.

But that doesn't mean they are unclear in this case, or that we should
just throw up our hands and use whatever code we happen to feel like
using.

The real question is whether or not it makes sense to define a new code to
identify this class of error. I think it makes all sorts of sense to do so, and
I think that code belongs in the 4.x space.

Ned
Viktor Dukhovni
2014-07-19 01:53:13 UTC
Permalink
Post by ned+
Post by Tony Finch
The point of null MX records it to explicitly say the address is invalid,
so an address status would seem to make sense.
No, the point is to say that a host is invalid.
A recipient domain is (often) not a host. The lookup key for a
nullmx RR is a domain. Since no MX hosts are returned, what is
invalid is the recipient domain, which is part of the recipient
address. I generally also have mappings in the Postfix transport
table of the form:

.invalid error:5.1.2 invalid destination domain

and rewrite unqualified mailboxes in headers from remote clients
by appending "@domain.invalid".

http://www.postfix.org/postconf.5.html#remote_header_rewrite_domain

The text in 3463 is quite broad:

X.1.2 Bad destination system address

The destination system specified in the address does not exist
or is incapable of accepting mail. For Internet mail names,
this means the address portion to the right of the "@" is
invalid for mail. This code is only useful for permanent
failures.

It applies equally well to nullmx and the "invalid" TLD.
--
Viktor.
Viktor Dukhovni
2014-07-19 05:59:23 UTC
Permalink
Post by Ted Lemon
divertimento% dig mx ietf.org
Sorry, no, that would be "dig mx www.ietf.org":

$ dig +noall +ans -t mx www.ietf.org
www.ietf.org. IN CNAME www.ietf.org.cdn.cloudflare.net.

so no MX records there...
--
Viktor.
Ted Lemon
2014-07-19 21:33:00 UTC
Permalink
You misunderstand. I was suggesting that the MX record for ietf.org be used as a template for other non-mail-receiving subdomains of ietf.org.

(To avoid further controversy, though, the responses I've gotten on this topic have been generally helpful, and I am not asserting that this should be done instead of what has been proposed. I was merely floating it to see what the objection would be, and the response was informative.)
Douglas Otis
2014-07-21 13:24:37 UTC
Permalink
Post by Viktor Dukhovni
Post by Ted Lemon
divertimento% dig mx ietf.org
$ dig +noall +ans -t mx www.ietf.org
www.ietf.org. IN CNAME www.ietf.org.cdn.cloudflare.net.
so no MX records there...
But there are address records.

www.ietf.org.cdn.cloudflare.net. 87 IN A 104.20.1.85
www.ietf.org.cdn.cloudflare.net. 87 IN A 104.20.0.85
www.ietf.org.cdn.cloudflare.net. 116 IN AAAA 2400:cb00:2048:1::6814:55
www.ietf.org.cdn.cloudflare.net. 116 IN AAAA 2400:cb00:2048:1::6814:155

http://tools.ietf.org/html/rfc5321#section-5
,--
If an empty list of MXs is returned,
the address is treated as if it was associated with an implicit MX
RR, with a preference of 0, pointing to that host.
'--

Which means there are 4 implied MX records causing likely 4 timeouts depending on how port 25 is handled.
Since there is no support to require use of MX records, the remaining solution (although not as clean) is to create negated MX record.

Regards,
Douglas Otis
S Moonesamy
2014-07-19 08:14:34 UTC
Permalink
Hi John,
That's a good question. I'll explain the problem as follows:

(a) The user uses an incorrect email address for the recipient.

(b) The mail service does not provide timely feedback about not
being able to deliver the message (see (a)).

The fix proposed is to signal that the mail target does not support a
mail service. It's not a bad idea. Now, how do you (used in a
general sense) do that? Currently, there isn't any way to do that
because of the implicit MX. There was a fix proposed over nine years
ago. It was to use a dot as the mail target. From an application
point of view, what the dot means is a DNS problem. :-) From a SMTP
point of view, the target host is not valid; the user will be sent a
message in about four hours with information about the delivery status.

The MX RDATA format, defined in an Internet Standard, is as follows:

"A <domain-name> which specifies a host willing to act as a
mail exchange for the owner name."

There is a problem. The IETF can:

(a) Solve it.

(b) Pretend that it does not exist.

(c) Wait.

I do not have a strong opinion about all.

Regards,
S. Moonesamy
John R Levine
2014-07-19 14:50:26 UTC
Permalink
Post by S Moonesamy
(a) Solve it.
(b) Pretend that it does not exist.
(c) Wait.
(d) Document the exisiting practice that people have been using since 2006.

Regards,
John Levine, ***@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
Scott Kitterman
2014-07-19 15:01:46 UTC
Permalink
Post by John R Levine
Post by S Moonesamy
(a) Solve it.
(b) Pretend that it does not exist.
(c) Wait.
(d) Document the exisiting practice that people have been using since 2006.
(e) Document the existing practice that people have been using since 2006,
but give it a new name so that those people have no idea you've done it
because a semantically correct name is better than one that people know.

Scott K
Dave Crocker
2014-07-18 14:45:50 UTC
Permalink
Post by Ted Lemon
I must be missing something here. You're saying you want me to set
up a null MX for all my hosts to prevent someone else's MTA having
undeliverable mail sitting in the queue for a week? Why would I
care about your MTA's queue? Why would this issue even be on my
radar?
Well, some operators actually like being good neighbors, especially when
the effort needed is tiny and one-time.

But even if they don't care about that, they might prefer not to have
those guys banging on their servers for days until the message times out.
Post by Ted Lemon
The second example you give, stopping mail being delivered to the web
server, is actually served better by setting up a proper MX that
directs the mail to the right server. Does an HTTP server really
care about the occasional SYN to port 25?
Ahhh. You haven't heard of the scaling effects of botnets.

So the answer is yes, since it might not be 'occasional'.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Ted Lemon
2014-07-18 14:48:27 UTC
Permalink
Post by Dave Crocker
Ahhh. You haven't heard of the scaling effects of botnets.
OK, so the NULL MX record is actually intended to make botnets send fewer TCP SYNs to non-mail-supporting hosts. Got it.
Ted Lemon
2014-07-18 14:50:15 UTC
Permalink
Post by Dave Crocker
Well, some operators actually like being good neighbors, especially when
the effort needed is tiny and one-time.
Understood, but it's not clear to me that "some operators" is a big enough target audience to see any appreciable win from this technique.
Dave Crocker
2014-07-18 15:03:41 UTC
Permalink
Post by Ted Lemon
Understood, but it's not clear to me that "some operators" is a big enough target audience to see any appreciable win from this technique.
Ted, I can't tell what sort of actions you are pressing to have taken.

The document formalizes existing practice. Sometimes the IETF does that.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Ted Lemon
2014-07-18 15:06:20 UTC
Permalink
Post by Dave Crocker
Ted, I can't tell what sort of actions you are pressing to have taken.
I'm not asking for action to be taken. I'm making an observation, and waiting for you to either ignore it, contradict it, or agree with it.
Hector Santos
2014-07-18 15:58:43 UTC
Permalink
Post by Ted Lemon
I must be missing something here. You're saying you want me to set up a null MX for all my hosts to prevent someone else's MTA having undeliverable mail sitting in the queue for a week? Why would I care about your MTA's queue? Why would this issue even be on my radar?
It could be useful as an optimizer to avoid the implicit mx step. It can also help with any CBV "call back verifiers" support to immediately skip checking the return path dynamically at the SMTP level. This would provide your receiver with a "55z 5.5.z invalid return path" dynamic rejection at the 5321 mail from or rcpt to state point.

So in this regard, on the receiver side, it is definitely become a valid SMTP compliance check with an enforceable reason to reject regardless of the mail legitimacy. On the sender side, it's an optimizer to avoid the implicit mx attempt.


--
Hector Santos
http://www.santronics.com
Mark Andrews
2014-07-19 00:10:02 UTC
Permalink
Post by Ted Lemon
Post by Mark Andrews
There are lots of machines which do not have the SMTP port configured
yet have A or AAAA records resulting in a implicit MX record and
week+ long no delivery notifications.
Just about everyone with a outsourced HTTP service needs to be able
to stop MTAs sending to email to the outsourced service. MUA's
could also lookup the MX RRset and issue a error without talking
to the MSA.
I must be missing something here. You're saying you want me to set up a
null MX for all my hosts to prevent someone else's MTA having
undeliverable mail sitting in the queue for a week? Why would I care
about your MTA's queue? Why would this issue even be on my radar?
The second example you give, stopping mail being delivered to the web
server, is actually served better by setting up a proper MX that directs
the mail to the right server. Does an HTTP server really care about the
occasional SYN to port 25?
Is it? You are forcing me to configure a MTA to accept mail for
"www.example.com", even if I don't want to, because otherwise I
have to trust a hosting service to not run a smtp service on the
http server. I'm giving the hosting service stuff I want to be
made public. I want to prevent stuff, that should remain private,
from being sent to their machine by mistake.
Post by Ted Lemon
I'm not against this draft moving forward, but I find these use cases somewhat puzzling.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org
Viktor Dukhovni
2014-07-19 00:47:27 UTC
Permalink
Post by Ted Lemon
I must be missing something here. You're saying you want me to set up
a null MX for all my hosts to prevent someone else's MTA having
undeliverable mail sitting in the queue for a week? Why would I care
about your MTA's queue? Why would this issue even be on my radar?
This is very use to prevent misuse of parked domains. These
sometimes become live, or in any case misuse of these by spammers
can negatively impact one's brand reputation. If one has a domain
that is never used to send mail, a nullmx is a sensible thing to
publish. One is of course free to not publish nullmx RRs, or not
even consider the question.
--
Viktor.
Murray S. Kucherawy
2014-07-18 03:39:38 UTC
Permalink
Post by John C Klensin
(d) It seems to me that the cases this proposal addresses are
special enough that a dedicated Extended Status Code would be in
order. Instead, the document specifies the highly generic 5.1.2
(even those the RFC 3463 definition of X.1.2 includes "incapable
of accepting mail" and "invalid for mail" (which don't mean
quite the same thing). Especially since there is not an
easily-located WG discussion, the document should at least
explain its choice.
If consensus is to register a new code as suggested, one could certainly
help himself to a cloning of the useful parts of
draft-ietf-appsawg-email-auth-codes, now in Last Call.

-MSK
Viktor Dukhovni
2014-07-19 14:25:29 UTC
Permalink
It just designates non-sending domains,
That's a bit of an under-statement, because, for example,
with the widely practived:

reject_unknown_sender_domain

restriction in Postfix, mail from nullmx domains *is* rejected,
so any that declare-themselves non-receiving become non-sending
in practice. If the draft suggests that nullmx domains might
expect to send mail will impunity, that would be misleading.

In practical terms, if you don't receive, you can't send (that is
you can't use the domain in the SMTP return path).
--
Viktor.
Dave Crocker
2014-07-19 14:38:14 UTC
Permalink
Post by Viktor Dukhovni
It just designates non-sending domains,
That's a bit of an under-statement, because, for example,
reject_unknown_sender_domain
restriction in Postfix, mail from nullmx domains *is* rejected,
so any that declare-themselves non-receiving become non-sending
in practice. If the draft suggests that nullmx domains might
expect to send mail will impunity, that would be misleading.
In practical terms, if you don't receive, you can't send (that is
you can't use the domain in the SMTP return path).
Sorry, no.

1. The return-path is not required to have any relationship to any
another email field.

2. The semantics of nullmx make an assertion only about receiving.

In fact, there are legitimate scenarios that include use of domains used
for sending but not receiving, as the draft cites.

The fact that some operational choices might not allow this scenario is
a separate matter, outside of IETF specifications.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Viktor Dukhovni
2014-07-21 15:14:52 UTC
Permalink
Post by Dave Crocker
Post by Viktor Dukhovni
That's a bit of an under-statement, because, for example,
reject_unknown_sender_domain
restriction in Postfix, mail from nullmx domains *is* rejected,
so any that declare-themselves non-receiving become non-sending
in practice. If the draft suggests that nullmx domains might
expect to send mail will impunity, that would be misleading.
In practical terms, if you don't receive, you can't send (that is
you can't use the domain in the SMTP return path).
Sorry, no.
1. The return-path is not required to have any relationship to any
another email field.
2. The semantics of nullmx make an assertion only about receiving.
In fact, there are legitimate scenarios that include use of domains used
for sending but not receiving, as the draft cites.
The fact that some operational choices might not allow this scenario is
a separate matter, outside of IETF specifications.
One can bury one's head in the sand if one likes, but non-receiving
domains that turn on nullmx (or whatever it ends up being called)
need to be aware that in practice they will find their mail rejected
by many receiving systems if they attempt to use such a domain in
the "MAIL FROM:<return-path>".
--
Viktor.
John Levine
2014-07-21 17:08:16 UTC
Permalink
Post by Viktor Dukhovni
One can bury one's head in the sand if one likes, but non-receiving
domains that turn on nullmx (or whatever it ends up being called)
need to be aware that in practice they will find their mail rejected
by many receiving systems if they attempt to use such a domain in
the "MAIL FROM:<return-path>".
As I think I said in the summary note a few days ago, my updated copy
of the draft now says pretty much that.

R's,
John
Loading...