Subject: Re: Last Call: draft-klensin-rfc2821bis

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Mar 2008 09:33:01 -0700

While this response may be a bit late, the change in section 5.1  
indicating SMTP server discovery now explicitly supports IPv6 address  
records represents a significant change from RFC2821.

While a desire to retain current practices has some justification,  
extending an already dubious and archaic practice to the explicit use  
of IPv6 raises significant questions.

The level of misuse afflicted upon SMTP often results in an  
exploration of DNS SMTP discovery records to determine whether a  
purported domain might be valid in the forward direction.  To remain  
functional, reverse DNS checks are often avoided due to the poor level  
of maintenance given this zone.  A move to deprecate A records for  
discovery when performing these checks to ascertain domain validity  
would favourably impact the level of undesired transactions.  To  
combat rampant domain spoofing, some domains also publish various  
types of SMTP related policy records.  To counter problems related to  
wildcard policy records, a lack of policy may be conditioned upon  
presences of possible SMTP discovery records.

Adding IPv6 to the list transactions needed to qualify SMTP domains  
that is predominately triggered by geometrically growing levels of  
abuse or misuse appears to be a remarkably poor choice.  To suggest a  
domain might reply upon this mechanism again appears to be remarkably  
poor advice.  Reliance upon a communication system should not be  
predicated upon such a questionable mechanisms.  During the next  
disaster, would you want FEMA to not use MX records or to depend upon  
IPv6 address records?  Not including IPv6 as a discovery record would  
better protect networks in the face of growing misuse of SMTP while  
also better ensuring the integrity of SMTP.

-Doug
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Mar 2008 13:04:23 -0400

Doug,

I'm sorry, but I can't understand what you are talking about.
That is at least in part because you are using vocabulary that
does not appear in 2821bis or other common IETF standardized
email technology.  You also seem to be making assumptions that
aren't part of the 2821 model (whether they are valid or not).

In 2821 and its predecessors, MX records and the associated
preferences were specified as the preferred mechanism for
finding the next-hop SMTP server.   There was also a special
case, originally part of a transition mechanism for RFC 974,
that, if no MX records were found for a particular name, one or
more A RRs would be located for the name and treated as if they
were the targets of an MX record with preference zero.

While various implementations have been more permissive over
time, the data field in an MX RR has always been expected to be
a DNS name that would, in turn, resolve to one or more A RRs.

That is the mechanism that has been used for Internet mail over
IPv4 for many years.  

Now, as far as I know, 2821bis makes only two changes in this
area.  The first is to be explicit about the expected data value
in MX records.  The second is to explicitly specify that names
with AAAA records are permitted as an alternative to names with
A records.  Without that change, which was anticipated in 2821
but not as explicit because of the state of development
experience at the time, it would be impossible to run SMTP over
IPv6 without local imaginative extensions of the standard.

It does not provide for an extension of the "if there are no MX
records, look for an A RR" model because the mailing list
concluded that the transition mechanism was not needed for IPv6
transition and because it would have required the standard to
specify preferential rules for A and AAAA records.   It seemed
much better to let those configuring mail systems to use the
existing MX preference mechanism to specify what treatment they
thought appropriate.

That is really all the material to which you refer does (or
changes).

Now, are you suggesting that:

(1) It is time to abandon the current Internet email fabric in
terms of, e.g., your "notify and retrieve" proposals?

(2) That we should not specify operation of SMTP over IPv6 but
either prohibit that or leave it to the imagination?

(3) That MX records are so useless that we should deprecate them
and embark on some other "discovery" mechanism rather than
updating 2821?

(4) Something else?

      john

--On Thursday, 20 March, 2008 09:33 -0700 Douglas Otis
<[email-masked]> wrote:

> While this response may be a bit late, the change in section
> 5.1   indicating SMTP server discovery now explicitly supports
> IPv6 address   records represents a significant change from
> RFC2821.
> 
> While a desire to retain current practices has some
> justification,   extending an already dubious and archaic
> practice to the explicit use   of IPv6 raises significant
> questions.
> 
> exploration of DNS SMTP discovery records to determine whether
> a   purported domain might be valid in the forward direction.
> To remain   functional, reverse DNS checks are often avoided
> due to the poor level   of maintenance given this zone.  A
> move to deprecate A records for   discovery when performing
> these checks to ascertain domain validity   would favourably
> impact the level of undesired transactions.  To   combat
> rampant domain spoofing, some domains also publish various  
> types of SMTP related policy records.  To counter problems
> related to   wildcard policy records, a lack of policy may be
> conditioned upon   presences of possible SMTP discovery
> records.
> 
> Adding IPv6 to the list transactions needed to qualify SMTP
> domains   that is predominately triggered by geometrically
> growing levels of   abuse or misuse appears to be a remarkably
> poor choice.  To suggest a   domain might reply upon this
> mechanism again appears to be remarkably   poor advice.
> Reliance upon a communication system should not be  
> predicated upon such a questionable mechanisms.  During the
> next   disaster, would you want FEMA to not use MX records or
> to depend upon   IPv6 address records?  Not including IPv6 as
> a discovery record would   better protect networks in the face
> of growing misuse of SMTP while   also better ensuring the
> integrity of SMTP.
> 
> -Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Mar 2008 09:03:01 +1100

> and embark on some other "discovery" mechanism rather than

	I think Doug is saying don't let domains with just AAAA
	records be treated as valid RHS of email.  Today we
	have to add records to domains with A records to say that
	these are not valid RHS of email.  With MX synthesis
	from AAAA you create the same problem for domains with
	AAAA records.

		user@<A record owner>
		user@<MX record owner>
		user@<AAAA record owner>  * don't allow this.
 
	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Mar 2008 18:30:51 -0400

> 		user@<AAAA record owner>  * don't allow this.

Mark, Doug,

With the understanding that this is just my personal opinion (as
editor, I'll do whatever I'm told) _and_ that I'm personally
sympathetic to phasing out even the A record implicit MX...

It seems to be that 2821bis is the wrong place to try to fix
this, especially via a comment posted well after the _second_
Last Call closed.   The current phrasing is not an oversight.
It was explicitly discussed on the mailing list and this is the
behavior that people decided they wanted.

My recommendation is that someone generate a new I-D that
suggests that, even though the standard requires support for
both types of implicit MXs, it is not a desirable practice and
that systems supporting mail servers should use explicit MX
records, ordered however they think appropriate to get the
behavior they want.  If consensus could be achieved and the
justification were clear enough, such a BCP would probably get
much more attention than a change of a few lines in 2821bis.

Again, just my opinion.

    john

---

From: Douglas Otis <[email-masked]>
Date: Sat, 22 Mar 2008 23:02:30 -0700

On Mar 20, 2008, at 3:30 PM, John C Klensin wrote:

> It seems to be that 2821bis is the wrong place to try to fix this,  
> especially via a comment posted well after the _second_ Last Call  
> closed.   The current phrasing is not an oversight. It was  
> explicitly discussed on the mailing list and this is the behavior  
> that people decided they wanted.

John,

In the past you had made several comments that RFC2821bis would not  
change SMTP, and that you had also stated AAAA records where NOT  
defined as SMTP server discovery records.  (Not in those words of  
course.)  It does not appear this change was your choice, but  
nonetheless and surprisingly this unfortunate change is now being made.

The "update" of RFC2821 is making a _significant_ architectural change  
to SMTP by explicitly stating AAAA records are within a list of SMTP  
server discovery records.  This change represents a poor architectural  
choice since this _will_ increase the burden on networks being spoofed  
by abusive email.  Due to high levels of abuse, confirming validity of  
email domains by checking for discovery (A and MX) records in the  
forward DNS zone often replaces an alternative of checking PTR records  
in the in-addr.arpa reverse DNS zone.  The reverse zone suffers from  
poor maintenance where its use creates a sizeable burden for  
recipients.  RFC2821bis now adds AAAA records to a list of records  
that must be checked to disqualify public SMTP server domains within  
the DNS forward direction.  This change adds to the transactional  
burdens already headed in the wrong direction.  It would seem a sound  
architectural change would be to deprecate A records as a means to  
qualify domains for message acceptance, but RFC2822bis adds AAAA  
records instead.  This situation becomes considerably worse when  
domain tree walking or wildcards are then preferred over checks  
against discovery records.

It was not my intention to post this after last call, but this only  
came to my attention recently.  For that I am sorry, nevertheless this  
issue may deserve greater consideration.

-Doug

---

From: John C Klensin <[email-masked]>
Date: Sun, 23 Mar 2008 20:55:22 -0400

Doug,

--On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis
<[email-masked]> wrote:

>...
> In the past you had made several comments that RFC2821bis
> would not change SMTP, and that you had also stated AAAA
> records where NOT defined as SMTP server discovery records.
> (Not in those words of course.)  It does not appear this
> change was your choice, but nonetheless and surprisingly this
> unfortunate change is now being made.
> 
> The "update" of RFC2821 is making a _significant_
> architectural change to SMTP by explicitly stating AAAA
> records are within a list of SMTP server discovery records.

Well, to be very precise, 2821 is ambiguous on the subject. Some
people have read (and implemented) it as if the text said
"address records", implying a default MX for the AAAA case as
well as the A one.   Others have read it more narrowly and only
supporting the default for A RRs.    To the extent to which
2821bis is expected to eliminate ambiguities that were present
in 2821, it had to say something on this subject.    If it says
"address records" (as the current text does), you (and perhaps
Mark and others) dislike the consequences and claim "significant
architectural change".   If it is changed to explicitly indicate
that only A RRs can be used to imply an MX record, then I assume
that those who read 2821 the other way and are now supporting
AAAA records to generate an implied MX would claim "significant
architectural change".  

Given that, the document can't win.  The choices are between
ambiguity (which I hope is the lowest preference for all of us)
and picking an option that some people won't like.

For me --and, again, this is personal opinion only-- that set of
choices pretty much cancels out arguments based on "significant
architectural change" and leaves us with a choice based on the
more fundamental "what is the right thing to do from the
standpoint of the installed base and efficient email operation".

As you know, I prefer to make those decisions based on normal
transport and delivery of normal mail.  Put differently, making
changes to, or decisions about, mail protocols in order to make
a spam-fighting technique work better doesn't appeal to me very
much, especially if that technique is easily worked around or
otherwise has little long-term value.  YMMD, of course.

>...

Even without the anti-spam argument that you raise, I think
there are mail performance and DNS reasons (one cited by Mark)
for declaring the utility of implicit MX records, even those
built on A RRs, to be at an end.  But that would clearly be a
significant change to 2821/ 2821bis, so I think that, regardless
of whether this issue is reconsidered for 2821bis, I'd recommend
the BCP path I comments on in an earlier note.  Remembering that
it is very late in the processing cycle for 2821bis, suppose an
I-D that could lead to such a BCP were in the archives and under
active discussion.  I would think that it would be easier to
make a case for a sentence or two in 2821bis that indicated that
the whole question of whether implicit MXs were a good idea and
that made an informative reference pointer to the relevant I-D
would be easier than getting clear consensus to ban implicit MXs
based on AAAA records or, for that matter, to get equally clear
consensus on the current text.

      john

---

From: John Leslie <[email-masked]>
Date: Mon, 24 Mar 2008 14:33:38 -0400

John C Klensin <[email-masked]> wrote:
> Well, to be very precise, 2821 is ambiguous on the subject.

   Agreed.

> Some people have read (and implemented) it as if the text said
> in 2821, it had to say something on this subject.

   It might, however, be best to simply document the ambiguity.
I suspect that implementation reports would show some implementations
querying for both AAAA and A RRs, while others query only for A RRs.
I am not convinced that 2821bis _should_ try to resolve this.

> If it says "address records" (as the current text does),

   Actually, it says "address RR" (if I understand what text we're
discussing). I believe we're discussing Section 5.1 of

http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-09.txt

where it says
" 
" The lookup first attempts to locate an MX record associated with the
" name.  If a CNAME record is found instead, the resulting name is
" processed as if it were the initial name.  If no MX records are
" found, but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA
" RR, or their successors) is found, the address RR is treated as if it
" was associated with an implicit MX RR, with a preference of 0,
" pointing to that host.

(Please correct me if I misunderstand what text we're discussing.)

> you (and perhaps Mark and others) dislike the consequences and
> claim "significant architectural change". If it is changed to
> explicitly indicate that only A RRs can be used to imply an
> MX record, then I assume that those who read 2821 the other way
> and are now supporting AAAA records to generate an implied MX
> would claim "significant architectural change".  

   Indeed, that seems likely (though not demonstrated).

   But regardeless, we're on shaky ground if we try to force either
kind of implementation to change. May I suggest a different starting
point:

   I think there's very strong consensus that the presence of an
MX RR demonstrates the intention to receive email addressed to the
domain in question. I don't think there's any consensus that the
presence of an AAAA or A RR demonstrates such an intent.

   There is, however, considerable history that the presence of an
address RR _in_combination_with_ a process listening on port 25
of the IP address in question indicates a willingness to receive
email for a domain identical to the domain of that address RR.

   Whether or not we have any consensus that this historical
practice should be deprecated (I would vote YES!), rfc2821-bis
is not, IMHO, the right place to deprecate it.

   (If I may digress a bit, let me explain that this implied-MX rule
is a real pain to me as an ISP, in that we maintain a SMTP server
on the same IP address as a number of virtual web services; and
the implied-MX rule brings us rather significant spam traffic that
I'd _much_ rather be sending to a different IP address than the web-
server for the domain in question.)

   Getting back to my point, what would be wrong with changing this
language in Section 5.1 to document the ambiguity instead of trying
(probably unsuccessfully) to prescibe a single way of resolving it?

   Thus, I suggest:
" ...
" If no MX records are
" found, but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA
" RR, or their successors) is found, the address RR
" is treated as if it
  ^^
  s/is/MAY be/

" was associated with an implicit MX RR, with a preference of 0,
" pointing to that host.

   I think that is a much better description of actual practice.

> and picking an option that some people won't like.

   I do not share John Klensin's distaste for ambiguity in evolving
standards. Were we starting afresh, I would put a lot of effort into
clarity, but when progressing a decades-old animal like SMTP to
Draft Standard, I think compatibility rates higher (and that we're
only fooling ourselves to claim that all existing implementations
will be changed to reflect what we write).

   Thus, I believe we'll be better served leaving the choice of
whether to infer a non-existent MX record to implementors and
administrators. As currently practiced, this implied-MX rule leads
to temporary errors (not reported for many hours) on typos, instead
of immediate permanent errors. Giving the immediate error, IMHO,
should be an option available to administrators.

> built on A RRs, to be at an end.

   I quite agree. (But I don't think 2821-bis can go there.)

> ... I'd recommend the BCP path I comments on in an earlier note.

   To tell truth, I dislike writing I-Ds. But I'd be willing to
help in the writing of such a document. Any other volunteers?

--
John Leslie <[email-masked]>
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ned Freed <[email-masked]>
Date: Mon, 24 Mar 2008 11:42:11 -0700 (PDT)

> I am not convinced that 2821bis _should_ try to resolve this.

I don't think we have a choice. it is obvious that this ambiguity can lead to
interoperability problems, and that means this has to be resolved if the
document is to obtain draft standard status.

> kind of implementation to change. May I suggest a different starting

On the contrary, it is expected that options can be eliminated from
documents moving to draft, especially if in doing so an interoperability
problem is removed.

> presence of an AAAA or A RR demonstrates such an intent.

Perhaps, but the fact remains that MX-less configurations are currently legal
and in use.

> email for a domain identical to the domain of that address RR.

OK...

> is not, IMHO, the right place to deprecate it.

On this we agree. We haven't gone through any sort of consensus process on this
and since there is no justification for deprecating use of A-record-only
configurations as part of a move to draft this cannot be done at time.

> (probably unsuccessfully) to prescibe a single way of resolving it?

See above. This would be fine if the document were intended for proposed but it
is not. I suppose we could ask for an exception to be made but frankly I see no
grounds for granting one.

				Ned

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 24 Mar 2008 20:46:33 +0100

John Leslie wrote:

> practice should be deprecated (I would vote YES!),

+1

> rfc2821-bis is not, IMHO, the right place to deprecate it.

It could be seen as an unintended chance to keep AAAA out
of this business, because RFC 2821 forgot to mention it. 
Admittedly a trick, twisting an unreported 2821 erratum
into a feature, but if it is for a good purpose, why not.

> " ...
> " If no MX records are
> " found, but an address RR (i.e., either an IPv4 A RR or
> " an IPv6 AAAA RR, or their successors) is found, the
> " address RR is treated as if it
>              ^^
>   s/is/MAY be/

That proposal touches the IPv4 fallback.  I think we'd need
to split it, IPv4 as is (2821 + 2821bis), IPv6 MAY (because
RFC 2821 did not require it 2821bis should say what we want).

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Mar 2008 14:17:48 -0700

On Mar 24, 2008, at 11:42 AM, Ned Freed wrote:

>>>> The "update" of RFC2821 is making a _significant_ architectural  
>>>> change to SMTP by explicitly stating AAAA records are within a  
>>>> list of SMTP server discovery records.
>>>
>>> "address records", implying a default MX for the AAAA case as well  
>>> as the A one.   Others have read it more narrowly and only  
>>> 2821bis is expected to eliminate ambiguities that were present in  
>>> 2821, it had to say something on this subject.
>
>>   It might, however, be best to simply document the ambiguity. I  
>> suspect that implementation reports would show some implementations  
>> querying for both AAAA and A RRs, while others query only for A  
>> RRs. I am not convinced that 2821bis _should_ try to resolve this.
>
> I don't think we have a choice. it is obvious that this ambiguity  
> can lead to interoperability problems, and that means this has to be  
> resolved if the document is to obtain draft standard status.

Anyone who relies upon just publishing AAAA records to enable the  
discovery of their receiving MTAs are unlikely to find this to be  
widely interoperable.  Until such time that A records for discovery  
have been deprecated, the A record method of discovery or email- 
address domain validation continues to be used.  MX records have been  
in use for a period long enough to safely rule out new explicitly  
"implied" MX records.  The choice seems rather clear, especially in  
the face of undesired traffic created by implied use of address  
records.  Please don't add AAAA or any future address record to a list  
of records likely to be abused by spammers.

>> (Please correct me if I misunderstand what text we're discussing.)

This is the correct section.

>>> explicitly indicate that only A RRs can be used to imply an MX  
>>> record, then I assume that those who read 2821 the other way and  
>>> are now supporting AAAA records to generate an implied MX would  
>>> claim "significant architectural change".
>
>> kind of implementation to change. May I suggest a different  
>> starting point:
>
> documents moving to draft, especially if in doing so an  
> interoperability problem is removed.

Clarity can be established and interoperability _improved_ by limiting  
discovery to just A and MX records.  Perhaps a note might be included  
that at some point in the future MX records may become required.

>>   I think there's very strong consensus that the presence of an MX  
>> RR demonstrates the intention to receive email addressed to the  
> Perhaps, but the fact remains that MX-less configurations are  
> currently legal and in use.

While there are some that use A records, which remains largely due to  
prior practices, these prior practices did _not_ include the use of  
AAAA records.

>> address RR _in_combination_with_ a process listening on port 25 of  
>> the IP address in question indicates a willingness to receive email  
>> for a domain identical to the domain of that address RR.

To avoid ambiguity, A and not AAAA records would be an accurate  
statement of prior practices.

>> practice should be deprecated (I would vote YES!), rfc2821-bis is  
>> not, IMHO, the right place to deprecate it.
>
> On this we agree. We haven't gone through any sort of consensus  
> process on this and since there is no justification for deprecating  
> use of A-record-only configurations as part of a move to draft this  
> cannot be done at time.

Agreed, but making assurances regarding use of AAAA records for the  
purpose of discovery is ill advised, to say the least.

>> on the same IP address as a number of virtual web services; and the  
>> implied-MX rule brings us rather significant spam traffic that I'd  
>> _much_ rather be sending to a different IP address than the web- 

As more SMTP domains attempt to publish policies of various sorts,  
validation of the domain will also likely depend upon finding  
requisite discovery records.  Adding AAAA and all future address  
records to a list of SMTP discovery records fails miserably at taking  
advantage of the MX record replacing the function of the generic A  
record.

> See above. This would be fine if the document were intended for  
> proposed but it is not. I suppose we could ask for an exception to  
> be made but frankly I see no grounds for granting one.

To say that AAAA records can be used for discovery would be equally  
wrong from an interoperability standpoint.  The only valid solution  
would be to indicate that AAAA records as a discovery mechanism may  
not be supported and should not be used for this purpose.  Use MX  
records instead.

-Doug

---

From: Ned Freed <[email-masked]>
Date: Mon, 24 Mar 2008 14:46:47 -0700 (PDT)

> of records likely to be abused by spammers.

I'm afraid this is nothing but a strawman. Nowhere did I say _how_ the
ambiguity should be resolved, only that it needs to be resolved one way
or the other. If the consensus is that better interoperability can be
had by banning bare AAAA records that's perfectly fine with me. What is not
fine is saying "maybe bare AAAA works, maybe it doesn't, good luck and
be happy". That's what I understood was being advocated and why I jumped
into this now.

> that at some point in the future MX records may become required.

Again, I have no problem with this approach if that's what the consensus is.

> prior practices, these prior practices did _not_ include the use of

Which is really irrelevant since the point I was addressing is the idea of
banning the bare A practice oing forward.

Agreed.

> advantage of the MX record replacing the function of the generic A

Another point in favor of not allowing bare AAAA records for mail routing.

> not be supported and should not be used for this purpose.  Use MX

Which is perfectly fine as far as I'm concerned. The question is whether
there's a consensus to resolve the ambiguity in this fashion.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Mar 2008 18:40:10 -0400

FWIW, my opinion is that if you want to accept incoming mail via IPv6, 
you need to advertise one or more MX records that point to ipv6-capable 
hosts.

Treating A records (in the absence of MX records) as "implicit MX" 
records was a hack needed to avoid forcing everyone to advertise an MX 
record or lose incoming mail, back in days where many sites didn't even 
support DNS very well, much less MX.

We don't need such a hack today because nobody today can expect to 
reliably receive Internet mail using only an IPv6 address.  For the 
foreseeable future, if you want to reliably receive incoming email, 
you're going to need an MX server on the public IPv4 Internet. 
Similarly if you want to reliably send outgoing email, you're going to 
need an SMTP relay on the IPv4 Internet.  Any ability to use IPv6 is 
just an optimization.

There are at least two reasons why it's better to not treat AAAA as an 
implicit MX:

1. fewer DNS lookups for the case where a host doesn't want to receive mail
2. immediate failure of mail sent to domain names that don't advertise 
either an MX or A record

(I'm a bit more dubious about the anti-spam argument.)

Also, I think that RFC2821bis is a fine place to fix this.  Putting the 
clarification in a separate document just makes it less likely that 
people will notice the clarification.

Keith

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 25 Mar 2008 00:00:23 +0100

Ned Freed wrote:

> If the consensus is that better interoperability can be had
> by banning bare AAAA records that's perfectly fine with me.

FWIW, I'd like that...

>> Clarity can be established and interoperability _improved_ 
>> by limiting discovery to just A and MX records.  Perhaps a
>> note might be included that at some point in the future MX
>> records may become required.
 
> Again, I have no problem with this approach if that's what

...and that, too.  

>> Adding AAAA and all future address records to a list of 
>> SMTP discovery records fails miserably at taking advantage
>> of the MX record replacing the function of the generic A
>> record.
 
> Another point in favor of not allowing bare AAAA records
[...]
>> The only valid solution would be to indicate that AAAA 
>> records as a discovery mechanism may not be supported and
>> should not be used for this purpose.  Use MX records instead.
 
> Which is perfectly fine as far as I'm concerned. The question
> is whether there's a consensus to resolve the ambiguity in
> this fashion.

Checking about 63 articles on the SMTP list mentioning "AAAA",
some from the early '90s, they're about TLDs, CNAME, MX, SPF,
and what else.  I found no message clearly saying "but I want
no MX for my AAAA".  I vaguely recall that somebody mentioned
an implementation doing this, but that is not the same as "I
insist on an AAAA fallback", and IIRC it was only one poster.

 Frank

---

From: Bill Manning <[email-masked]>
Date: Tue, 25 Mar 2008 06:38:07 -0700

> > Again, I have no problem with this approach if that's what

	so what is supposed to happen when I remove all
	"A" RR's from my zones?

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 25 Mar 2008 15:56:14 +0100

> so what is supposed to happen when I remove all "A" RR's from
> my zones?

I'm not sure if we are talking about the same issue.  For SMTP
as it used to be since RFC 821 clients trying to find a server
accepting mail for [email-masked] look for y.example MX records,
and if they got something they locate corresponding servers
"by name" (A or AAAA), all details as explained in 2821bis.  

If they got nothing with their MX query RFC (2)821 and 2821bis
said that the client should try y.example directly "by name",
it could be an ordinary host with an SMTP server at port 25.

For various reasons mentioned in this thread this "fallback"
or "implicit MX rule" isn't a good idea today, and some folks
like to get rid of it for AAAA.   RFC 2821 didn't say that
this is also supposed to work for IPv6, and therefore 2821bis
isn't forced to stick to it.

The proposed note about the old A-fallback suggests that hosts
still relying on the "implicit MX" should get an explicit MX.

For the client almost nothing changes, it still tries q=mx,
now getting the y.example name, and then it can get the IP
"by name" (or use the additional info in the q=mx reply).

For the domain with only one SMTP host also almost nothing is
new, it is only encouraged (by the proposed note) to publish
this name in an MX record.

You are not supposed to remove any A records from your zones.
You are not supposed to do anything at all, because you have
MX records as it should be... :-)

 Frank

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Mar 2008 09:30:27 +1100

> 	so what is supposed to happen when I remove all

	The same thing that happens today with zones that don't
	have A records.  You use MX records to refer to machines
	that have address (A and/or AAAA) records.

	Mark

---

From: Bill Manning <[email-masked]>
Date: Tue, 25 Mar 2008 19:31:17 -0700

> it could be an ordinary host with an SMTP server at port 25.

	right.

example.com.  soa (
	stuff
	)

	ns foo.
	ns bar.
;
mailhost   aaaa  fe80::21a:92ff:fe99:2ab1

	is what i am using today.

the RFC's have the right idea.

> isn't forced to stick to it.

	its not a bad idea either, just that some folks
	are feeling grumpy. 
	RFC 2821 didn't say - and the presumption should be
	that since IPv6 is just like IPv4... then the IPv4
	methods shoudl work.

> this name in an MX record.

	what is being proposed is -FORCING- people to use
	an RR type they may not want to use.

> MX records as it should be... :-)

	er, NO.  SMTP has no dependence on what may or may
	not exist in the DNS.  Forcing SMTP to depend on DNS
	is a huge mistake.  And yes Virginia, I plan on removing
	A rr's from my zones (eventually)

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Tue, 25 Mar 2008 19:32:44 -0700

> 	that have address (A and/or AAAA) records.

	er...  what about zones w/ A & AAAA rr's and no MX's?
	when I pull the A rr's, you are telling me that SMTP
	stops working?  That is so broken.

--bill

-- 
--bill

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Mar 2008 19:38:33 -0700 (PDT)

> 	stops working?  That is so broken.

That's exactly the issue that's being debated now: The issue of what happens
when a domain has one or more AAAA records and no MX. RFC 2821 was ambiguous as
to what to do in this case. 2821bis currently says that AAAAs work the same as
As in this case. Several folks have expressed the opinion that this is wrong
and the right thing to do is to only allow the address record fallback for A
records. Othere have even gone so far as to say that fallback behavior should
be deprecated and eventually phased out in favor of requiring an MX entry for
SMTP transfer, although I don't believe anyone is advocating for making that
change in 2821bis.

You seem to be of the opinion that fallback behavior should be extended to
AAAA, and you seem to be the first one to express that opinion. (I myself have
no opinion on how to resolve this other than believing it has to be resolved -
the present ambigiuty is unacceptable.)

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Mar 2008 19:51:32 -0700 (PDT)

> 	A rr's from my zones (eventually)

You know, that's a very interesting point. One of more common configuration
variations we see is to disable MX lookups and just use address records. (This
is done for a variety of reasons, most often having to do with administrative
control issues.) In an IPv6-only future world I see no reason why the need for
this sort of configuration will vanish and I don't think having the RFCs
say it shouldn't work is a good idea.

I'm therefore changing my position from "no opinion" to "keep 2821bis the way
it is".

				Ned

---

From: Willie Gillespie <[email-masked]>
Date: Tue, 25 Mar 2008 21:02:47 -0600

> I'm therefore changing my position from "no opinion" to "keep 2821bis the way

I don't think disabling MX lookups altogether is a smart move.  There
could be a variety of reasons I want my A or AAAA records to point to
one server, and my mail to go to a different server altogether.

Willie

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Mar 2008 14:13:23 +1100

> variations we see is to disable MX lookups and just use address records. (Thi

	You just overrode RFC 2821 by *disabling* the MX lookup.

	There is no reason why you can't also override RFC 2821bis
	by disabling the MX lookups and connecting directly.

	I don't see this as changing anything.

	Mark

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Mar 2008 23:18:53 -0400

Ned Freed wrote:
> variations we see is to disable MX lookups and just use address records.

how does anyone expect that to work across administrative domains?

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 25 Mar 2008 23:40:12 -0400

--On Tuesday, 25 March, 2008 23:18 -0400 Keith Moore
<[email-masked]> wrote:

>> You know, that's a very interesting point. One of more common
>> configuration variations we see is to disable MX lookups and
>> just use address records.
> 

Sorry, I'm now completely confused.  Maybe it has just been a
long day, but...

Ned, by "disable MX lookups", do you mean "don't put MX records
into the DNS zone and therefore force a fallback to the address
records" or "ignore the requirement of the standard that
requires using MX records if they are there"?   If the latter,
the behavior, however useful (or not) is, IMO, so far outside
the standard that it is irrelevant to any discussion about how
DNS records are used in a standard way.

Keith, what do administrative domains have to do with this?  If
I can write
    foo.example.com. IN MX 0 foo.example.com.
    foo.example.com. IN A 10.0.0.6
then, as things are now specified, I can lose the MX record
entirely with no difference in effect.  Similarly, if I can write
   
    foo.example.net. IN MX 0 foo.example.com.
    foo.example.com. IN A 10.0.0.6

Things still work as predicted if I discard the first record,
keep the second, but either know to reference the relevant SMTP
server as "foo.example.com" or, if I don't need
"foo.example.net" for anything else, insert a record in the
"example.net" zone that looks like
   foo.example.net IN CNAME foo.example.com.

Certainly there are cases where that is administratively
burdensome, or at least annoying.  There are also cases in which
I need multiple MX records, not a single implicit one.  But, for
these fairly common cases...

    john

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Mar 2008 23:55:15 -0400

> Keith, what do administrative domains have to do with this? 

I can imagine wanting an option to skip MX record lookup for relaying 
mail within an administrative domain - if, say, all of the relevant 
domains within that administrative domain were known to have A records 
pointing to their inbound SMTP server.

By contrast, I have a hard time imagining a good reason to skip MX 
lookup for relaying mail from one administrative domain to another. 
(unless maybe there is a bilateral agreement between the source and 
destination domain that specifies how such mail is to be relayed.)

(I have no doubt at all that people ask for such a thing, but I am at a 
loss as to why such behavior should be blessed by the standards.)

Keith

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Mar 2008 22:08:30 -0700 (PDT)

> how does anyone expect that to work across administrative domains?

The usual reason for it is exactly that: To get things to work across ADMDs
where stuff is otherwise messed up, services are unavailable, etc.

Look, I'm not advocating the practice. All I'm saying is that people find
it necesary to do fairly frequently.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Mar 2008 22:10:30 -0700 (PDT)

> requires using MX records if they are there"?

I'm talking about having the ability to disable DNS MX lookups entirely
and fall back to address information.

> If the latter,

I'm sorry, but i don't see it that way. I was close to convinced that this sort
of fallback behavior was no longer useful under any circumstances until Bill
reminded me that's not the case.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Mar 2008 22:47:35 -0700 (PDT)

> I don't think disabling MX lookups altogether is a smart move.

Nowhere did I say that was what people do.

>  There

I'm well aware of that.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 02:12:13 -0400

It might be the case that it's useful for an MTA to have an option to 
skip MX lookup for specific destinations because of DNS brokenness at 
those destinations.  But this seems to me to be outside of the scope of 
the standard.  Skipping MX lookup is not acceptable as a general 
practice, nor is it something we want to encourage.

In general, it's always been acceptable to configure an MTA to handle 
mail in some special-case way for specific domains where there was 
specific knowledge such that the special-case handling made sense for 
those domains.  The MX-then-A lookup is what you should do in the 
absence of any such knowledge.

---

From: Markku Savela <[email-masked]>
Date: Wed, 26 Mar 2008 08:45:03 +0200

> From: Ned Freed <[email-masked]>

> the present ambigiuty is unacceptable.)

As a private person using the "A record only" way of receiving mail, I
find it useful.

But, the point supporting the stand that it should work for AAAA is:

     If something works and is defined with IPv4, then the same thing
     should always work exactly the same way, when IPv4 is replaced
     with IPv6.

The goal should be to make IPv4 and IPv6 easily replaceable anywhere,
whithout any reduced functionality.

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Mar 2008 23:48:37 -0700 (PDT)

> the standard.

By the same token, discussions of gatewaying to non-Internet systems could be
considered "outside the standard". But RFC 2821 devotes many pages to
discussing this sort of thing.

> Skipping MX lookup is not acceptable as a general

I never implied that it was acceptable. In fact I'm fairly sure I said
the exact opposite.

> absence of any such knowledge.

Yep.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 03:03:07 -0400

> whithout any reduced functionality.

I don't see how requiring MX lookups for IPv6 mail relaying reduces 
functionality.  As far as I can tell, it increases functionality because 
it provides (as a side effect) an easy, low-overhead way to say "this 
domain doesn't accept mail" in an IPv6 world.  Just don't list any MX or 
A records for it.

I guess the case that isn't being given much attention is the one where 
you have an IPv6 address assigned to a host, and you have a domain name 
associated with that address, and you want that host to be able to 
receive mail - but you don't have write permission for the DNS RRs for 
that domain, so you can't create MX records for it.  But to me the 
solution to that is easy - get your own domain name.

(IMHO the idea that some other party besides the one that runs a host 
should be able to make assertions in DNS about that host's domain name 
has always been fairly broken - we have ended up with a tussle between 
DNS administrators and host owners/administrators as a result.)

Keith

---

From: SM <[email-masked]>
Date: Wed, 26 Mar 2008 00:10:38 -0700

>         stops working?  That is so broken.

SMTP will still work as the above case is covered by the implicit MX rule.

>one server, and my mail to go to a different server altogether.

The draft is not proposing that MX lookups should be disabled.

The definition of "Address records" was clarified in the draft to 
cover AAAA RRs.  The objection raised was about that.

In an IPv4-only world, the implicit MX rule is viewed as a useful 
feature by some.  Mail notifications (Cron, web server generated) 
sent from core3.example.com will be delivered if there is an A RR and 
no MX RR for core3.example.com.  In an IPv6-only world, the feature 
can be useful as well.

Some people mentioned that this is a legacy feature.  There are 
domains which are used to provide web services only.  These domains 
do not wish to receive mail.  To get around the implicit MX rule, they use:

  example.net   IN A   192.0.2.1
  example.net   IN MX 0 .

or else they point the MX to an invalid hostname:

  example.com   IN A   192.0.2.2
  example.com   IN MX 0 dev.null.

If the implicit MX rule is depreciated for IPv6, the above won't be needed.

The implicit MX rule creates an ambiguity during the transition from 
IPv4 to IPv6.  That's discussed in Section 5.2 of the draft:

   "The appropriate actions to be taken will either depend on local
    circumstances, such as performance of the relevant networks and any
    conversions that might be necessary, or will be obvious
    (e.g., an IPv6-only client need not attempt to look up
    A RRs or attempt to reach IPv4-only servers). Designers of
    SMTP implementations that might run in IPv6 or dual stack
    environments should study the procedures above, especially the
    comments about multihomed hosts, and, preferably, provide mechanisms
    to facilitate operational tuning and mail interoperability between
    IPv4 and IPv6 systems while considering local circumstances."
We could look at the question by asking whether the fallback MX 
behavior should be an operational decision.  But then we would be 
treating IPv4 and IPv6 differently.

Regards,
-sm

---

From: Bill Manning <[email-masked]>
Date: Wed, 26 Mar 2008 00:27:25 -0700

> SMTP will still work as the above case is covered by the implicit MX rule.

	presuming the existance of an MX...  (thats the "implicit"
	part of the "rule").

>     IPv4 and IPv6 systems while considering local circumstances."

	what this daft is trying to do is force the presumptive
	existance of an MX in a zone into an explict rule that 
	forces the existance of an MX, else SMTP fails.

> treating IPv4 and IPv6 differently.

	IPv4 and IPv6 are different.

--bill

-- 
--bill

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 03:33:05 -0400

> treating IPv4 and IPv6 differently.

IPv4 and IPv6 really are different, in a number of ways that affect both 
applications and operations.  e.g. Scoped addressing, the assumption 
that a network has multiple prefixes and a host has multiple addresses 
and that applications need to cope with this.  It should not be taken as 
an axiom that IPv4 and IPv6 should be treated the same.

Also, the Internet is very different now than the ARPAnet was when it 
adopted IPv4, and the IPv6 Internet will be different still.  In the 
early days of IPv4 nearly every host was a timesharing machine 
supporting several users, hosts were big and expensive and needed 
special maintenance, and so forth.  It was natural in that world to 
think in terms of "logging in" to a host, and it was natural in that 
world to think of a host in terms of supporting a user community that 
might want to exchange mail.

In today's PC world these assumptions are much less valid, and they are 
less valid still in an IPv6 world where it becomes feasible to assign an 
address to every device that might want to be monitored or controlled - 
every power meter, parking meter, traffic signal, street lamp, light 
switch, security camera, etc.  The last thing you want to assume in an 
IPv6 world is that every host is capable of receiving mail and doing 
something useful with it.   Nor do you want to burden DNS admins with 
setting up a dummy MX record for every IPv6 host. For that reason, in 
the IPv6 world, the default behavior when there's no MX record should be 
to assume that the host does not accept mail.

(of course, this begs the question of what to do about other services 
that don't have their own DNS records and don't use SRV.  But that's not 
a topic for rfc2821bis.)

Keith

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Mar 2008 18:57:44 +1100

>   example.net   IN A   192.0.2.1

	Which is not documented in any RFC despite being a good idea.

	It is easy to turn "MX 0 ." into "This domain doesn't support
	email" as "." is not confusable with a hostname.  There is no
	reason to look up addresses records for "."
 
>   example.com   IN MX 0 dev.null.

	Which could just be a misconfiguration.   You still have to
	look up addresses for "dev.null".

> If the implicit MX rule is depreciated for IPv6, the above won't be needed.

	It's still needed to prevent the A lookup.

---

From: SM <[email-masked]>
Date: Wed, 26 Mar 2008 01:09:23 -0700

>         forces the existance of an MX, else SMTP fails.

That's not what Section 5.1 (Locating the Target Host) of the draft says.

>         is what i am using today.

The above will work.  This is considered as a MX with a preference of 
0 pointing to mailhost.example.com.

Regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Mar 2008 04:41:42 -0400

> 	forces the existance of an MX, else SMTP fails.

While several people have suggested that, it is not what the
draft says and would be a significantly incompatible change.
What the draft basically says is that, if there is no MX record
present, one should go looking for the same domain name with an
address record type and, if such a thing is found, construe the
address record as if it were associated with an MX record with
preference of zero.

With one qualification, that has been the rule ever since RFC
974 was written.  That rule was reaffirmed in RFC 1123.  There
was no change to it in 2821.

At the time 974 and 1123 were written, the only sort of address
record in Class=IN was an A RR, and those documents used "A RR"
terminology.  The change in 2821bis essentially substituted the
phrase "address record" (or "address RR") for "A record" because
(i) that seemed to be consensus on the list at that time and
(ii) there is significant, although not universal, existing
practice that is consistent with treating IPv4 (A) and IPv6
(AAAA) RRs the same way, at least with regard to SMTP.

With that change to "address record", if no MX record is found,
the SMTP client is required to look for DNS names with either A
or AAAA RRs, rather than A RRs only.

As far as I can tell, the _only_ real question here is whether
that "either type of address record can be used as an implicit
mail destination if no MX record is present" rule, which is now
in the text, is the correct one.   If it is not, then the only
other option is to try to keep the implicit destination rule to
A (IPv4) records only, which would essentially require that an
MX record be present if one wanted to deliver mail to an IPv6
host.

The questions of whether MX records should be generally
required, what happens when an application chooses to ignore the
MUST NOT rule in Section 5.1 and use address records when an MX
record is present, and a number of other issues are, it seems to
me, very interesting but not relevant here... if only because
they would constitute very significant and incompatible changes
from 2821 and to the installed base.  There is, separately, some
language in Section 2.3.5 about the types of domain names that
can be used as FQDNs in mail sessions; I don't believe those
rules are affected by this discussion either.

>> We could look at the question by asking whether the fallback
>> MX  behavior should be an operational decision.  But then we
>> would be  treating IPv4 and IPv6 differently.
> 

Bill, I don't know what you are advocating any more.  It seems
to me that, by saying that you want to be able to run a mail
server without MX records and with IPv6 only (I think you said
that, but maybe I understood), you are asking for exactly the
behavior that is now in the specification, i.e., that either A
or AAAA RRs can be used to form an implicit MX.   For this
purpose, that makes IPv6 and IPv4-related DNS records pretty
much the same, no matter what the differences are between the
protocols.

In addition, the applications area has been told, repeatedly,
that its protocols should, by default, treat IPv6 like IPv4,
keeping any differences in treatment to a minimum.  So, saying
"IPv4 and IPv6 are different" at this stage, while true, does
not seem sufficiently explanatory to be a useful contribution to
the discussion.

     john

---

From: SM <[email-masked]>
Date: Wed, 26 Mar 2008 01:48:05 -0700

>         reason to look up addresses records for "."

There was an I-D, draft-delany-nullmx-00, which didn't make it to RFC status.

>         look up addresses for "dev.null".

Yes.  People still do it.

>         It's still needed to prevent the A lookup.

It would be needed until IPv6 takes over.

Regards,
-sm

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Mar 2008 10:52:41 +0200 (EET)

> As a private person using the "A record only" way of receiving mail, I

It might be helpful in this context if you could elaborate a bit why 
you find it useful?

The only reason I can think of is if (web?) UI of DNS hosting company 
would make it burdensome to update both MX and the A record.

As John Klensin wrote on Tue, 25 Mar 2008 23:40:12 -0400 
(<[email-masked]>), MX can refer to a name so for 
typical usage scenarios I can think of, just updating your A record 
would automatically update MX settings as well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Mar 2008 22:41:19 +1100

> There was an I-D, draft-delany-nullmx-00, which didn't make it to RFC status.

	I was aware which is why I said "RFC" not "document".
 
> >         look up addresses for "dev.null".

	Yes they do.  We, the IETF, have failed them by not providing
	them with a clear mechanism to do what they want without bad
	side effects.
 
> It would be needed until IPv6 takes over.

	It will be needed even *after* IPv6 takes over.  There will
	be lots of queries for A records long after the majority
	of hosts don't have A records.

	We need to remove the implict MX from A to prevent the A
	record lookups occuring as things currently stand.

	Mark

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 26 Mar 2008 13:15:23 +0100

> is what i am using today.

In that case adding an MX record pointing to mailhost
or not is perfectly irrelevant from an IPv4-only POV:  

IPv4-only users cannot reach your AAAA, therefore they
better reject mails claiming to be from [email-masked]
at their border for obvious reasons.

It also breaks the broken 1123 5.3.6(a) forwarding in
more pieces, if the forwarder accepts IPv6-only and
forwards it to IPv4-only, the receiver can't send DSNs
or ordinary replies.  Or if they can over another route
that is something an 1123 5.3.6(a) forwader can't know. 

Consider it as one-way spam if the mail with IPv6-only
addresses somehow makes it into IPv4-only land.  That
is broken, as you said, but unrelated to demanding an
MX record for IPv6 SMTPs.

Without a mandatory MX for your IPv6 SMTP if the mail
reaches IPvAnything land and folks want to reply or
send DSNs where required, they have to query for MX,
A, and AAAA to finally find your IPv6 SMTP.

For simple "if it can't receive it has no business to
send" checks at the border it is also three queries.
With a mandatory MX for IPv6 we simply reduce this.

All "v=spf1 -all" and obscure null-MX ideas could be
phased out if "no MX" means "cannot receive, must not
send".  We will never reach this ideal for IPv4, but
*NOW* is a chance to prepare it for the time when the
whole Internet is IPv6-only.  

 Frank

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 08:27:24 -0400

> at their border for obvious reasons.

uh, no.  IPv4-only hosts can see the AAAA record even if they can't 
directly send mail to that address.  and there's no reason ("obvious" or 
otherwise) why a MTA should reject mail from a host just because that 
MTA can't directly route to it - since there's nothing that requires a 
user to use the same MTA for outbound mail that is used to receive 
inbound mail.  (granted, lots of really really stupid things are done in 
the name of spam filtering that make no more sense than this, but 
they're not "obvious" - they're just stupid).

of course, as a practical matter, any domain for which mail eventually 
ends up in an IPv6-only world is going to need to have at least one MX 
pointing to a IPv4-capable host, until IPv6 becomes ubiquitous or very 
nearly so.  so the example above only makes sense in a world where IPv6 
is ubiquitous - or perhaps, where the owner of example.com wants to 
gauge the degree of IPv6 support for outgoing mail.

---

From: Bill Manning <[email-masked]>
Date: Wed, 26 Mar 2008 05:33:41 -0700

> at their border for obvious reasons.

	sounds like a great way to reduce the incoming 
	spam to me.

> MX record for IPv6 SMTPs.

	you mean mail w/ a name that only maps
	to IPv6 addresses is resolvable by names w/ only IPv4
	addresses.  What about the situation where
	mail emitted from a node with only IPv4 addresses
	is resolvable in the IPv6 world?  same "one-way" spam.

> A, and AAAA to finally find your IPv6 SMTP.

	or... they have to query AAAA, then A, then MX

> With a mandatory MX for IPv6 we simply reduce this.

	your arguing that because an SMTP agent implementation
	policy might be in place, that every one who runs
	DNS is now required (that "mandatory" thing) to 
	install an MX?

> whole Internet is IPv6-only.  

	placing an SMTP dependency in the DNS is 
	(imho) fundamentally wrong.  

	The trick here is that applicaiton designers in
	these modren times equate all DNS entries as being
	in the same address family.  Twas not always so and
	class IN to the contrary, IPv4 and IPv6 are pragmatically
	different address families.  Architecturally, the "right"
	thing to do would have been to create a new class for IPv6
	- just like the classes for Chaos and Hesiod.  Orthoginal
	namespaces would have made appications developers lives easier.

	Long and Lean - publication of data elements in the DNS does
	not now and never has equated to reachability for bit delivery.

--bill

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Mar 2008 09:17:58 -0400

> 	record lookups occuring as things currently stand.

Mark,

Whether that proposal is a good one or a bad one, it can't be
done in 2821bis because that is a document moving from Proposed
to Draft Standard and the implicit MX feature is _very_ widely
deployed and used.  So, IMO, this discussion is not directly
relevant to the (already closed) Last Call on 2821bis and should
probably be move to the ietf-smtp mailing list.

Second, no matter what is done with standardization, it will be
many, many years before one could count on those A RR lookups
not occurring -- too much software out that that is very rarely
updated.   The advantage of the "MX 0 ." approach over getting
rid of the implicit MX from A is that, if there were consensus
for it, it can be deployed in less than geological time.

But, either way, it seems to me that the correct (and only
feasible) actions start with an I-D that says something useful
and is discussed on, at least, the ietf-smtp list.

Just my opinion, of course.
   john

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 26 Mar 2008 14:17:22 +0100

Keith Moore wrote:
 
> IPv4-only hosts can see the AAAA record even if they can't 
> directly send mail to that address.  and there's no reason
> ("obvious" or otherwise) why a MTA should reject mail from
> a host just because that MTA can't directly route to it

What I wrote was "at their border", that is not any MTA on a
route from sender to receiver.  "At their border" is the hop
where receivers decide if they accept the mail, or reject it.

If they accept it, and later find they can't deliver it, and
it is not a case for /dev/null, they MUST report the problem:

| it MUST construct an "undeliverable mail" notification
| message and send it to the originator of the undeliverable
| mail (as indicated by the reverse-path).

For IPv4-only back to IPv6-only that cannot work, therefore
the IPv4-only border MTA is obliged to reject mails with an
IPv6-only envelope sender address.

> there's nothing that requires a user to use the same MTA
> for outbound mail that is used to receive inbound mail.

My definition of IPv4-only is that there is no other route.

The IPv4 border MTA needs to know if that is the case or not
for its decision to accept or reject IPv6-only envelope
sender addresses, because if all else fails it MUST [s.a.].
 
> granted, lots of really really stupid things are done in 
> the name of spam filtering that make no more sense than
> this, but they're not "obvious" - they're just stupid

The duty to send DSNs is not about "spam filtering", it is
about the reliability of SMTP.  Dropping all undeliverable
IPv6-only reverse-path mails in an IPv4-only MRN can affect
90% spam, but where it affects the remaining good mails it
would be bad.

> of course, as a practical matter, any domain for which
> mail eventually ends up in an IPv6-only world is going
> to need to have at least one MX pointing to a IPv4-capable
> host, until IPv6 becomes ubiquitous or very nearly so.

> so the example above only makes sense in a world where
> IPv6 is ubiquitous

Bill did not say that it is a hypothetical example for the
times when IPv6 is ubiquitous, I took it for a real example
today.  As a practical matter, I have no idea which of my 
providers if any is able to reach an IPv6-only example.com

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 26 Mar 2008 15:36:17 +0100

Bill Manning wrote:

> sounds like a great way to reduce the incoming spam to me.

Dunno, I normally want to know if a mail from me (really,
SPF PASS and all) did not make it, and for that purpose I
want the good bounces.  If legit undeliverable mail ends
up in black holes a.k.a. "spam filters" it can be a PITA. 

> What about the situation where mail emitted from a node
> with only IPv4 addresses is resolvable in the IPv6 world?
> same "one-way" spam.

Is that so ?  There is a way to map IPv4 to IPv6 addresses,
as far as SMTP is concerned you can at least try to report
errors.  If you are on an IPv6 island with no way to reach
the mapped addresses that won't help, but it is no protocol
design issue for SMTP.  

>> they have to query for MX, A, and AAAA to finally find
>> your IPv6 SMTP.
 
> or... they have to query AAAA, then A, then MX

No, MX comes always first, but you can of course swap AAAA
and A, or in an IPv4-only scenario skip AAAA if you anyway
can't use it.

Q=mx needs to be first for domains without SMTP.  It would
waste time and bandwidth to try to reach them when that is
not possible.  In more convoluted examples it could be very
wrong to send mails to an existing SMTP at the domain, if 
the MX doesn't offer to do this.  That is no new 2821bis
idea, that is as it always was since god posted STD 10 :-)
 
> policy might be in place, that every one who runs DNS
> is now required (that "mandatory" thing) to install an MX?

I hope we are talking about SMTP over TCP in the Internet.
If we do, senders must somehow find an SMTP at a public IP
for the destination mail addresses.  For a domain literal
that's directly the IP and you don't need DNS.  In normal
cases with a FQDN you need DNS anyway, to get the IP "by
name". 

The standards since STD 10 require to try MX first to get
a list of names and priorities, see above.  And yes, the
proposal for IPv6 is to make MX mandatory, as Keith said
there will be a huge number of AAAA devices, and it would
be a huge waste of time to time to try AAAA after MX for
devices which never send or receive mail, e.g., a forged
mail from webcam.  Adding SPF "v=spf -all" everywhere is
no alternative.  Besides SPF is voluntary, not mandatory.

Null-MX idea is another variant of "opt out" everywhere,
also not attractive, why should all IPv6 devices with AAAA
but no SMTP get null-MX records ?

A realistic idea is "opt in" with an explicit MX.  In your
example you can still send from any AAAA you like, as long
as the addresses use domains with an MX.  Or with the old
"implicit MX" A-fallback.  But please no new AAAA-fallback.

> placing an SMTP dependency in the DNS is (imho) 
> fundamentally wrong.  

AFAIK the MX-concept is *THE* fundamental idea in STD 10, 
later STD 3 eliminated the "source route" alternative(s).

> IPv4 and IPv6 are pragmatically different address families.
> Architecturally, the "right" thing to do would have been
> to create a new class for IPv6

That's something I can't judge, I stay out of all flamewars
about IPv6 and NATs here.  But I know that Internet Drafts
ignoring IPv6 are DoA, worse than forgetting security and
privacy and IANA and I18N considerations... :-)

With the situation as it is, and with respect to SMTP, the
MX records can include an IPvAnything MTA for an otherwise
IPvX-only domain.  MX was always a good at such tasks, e.g.,
UUCP-domains with no IP at all.

> Long and Lean - publication of data elements in the DNS
> does not now and never has equated to reachability for
> bit delivery.

Okay, but 2821bis doesn't discuss SMTP over FidoNet or what
else, it considers DNS with addresses and MX as given.  If
you want a note in 2821bis that this is actually limited to
the IN class and not about Chaos etc. maybe John can do (?)

 Frank

---

From: Tony Hansen <[email-masked]>
Date: Wed, 26 Mar 2008 10:46:37 -0400

As the shepherd/pseudo-chair for 2821bis effort, our plan of action is 
going to be as follows:

   *)	the implicit MX issue needs to be resolved.
   *)	there are a few other small items that need to be resolved that
	will be detailed on the [email-masked] list

We'll give the discussion about one more week and then make a consensus 
decision. So speak up now.

	Tony Hansen
	[email-masked]

---

From: John Levine <[email-masked]>
Date: 26 Mar 2008 15:01:39 -0000

>> a host just because that MTA can't directly route to it

Well, other than the practical fact that it's almost certainly spam.

Not to be cynical or anything, but regardless of what we decree, I
think it's vanishingly unlikely that many systems on the public
Internet* will accept mail from a domain with only an AAAA record.
When I consider the theory that there will be interesting numbers of
mail systems that do all the stuff they need to do to upgrade from v4
to v6, but that their DNS will be hosed in a way that lets them add
AAAA records but not MX records, I'm sorry, but that doesn't pass the
smell test.

At the current stage of 2821bis I agree that the best we can do is
to preserve the existing ambiguous language, but down the road we
will either have to align with reality or take a courageous stand
against it.  I know which I'd do.

R's,
John

* - that's public Internet, not to be confused with all of the local
routing hacks we have within our own networks

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Mar 2008 12:20:31 -0400

--On Wednesday, 26 March, 2008 10:52 +0200 Pekka Savola
<[email-masked]> wrote:

>> As a private person using the "A record only" way of
>> receiving mail, I find it useful.
> 
> It might be helpful in this context if you could elaborate a
> bit why  you find it useful?
> 
> The only reason I can think of is if (web?) UI of DNS hosting
> company  would make it burdensome to update both MX and the A
> record.

Even that is unlikely since, if the same mail server is used for
IPv4 and IPv6 transport, the MX would not change ... one would
merely need to add an AAAA RR for the same host to the
presumably-existing A RR.   A hosting provider who would not let
one do that is, almost by definition, not providing IPv6
support, which is not an SMPT problem.

   john

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Mar 2008 17:09:56 +0000

On Wed, 26 Mar 2008, John C Klensin wrote:
>
> At the time 974 and 1123 were written, the only sort of address record
> in Class=IN was an A RR, and those documents used "A RR" terminology.
> The change in 2821bis essentially substituted the phrase "address
> record" (or "address RR") for "A record" because (i) that seemed to be
> consensus on the list at that time and (ii) there is significant,
> although not universal, existing practice that is consistent with
> treating IPv4 (A) and IPv6 (AAAA) RRs the same way, at least with regard
> to SMTP.
>
> With that change to "address record", if no MX record is found, the SMTP
> client is required to look for DNS names with either A or AAAA RRs,
> rather than A RRs only.

There's also RFC 3974 (Jan 2005, informational) which recommends treating
AAAA like A. The most popular MTAs implement this logic.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER: VARIABLE 3, BECOMING SOUTHERLY 4 OR 5. MODERATE. OCCASIONAL RAIN.
MODERATE OR GOOD.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 13:45:49 -0400

> it is not a case for /dev/null, they MUST report the problem:

you're assuming lots of conditions there that don't apply in the general 
case... e.g. single-hop internal routing for inbound mail and yet the 
MTA can't detect that the mail is nondeliverable until after it has 
accepted it, and no designated relay to the IPv4 world for outbound 
mail.  the former is occasionally true, the latter would be insane.  one 
way to look at it is that the border for inbound mail may be different 
than the border for outbound mail.

> IPv6-only envelope sender address.

often, the inbound MTA for a domain lacks reliable knowledge of whether 
either the sender or recipient address is actually valid.  it appears 
that you would have the inbound MTA drop mail based on a very dubious 
presumption.  you would rather cause additional delivery failures of 
subject messages than to risk the failure of nondelivery reports.  most 
operators, I think, would have the opposite preference.  and regardless 
of what 2821 says, I don't think your reading of it is justified.

> My definition of IPv4-only is that there is no other route.

that's a pretty useless definition because the case would not exist in 
practice until IPv6 were ubiquitous.  there's always the possibility for 
an IPv6-only domain to contract with an MTA sited on both v4 and v6 to 
relay outgoing mail.  it would be insane for an IPv6-only domain that 
wanted to send and receive mail to not have such an arrangement.

> sender addresses, because if all else fails it MUST [s.a.].

if we were to take your presumption to its logical conclusion, every 
inbound MTA should just reject all mail - since it can never be 100% 
certain of being able to either deliver the message or send an NDN.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 13:50:16 -0400

> Internet* will accept mail from a domain with only an AAAA record.

I think it's vanishing unlikely that email will be useful at all, if 
spam filter writers keep trashing mail based on such dubious criteria.

Keith

---

From: John Levine <[email-masked]>
Date: Wed, 26 Mar 2008 14:50:39 -0400 (EDT)

> I think it's vanishing unlikely that email will be useful at all, if spam 
> filter writers keep trashing mail based on such dubious criteria.

Not to reignite the usual spam argument, but it is (unfortunately in this 
case) not 1988 or even 1998 any more.  When upwards of 90% of all mail is 
spam, keeping mail usable is at least as dependent on limiting the spam 
that shows up in people's mailboxes as delivering the trickle of good 
mail.

Real life spam filters use metrics and tune to the actual behavior of 
mailers.  If most of the mail that comes from domains with AAAA and no MX 
is spam, they'll tune for that, and it won't be a mistake.  For the 
forseeable future, most such mail will be from zombies, and it'll all be 
spam.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Mar 2008 20:05:54 +0100

John Levine wrote:
> When upwards of 90% of all mail is 

And to add to what John is saying, given that horrific statistic and 
that mail is still usable for a whole lot of people I think we should 
have cause to be optimistic.  After all, just how much worse can it get?

And no, that's not a challenge.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2008 12:14:17 -0700

John Levine wrote:
> spam

This document is not the place to fight spam. If you want a BCP to deprecate
the fall-back, then write one. Until all the implementations remove
fall-back to A, the correct behavior is to also fall-back to AAAA. People
(particularly the apps dev & support communities) are having a hard enough
time getting their heads around even thinking about IPv6 that making your
proposed procedural change is insane. Whatever reasons people have for not
implementing MX will not change just because they are deploying IPv6. 

The current text is just fine the way it is.

Tony

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 15:20:29 -0400

John Levine wrote:

> Not to reignite the usual spam argument, but it is (unfortunately in 
> this case) not 1988 or even 1998 any more.  When upwards of 90% of all 
> mail is spam, keeping mail usable is at least as dependent on limiting 
> the spam that shows up in people's mailboxes as delivering the trickle 
> of good mail.

deleting mail based on bogus criteria is not keeping mail usable.  it's 
killing it.

> mailers.  If most of the mail that comes from domains with AAAA and no 
> MX is spam, they'll tune for that, and it won't be a mistake.

yes it will.  partially because the behavior of one domain is generally 
independent of that of another, partially because the volume of mail 
produced by such domains is largely independent of the behavior of any 
single domain, and partially because spammers (being a smaller 
population) will adapt more quickly to avoid getting trapped by this 
shortsighted hack.

> For the forseeable future, most such mail will be from zombies, and it'll all be 
> spam.

maybe the zombies are the ones who are using statistics inappropriately 
to decide how to filter mail.

people need to stop defending such stupidity.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 15:28:23 -0400

> The current text is just fine the way it is.

I disagree.  There are several good reasons for senders not falling back 
to AAAA lookup.  I just don't happen to think that spam filtering is one 
of them.

Keith

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 26 Mar 2008 20:53:17 +0100

Keith Moore wrote:
 
> you're assuming lots of conditions there that don't apply
> in the general case...

The cases involving MX queries are not unusual, a good part
of 2821bis explains how this works.  MTAs know if they are
an inbound "border MTA" or not depending on the client.

> e.g. single-hop internal routing for inbound mail and yet
> the MTA can't detect that the mail is nondeliverable until
> after it has accepted it

If it has no SPF PASS or a similar indication that sending
an NDR "to the originator of the undeliverable mail (as
indicated by the reverse-path)" should work it is forced to
violate a MUST in 2821 or 2821bis.  NDRs are not OPTIONAL.

> one way to look at it is that the border for inbound mail
> may be different than the border for outbound mail.

Most likely it is, but the admins are supposed to know what
their outbound MTAs can do.  If they can't send NDRs to XXX
they better don't accept mail from XXX, otherwise they run
into problems with the MUST.

It would also affect users starting an RFC 3834 mailbot, the
envelope sender address is supposed to work for auto-replies.
And when it works this should be the originator, but 2821bis
does not try to solve that closely related problem.

Similar for all other RFCs using the envelope sender address, 
DSNs, MDNs, etc. (I'm not up to date with Lemonade and Sieve,
but e.g. the Sieve vacation I-D or RFC is based on RFC 3834)

> often, the inbound MTA for a domain lacks reliable knowledge
> of whether either the sender or recipient address is actually
> valid.  it appears that you would have the inbound MTA drop
> mail based on a very dubious presumption.

NAK, I think it should REJECT mail if it has no clue what to
do with it if all else fails.  Your proposal, accept and pray,
could result in dropped mails silently vanishing in /dev/null,
or what is known as "misdirected bounces".

> you would rather cause additional delivery failures of subject
> messages than to risk the failure of nondelivery reports.

For legit mail rejected at the border the sender then at least
knows that the mail bounced, and "can make another plan", as
EAI nicely put it.  Dropped legit mail "accepted on probation"
are a black hole from the sender's POV, that's bad.

For what we are discussing here we can ignore all details of
misdirected vs. good bounces, the assumption was that an IPv4
MRN cannot reach the IPv6 MON.  Even an SPF PASS cannot help
in this case, it is an IP problem "below" SMTP.

> most operators, I think, would have the opposite preference.

Operators still thinking that "accept on probation" is a good
strategy somehow missed Y2K and that 90% of mails are spam.
Or they always considered NDRs as OPTIONAL, but then they are
not reading RFC 2821 or 2821bis.

> regardless of what 2821 says, I don't think your reading of
> it is justified.

Well, I don't think NDRs are OPTIONAL, and I want to get NDRs
if legit mail from me does not make it.  If that's unjustified
what is ?  Publishing 2821bis as experimental is no option :-)

> that's a pretty useless definition because the case would
> not exist in practice until IPv6 were ubiquitous.

Bill's IPv6-only AAAA example.com triggered the discussion, he
expressly wanted no MX, there is no IPv4 MTA accepting NDRs or
other replies to [email-masked] address.  

> there's always the possibility for an IPv6-only domain to
> contract with an MTA sited on both v4 and v6 to relay 
> outgoing mail.  it would be insane for an IPv6-only domain
> that wanted to send and receive mail to not have such an
> arrangement.

Insane or not, it's what Bill wanted.  Likewise IPv4 receivers
could try to add IPv6 to their network, but the interesting
scenario is where that's not the case.  

> if we were to take your presumption to its logical conclusion,
> every inbound MTA should just reject all mail - since it can
> never be 100% certain of being able to either deliver the 
> message or send an NDN.

It needs to be confident that it can do what the MUST in 2821bis
says.  100% certain is too harsh, but 2821bis has clear ideas
about "frivolous":

| it is accepting responsibility for delivering or relaying the
| message.  It must take this responsibility seriously.  It
| MUST NOT lose the message for frivolous reasons, such as
| because the host later crashes or because of a predictable
| resource shortage.

Or because IPv4-only to IPv6-only cannot work to report errors.

 Frank

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Mar 2008 13:53:55 -0700

Tony Hain wrote:
> This document is not the place to fight spam.

right.

>  Until all the implementations remove

I keep trying to understand why the SMTP use of AAAA records should be any 
different than its use of A records.  Haven't heard a solid explanation, 
nevermind seen consensus forming around it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 16:55:53 -0400

> violate a MUST in 2821 or 2821bis.  NDRs are not OPTIONAL.

nobody is expected to pay any attention to SPF as a matter of compliance 
with 2821.  SPF is pretty much a joke.

> into problems with the MUST.

yes, but "can't send NDRs to XXX" is not the same thing as only having 
an IPv6 path.  because any sane mail admin will know that having a way 
to deliver mail via IPv4 (and for that matter, to accept mail via IPv4) 
is a practical necessity.

> or what is known as "misdirected bounces".

yes, it could.  but the particular case you are arguing is specious.

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Mar 2008 16:59:11 -0400

> nevermind seen consensus forming around it.

because conditions are different now than it was when RFC 974 was 
written, and the case that compelled fallback to A in RFC 974 does not 
significantly exist for AAAA.

I keep trying to understand why people keep expecting IPv4 to operate 
exactly the same as IPv6 without bothering to consider the differences 
between them.  (Or maybe I just answered my own question?)

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Mar 2008 14:26:01 -0700

I don't undestand the reasoning here.
 
My understanding is that we implicitly deprecated receivers relying on fallback to A in 2821. Section 5 makes it clear that you look for MX first and that MX takes priority.
 
It is thus not compliant to look at AAAA records today and I see no reason to change this in the future. Instead any 2821Bis should do the job of a bis and deprecate reliance on A fallback, but not support for it. suggesting that people write a BCP to deprecate a protocol feature instead of a bis seems backwards to me.

Mail is a service lookup, not a host name lookup. Support for use of fallback to IPv4 host name lookup is a historical accident due to the fact that the distinction was not understood at the time. We do not require IPv6 host name fallback, IPv6 host name fallback has a significant cost that will have immediate impact on every mail service lookup that is compliant.

IPv6 should use the service resolution lookup. 
 
We should prohibit fallback to AAAA outright and deprecate configurations that rely on A.

________________________________

From: [email-masked] on behalf of Tony Hain
Sent: Wed 26/03/2008 3:14 PM
To: [email-masked]
Subject: RE: Last Call: draft-klensin-rfc2821bis

John Levine wrote:
> this
> MX

Tony

---

From: Willie Gillespie <[email-masked]>
Date: Wed, 26 Mar 2008 15:35:43 -0600

Keith Moore wrote:
<snipped>
> significantly exist for AAAA.

I agree with Keith here.

The published RFC 2821 states in section 5:
  "... The lookup first attempts to locate an MX
   record associated with the name.  ...   If
   no MX records are found, but an A RR is found, the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host.  If one or more MX RRs are found for a given
   name, SMTP systems MUST NOT utilize any A RRs associated with that
   name unless they are located using the MX RRs; the "implicit MX" rule
   above applies only if there are no MX records present."

There's too much running code to change that now.  However, that doesn't
mean we have to subject AAAA only hosts to the same treatment.  See
Keith's previous post referencing "every power meter, parking meter,
traffic signal" to really understand why this wouldn't be a good idea.
For this reason, I don't agree with section 5 of
draft-klensin-rfc2821bis-09.txt.

For those purists who don't want *any* lookups beyond the MX: sorry, but
we have to be backwards compatible here.  When trying to deliver mail,
we should do an MX lookup.  If there are no MX RRs, we still need to
lookup the A record using "implicit MX" rule to stay backwards
compatible.  That doesn't mean you need to lookup AAAA records, though.

The only real argument I've heard for using AAAA records as implicit MX
RRs is to try and keep IPv4 like IPv6 as far as a few lines of code go
for the application side of things.

Just my thoughts,
Willie

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 26 Mar 2008 14:42:20 -0700

It is pretty clear here that we are talking about a configuration that is actually specfically prohibited by 2821.
 
If you are doing SMTP and claiming to be 2821 compliant you must lookup the MX and you must not look at the A if there is no MX there. Any sender that is breaking those rules is not compliant with the spec.
 
Spam is relevant in this regard to the extent that when you have a protocol that is under such a level of sustained attack, it is entirely justified for receivers to employ strict compliance with the standard as an acceptance criteria. If you are not 2821 compliant then no soup for you.

I see no reason at all to extend support for non-compliant systems to the IPv6 world. On the contrary, it seems to me that this transition is exactly the point at which you would want to say that the host name fallback support is terminated.
 
The argument would become even stronger if it turned out that email comming over IPv6 transports could be more easily distinguished from spam than over other transports. This might even be turned into an incentive for making the IPv6 transition.
 
What I am thinking here is that we stand a better chance of authenticating IPv6 address block allocations and thus eliminating bogons. Residential support for IPv6 is non-existent today. We have a good chance of getting some BCP type agreements out of the likes of MAAWG that could limit botnet and spambot potential there.
 
Lets make IPv6 as clean as possible, leave host name A record fallback to the legacy world.

From: [email-masked] on behalf of Ned Freed
Sent: Wed 26/03/2008 2:48 AM
To: Keith Moore
Cc: John C Klensin; Frank Ellermann; Ned Freed; [email-masked]; Bill Manning
Subject: Re: Last Call: draft-klensin-rfc2821bis

Yep.

                                Ned

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 26 Mar 2008 23:17:42 +0100

Keith Moore wrote:
 
> nobody is expected to pay any attention to SPF as a matter
> of compliance with 2821.  SPF is pretty much a joke.

Then let's move RFC 3834 and a bunch of draft standards to 
"historic" because they rely on an envelope sender address
indicating the originator.

SPF PASS guarantees that a bounce to an alleged envelope
sender address cannot hit an innocent bystander.  SPF FAIL
guarantees that the alleged sender is not the originator.
In both cases if it is not correct it's the problem of the
sender to fix it, nobody is forced to publish policies.

And receivers are not forced to check SPF if they possess
a good crystal ball to distinguish a forged envelope sender
address from a good reverse path.  

But if their crystal ball degenerates into "90% of mail is
spam, most spam uses forged envelope sender addresses, and
therefore sending DSNs makes no sense" it cannot work, SMTP,
RFC 3834, MDNs, reduced to "maybe the mail made it or not,
to find out use jabber or the phone".  That is broken.

>> If they can't send NDRs to XXX they better don't accept
>> mail from XXX, otherwise they run into problems with the
>> MUST.
 
> yes, but "can't send NDRs to XXX" is not the same thing as
> only having an IPv6 path.  because any sane mail admin will
> know that having a way to deliver mail via IPv4 (and for
> that matter, to accept mail via IPv4) is a practical
> necessity.

A hopefully sane poster on this list insisted on having an
AAAA SMTP without MX.  And while you might think that over
a million SPF FAIL domains including ietf.org are a joke, one
SPF supporter here can't tell if he could reach Bill's IPv6
SMTP on any available route.  I hope Gmail or GMX can reach
his IPv6 SMTP, directly my box can't.  BTW, GMX is one of the
SPF FAIL jokes, GMail limits itself to SPF PASS, I can't tell
which is the bigger email provider in Germany.

 Frank

---

From: Jim Fenton <[email-masked]>
Date: Wed, 26 Mar 2008 15:35:32 -0700

> nevermind seen consensus forming around it.

It seems there are two ways of looking at this:

(1) AAAA records in the IPv6 world should do exactly same things as A 
records in the IPv4 world, so SMTP should look for an AAAA record in the 
absence of an MX record, just as A records are used in the absence of MX 
records.

(2) Although some SMTP servers will continue to be found through A 
records for legacy reasons, there is no longer a good reason for any new 
server not to have a published MX record.  SMTP clients (senders) will, 
of course, need to continue to look up A records, but since there is 
currently no significant use of AAAA records for email routing, we 
should not perpetuate this legacy in IPv6 as it is in IPv4.

These are both reasonable positions, but I'm in camp (2).  The 
additional use of AAAA records for email address resolution would add 
complexity to at least some implementations and test cases, and it 
something that should never be needed:  v6 mail handlers will just 
publish MX records.  There is probably a small DNS efficiency argument 
as well, especially if the MX, A, and AAAA requests are not made together.

I wish that 2821bis made a stronger statement deprecating the use of A 
records for email address resolution, but it seems not to have been the 
consensus to do so.  Writing a separate BCP on this point is not a good 
use of anyone's time.

-Jim

---

From: David Conrad <[email-masked]>
Date: Wed, 26 Mar 2008 15:53:37 -0700

Hi,

On Mar 26, 2008, at 3:35 PM, Jim Fenton wrote:
> records in the IPv4 world,
...

I don't really have a strong opinion on the whether or not AAAAs  
should be used for email address resolution. However, it might be  
worthwhile to point out that since IPv6 has no significant benefit to  
the vast majority of users to drive acceptance, I suspect that from a  
network administrator's point of view, every time IPv6 is not treated  
the same way IPv4 is, you are adding an impediment to IPv6 deployment.

Regards,
-drc

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 26 Mar 2008 15:59:23 -0700

Your arguments make no sense. Any service that has an MX creates absolutely
no cost, and the fallback to AAAA only makes one last attempt to deliver the
mail before giving up. Trying to force the recipient MTA to publish an MX to
avoid delivery failure on the sending MTA is useless, and in no way belongs
in a standard document. MX records are an operational optimization, nothing
more. The function of mail delivery is between IPv4/IPv6 endpoints, and how
those endpoints find each other is orthogonal to the actual service of mail
delivery. Having the document state a prioritization between 2 of the
possible methods is pushing the edge already, but worth allowing because
there should be consistent interpretation between domains that don't have a
prior agreement. 

You should also stop trying to rewrite history by claiming that something
was 'not understood at the time'. While you may wish things were more
tightly enforced, pragmatics will always win out, which also means that no
matter what the IETF says people will do whatever it takes to deliver the
mail. If you don't want mail delivered to any machine except those with an
MX, then don't listen on the port for all the others. 

This actually begs the question, how would publication or not of an MX have
any impact on a spam-bot network? It is not like the service provider mail
servers are trying to look up bot members to send spam to. If the service
provider mail servers are doing MX lookups as some sort of verification
step, it is trivial for a spammer to create a bunch of MX records to bypass
that lame effort. 

Tony

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hallam-Baker, Phillip
Sent: Wednesday, March 26, 2008 2:26 PM
To: [email-masked]; [email-masked]
Subject: RE: Last Call: draft-klensin-rfc2821bis

My understanding is that we implicitly deprecated receivers relying on
fallback to A in 2821. Section 5 makes it clear that you look for MX first
and that MX takes priority.
 
It is thus not compliant to look at AAAA records today and I see no reason
to change this in the future. Instead any 2821Bis should do the job of a bis
and deprecate reliance on A fallback, but not support for it. suggesting
that people write a BCP to deprecate a protocol feature instead of a bis
seems backwards to me.

Mail is a service lookup, not a host name lookup. Support for use of
fallback to IPv4 host name lookup is a historical accident due to the fact
that the distinction was not understood at the time. We do not require IPv6
host name fallback, IPv6 host name fallback has a significant cost that will
have immediate impact on every mail service lookup that is compliant.

We should prohibit fallback to AAAA outright and deprecate configurations
that rely on A.

________________________________________
From: [email-masked] on behalf of Tony Hain
Sent: Wed 26/03/2008 3:14 PM
To: [email-masked]
Subject: RE: Last Call: draft-klensin-rfc2821bis

Tony

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Mar 2008 16:32:03 -0700

Jim Fenton wrote:
> server not to have a published MX record.

Then they won't.

And we don't need to alter algorithms that have been in operation for more than 
20 years and working well.

Really, it does not make sense to impose changes based on hopeful thinking 
rather than compelling need.

   SMTP clients (senders) will,
> should not perpetuate this legacy in IPv6 as it is in IPv4.

Please document the problems caused by this legacy, since serious problems are 
what ought to dictate changing an installed service.

The added 'complexity' has worked well enough for 20 years, so it's a bit 
difficult to assert it as significant now.

Make AAAA records get the same handling as A and you've made the smallest 
possible change to Internet email's transport service.  Start messing around 
with the role of the address record, and you are altering the service at a more 
basic architectural level.  Absent compelling need, that's usually a poor idea.

d/
-- 

   Dave Crocker

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 27 Mar 2008 01:10:09 +0100

Tony Hain wrote:

> You should also stop trying to rewrite history by claiming
> that something was 'not understood at the time'.

That got me to speed read a few RFCs, 805, 819, 882, 883, 973,
and in 974 I finally found what I wanted:

| It is possible that the list of MXs in the response to the
| query will be empty.  This is a special case.  If the list
| is empty, mailers should treat it as if it contained one RR,
| an MX RR with a preference value of 0, and a host name of
| REMOTE.  (I.e., REMOTE is its only MX).  In addition, the
| mailer should do no further processing on the list, but
| should attempt to deliver the message to REMOTE.  The idea
| here is that if a domain fails to advertise any information
| about a particular name we will give it the benefit of the
| doubt and attempt delivery.

"special case", "fails to advertise", "benefit of the doubt",
that does not sound like "we still want this 22 years later
also for IPv6".

Earlier MAILA, MAILB, MF, MD, MINFO, MG, etc. proposals were
rather confusing compared with MX, but apparently did not 
suggest to try A (?)  They just started to use a hierarchical
DNS at this time, and replacing relative names in bang paths
by absolute names was apparently one of the DNS design goals.

 Frank

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Mar 2008 02:20:32 -0400

Tony Hain wrote:
> Your arguments make no sense. Any service that has an MX creates
> absolutely no cost, and the fallback to AAAA only makes one last
> attempt to deliver the mail before giving up. Trying to force the
> recipient MTA to publish an MX to avoid delivery failure on the
> sending MTA is useless, and in no way belongs in a standard document.
> MX records are an operational optimization, nothing more.

that's completely incorrect.

what MX records mean is that a domain name used on the right hand side
of an email address need have nothing at all to do with any host or
other service that has the same domain name.  in particular the servers
and resources associated with that email address don't have to share the
same host, network, addresses, user community, administration, or
anything else.  (except that the administration of the DNS zone and RRs
associated with that domain is the same for both)

in short, MX records decouple mail domain names from host names.  and
this turns out to be a very useful thing to do.  e.g.

1. a domain used for mail that doesn't correspond to any actual host

2. a host that doesn't want to source or receive mail

3. when it is desirable to associate email and other services with the
same domain name, and yet not have all of those services hosted on the
same cpu or at the same address.

for instance, the email for network-heretics.com and the web server for
the same domain are hosted by entirely different companies on different
networks -- because I couldn't find a hosting company that did an
adequate job of both at a reasonable price.  and yet it's very useful to
have them both associated with the same domain name.

> The function of mail delivery is between IPv4/IPv6 endpoints, and how
> those endpoints find each other is orthogonal to the actual service
> of mail delivery. Having the document state a prioritization between
> 2 of the possible methods is pushing the edge already

that's an incorrect way to characterize what is going on, because an A
record is only a valid destination for mail to a particular domain if no
MX records exist.  if even a single MX record exists, it's incorrect to
route the mail based on an A record, even if an attempt to relay the
mail via the listed MX resulted in a temporary error.

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 27 Mar 2008 08:51:15 -0700

You are completely incorrect in describing MX records as no more than an optimization. The MX record defines the mail SERVICE. An A or AAAA record defines a HOST.
 
Nor am I rewriting history here, the early RFCs that describe the emergence of the mail service and the DNS make it very clear that the operational needs of email were not fully understood at the start of the process. That is why it was called research.
 
The MX record was very clearly introduced in recognition of the fact that deployment of the DNS made possible better options than had been possible with the hosts file.

And begging the question is a logical fallacy in which the conclusion is assumed in the premise, petition principii.

From: Tony Hain [mailto:[email-masked]]
Sent: Wed 26/03/2008 6:59 PM
To: Hallam-Baker, Phillip; [email-masked]
Subject: RE: Last Call: draft-klensin-rfc2821bis

Tony

 

 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 27 Mar 2008 09:05:13 -0700

> have them both associated with the same domain name.

That is all well and good, but it is completely of value to the receiving
MTA, and under their complete control. There is nothing that requires a
receiving MTA to follow this model, despite what others may see as value.
Defining the facility is what the standards need to do. Dictating
operational practice without cause is what a standard needs to avoid doing. 

> mail via the listed MX resulted in a temporary error.

I agree that if an MX exists, the operator of the receiving MTA has stated
its expectations, and the sending MTA needs to oblige. That is not the same
as mandating that every organization has to follow the same model. If there
were some serious technical consequence for lack of the MX record I would be
all for specifying its use. Operational practice with A records shows that
there is no real issue, and that anything that does come up is under the
control of the impacted party with a clear mechanism to resolve it. 

Again, the text is fine as it is.

Tony

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 27 Mar 2008 12:31:50 -0700

The key issue here is whether people who rely on AAAA are likely to
achieve their desired result. Today it does not matter because anyone
who relies on AAAA alone with no A fallback is going to receive almost
no mail.

That in turn is going to depend on whether software implementations are
written to fall back to A record lookup or host name lookup. Before AAAA
they were the same thing.

One software architecture would be to interpret RFC 2821 litterally and
only do A record fallback. I suspect that most people would implement
this by directing to their hostname lookup module which in an IPv6 stack
is going to be A/AAAA agile. So in that case the AAAA fallback is going
to come for free.

Coupled with the fact that DNS servers are probably going to be
configured to push AAAA records with an A record lookup by default in an
IPv6 world I suspect that there is not going to be a problem.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tony Hain
> Sent: Thursday, March 27, 2008 9:05 AM
> To: 'Keith Moore'
> Cc: [email-masked]
> > other service that has the same domain name.  in particular the 
> > servers and resources associated with that email address 
> don't have to 
> > share the same host, network, addresses, user community, 
> > administration, or anything else.  (except that the 
> administration of 
> > the DNS zone and RRs associated with that domain is the 
> same for both)
> > 
> > for instance, the email for network-heretics.com and the web server 
> > for the same domain are hosted by entirely different companies on 
> > different networks -- because I couldn't find a hosting 
> company that 
> > did an adequate job of both at a reasonable price.  and yet 
> it's very 
> > useful to have them both associated with the same domain name.
> 
> That is all well and good, but it is completely of value to 
> the receiving MTA, and under their complete control. There is 
> nothing that requires a receiving MTA to follow this model, 
> despite what others may see as value.
> Defining the facility is what the standards need to do. 
> Dictating operational practice without cause is what a 
> standard needs to avoid doing. 
> 
> > 
> > > The function of mail delivery is between IPv4/IPv6 endpoints, and 
> > > how those endpoints find each other is orthogonal to the actual 
> > > service of mail delivery. Having the document state a 
> prioritization 
> > > between
> > record is only a valid destination for mail to a particular 
> domain if 
> > no MX records exist.  if even a single MX record exists, it's 
> > incorrect to route the mail based on an A record, even if 
> an attempt 
> > to relay the mail via the listed MX resulted in a temporary error.
> > 
> 
> I agree that if an MX exists, the operator of the receiving 
> MTA has stated its expectations, and the sending MTA needs to 
> oblige. That is not the same as mandating that every 
> organization has to follow the same model. If there were some 
> serious technical consequence for lack of the MX record I 
> would be all for specifying its use. Operational practice 
> with A records shows that there is no real issue, and that 
> anything that does come up is under the control of the 
> impacted party with a clear mechanism to resolve it. 
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Mar 2008 15:51:31 -0400

--On Thursday, 27 March, 2008 12:31 -0700 "Hallam-Baker,
Phillip" <[email-masked]> wrote:

> The key issue here is whether people who rely on AAAA are
> likely to achieve their desired result. Today it does not
> matter because anyone who relies on AAAA alone with no A
> fallback is going to receive almost no mail.

Phillip,

This is true iff you believe that there are too few IPv6-enabled
mail senders to transmit such mail.  It ultimately has nothing
to do with whether there are MX records present, since having an
explicit MX record that pointed to a mail exchanger host that
only had a AAAA record would leave the sender in exactly the
same situation -- deliver over IPv6 or don't deliver at all.
That parallelism moves the discussion entirely out of the scope
of whether the text in rfc2821bis is correct or not.

More important, I suspect that belief is false.   Installations
who run IPv6-only generally know their correspondents.  The
correspondent would presumably need to be running dual-stack, or
have a submission server or equivalent that is running
dual-stack (or IPv6 only as well), but, in many parts of the
world, those are not rare.

A statement I believe would be true is that a mail server that
only supported incoming connections over IPv6 would receive
almost no spam, at least until IPv6 becomes much more popular.
But, the last I heard, that would usually be considered an
advantage.

   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Mar 2008 17:50:55 -0400

--On Thursday, 27 March, 2008 09:00 +0200 Matti Aarnio
<[email-masked]> wrote:

> 
> On Wed, Mar 26, 2008 at 10:46:37AM -0400, Tony Hansen wrote:
> There will be lots of legacy codes using legacy APIs for long
> future. I do use  getaddrinfo()  API myself, and permit it do
> all queries to get addresses.  Thus it will also query for A
> in addition to AAAA. It can even be ordered to ignore IPv4 or
> IPv6 as sysadmin wants.
> 
> For the future the previous "query for A record" should
> possibly be altered to "query for network address (IPv6 AAAA
> and/or IPv4 A)" or some such generic wording.

That is approximately what it says (in 2821bis) now.  It was
saying that which touched off the thread of which this one is a
descendant.

   john

---

From: Matti Aarnio <[email-masked]>
Date: Thu, 27 Mar 2008 09:00:22 +0200

> >>	record lookups occuring as things currently stand.

There will be lots of legacy codes using legacy APIs for long future.
I do use  getaddrinfo()  API myself, and permit it do all queries to
get addresses.  Thus it will also query for A in addition to AAAA.
It can even be ordered to ignore IPv4 or IPv6 as sysadmin wants.

For the future the previous "query for A record" should possibly
be altered to "query for network address (IPv6 AAAA and/or IPv4 A)"
or some such generic wording.

-- 
/Matti Aarnio	<[email-masked]>
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Mar 2008 18:17:22 -0400

--On Wednesday, 26 March, 2008 14:26 -0700 "Hallam-Baker,
Phillip" <[email-masked]> wrote:

> My understanding is that we implicitly deprecated receivers
> relying on fallback to A in 2821. 

We did no such thing.

> Section 5 makes it clear
> that you look for MX first and that MX takes priority.  

Yes.  And that has been the rule since MX records were
introduced, a rule that was reinforced by RFC 1123.  This is not
news.  It has also been the case --since RFC 974, over 22 years
ago-- that, if the MX lookup fails, one looks for an A RR. RFC
2821 changed nothing in that regard.  People have repeated that
to you multiple times.  

> It is thus not compliant to look at AAAA records today and I
> see no reason to change this in the future.

This is also not true, but the reason is more subtle.  If 2821
said "don't look for an AAAA record and use it as a default"
then, certainly, looking for it after the MX lookup failed would
not be non-complaint.  But it says no such thing.   

Instead, there is a question of whether the text in 2821 should
be interpreted as "look for address records if the MX fails" or
"look for a A RR if the MX fails and, if it isn't found, give
up".  The first interpretation is strongly supported by general
advice to implementers of applications to make IPv6 behave as
much like IPv4 as possible unless there is a clear reason to not
do so.  Either interpretation is plausible, and we've got
examples of running code that implements the former.  There may
also be cases of the latter in production servers, but we
haven't asked and I don't, personally, know of any.  Leaving the
ambiguity, long-term, is not reasonable.

So 2821bis does what a "bis", and a document going for Draft
Standard, is supposed to do, and that is reflect existing
practice and clear up ambiguities.  Saying nothing is not, IMO,
an option.  Deprecating the A MX default is not an option.  And,
given current practice, prohibiting the current default is, IMO,
inappropriate unless real harm to the mail system is
demonstrated.  No one has done that, at least in any message
I've read.  

That current default --both types of address records are
available-- is also, by far, the safer one if some
implementations assume that the MX is required and others assume
that it is not. One could make a different argument, but whether
to permit or prohibit using an AAAA record for an MX default is
the only question.  And we cannot say "MAY" because it would
guarantee inconsistent and unpredictable behavior.

But, whatever the decision, it is highly constrained.  Arguing
on the basis of deprecation of a feature that did not occur, or
arguing for removal of a function on which many thousands of
hosts are depending is, at best, a waste of everyone's time.

> Mail is a service lookup, not a host name lookup. Support for
> use of fallback to IPv4 host name lookup is a historical
> accident due to the fact that the distinction was not
> understood at the time. We do not require IPv6 host name
> fallback, 

This, to put it politely, is nonsense.  I don't know that I can
say anything else without violating IETF list norms for postings.

> IPv6 host name fallback has a significant cost that
> will have immediate impact on every mail service lookup that
> is compliant.

No.  At most it will have a one DNS lookup impact on mail server
lookups that are not associated with MX records.  If the sender
prefers IPv4 over IPv6, it will have that impact only if there
is no A record present and there are some other valid records
for the domain name.  If the sender prefers IPv6 over IPv4, then
it adds nothing.  

In an IETF that believes the potential recursion of URNs and
NAPTR records is reasonable, it is really hard for me to get
excited about that one possible extra lookup.   YMMD, of course.

   john

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Mar 2008 11:04:40 +1100

> excited about that one possible extra lookup.   YMMD, of course.

	Doug's issue, which sparked off this latest debate, would
	be addressed by codifying "MX 0 .".  This would allow hosts
	to say that do not accept email and any email (MAIL FROM)
	claiming to come from such a domain to be dropped in the
	SMTP session.

	Note: this does not prevent email coming from such hosts
	as it would be applied to "MAIL FROM" not "HELO".  You could
	still get mail from your fridge, it would just not be from
	fridge@<hostname>. You would have to configure the email
	address like you do today when you use your ISP's mail
	domain.

	Mark

---

From: Tony Finch <[email-masked]>
Date: Fri, 28 Mar 2008 00:20:16 +0000

> It can even be ordered to ignore IPv4 or IPv6 as sysadmin wants.

There's an amusing interop issue with getaddrinfo and DNS lookups in MTAs.
In many implementations getaddrinfo will perform SRV lookups for you (as
an extension to /etc/services or getservbyname), so it probably doesn't do
the right thing (or it can be persuaded not to do the right thing by
people with perverse DNS setups). On Mac OS X, the daemon that handles
getaddrinfo has a special case for port 25 which performs MX lookups for
you (like SRV lookups), so it certainly does't do the right thing! Serious
email software needs to talk to the low-level resolver API in situations
when it cares about the detailed semantics of domain resolution, and it
needs a way of talking to the high-level resolver API when the sysadmin
chooses so that /etc/hosts, /etc/nsswitch.conf, and similar platform-
specific settings can do their thing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
TRAFALGAR: NORTHWEST VEERING NORTH 4 OR 5. MODERATE OR ROUGH. MAINLY FAIR.
MAINLY GOOD.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ned Freed <[email-masked]>
Date: Thu, 27 Mar 2008 17:14:40 -0700 (PDT)

> > excited about that one possible extra lookup.   YMMD, of course.

I can't get excited about this either.

> 	claiming to come from such a domain to be dropped in the

OTOH, I think standardizing this convention makes all sorts of sense, but
not, of course, in 2821bis.

				Ned

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Mar 2008 11:38:32 +1100

> not, of course, in 2821bis.

	Why not in 2821bis?  Is 2821bis really that time critical?

---

From: Joe Abley <[email-masked]>
Date: Thu, 27 Mar 2008 21:29:13 -0400

> 	Why not in 2821bis?  Is 2821bis really that time critical?

I would prefer to see the "empty field" intention implicit in "MX 0 ."  
codified with more generality, so that (to give just two examples) it  
can also be used in the MNAME field of SOA RDATA to indicate "I do not  
accept dynamic updates", or in the RNAME to indicate "there is no  
mailbox published in this RR".

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Mar 2008 13:25:39 +1100

> mailbox published in this RR".

	UPDATES are supposed to be sent to the NS RRset.  If the
	SOA MNAME happens to match one of the nameservers listed
	in the NS RRset then one should try that first.  This allows
	UPDATES to work when the primary nameserver is not directly
	reachable.

	The client should stop trying to update on REFUSED.  If a
	nameserver doesn't implement forwarding of UPDATEs then
	NOTIMP should be returned.

	The DNS RFC's define the MX record format.  They do not define
	the semantics associated with the record.  RFC 2821 does that.

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Mar 2008 23:40:42 -0400

--On Friday, 28 March, 2008 11:38 +1100 Mark Andrews
<[email-masked]> wrote:

>> OTOH, I think standardizing this convention makes all sorts
>> of sense, but not, of course, in 2821bis.
> 

It is on its way to Draft Standard.  This would be a
sufficiently new feature to force recycle at Proposed, which, to
put it mildly, would not be welcomed by the editor or, more
important, those who convinced me to do the work.

  john

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2008 01:42:29 -0400

> receiving MTA to follow this model, despite what others may see as value.

well, if you want to receive mail from other domains without special 
arrangement, you need to specify in DNS how those other domains should 
send mail to you.  and you do that by following the instructions in the 
mail standards, rfc2821[bis] in particular.

if you don't want to receive mail from other domains, or if you're 
willing to make special arrangements with the domains from which you 
wish to receive mail, you have no particular requirement to follow the 
specifications for how to advertise this in DNS.

but hey, if you're willing to work out your own way of doing something, 
you don't need standards.  that's not what standards are for.

> as mandating that every organization has to follow the same model.

again, they only need to follow that model if they want to receive mail 
without making special arrangements with the sender.  if they want to do 
  arbitrary things, like use a different mail transfer protocol or a 
different port or a different way of advertising things in DNS than the 
standards say, they're welcome to do so - but they shouldn't expect to 
receive mail.

> If there were some serious technical consequence for lack of the MX record I would be
> there is no real issue, 

only if you ignore the problems that have been observed and the 
increased likelihood of such problems occurring in IPv6.

Keith

---

From: David Morris <[email-masked]>
Date: Thu, 27 Mar 2008 22:00:40 -0800 (PST)

> increased likelihood of such problems occurring in IPv6.

Perhaps you could help us out and share a reference to documentation of
such problems. I for one have not personally observed any problems related
to using the A record to locate a mail server when there is no MX. As a
result I have no clue why IPv6 will increase such problems. My sense is
that quite a few posters to this thread also lack your perspective.

Dave Morris

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2008 02:31:07 -0400

David Morris wrote:
> to using the A record to locate a mail server when there is no MX.

part of the problem is that most hosts don't wish to receive mail but 
there is no way to indicate this to a mailer that is trying to deliver 
mail to them.  if the host has an A record, under the current 
specifications, a mailer that gets a message (presumably spam) with a 
recipient address at that domain is expected to try to deliver that 
message.  and unless that host implements a dummy SMTP server that 
refuses all incoming mail with a permanent error the sending mailer will 
keep getting "connection refused" - which is treated as a temporary 
error and the sending mailer will keep retrying.  this clogs up mail queues.

and the dummy SMTP server works, but it consumes resources on the host 
and eats bandwidth on the network.  having a way to say "don't send this 
host any mail" in DNS seems like a useful thing.  and we simply don't 
need the fallback to AAAA because we don't have the backward 
compatibility issue that we had when MX records were introduced.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2008 02:34:54 -0400

Tony Finch wrote:
> In many implementations getaddrinfo will perform SRV lookups for you 

this is just broken.   SRV should only be used for applications that are 
specified to use SRV.

for this reason among others, I never specify a service name in a call 
to getaddrinfo.

Keith

---

From: <[email-masked]>
Date: Fri, 28 Mar 2008 11:03:01 -0000

> >> OTOH, I think standardizing this convention makes all 
> sorts of sense, 
> >> but not, of course, in 2821bis.
> > 
> sufficiently new feature to force recycle at Proposed, which, 
> to put it mildly, would not be welcomed by the editor or, 
> more important, those who convinced me to do the work.

Let me throw another idea into the mix. What if we were to
recommend a transition architecture in which an MTA host
ran two instances of the MTA software, one binding only to
IPv4 addresses, and the other binding to only IPv6 addresses.
Assume that there will be some means for the two MTA software
instances to exchange messages when their DNS queries return
the wrong kind of addresses (A or AAAA). The IPv4 MTA can 
continue to use the rules regarding MX records with A record
fallback. The IPv6 MTA could require SRV records to identify
destinations and have no AAAA fallback.

It immediately seems obvious that some issues surrounding 
an architecture of email systems during the IPv4-IPv6 transition,
are well out of scope of RFC28821bis. Therefore, I suggest that
2821bis move forward and that people interested in documenting
email transition strategies discuss this with the Application
area AD's. Such work should not be done without some form of
outreach to operational groups such as MAAWG since email operators
are quite likely to do whatever makes operational sense without
regard to IETF documents. Unless, of course, email operators
are highly involved in writing such documents.

--Michael Dillon

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Mar 2008 01:20:55 -1000

On Mar 27, 2008, at 8:31 PM, Keith Moore wrote:
> David Morris wrote:
>>
>> Perhaps you could help us out and share a reference to  
>> documentation of such problems. I for one have not personally  
>> observed any problems related to using the A record to locate a  
>> mail server when there is no MX.
>
> part of the problem is that most hosts don't wish to receive mail  
> but there is no way to indicate this to a mailer that is trying to  
> deliver mail to them.

Agreed.  Although MX records provide a discovery method for SMTP  
services, fall-back to A records prevents an assertion of no SMTP  
services when A records exist at the domain.

> if the host has an A record, under the current specifications, a  
> mailer that gets a message (presumably spam) with a recipient  
> address at that domain is expected to try to deliver that message.   
> and unless that host implements a dummy SMTP server that refuses all  
> incoming mail with a permanent error the sending mailer will keep  
> getting "connection refused" - which is treated as a temporary error  
> and the sending mailer will keep retrying.  this clogs up mail queues.

As John Levine pointed out, a message with an originating email- 
address referencing a domain only containing AAAA records is likely to  
be refused.  In part to avoid potential issues handing NDNs as Frank  
suggested, and in part that each IPv6 hostname offers a vast number of  
domains and addresses that can be exploited as a spoofed source due to  
the RFC2821bis fallback specifically including IPv6 AAAA records.

> and the dummy SMTP server works, but it consumes resources on the  
> host and eats bandwidth on the network.  having a way to say "don't  
> send this host any mail" in DNS seems like a useful thing.  and we  
> simply don't need the fallback to AAAA because we don't have the  
> backward compatibility issue that we had when MX records were  
> introduced.

Not sanctioning IPv6 AAAA records as an MX fall-back avoids the  
undesired traffic now caused by SMTP spoofing of A records.  MX  
records might then be seen as an opt-in mechanism from the perspective  
of IPv6, since opt-out mechanism are onerous for those not wishing to  
participate.  While Bill and others expressed concerns of being tied  
to DNS, whatever replaces DNS must also offer separate service and IP  
address resolution mechanisms.  The concerns related to DNS seems to  
assume there would not be separate service/address mechanisms, but  
this would not suit those running their services out of different  
domains.

Not sanctioning IPv6 MX to AAAA fallback actually makes IPv6 easier to  
manage in that email policies will not be required at all IPv6  
hostnames, as they would be for IPv4.  Those wanting to employ small  
and simple services connected directly to the Internet might otherwise  
find these services inundated by undesired traffic whenever their  
hostname is used to spoof an email source.  Not sanctioning IPv6 MX to  
AAAA fallback makes IPv6 safer from abuse, perhaps enough to  
compensate for the quadrillions of hostnames and IP addresses that  
might be involved.  Over time SMTP itself may not remain viable as an  
exchange between anonymous parties if RFC2821bis retains IPv6 AAAA  
records as a fall-back for MX records.

-Doug

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Mar 2008 11:10:25 -0400

--On Wednesday, 26 March, 2008 17:09 +0000 Tony Finch
<[email-masked]> wrote:

>> With that change to "address record", if no MX record is
>> found, the SMTP client is required to look for DNS names with
>> either A or AAAA RRs, rather than A RRs only.
> 
> There's also RFC 3974 (Jan 2005, informational) which
> recommends treating AAAA like A. The most popular MTAs
> implement this logic.

Yep.  But the people who are already convinced that treating
AAAA like A is the Right Thing are, well, already convinced.
And those who aren't will probably just say "well, 3974 is
informational".

Please see comments (yours, mine, and others) on the ietf-smtp
list.

    john

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2008 11:23:22 -0400

> address resolution mechanisms.

there are lots of cases where I'd share the concern that DNS gets out of 
sync with reality.  but having this information in DNS doesn't bother me 
in this case because the servers to which incoming mail messages to 
[email-masked] are supposed to be sent, are a property of the 
example.com domain, far more than a property of any host.  it makes 
sense to put information about a domain in DNS (or whatever might 
someday replace DNS).

Keith

---

From: Ned Freed <[email-masked]>
Date: Thu, 27 Mar 2008 17:50:48 -0700 (PDT)

> 	Why not in 2821bis? 

Mainly because this entire exercise is focused on a move to draft with this
revision and a move to draft is not the time to introduce new features.

> Is 2821bis really that time critical?
 
It is somewhat time critical, but to be blunt I'm much more worried that if we
delay long enough to get consensus on this change and force a recycle at
proposed the necessary energy to move this document to draft won't be there
when it is possible to do so.

I'm also concerned that opening the door to new features and additions to
this document will result in a slew of additional well intentioned proposals
for changes and additions that will delay things even more.

This entire effort to revise the core email protocol documents has only been
been able to reach some sort of closure because we've managed to keep a pretty
narrow focus on just cleaning ujp what's there in the base specifications. And
even then it has taken a huge amount of work. I don't think you realize the
potential for harm opening the door the way you propose can do.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 27 Mar 2008 17:41:39 -0700 (PDT)

> specific settings can do their thing.

If anything this understates the problems MTAs face. Sure, you can use your own
resolver routines and avoid these semantics issues with getaddrinfo, but now
you're doing purely DNS-based address lookup. It may not be standardized, but
it is surprisingly common to use other name services or host files for this
within an administative domain. And while it may be possible to duplicate the
logic to do these other  sorts of lookups, you're now talking about
substantially more code and complexity, not to mention platform and
environmental dependencies.

				Ned

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Mar 2008 19:20:37 +0100

Ned Freed wrote:
 
> this entire exercise is focused on a move to draft with this revision

In this case I'm a part of the rough, my focus is on "get it right"
before the staus.  For 2822upd I'd be upset if it is no STD in 2010,
2821bis is different.  

> a move to draft is not the time to introduce new features.

It's a trick to keep wild and wonderful new features out.  For the
IPv6-fallback discussed in this thread "getting it right" is more
important than the status.  Ideal case, 2821bis is good as is, and
can replace the relevant parts of STD 10 in two years.  

Worst case, we find that 2821bis should have no IPv6-fallback in
two years, a 2821ter starting at PS would then take about five
years before its successor can be at STD.  

With a modified 2821bis requiring PS now assuming again five years
from PS to STD we'd be there 2013 instead of 2015 compared with the
worst case, or in 2013 instead of 2010 compared with the ideal case.

The question of the status PS / DS / STD alone IMO misses the point
of getting it right.

> to be blunt I'm much more worried that if we delay long enough to
> get consensus on this change and force a recycle at proposed the
> necessary energy to move this document to draft won't be there

No energy to fix it if necessary would be bad independent of the
status.  And 2821bis as is fixes various things that needed to be
fixed, whatever the outcome of the IPv6-fallback question and the
status will be.

IMO adding null-MX to 2821bis makes no sense technically, it is an
IPv4 kludge, not something to be added to billions of IPv6 webcams
or similar devices as "SMTP opt out".  OTOH a "SMTP opt in" by a
mandatory MX for IPv6 could be okay.

> even then it has taken a huge amount of work.

Sure, but SMTP is also important enough to deserve that much work.

Actually it would have deserved more work from me, but when folks
start whining about the status and not introducing new features at
critical points this is pretty much demotivating, and I fear the
outcome is not as good as it could have been without this "status
first" group think.
 
 Frank

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Mar 2008 14:51:14 -0400

--On Friday, 28 March, 2008 19:20 +0100 Frank Ellermann
<[email-masked]> wrote:

> It's a trick to keep wild and wonderful new features out.  For
> the IPv6-fallback discussed in this thread "getting it right"
> is more important than the status.  Ideal case, 2821bis is
> good as is, and can replace the relevant parts of STD 10 in
> two years.  
> 
> Worst case, we find that 2821bis should have no IPv6-fallback
> in two years, a 2821ter starting at PS would then take about
> five years before its successor can be at STD.  
>...

Frank,

As you and others have been repeatedly told on the ietf-smtp
list, if you have wild and wonderful new features, write drafts,
introduce them as separate, Proposed Standard, updates to 2821
that stand on their own, with their own justifications.  If that
had been done when the 2821bis effort started, or in the
subsequent months, if any of the supposed wonderful new features
introduced then had achieved interoperable implementations and
some deployment, it would have been perfectly reasonable to slip
them into 2821bis before the first Last Call a few months ago.

That approach is important because 2821 (and 2821bis),
independent of their formal status, are updates to a collection
of long-established and very widely deployed full standards.
Few people, other than the advocates of a particular wild and/or
wonderful idea, are going to be happy putting anything into it
--even at Proposed-- for which we do not have considerable
operational experience.  Those were essentially the rules for
DRUMS and they are the rules that Tony, Lisa, and myself have
been trying to apply to 2821 changes: we clarify, we correct
errors, but 2821[bis] is not the right place for wild and
wonderful ideas until they are thoroughly tamed.

Looked at a different way, the only advantage I can see of
stuffing a new idea into 2821bis and then cycling at Proposed
over writing the new idea up and processing it as a separate
update to 2821bis is the former would tend to hide from the
reader that it is a new idea and one that is less tested and
understood than the balance of 2821.  I don't believe the former
is a good way to proceed, but that is just my opinion.

So, with the understanding that this is just my opinion (but
that, as editor, I'm getting impatient with new ideas and
discussions surfacing during and after Last Call), let me repeat
my suggestion.  If you (or others, and you are clearly not the
worst offender) have new and/or wonderful ideas, write them up
in one or more I-Ds.  If they are good enough to stand on their
own, you should have no difficulty persuading an AD to process
them and getting them approved.  If they are not, then let's not
get involved with trying to insert them into 2821[bis] at the
last minute or later.   And, of course, if you are convinced
that there are enough wild and wonderful ideas to justify it, or
that circumstances have changed enough to justify redefining
Internet Mail, see if you can get tracking for a WG.  I'll wish
you well.

    john

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Mar 2008 15:23:18 -0400

> destinations and have no AAAA fallback.

it's not as if we want mail that is initially submitted via 
SMTP-over-IPv4 to be treated differently from the mail that is initially 
submitted via SMTP-over-IPv6.  if an MX for a domain has presence on 
both IPv4 and IPv6, there's no reason that an SMTP client shouldn't try 
to contact that MX using either IPv4 or IPv6.

as for using SRV for this case, it's pointless.  MX already works fine; 
SRV would require an extra DNS lookup with the attendant delay, 
overhead, and potential for failure.  using SRV is also more disruptive 
with no benefit that I can see.

> are well out of scope of RFC28821bis. 

perhaps, but I disagree that this is one of those issues.

more broadly, I think what we're seeing is an example of why our model 
for revision of our standards is broken.   what you seem to be arguing 
is that since we can't get everything settled with 2821bis immediately, 
we should indefinitely defer any further changes to it - even when we 
have good reason to believe there are problems that we can fix in the 
near term and that it's better to fix them now than later.

really what we should be doing is periodically (or continuously) 
maintaining our specifications as new requirements issues are 
identified.  we need to develop a better sense of which kinds of 
changes/improvements/fixes can be made without a major rewrite/rethink 
and which ones require a process like that which produced rfc2821.

Keith

---

From: Ned Freed <[email-masked]>
Date: Fri, 28 Mar 2008 13:49:44 -0700 (PDT)

> before the staus.  For 2822upd I'd be upset if it is no STD in 2010,

I completely and categorically disagree.

> can replace the relevant parts of STD 10 in two years.

To the extent it's a trick, it's one intended to reach closure in something
less than geologic time.

> years before its successor can be at STD.

This is hopelessly optimistic. The odds are if this effort to move to draft
fails it will never happen period and we'll be stuck with even more
infrastructure reliance on proposed standard documents.

> The question of the status PS / DS / STD alone IMO misses the point

And IMO this obsession on dotting every last I and crossing every last T is a
classic case of letting the best be the enemy of the good.

> mandatory MX for IPv6 could be okay.

I disagree with this as well, but I can live with either choice as long
as the current ambiguity gets resolved.

> Sure, but SMTP is also important enough to deserve that much work.

You are SERIOUSLY underestimating how tired and out of sorts people are over
all of this.

> outcome is not as good as it could have been without this "status
 
Good. The "whining" as you call it pejoratively was intended to be demotivating
in regards to crammming new features into this document. Nice to hear it worked
to some extent. Too bad it didn't work even better.

				Ned

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 29 Mar 2008 00:43:55 +0100

John C Klensin wrote:

> if you have wild and wonderful new features, write drafts,
> introduce them as separate, Proposed Standard, updates to
> 2821 that stand on their own, with their own justifications.

For one of the two discussed proposals, nullmx, that would be
easy enough, an old I-D exists.  Maybe you missed the point
that I'm not convinced that this is a good idea, and I do NOT
want to see nullmx as last minute addition to 2821bis.  For
technical reasons, not as a status question.

> the former would tend to hide from the reader that it is a
> new idea and one that is less tested and understood than
> the balance of 2821.  I don't believe the former is a good
> way to proceed, but that is just my opinion.

If "hiding" it deep in 2821bis is the point, trying to avoid
reviews, it would be wrong.  But I don't think that is what 
the nullmx proponents wanted, maybe they do not know that an
I-D exists, or they think it is a so perfectly obvious and
harmless idea that adding it to 2821bis is good.

Just in case again, I do NOT support nullmx in 2821bis, and
do NOT consider it as important enough to talk about it now
after the 2nd Last Call, and because it's in no way strictly
incompatible with 2821bis the proponents can try to revive
the existing I-D later.

> If you (or others, and you are clearly not the worst
> offender) have new and/or wonderful ideas, write them up
> in one or more I-Ds.

The IPv6-Fallback issue is something that clearly would be
incompatible with 2821bis-09, it is a now or never question.

So what I've done is to propose to talk about AAAA and IPv6
at all in 2821bis, you've done that.  Shortly after that on
the DKIM list Doug said that the address fallback is really
bad.  That reminded me that Doug is not the first who said 
this, Meng Weng Wong among others also condidered this as
bad and back in 2004 even proposed to obsolete the fallback
in SPF.  For obvious reasons not the right place, so this
didn't fly.  Back in 2007 I forwarded the issue to the SMTP
list, in a way it was my fault that you added the missing
AAAA in 2821bis everywhere, even for the "implicit MX" rule.

IIRC after a short discussion, maybe involving the notorious
"not for DS" way to suppress all good, bad, and ugly ideas,
the topic was dropped.

Doug mentioned it months later on the DKIM list again, and I
said that after the second Last Call is definitely too late,
and that folks supporting to remove "implicit MX" for IPv6
were a minority before (actually what I had in mind was the
minority consisting of Doug and me).  He nevertheless tried
it, and this time here on the general list "implicit MX" was
seriously discussed, maybe because the "climate" here is not
so suppressive as on the SMTP list.

It was not my idea to reopen this issue here, it was not my 
idea to close it, and whether you think that is a lunacy on
my side or not, various folks said that an "implicit MX" for
IPv6 is wrong, IIRC Doug, Keith, JohnL, and JohnL.  And Ned
for some hours.  

 Frank

---

From: Pekka Savola <[email-masked]>
Date: Sat, 29 Mar 2008 09:33:52 +0200 (EET)

> as well, especially if the MX, A, and AAAA requests are not made together.

I agree with Jim's characterization and IMHO both positions are 
reasonable.

I also prefer (2) because I don't think the original "A fallback" was 
meant to stay there very long and we just never got around to 
deprecating that feature.  If you ask a random sampling of postmasters 
and DNS domain owners, I doubt many would even remember right off the 
bat that such a fallback exists.  Further, given that the feature in 
and of itself does not provide any additional value, I don't see why 
the practise should be propagated to IPv6.

But if the majority were to favour (1), that would be fine with me as 
well.

Additionally I believe this is not an issue we as the IETF should get 
stuck at for a longer period.  Reaching closure, whichever decision it 
is, in the timescale of a couple of months, is IMHO better than a very 
strong consensus on the approach.

---

From: John C Klensin <[email-masked]>
Date: Sat, 29 Mar 2008 05:30:11 -0400

--On Saturday, 29 March, 2008 09:33 +0200 Pekka Savola
<[email-masked]> wrote:

>> (1) AAAA records in the IPv6 world should do exactly same
>> things as A records in the IPv4 world, so SMTP should look
>> for an AAAA record in the absence of an MX record, just as A
>> records are used in the absence of MX records.
>> 
>> (2) Although some SMTP servers will continue to be found
>> through A records for legacy reasons, there is no longer a
>> good reason for any new server not to have a published MX
>> record.  SMTP clients (senders) will, of course, need to
>> continue to look up A records, but since there is currently
>> no significant use of AAAA records for email routing, we

> I agree with Jim's characterization and IMHO both positions
> are  reasonable.
> 
> I also prefer (2) because I don't think the original "A
> fallback" was  meant to stay there very long and we just never
> got around to  deprecating that feature.  If you ask a random
> sampling of postmasters  and DNS domain owners, I doubt many
> would even remember right off the  bat that such a fallback
> exists.

Based on some small experience with email deployment and
operations, I believe that you are wrong.  Indeed, if you asked
a random sampling of those groups --remembering that there are a
huge number of SMTP servers in the world, only a tiny fraction
of which are professional operations and with an even smaller
fraction being large-scale, carefully-managed production ones,
you might discover that many of them had forgotten that there
was such a thing as an MX record and how to set it up.

>...
> Additionally I believe this is not an issue we as the IETF
> should get  stuck at for a longer period.  Reaching closure,
> whichever decision it  is, in the timescale of a couple of
> months, is IMHO better than a very  strong consensus on the
> approach.

Months?  To paraphrase something Ned said much more elegantly, I
think you severely underestimate the degree to which people are
fed up with this revision of this document and the processes
that drag it out.  This issue was raised after the second Last
Call closed.  It is important enough that it was worth some
additional time to be sure that the broader community had
considered the issue.  That has clearly occurred.  While I think
there is fairly clear consensus that the issue needs to be
resolved and documented clearly (although there are dissenters
even from that), I don't believe that I seen any evidence of
anyone who had a strong position changing his or her mind since
the discussion started, nor have I seen a new argument presented
after the first few days.

Certainly, one could go around this loop for months, with people
repeating themselves in ever-louder ways, but do you really
think that would move us forward or result in a better or
clearer consensus?

IMO, it is time to decide and move on.   Like several others, I
think it is more important to decide than what the decision is.
Days would be good.  Maybe a week or so is tolerable.  But
certainly not months.

    john  (Speaking as a frustrated editor who 
           volunteered for a quick project well over a
           year ago)

---

From: Pekka Savola <[email-masked]>
Date: Sat, 29 Mar 2008 11:51:58 +0200 (EET)

> was such a thing as an MX record and how to set it up.

Point taken, but I don't believe this really applies to IPv6 yet.

...
> Days would be good.  Maybe a week or so is tolerable.  But

I was not precise and you misunderstood.  I was saying "timescale of 
months" because I didn't want "timescale of years". (I've been a bit 
disappointed with IETF's speed of progress lately and the latter seems 
to be the timescale we're working with in any consensus process 
whatsoever.)  Faster is fine with me if the document shepherd, editor 
and the AD manage to read the consensus and decide on the right 
approach in that time.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 29 Mar 2008 13:30:12 +0100

John C Klensin wrote:

> I don't believe that I seen any evidence of anyone who
> had a strong position changing his or her mind since
> the discussion started, nor have I seen a new argument
> presented after the first few days.

The argument from somebody saying that his "by name" API
hides IPv4 vs. IPv6 details as it should, and that adding
some logic to distinguish the results would be annoying,
impressed me.  2821bis cannot say MUST NOT for AAAA, but
it could still limit any "implicit MX" MUSTard to IPv4.

 Frank

---

From: Ned Freed <[email-masked]>
Date: Sat, 29 Mar 2008 06:23:44 -0700 (PDT)

> operations, I believe that you are wrong.

I have to agree.

> Indeed, if you asked

And even if they know MX records exist they may not be able to use them. Some
DNS provisioning arrangements allow users to set up MX records but there are
others that do not.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Sat, 29 Mar 2008 09:38:48 -0400

Frank Ellermann wrote:
> hides IPv4 vs. IPv6 details as it should,

The presumption that the API "should" hide the differences between IPv4 
and IPv6 is a dubious one.  IPv4 and IPv6 really do act differently, for 
  a variety of reasons.  Some applications can get away with pretending 
that they're the same, others cannot.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Mar 2008 06:52:30 -0700

> DNS provisioning arrangements allow users to set up MX records but there are

This observation moves the proposed AAAA-only mode into one of high risk. 
Rather than the benefit of reducing complexity, it becomes the danger of 
threatening interoperability.

Let's note that the proposal is a change from a model that has worked solidly 
for 20 years and has not been a source of problems.  While the proposal is for a 
mode that is appealing, it is not necessary.

Methinks it is therefore time to respectfully retire the proposal.

d/

-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Sat, 29 Mar 2008 10:16:10 -0400

I think it is time to put an end to specious arguments.

These standards get used for decades.  I don't think it's appropriate to 
cripple them because of some arrangement that happens to exist now from 
a few dysfunctional DNS providers.  Providers will get more flexible as 
the need becomes apparent, and domain owners who have problems with 
their DNS providers can change providers.  It's not difficult.

And as has been said many times, we don't have a backward compatibility 
problem here, because as a practical matter any domain is going to have 
to provide an IPv4 path for inbound mail until IPv6 is ubiquitous.

The existing model is based on the assumption that most computers on the 
network are large general purpose timesharing machines that support 
significant user communities that wish to receive email on those 
computers.  That assumption has been incorrect for at least the past 10 
years, and it's getting more and more incorrect all the time.

Keith

---

From: Theodore Tso <[email-masked]>
Date: Sat, 29 Mar 2008 10:34:01 -0400

> their DNS providers can change providers.  It's not difficult.

So I must be missing something, probably because I deleted without
reading closely enough one of the earlier messages on this thread.
But please indulge me --- exactly what is the benefit of deprecating
the "A" fallback, and/or not doing a lookup on the AAAA record if the
MX record doesn't exist?  Is it the load on the nameservers that
people would believe would be reduced if we didn't do this?  Is that
really a problem?  Or is it something else?

					- Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 29 Mar 2008 11:10:54 -0400

One of the problems I have seen first-hand is "disappearing" mail.  
Example: A webserver sends outbound email directly, but doesn't want  
to receive inbound email. The hostname leaks and mail gets sent to  
that address, based  on the A(AAA) record. The mail is "received", but  
disappears into some never-seen /var file. In that case, the sender  
never suspects that anything is amiss; it would be much better if the  
sender got an immediate "sorry, that domain name doesn't support email  
service" error.

Even if you turn off sendmail, as someone has pointed out earlier, the  
sending MTA will retry for several days until giving up, thus delaying  
error notification that would be immediate otherwise in this  
particular case.

You can obviously turn off sendmail local delivery, but many of the  
standard web hosting (cPanel and kin, but also the standard RH mail  
setup) arrangements don't make it particularly easy to have outbound- 
only sendmail.

Thus, disabling AAAA checking seems to provide much cleaner error  
behavior. The 'MX 0' proposals would achieve some of the same results,  
but removing the AAAA lookup is default-safe, rather than requiring  
operator action. It's too late to change the A behavior, but there  
doesn't seem to be a reason to perpetuate this violation of the  
principle of least surprise.

Henning

---

From: John Levine <[email-masked]>
Date: 29 Mar 2008 15:26:51 -0000

>MX record doesn't exist?

Under the current setup, any domain that has an A record is presumed
to be a mail domain, and if it's not, there's no good way to advertise
that fact.  (Current crocks include running a stub server that rejects
everything, and the MX 0 . proposal.)  In a world where the fraction
of mail that is spam is 95% and growing, the load from unwanted mail
to non-mail domains is significant.  I have at least one host name
that was never a mail domain, but since it used to appear in usenet
headers it gets over 30,000 spams a day, every day.

As Keith recently pointed out, since it is no longer 1983, the vast
majority of names with A records are not mail servers nor are they
domains that occur in mail addresses.  They're workstations or PCs
whose users get their mail through a domain and a server somewhere
else.  Or with IPv6, they'll be toasters and doorbells, even less
likely to be mail servers.

Getting rid of the AAAA fallback flips the default to be in line with
reality -- most hosts don't want to receive mail directly, so if
you're one of the minority that actually does, you affirmatively
publish an MX to say so.

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 29 Mar 2008 09:01:20 -0700

>really a problem?  Or is it something else?

The RFC2822bis draft does _not_ depreciate the "A" fallback.

This long thread has been mostly about the fallback to the AAAA 
record if the MX record doesn't exist.   The debate has been about 
whether IPv6 SMTP clients should use the existence of the MX record 
as a test to determine whether the host wishes to receive mail.

Regards,
-sm

---

From: Keith Moore <[email-masked]>
Date: Sat, 29 Mar 2008 12:08:56 -0400

in addition to that, the number of Internet hosts that want to support 
email is already a small fraction of the whole. this can be expected to 
get even more negligible in an IPv6 world where there are enough 
addresses to network every device you might ever want to control or 
monitor.

Henning Schulzrinne wrote:
> Example: A webserver sends outbound email directly, but doesn't want to 
> receive inbound email. The hostname leaks and mail gets sent to that 
> address, based  on the A(AAA) record. The mail is "received", but 
> error notification that would be immediate otherwise in this particular 
> case.
> 
> setup) arrangements don't make it particularly easy to have 
> outbound-only sendmail.
>

---

From: SM <[email-masked]>
Date: Sat, 29 Mar 2008 09:40:44 -0700

>sender got an immediate "sorry, that domain name doesn't support email

I came across a few (IPv4) cases where mail and web services are 
hosted by different organizations.  The MX query failed and the SMTP 
client did a fallback to the A RR.  The mail was accepted by the host 
running the web service and it "disappeared".

The above can happen when sendmail is running on the web server and 
it automatically adds the domain to the list of domains for local 
delivery and there's a catchall address.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2008 13:47:56 -0700

Henning Schulzrinne wrote:
> that address, based  on the A(AAA) record.

What do you mean by "leaks"?

If it means something other than the domain name of the webserver appears in the 
author's rfc2822.From field address (or, of course, the rfc2822.Reply-To field) 
then your scenario doesn't happen, because those are the only fields that get 
used for return email from a recipient.

Same if/then, with respect to rfc2821.mailfrom and handling notices.

If an incorrect domain name is in an author or return handling address, there 
are bigger problems to solve than AAAA/MX.

If you mean yet something else, then what?

> The mail is "received", but  
> disappears into some never-seen /var file. 

So, a domain name erroneously appears in an address field and the references 
host erroneously accepts mail it shouldn't.

This degree of problematic operation is not likely to get solved with a new DNS 
construct.

If someone is sending out invalid email addresses, then that needs to get fixed, 
rather than working on some post-hoc mechanism.

> behavior. 

Reasonable idea.

Let's do it for all Internet services, not just email.

d/
-- 

   Dave Crocker

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Mar 2008 18:09:34 -0400

>
> If an incorrect domain name is in an author or return handling  
> address, there are bigger problems to solve than AAAA/MX.

Indeed, this is the problem - the problem is that such  
misconfiguration doesn't get detected since the address *seems* to  
work just fine.

>
>> The mail is "received", but  disappears into some never-seen /var  
>> file.
>
> So, a domain name erroneously appears in an address field and the  
> references host erroneously accepts mail it shouldn't.
>
> This degree of problematic operation is not likely to get solved  
> with a new DNS construct.
>
> If someone is sending out invalid email addresses, then that needs  
> to get fixed, rather than working on some post-hoc mechanism.
>

The problem is that fixing this is made much more difficult than  
necessary by having the AAAA record.

> Let's do it for all Internet services, not just email.

Yes, some other time. Email just seems particularly prone to this  
problem due to the SMTP retry behavior. Most other services don't try  
for a week.

Henning

---

From: David Morris <[email-masked]>
Date: Sun, 30 Mar 2008 14:28:26 -0800 (PST)

> headers it gets over 30,000 spams a day, every day.

I'm not convinced you've identifed causality ... only correlation. I
suspect that many spam sources routinely 'scan' for open port 25s and
send mail .. if a connection is accepted, they assume they have a mail
server. If they want a dns name for the email, they do a rdns lookup.

Nothing about the assumed fallback to A or AAAA will effect that form of
address lookup. Don't listen on port 25 if you don't want the mail. For
your web mail, make the right headers so that a reply will work. Or
arrange to have the mail depart from a valid mail server. If the recipient
of your of your emails replies back, and they get a rejected message, in
15 minutes or 5 days, either way it won't be something they will know what
to do with if they didn't know in the first place to not send to that
address. Better to improve the basic design than to expect in 10 years
when there are no IPV4 systems left that they will finally get near time
notifications of a delivery failure. Or perhaps define a new ICMP message
which some new revision of the mail protocol will define means to
immediately return the email.

It is true that most hosts don't run mail servers ... but the corollary is
that the host names will be used in published email addresses so it may
not matter all that much than random typos result in a missfire to an A
record or AAAA record defined host.

On a side note ... there is a lot of tooth knashing re. slow adoption of
IPV6 ... simple fact is that EACH procedural incompatibility introduces a
small issue in the minds of folks who have to manage the conversions and
roll out. Will slow down adoption because of perceived increased support
costs.

Of course, it could end up like NAT ... ignored for purity reasons by
the IETF, but used in practice... one more way the IETF margninalizes
itself.

Dave Morris

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 31 Mar 2008 01:06:07 +0200

Keith Moore wrote:
 
>> The argument from somebody saying that his "by name"
>> API hides IPv4 vs. IPv6 details as it should,
 
> The presumption that the API "should" hide the 
> differences between IPv4 and IPv6 is a dubious one.
> IPv4 and IPv6 really do act differently, for a 
> variety of reasons.  Some applications can get away
> with pretending that they're the same, others cannot.

Okay, oversimplification on my side, the argument that
impressed me didn't include an "as it should" part, it
was about using the same old code with a "by name" API,
IIRC.  

Bill mentioned that IPv6 should have got its own new 
class, something I cannot judge, certainly no job for
2821bis.

For a stupid direct-to-MX script I've sometimes used
it just happens that its "by name" API is limited to
IPv4, in theory the code would use "implicit MX" also
for IPv6.  Willing to fix this when 2821bis says so:

 Frank

---

From: John Levine <[email-masked]>
Date: 30 Mar 2008 23:21:03 -0000

>I'm not convinced you've identifed causality ... only correlation.

The causality is that its name was scraped out of a zillion usenet
archives.  Much of mail it gets is to addresses that are actually old
message-id's.  Other hosts that don't have names don't get hit at all.

> I suspect that many spam sources routinely 'scan' for open port 25s
>and send mail .. 

I haven't seen that in an extremely long time, and I log the port 25
connect attempts to non servers on my network.  It sees plenty of port
25 attempts, but they're all to the scraped hosts and stale MXes.
Spammers have gargantuan spam lists and use the regular MX/A lookup,
sometimes using very stale precached MX lists.

> For your web mail, make the right headers so that a reply will
> work. Or arrange to have the mail depart from a valid mail server.

Um, I've been doing that for rather a long time.  That's unrelated to
the scraped address problem.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 Mar 2008 09:36:32 +1000

> harmless idea that adding it to 2821bis is good.

	It's a natural back port of the SRV rules to MX.

		"SRV 0 0 ." indicates "no service".

	It was obvious 20+ years ago that MX processing was broken
	as there was no way to say "I don't want email".  Looking
	a the MX record, "MX 0 ." was the obvious solution.  The
	only reason I can see that it never went ahead was FUD.

	It's so obvious that some MTA's already implement it.  Exim
	is the example I've been told about.

	The existing MX processing rules assume that *every* host
	wants to receive email.  The assumption has not been correct
	for 20+ years.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2008 16:48:35 -0700

Folks,

This thread has moved to the ietf-smtp mailing list, where I suspect it belongs.

We should avoid have two different venues for this discussion, so I suggest 
further postings be on the ietf-smtp mailing list.

d/

-- 

   Dave Crocker

---

From: Mark Andrews <[email-masked]>
Date: Mon, 31 Mar 2008 09:57:03 +1000

> Methinks it is therefore time to respectfully retire the proposal.

	Anyone running a SMTP server on a truly dynamic address is
	asking for trouble.  This is independent of whether there
	is a MX record or not.  Invariably there will be SMTP
	connection attempts to the old address which are intercepted.

	Matching MX target against the greeting message would also
	address this.

	Also getting rid of implict MX records would "deal" with all
	those ISP's that insist that they need to re-write NXDOMAIN
	responses.

	Mark

---

From: Keith Moore <[email-masked]>
Date: Sun, 30 Mar 2008 20:24:33 -0400

> This degree of problematic operation is not likely to get solved with a new DNS 

this specific problem will get solved with a simplification of how email 
uses DNS.

> rather than working on some post-hoc mechanism.

the two problems are not mutually exclusive.  but we can lessen their 
combined effects.

> Let's do it for all Internet services, not just email.

worth considering.  but for now only 2821bis is on the table.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Sun, 30 Mar 2008 23:53:37 -0400

I'm no longer going to comment on the mail aspects of this MX 
debate on the IETF list -- see the ietf-smtp list.  But there is 
an issue here with much broader implications...

> 		"SRV 0 0 ." indicates "no service".

Well, strictly speaking, it doesn't mean that, regardless of 
what the SRV specs say.   What is means is "this service is not 
advertised for this domain".  If a service is associated, as 
part of its protocol, with an established (not necessarily 
well-known) port, then the only way to determine that the 
service isn't offered is by attempting to connect to that port. 
If is isn't associated with a specific port, one may have a hard 
time trying to find the service, but the only way to know that 
is isn't being offered is scan ports looking for it its 
symptoms.   For good reason or bad, there are also all sorts of 
ways to communicate the location of a service and the port to 
use that have nothing to do with the DNS and DNS changes, 
restrictions, and records cannot affect them.  These are not 
special properties of SMTP, with or without MX records; they are 
properties of TCP.  If one wants to fix those problems, then TCP 
has to be changed to affirmatively return a "no service" message 
if an attempt is made to connect to a port on which no service 
is specifically listening.

> 	as there was no way to say "I don't want email".

First, it may have been obvious to you, but it wasn't obvious to 
many of us.   In the general case, it still isn't.  But you 
stated the situation exactly correctly.   "MX 0 ." means "I 
don't want email".   "SRV 0 0 ." doesn't really indicate "no 
service", it indicates "please do look for that service here".

>   Looking

While it is better than interpreting the lack of a bit in a WKS 
record as "no service", it is still nothing more than an attempt 
to use the DNS to say "please don't try a mail connection to 
this domain".  I think that is probably ok and would be happy to 
see a proposal carefully considered to see if consensus could be 
reached (as Frank points out, there was such a proposal but it 
quietly disappeared, no FUD campaign needed).  But I note that 
"please don't do X" is a solution to a different set of problems 
than a solution that would prevent someone who is predisposed to 
antisocial behavior from trying something.  Since bad guys can 
deduce addresses by scanning --and will certainly do so if we 
make it sufficiently hard for them to use the DNS-- this type of 
DNS change, it seems to me, would have little effect on the 
antisocial.   And, again, that isn't a statement about email 
because it applies with equal force to any other application 
service we have.

> 	wants to receive email.  The assumption has not been correct

The existing A processing rules assume that *every* host wants 
to, or is at least able to, receive web connections, file 
transfer connections, SIP connections, telnet connections, 
Jabber connections, and, by the way, DNS connections.  Changing 
the MX rules won't change the assumption that every host 
supports email.  And most, it will make a statement of 
preference that mail connections won't be accepted more clear. 
And, viewed in that light, Exim's behavior represents a 
willingness to honor a preference... a willingness that, 
incidentally, can be bypassed by the simple expedient of giving 
it an address in literal form rather than one that is processed 
via the DNS.  Of course, Exim can, and often is, configured to 
reject mailbox@[ip-literal] addresses, but that behavior is 
outside the standard.

       john

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2008 02:21:42 -0400

agree with most of what you said, however:

> Since bad guys can  deduce addresses by scanning --and will certainly do so if we 
> antisocial.

note that scanning is a lot harder in IPv6 than it was in IPv4, because 
such a large address space is delegated to a customer and the normal 
assumption of stateless address autoconfiguration implies that addresses 
are allocated sparsely within the last 64 bits.

Keith

---

From: Tony Finch <[email-masked]>
Date: Mon, 31 Mar 2008 12:58:21 +0100

> you're one of the minority that actually does, you affirmatively

I agree that this is the right thing to do in an ideal world.

However there's a lot of old running code out there that implements the
AAAA fallback. Is IPv6 still enough of a toy that the stability of its
specifications doesn't matter?

Tony (in two minds).
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: SOUTHERLY VEERING WESTERLY, 4 IN MALIN AT FIRST, OTHERWISE 7 TO
SEVERE GALE 9. ROUGH BECOMING VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR
GOOD, OCCASIONALLY POOR.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 31 Mar 2008 09:11:09 -0400

I don't think this is a major issue, for two reasons: By the time that  
IPv6 mail becomes common, mail clients (and MTAs) will have been  
updated numerous times to deal with the security issue de jour.  
Secondly, even if a mail client or MTA were to erroneously implement  
this behavior, this causes no particular harm to the world at large,  
except bad error behavior for that particular MTA or MUA.

Henning

---

From: Bill Manning <[email-masked]>
Date: Mon, 31 Mar 2008 07:56:45 -0700

> service", it indicates "please do look for that service here".

	actually, it means the DNS admin doesn't want SMTP
	connections set to the indicated node.  

> this domain".  

	right. 

--bill

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Mar 2008 08:19:57 -0700

were you folks pursuing this on ietf-smtp, as requested, you might have noticed 
that the problems with changing the model have been explored thoroughly.

d/

-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Mon, 31 Mar 2008 11:25:19 -0400

> specifications doesn't matter?

You could make the same kind of argument in the other direction: Is IPv6 
still enough of a toy that we shouldn't maintain the specifications for 
applications that use it, updating them when there's a good reason to do so?

I'm not worried about running code that implements the AAAA fallback, 
because I don't think that this change breaks anything.  If domains were 
already relying on just an AAAA record to tell other domains how to send 
  mail to them, I'd be concerned about backward compatibility.  But 
that's  not the case.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf