Subject: Re: Queued Mail or Unreturnable Mail?
From: "Frank Ellermann" <[email-masked]>
To: [email-masked]
Date: Thu, 1 May 2008 04:02:48 +0200
List-Id: <ietf-smtp.imc.org>

John Leslie wrote:

[...]
>    Let's also leave aside the religious arguments about what belongs
> in 2821bis. (IMHO, this is largely an operational tuning issue, and
> the protocol spec shouldn't try to mandate operational tuning.)
[...]

>    Backscatter is a support nightmare. Unless you can match NDNs to
> actual messages sent, many customers will be happiest if you discard
> them all.

But "discard them all" is against my religion.  Professions have their
rules, lawyers don't work for the mob, docs don't help with euthanasia,
hackers don't manipulate data, soldiers don't attack civilians, and
postmasters don't "discard them all".

The same customers could whine if their mail with a typo caused a good
bounce ending up in /dev/discard_them_all.  For one of the religions
you don't wish to talk about it is a core dogma to cause good bounces
in a rare scenario decreed to be legit in a closely related religion
you also don't wish to talk about.  

On the SMTP list we IMO cannot say that the future SMTP standard is 
(only) a religion.  It is supposed to be the real thing, replace 821
in STD 10 in about 30 months.

>    The problem <ietf-smtp> can't seem to face is that the mere
> presence of a process listening on port 25 of a particular IP
> address says nothing about intent to receive email for a particular
> domain which has an A)ddress record pointing to that IP address. An
> MX record _does_ state such an intent.

2821 and 2821bis have it clear that the mere presence of a listening
process does not say anything about the intent to receive mail for
the corresponding domains.  The MX can say something else, without 
MX a listening process at A or AAAA can reject clients or individual
mails as it sees fit.  

The problematic situation is the absence of MX and listening process,
senders are forced to wait 100 hours, somebody might find the reboot
button of the affected host.  Another problematic situation is mail
claiming to be "from" this domain without MX, receivers cannot wait
until somebody finds the reboot button for a quick plausibility test,
they are forced to reject such suspicious mails temporarily.  

Religious operational tuning or not, when receivers accept suspicious
mails "on probation" they didn't read and understand 2821bis, likely following their own homebrewn "discard them all" strategies.

 Frank

Date: Wed, 30 Apr 2008 18:00:10 -0400
From: John Leslie <[email-masked]>
To: Sabahattin Gucukoglu <[email-masked]>
Cc: [email-masked]
Subject: Re: Queued Mail or Unreturnable Mail?
Sender: [email-masked]

Sabahattin Gucukoglu <[email-masked]> wrote:
> 
> I've got a message in my queue here destined for natwest.co.uk.  
> Natwest.co.uk exists, but it isn't running an SMTP service; it's intended 
> as a web server... The message is a DSN generated by this host.

   These are common. Often it is a misconfiguration, more often it's a
forged MailFrom in a spam.

   But, s/a message/a million messages/ -- you get a better idea of the
issue. If I didn't reject most spam at SMTP time, I'd probably have a
million of these critters in _my_ mail queues. Large ISPs probably have
a million, even _after_ rejecting what they can at SMTP time. :^(

> There's no MX, and I don't check SPF. 

   Let's leave aside the religious arguments about SPF -- in at least
some cases, it does clearly indicate an intention to receive email
addressed to a domain. Can we agree that an MX record, when accurate
and up-to-date, _does_ indicate an intent to receive email?

   If we have an indication of intent, it's reasonable to keep a message
like this in the queue. But what if we don't have such an indication?

   Let's also leave aside the religious arguments about what belongs in
2821bis. (IMHO, this is largely an operational tuning issue, and the
protocol spec shouldn't try to mandate operational tuning.)

> The original message was intended for a primary host for which I am 
> an acting secondary...

   The same issues arise in many corporate environments where the
externally visible MX MTA has limited visibility to the actual MDA.

> Which is the problem?
> 
> 1. I am naive enough to receive mail from non-verifiable senders...
> 2. I am not doing enough to ensure that I will not have to generate
>    a DSN.  

   Both, to some degree.

   Given the preponderance of spam, it is silly to argue that non-delivery
is rare. To return a 250 to the DATA phase without any checking whatsoever
of the bounce address _is_ naive unless you have matched MailFrom (e.g.
null) or RcptTo to a directive to _never_ send bounces.

   (I decline to argue whether 2821bis "should" permit such rejection at
SMTP time: clearly some folks _will_ do so. Besides, blindly following
a spec _can_ be called "naive".)

   OTOH, _anything_ one might do to determine that a message will not be
delivered is best done as early as possible. Most spam-abatement measures
produce the happiest results if done by the first MX MTA during the SMTP
session.

> The problem is not the semantics of nonexistent senders so much as that
> the result is backscatter and full mail queues.

   Backscatter is a support nightmare. Unless you can match NDNs to actual
messages sent, many customers will be happiest if you discard them all.

   Full mail queues is less of an issue (up to a few hundred thousand,
anyway). Those just slow things down...

> My endeavours are better served by protecting the recipient mailboxes;
> by guaranteeing that they are either deliverable or not at the SMTP
> level (usually RCPT command).

   Agreed.

> My vote is for 2 on general grounds of practicality, ease of
> implementation and least harm done. Perhaps elements of 1 can be added,

   In general, more tools is better...

> but I'm not certain it's at all useful unless it's done thoroughly enough.
> While policy-wise 1 makes sense, yet there is little doubt it could never
> become standardised.

   It is a mistake to think we _could_ standardize sender verification.
There's a continuum, not a sharp knee. Individual administrators need to
balance the probability of successful delivery against the probability
of an NDN failing to reach a useful mailbox or process. Proposals like
BATV can raise the latter probability arbitrarily high; provable absence
of mail service can reduce it arbitrarily low; mostly we're stuck in the
middle.

   What is upsetting to operators is a seemingly religious claim that
it's wrong to expect domains to actively signal their intent to receive
and process email. If they won't, we feel somewhat justified in rejecting
email likely to bounce before acknowledging the DATA phase. At some point
(long passed IMHO), calling us bad people won't be sufficient to stop
this.

   The problem <ietf-smtp> can't seem to face is that the mere presence
of a process listening on port 25 of a particular IP address says nothing
about intent to receive email for a particular domain which has an
A)ddress record pointing to that IP address. An MX record _does_ state
such an intent. There _are_ other ways to state such an intent, BTW.

> It would do too much harm,

   That's a judgment call...

> and the actual benefit is questionable when 2 is an option that has for
> a long time been advocated as a best practice

   ... though not always possible...

> (many small sites stopped using backup MXs just to avoid the
> administration and many other sites are less willing to act as backups 
> for complete strangers).

   Backup MX isn't the only use case (though we've mostly abandoned it).
There are good reasons in many environments to accept email "outside
the firewall" and forward it through the firewall to a server whose
status you cannot know. It's also common to have different spam
filtering for different accounts, at least some of which are "inside
the firewall. (One doesn't need to approve of "firewalls" to acknowledge
that such practices are common.)

   We certainly could design a mechanism _better_ than MX records to
document intent relative to receiving email, especially DSNs. But unless
and until we do, folks are likely to use MX records as part of the
balancing act of guessing the probability of NDNs reaching a responsible
reader.

--
John Leslie <[email-masked]>

Date: Wed, 30 Apr 2008 18:11:09 +0100
From: Sabahattin Gucukoglu <[email-masked]>
To: [email-masked]
Subject: Queued Mail or Unreturnable Mail?
Sender: [email-masked]

Hi all,

This question is bothering me.  It's stalled my reading of 2821bis, and the 
discussion around the issue (having diverged from IPv6) seems worthwhile 
fodder for continued debate.

I've got a message in my queue here destined for natwest.co.uk.  
Natwest.co.uk exists, but it isn't running an SMTP service; it's intended 
as a web server.  There's no MX, and I don't check SPF.  (Both natural 
conditions for typical hosts.)  The message is a DSN generated by this 
host.  The original message was intended for a primary host for which I am 
an acting secondary.  I will only accept mail for primaries when I can't 
connect to them myself, with a few exceptions to help routing difficulties 
of some hosts reaching the primary directly.

Which is the problem?

1.  I am naive enough to receive mail from non-verifiable senders.  I have 
not gone even to the extent of checking that the domain exists; a surefire 
but, as you can see here, pointless check.  I will never be happy until 
every conceivable check is done to verify that, should an error occur, I 
wil *always* be able to send mail back to the sending site at the sending 
mailbox.  There will never be mail for which I cannot succeed in delivery a 
status report.  That will be true even during my transition to IPv6: 
without, dual, exclusive.  Many hosts on the net are already finding it 
hard both to avoid misusing the null sender and yet to provide a safe, 
nondeliverable address that isn't rejected at the SMTP level for those 
common (but inadvisable) instances where bounces aren't actually wanted 
without creating blackholes.  (Perhaps you could argue that, for sites 
which send double bounces to local postmasters, sending to noreply-style 
addresses which *are* rejected during the SMTP conversation at least gives 
the sending site a chance to review why bounces are being generated for 
recipients there post-accept.)

2.  I am not doing enough to ensure that I will not have to generate a DSN.  
The problem is not the semantics of nonexistent senders so much as that the 
result is backscatter and full mail queues.  My endeavours are better 
served by protecting the recipient mailboxes; by guaranteeing that they are 
either deliverable or not at the SMTP level (usually RCPT command).  I find 
that this strategy is easiest to implement, and that the only time it is a 
problem to deliver unreturnable mail for mailboxes at the local host is the 
rare case when the recipient (who is, more often than not, a human being) 
needs to return some status report about mail sent to it.  Careful 
configuration reduces actual blowback, such as by configuring autoreply 
throttles or denying acknowledgement to untrusted or unknown senders (I 
have a mailing list which accepts posts from the world but doesn't 
acknowledge moderated outside posts unless I, the moderator, actually 
accept or reject the post explicitly).  In that event, as we've been 
saying, the Return-Path is not necessarily appropriate (mailing list 
software, autoresponders, etc) in which case an unreturnable sender is not 
an issue where sender fields are return mailbox are different.  For the 
backup MX case, of course, there exists the possibility as shown that mail 
may be accepted when it is later impossible to propagate to the primary.  
The envelope sender must then be used, and this results in possibly dead 
jobs if a verification step wasn't done at the time, but the problem is 
easily possible to diminish in severity by doing call-forward-style checks 
or, more surely, by simply maintaining a list of all known recipients at 
every MX (there is a serious administrative cost if the backup is not 
maintained by the same people who maintain the primary, in spite of many 
other reasons why doing that is a bad idea unrelated to recipient mailbox 
addresses - like spam blocklist or greylisting circumvention).

My vote is for 2 on general grounds of practicality, ease of implementation 
and least harm done.  Perhaps elements of 1 can be added, but I'm not 
certain it's at all useful unless it's done thoroughly enough.  While 
policy-wise 1 makes sense, yet there is little doubt it could never become 
standardised.  It would do too much harm, and the actual benefit is 
questionable when 2 is an option that has for a long time been advocated as 
a best practice (many small sites stopped using backup MXs just to avoid 
the administration and many other sites are less willing to act as backups 
for complete strangers).

Discuss. :-)

Cheers,
Sabahattin

-- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Sat, 26 Apr 2008 10:19:53 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Frank Ellermann wrote:
> Alessandro Vesely wrote:
>> I would not call that a "fix".
>  
>> Forwarding mail from server scripts often results in messages 
>> transferred with an empty MAIL FROM, RFCs notwithstanding.
> 
> Forwarders are unrelated to RFC 3834

Yes, I just meant to give one more example of empty sender, apparently 
violating rfc2821[bis].

>> Some even hypothesize a BCP candidature for such "modernism"...
> 
> I have never heard of that idea, and don't think that it is good,

I heard the idea in discussions about the

  MAIL FROM: <> AUTH=[email-masked]

The rationale is that, even if the target server does not understand 
the provided AUTH field, an empty sender is more convenient for both 
parties. While I think it may break the original SMTP design, I must 
acknowledge that spam drives people crazy.

> but of course adding "or BCP" to "standards-track" would be okay
> in 4.5.5.

Even if that is fine, it doesn't address the real problem. I know that 
the decision of not addressing the spam issue was made much ahead. 
However, it may make sense to try and assess its possible 
consequences, now that the process is nearly but not yet concluded.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Date:  Fri, 25 Apr 2008 22:06:36 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 21
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Alessandro Vesely wrote:

>> RFC 5230 is an application of RFC 3834.  There is no reference
>> in 2821bis.  I recall that John discussed it with Keith, maybe
>> that should be fixed, adding an RFC 3834 reference in 4.5.5 (?)
 
> I would not call that a "fix".
 
> Forwarding mail from server scripts often results in messages 
> transferred with an empty MAIL FROM, RFCs notwithstanding.

Forwarders are unrelated to RFC 3834 "auto-replies" by mailbots,
compare <http://www.openspf.org/Frank_Ellermann/Auto-responders>

> Some even hypothesize a BCP candidature for such "modernism"...

I have never heard of that idea, and don't think that it is good,
but of course adding "or BCP" to "standards-track" would be okay
in 4.5.5.

 Frank

Cc: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
From: Douglas Otis <[email-masked]>
To: Hector Santos <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Date: Fri, 25 Apr 2008 12:18:39 -0700
Sender: [email-masked]

On Apr 24, 2008, at 7:30 PM, Hector Santos wrote:

>
> Robert A. Rosenberg wrote:
>>> Well, an explicit MX does not resolve this problem of a response  
>>> address not being reachable.
>>
>> You said that "validdomin.com" is a valid domain so attempts to  
>> send to the no-reply address will get to the SMTP server supporting  
>> validdomin.com which will then send a "No Such User" reply (which  
>> in my book qualifies as reachable since the message to no-reply WAS  
>> delivered to the SMTP Server (but then rejected).
>
> My overall point, in so many words, was that mandating an MX record  
> requirement is meaningless IF the GOAL of the mandate is to thwart  
> bad guys.

Bad-actors run an overwhelming majority of SMTP clients.  If or when  
IPv6 is introduced, IP addresses will quickly become less useful in  
defending against a rising level of SMTP exploitation.  Name mismatch  
must be tolerated in reverse zone due to PTR set limitations.   
Administrative errors often found within the reverse zone and the  
added number of labels for IPv6 ensure checking reverse names will  
remain burdensome.  Names found in the reverse zone are often used  
only to make guesses about the nature of the related address.  These  
guesses are based upon inconsistent and non-standardized conventions,  
especially for classless delegations.  Within the forward zone, unlike  
address records, MX records exclusively support the SMTP service.   
Unless a domain offers clear indications of supporting SMTP by  
publishing discovery records, recipients should forgo other validation  
checks.

Some expect hosts to publish bogus MX records to "opt-out" and avoid  
what might become a significant amount of undesired traffic related to  
SMTP service, signatures, and policy validations.   Of course, an  
equitable solution would be to require valid MX records for those  
supporting SMTP and SMTP extensions, where upon not finding an MX  
record would indicate the extension is not supported.  Without at  
least an A record, SMTP itself is not supported.

Policy assertions may assist in mitigating some exploitation.  Rather  
than flooding name space with synthesized policy records, policy  
should be published in conjunction with the discovery records for the  
specific service.  While many may dismiss a concern about the  
application of policy scaling, policy tactics should be expected to  
evolve.  A means to scale policy must be established.  Policy can  
scale when published only in conjunction with explicit discovery  
records.

Clearly, what does not scale and what would be most unfair is to  
expect every host to publish bogus discovery records for all  
problematic public message exchange protocols.  It is not about  
thwarting bad guys, it is about mitigating undesired traffic for those  
not involved with the problematic protocol.

-Doug

Date: Fri, 25 Apr 2008 18:47:12 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: Tony Finch <[email-masked]>, Paul Smith <[email-masked]>
Sender: [email-masked]

Tony Finch writes:
>    All other types of messages (i.e., any message which is not 
>    required by a standards-track RFC to have a null reverse-path) 
>    SHOULD be sent with with a valid, non-null reverse-path.

My bad.

Arnt

Date: Fri, 25 Apr 2008 18:21:06 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Frank Ellermann wrote:
> Arnt Gulbrandsen wrote:
> 
>> 2821 4.5.5 lists some types for which you should use the null
>> path.  It doesn't forbid using <> for types not on its list.
>  
>> 3461 5.2.2 (d), 3834 3.3 and 5230 5.1 add to the list, and I
>> would not be surprised if other RFCs add more and code does
>> even more.
> 
> 2821bis explicitly mentions RFCs 3461 and 3798 in this section.
>   
> RFC 5230 is an application of RFC 3834.  There is no reference
> in 2821bis.  I recall that John discussed it with Keith, maybe
> that should be fixed, adding an RFC 3834 reference in 4.5.5 (?)

I would not call that a "fix".

Forwarding mail from server scripts often results in messages 
transferred with an empty MAIL FROM, RFCs notwithstanding. Some even 
hypothesize a BCP candidature for such "modernism"...

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Date:  Fri, 25 Apr 2008 17:12:44 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 42
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> 2821 4.5.5 lists some types for which you should use the null
> path.  It doesn't forbid using <> for types not on its list.
 
> 3461 5.2.2 (d), 3834 3.3 and 5230 5.1 add to the list, and I
> would not be surprised if other RFCs add more and code does
> even more.

2821bis explicitly mentions RFCs 3461 and 3798 in this section.
  
RFC 5230 is an application of RFC 3834.  There is no reference
in 2821bis.  I recall that John discussed it with Keith, maybe
that should be fixed, adding an RFC 3834 reference in 4.5.5 (?)

4.5.5 says that MAIL FROM: SHOULD be not empty in scenarios not
covered by standards-track RFCs mandating an empty reverse-path.
           ^^^^^^^^^^^^^^^^^^^^
IMHO exploring the far end of SHOULD on the border to MUST.

 Frank

 

 

Date: Fri, 25 Apr 2008 15:37:23 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Paul Smith <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Fri, 25 Apr 2008, Arnt Gulbrandsen wrote:
>
> 2821 4.5.5 lists some types for which you should use the null path. It doesn't
> forbid using <> for types not on its list.

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

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC 4 OR 5, BECOMING NORTHEASTERLY 6 TO GALE 8,
PERHAPS SEVERE GALE 9 LATER. MODERATE OR ROUGH. RAIN AT TIMES. MODERATE OR
GOOD, OCCASIONALLY POOR.

Date: Fri, 25 Apr 2008 16:11:38 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: Tony Finch <[email-masked]>, Paul Smith <[email-masked]>
Sender: [email-masked]

Tony Finch writes:
> On Fri, 25 Apr 2008, Paul Smith wrote:
>>  The envelope sender for automated mail just be blank. That's defined 
>>  as the address you use if you don't want a bounce.
>
> A null return path should not be used on a message unless it conforms 
> to one of a few standards-track types. RFC 2821 section 4.5.5.

2821 4.5.5 lists some types for which you should use the null path. It 
doesn't forbid using <> for types not on its list.

3461 5.2.2 (d), 3834 3.3 and 5230 5.1 add to the list, and I would not 
be surprised if other RFCs add more and code does even more.

Arnt

Date: Fri, 25 Apr 2008 15:44:22 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--CXFpZVxO6m2Ol4tQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-25 09:43:33 +0100, Paul Smith wrote:
> Peter J. Holzer wrote:
> >On 2008-04-24 15:36:59 +0200, Arnt Gulbrandsen wrote:
> >>Robert A. Rosenberg writes:
> >>>At 03:19 -0400 on 04/19/2008, Hector Santos wrote about Re: I-D 
> >>>Action:draft-klensin-rfc2821bis-10.txt:
> >>>>  no-reply @ validdomin.com
[...]
> >>I would not bet that mail to such an address is stored on disk, or 
> >>causes any reaction other than (at most) an autoresponse. But YMMV.
> >
> >I wouldn't bet either, but I would consider it bad practice if the
> >envelope sender for any automated mail is a black hole. If no human is
> >reading it, then there should at least be some program which analyzes
> >bounces and marks bouncing addresses as probably invalid.
> >  
> The envelope sender for automated mail just be blank. That's defined as 
> the address you use if you don't want a bounce.

"automated mail" and "don't want a bounce" are pretty much orthogonal.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--CXFpZVxO6m2Ol4tQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIEeA2fZ+RkG8quy0RAn/4AJ9p2TCGIVamToQ/075qYEVOpJjw+ACgtT2H
VC6lvchTn3HOXnmp9QkgdnsŸtl
-----END PGP SIGNATURE-----

--CXFpZVxO6m2Ol4tQ--

Date: Fri, 25 Apr 2008 14:26:34 +0100
From: Tony Finch <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Fri, 25 Apr 2008, Paul Smith wrote:
>
> The envelope sender for automated mail just be blank. That's defined as the
> address you use if you don't want a bounce.

A null return path should not be used on a message unless it conforms to
one of a few standards-track types. RFC 2821 section 4.5.5.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: EAST OR SOUTHEAST 4 OR 5. MODERATE. FOG PATCHES IN NORTH. MODERATE OR
GOOD, OCCASIONALLY VERY POOR IN NORTH.

Date: Fri, 25 Apr 2008 09:11:02 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Paul Smith <[email-masked]>
CC: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Paul Smith wrote:

> True. But if you could mandate that NOT having an MX record makes the 
> domain NOT valid for mail, then it might be easier to filter out some 
> junk. Also, it stops mail senders (sending bounce messages normally) 
> *arbitrarily* choosing to try to send the mail to a host.
> 
> It's "arbitrary" because there's no way to set up a host name which 
> WON'T get mail (other than to do something extra such as set up a dummy 
> MX record, which would make anyone think that the name SHOULD get mail 
> contrary to the actual reason for doing it), so simply setting up a host 
> name causes the incorrect implication that you want to get mail on that 
> host.

I agree, but in my view, I don't think it is my place as a SMTP software 
provider to mandate it across the board.   It would have to be 
implementation option.

There is no question in my mind, if every (wide adoption) SMTP software 
began to do this, we would have an impact on both ends - good and bad.

But how much of an negative impact will it have and is it safe to assume 
those people are going to JUMP to fix their MX records?

Maybe they don't won't have a choice.

But in my view, again as a Software guy, I would leaned toward to 
maintaining compatibility and if we are asking for code change, then I 
prefer to look for something we can use to something extra that will 
justify a new change in "logic".   From this standpoint, I prefer to 
play the game safe technically and also legally.

For example, if the email had a DKIM signature, that is would be, IMV, a 
legal trigger to do new things that is above the normal legacy 
expectations.

> Yes, you can say that the lack of a waiting service port means it isn't 
> a mail host - but it DOESN'T. It means that it isn't a mail host *now*. 
> It might be in 2 minutes, or it might never be - there's no way of knowing.

Very true.  This is all part of an system retry logic and setup. For our 
setup/operation, a strong requirement is enabled for system availability.

The theory behind our CBV implementation is that if you're good and 
ready to send me mail, then you better be good and ready at the same 
precise moment of time to accept mail (verified by CBV).

> If there was some mandated, standard way of advertising that there 
> *should* be a service on a certain port, then that would work, but IMHO, 
> an MX record could do just that for port 25.

But MX is just a "menu" of A* records.  It is the A* (host) records that 
need to be resolved. Whether is a group or just 1 (implicit) host set, 
the real technical requirement can be stated as:

        A valid SMTP host is one with a A/AAAA record
        with a SMTP service port.

and the idea of system availability can be argued to be an out of scope 
policy question, not technical.

I think 2821bis covers this pretty well:

   4.5.4.2.  Receiving Strategy

    The SMTP server SHOULD attempt to keep a pending listen on the SMTP
    port (specified by IANA as port 25) at all times.  This requires the
    support of multiple incoming TCP connections for SMTP.  Some limit
    MAY be imposed but servers that cannot handle more than one SMTP
    transaction at a time are not in conformance with the intent of this
    specification.

    As discussed above, when the SMTP server receives mail from a
    particular host address, it could activate its own SMTP queuing
    mechanisms to retry any mail pending for that host address.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 25 Apr 2008 08:25:38 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC:  [email-masked], "Robert A. Rosenberg" <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Hector Santos writes:
>> My overall point, in so many words, was that mandating an MX record 
>> requirement is meaningless IF the GOAL of the mandate is to thwart bad 
>> guys.
> 
> Who cares about bad guys? Really?

Good point.

If you ask with the mindset of everyone playing by the same (protocol) 
rules established,  I agree.

At the operations side, one might reasonably argue the pendulum has 
shifted such that a new mandate would have a high payoff.  After all, 
the theory is, the impact would be small against the good guy but if you 
are legitimate, you would have an avenue of complaining and resolution - 
you hope.  Bad guys don't complaint - they evolve.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 25 Apr 2008 08:16:32 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Paul Smith <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Paul Smith wrote:
> 
> Unfortunately, there's a large number of mail servers out there which 
> won't accept mail with null return paths, contrary to RFC 2821 - that's 
> at least one reason why people use noreply@ etc.

Right, which might also include a bounce being redirected (sandboxed) 
away from users.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 25 Apr 2008 09:41:28 +0100
From: Paul Smith <[email-masked]>
To: Hector Santos <[email-masked]>
CC: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Hector Santos wrote:
>   - Service Port
>   - Valid Recipient
>
> At the very least, the service port is a major consideration.
>
> In short, having a MX record does not make you a valid mail host until 
> everything else about the process is valid.
>
True. But if you could mandate that NOT having an MX record makes the 
domain NOT valid for mail, then it might be easier to filter out some 
junk. Also, it stops mail senders (sending bounce messages normally) 
*arbitrarily* choosing to try to send the mail to a host.

It's "arbitrary" because there's no way to set up a host name which 
WON'T get mail (other than to do something extra such as set up a dummy 
MX record, which would make anyone think that the name SHOULD get mail 
contrary to the actual reason for doing it), so simply setting up a host 
name causes the incorrect implication that you want to get mail on that 
host.

Yes, you can say that the lack of a waiting service port means it isn't 
a mail host - but it DOESN'T. It means that it isn't a mail host *now*. 
It might be in 2 minutes, or it might never be - there's no way of knowing.

If there was some mandated, standard way of advertising that there 
*should* be a service on a certain port, then that would work, but IMHO, 
an MX record could do just that for port 25.

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

Date: Fri, 25 Apr 2008 09:43:33 +0100
From: Paul Smith <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070606060302050406040301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter J. Holzer wrote:
> On 2008-04-24 15:36:59 +0200, Arnt Gulbrandsen wrote:
>   
>> Robert A. Rosenberg writes:
>>     
>>> At 03:19 -0400 on 04/19/2008, Hector Santos wrote about Re: I-D 
>>> Action:draft-klensin-rfc2821bis-10.txt:
>>>       
>>>> Just consider the many transactions with addresses such as:
>>>>
>>>>   no-reply @ validdomin.com
>>>>
>>>> that many feedbacks system use today, including bad guys and the 
>>>> bad/good direct marketing people.
>>>>         
>>> What is the envelope address for these messages?
>>>       
>> The ones that end mail to me (about fifty addresses in my personal mail 
>> archive, mostly noreply@, some no-reply@, some others) generally use 
>> the same address,and it's valid in the sense that the address is 
>> syntactically valid and that mail to the address is accepted by the 
>> best MX for the domain.
>>
>> I would not bet that mail to such an address is stored on disk, or 
>> causes any reaction other than (at most) an autoresponse. But YMMV.
>>     
>
> I wouldn't bet either, but I would consider it bad practice if the
> envelope sender for any automated mail is a black hole. If no human is
> reading it, then there should at least be some program which analyzes
> bounces and marks bouncing addresses as probably invalid.
>   
The envelope sender for automated mail just be blank. That's defined as 
the address you use if you don't want a bounce.

Unfortunately, there's a large number of mail servers out there which 
won't accept mail with null return paths, contrary to RFC 2821 - that's 
at least one reason why people use noreply@ etc.

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

--------------070606060302050406040301
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter J. Holzer wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">On 2008-04-24 15:36:59 +0200, Arnt Gulbrandsen wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Robert A. Rosenberg writes:
    </pre>
    <blockquote type="cite">
      <pre wrap="">At 03:19 -0400 on 04/19/2008, Hector Santos wrote about Re: I-D 
Action:draft-klensin-rfc2821bis-10.txt:
      </pre>
      <blockquote type="cite">
        <pre wrap="">Just consider the many transactions with addresses such as:

  no-reply @ validdomin.com

that many feedbacks system use today, including bad guys and the 
bad/good direct marketing people.
        </pre>
      </blockquote>
      <pre wrap="">What is the envelope address for these messages?
      </pre>
    </blockquote>
    <pre wrap="">The ones that end mail to me (about fifty addresses in my personal mail 
archive, mostly noreply@, some no-reply@, some others) generally use 
the same address,and it's valid in the sense that the address is 
syntactically valid and that mail to the address is accepted by the 
best MX for the domain.

I would not bet that mail to such an address is stored on disk, or 
causes any reaction other than (at most) an autoresponse. But YMMV.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I wouldn't bet either, but I would consider it bad practice if the
envelope sender for any automated mail is a black hole. If no human is
reading it, then there should at least be some program which analyzes
bounces and marks bouncing addresses as probably invalid.
  </pre>
</blockquote>
The envelope sender for automated mail just be blank. That's defined as
the address you use if you don't want a bounce.<br>
<br>
Unfortunately, there's a large number of mail servers out there which
won't accept mail with null return paths, contrary to RFC 2821 - that's
at least one reason why people use noreply@ etc.<br>
<pre class="moz-signature" cols="72">-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows</pre>
</body>
</html>

--------------070606060302050406040301--

Date: Fri, 25 Apr 2008 09:43:11 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: "Robert A. Rosenberg" <[email-masked]>, Hector Santos <[email-masked]>
Sender: [email-masked]

Hector Santos writes:
> My overall point, in so many words, was that mandating an MX record 
> requirement is meaningless IF the GOAL of the mandate is to thwart 
> bad guys.

Who cares about bad guys? Really?

Arnt

Date: Thu, 24 Apr 2008 22:30:59 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
>> Well, an explicit MX does not resolve this problem of a response 
>> address not being reachable.
> 
> You said that "validdomin.com" is a valid domain so attempts to send to 
> the no-reply address will get to the SMTP server supporting 
> validdomin.com which will then send a "No Such User" reply (which in my 
> book qualifies as reachable since the message to no-reply WAS delivered 
> to the SMTP Server (but then rejected).

My overall point, in so many words, was that mandating an MX record 
requirement is meaningless IF the GOAL of the mandate is to thwart bad guys.

So even if validdomain.com has a MX record, it means nothing if the 
other two key parts of the SMTP transaction equation are not valid:

   - Service Port
   - Valid Recipient

At the very least, the service port is a major consideration.

In short, having a MX record does not make you a valid mail host until 
everything else about the process is valid.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 24 Apr 2008 17:08:28 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

At 15:36 +0200 on 04/24/2008, Arnt Gulbrandsen wrote about Re: I-D 
Action:draft-klensin-rfc2821bis-10.txt:

>Robert A. Rosenberg writes:
>>At 03:19 -0400 on 04/19/2008, Hector Santos wrote about Re: I-D 
>>Action:draft-klensin-rfc2821bis-10.txt:
>>>Just consider the many transactions with addresses such as:
>>>
>>>    no-reply @ validdomin.com
>>>
>>>that many feedbacks system use today, including bad guys and the 
>>>bad/good direct marketing people.
>>
>>What is the envelope address for these messages?
>
>The ones that end mail to me (about fifty addresses in my personal 
>mail archive, mostly noreply@, some no-reply@, some others) 
>generally use the same address,and it's valid in the sense that the 
>address is syntactically valid and that mail to the address is 
>accepted by the best MX for the domain.
>
>I would not bet that mail to such an address is stored on disk, or 
>causes any reaction other than (at most) an autoresponse. But YMMV.
>
>Arnt

If you mean that the From and Return-Path are both use the noreply 
type user id, then they are unable to see bounces. I just checked my 
archives for noreply and no-reply mail and all the messages have a 
non-noreply type return-path. The envelope address that I was 
referring to is what becomes the return-path.

Date: Thu, 24 Apr 2008 21:48:56 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-24 15:36:59 +0200, Arnt Gulbrandsen wrote:
> 
> Robert A. Rosenberg writes:
> >At 03:19 -0400 on 04/19/2008, Hector Santos wrote about Re: I-D 
> >Action:draft-klensin-rfc2821bis-10.txt:
> >>Just consider the many transactions with addresses such as:
> >>
> >>   no-reply @ validdomin.com
> >>
> >>that many feedbacks system use today, including bad guys and the 
> >>bad/good direct marketing people.
> >
> >What is the envelope address for these messages?
> 
> The ones that end mail to me (about fifty addresses in my personal mail 
> archive, mostly noreply@, some no-reply@, some others) generally use 
> the same address,and it's valid in the sense that the address is 
> syntactically valid and that mail to the address is accepted by the 
> best MX for the domain.
> 
> I would not bet that mail to such an address is stored on disk, or 
> causes any reaction other than (at most) an autoresponse. But YMMV.

I wouldn't bet either, but I would consider it bad practice if the
envelope sender for any automated mail is a black hole. If no human is
reading it, then there should at least be some program which analyzes
bounces and marks bouncing addresses as probably invalid.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--AhhlLboLdkugWU4S--

Date: Thu, 24 Apr 2008 15:36:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

Robert A. Rosenberg writes:
> At 03:19 -0400 on 04/19/2008, Hector Santos wrote about Re: I-D 
> Action:draft-klensin-rfc2821bis-10.txt:
>> Just consider the many transactions with addresses such as:
>>
>>    no-reply @ validdomin.com
>>
>> that many feedbacks system use today, including bad guys and the 
>> bad/good direct marketing people.
>
> What is the envelope address for these messages?

The ones that end mail to me (about fifty addresses in my personal mail 
archive, mostly noreply@, some no-reply@, some others) generally use 
the same address,and it's valid in the sense that the address is 
syntactically valid and that mail to the address is accepted by the 
best MX for the domain.

I would not bet that mail to such an address is stored on disk, or 
causes any reaction other than (at most) an autoresponse. But YMMV.

Arnt

Date: Wed, 23 Apr 2008 17:53:40 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

At 03:19 -0400 on 04/19/2008, Hector Santos wrote about Re: I-D 
Action:draft-klensin-rfc2821bis-10.txt:

>Note, I am not questioning that an explicit MX requirement method is 
>not a valid consideration.  I am questioning to what purpose?
>
>Just consider the many transactions with addresses such as:
>
>    no-reply @ validdomin.com
>
>that many feedbacks system use today, including bad guys and the 
>bad/good direct marketing people.

What is the envelope address for these messages? So long as it exists 
and will accept delivery failure Email, the fact that the FROM 
address is SEND-ONLY (but in a valid domain that will respond by 
sending a "NO SUCH USER" error message to any recipient that tries to 
reply [or send] to such an address) is a non issue that is self 
correcting (you spank the user who tries to send to the address).

>Well, an explicit MX does not resolve this problem of a response 
>address not being reachable.

You said that "validdomin.com" is a valid domain so attempts to send 
to the no-reply address will get to the SMTP server supporting 
validdomin.com which will then send a "No Such User" reply (which in 
my book qualifies as reachable since the message to no-reply WAS 
delivered to the SMTP Server (but then rejected).

Date: Mon, 21 Apr 2008 09:03:35 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SMTP Interest Group <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Keith Moore wrote:
> 
> Alex van den Bogaerdt wrote:

>> So he setup a forward to <user@[machine-ip6-address]> and it worked.
>> Not really an argument _pro_ adding AAAA-fallback IMHO.
> 
> not clear.  he might have set up forwarding to user@domain.  and it 
> worked because it just happened that the one MTA doing the forwarding 
> implemented fallback to AAAA.
> 
> I don't think that's much of a pro-fallback argument either, but we 
> should acknowledge that some existing MTAs do implement fallback.

hmmmm,  shouldn't we all acknowledge its the standard to do a fallback 
in all MTA (software)?   Whether "some" operators (users of MTAs)turn it 
off, is another matter.

What I am interesting in finding out, is what is the BCP by the MTA in 
fallback situations in the area of retries.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 21 Apr 2008 08:22:34 -0400
From: Keith Moore <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Alex van den Bogaerdt wrote:
> On Mon, Apr 14, 2008 at 10:33:51PM -0400, Tony Hansen wrote:
> 
>>                                          One person who had a site set
>> up with an IPv6-only connection and no MX record told me "I wanted to
>> forward my e-mail to an account on that machine. It worked the first
>> time, so I didn't see a need to change it."
> 
> So he setup a forward to <user@[machine-ip6-address]> and it worked.
> Not really an argument _pro_ adding AAAA-fallback IMHO.

not clear.  he might have set up forwarding to user@domain.  and it 
worked because it just happened that the one MTA doing the forwarding 
implemented fallback to AAAA.

I don't think that's much of a pro-fallback argument either, but we 
should acknowledge that some existing MTAs do implement fallback.

Date: Mon, 21 Apr 2008 10:36:26 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Apr 16, 2008 at 04:45:07PM -0400, John C Klensin wrote:

> --On Wednesday, 16 April, 2008 14:31 -0600 Willie Gillespie
> <[email-masked]> wrote:
> 
> > Tony Finch wrote:
> >> On Wed, 16 Apr 2008, Ned Freed wrote:
> >>>> I doubt that it makes sense to accept email from
> >>>> [email-masked] on a system that can only
> >>>> communicate with IPv4 addresses.
> > 
> > I foresee some company setting up an IPv6 to IPv4 e-mail relay
> > for individuals or other companies that only have IPv6
> > addresses.
> 
> Very likely, IMO
> 
> > For an IPv4-only receiving system, would this appear as an
> > e-mail from [email-masked] (even though it comes over
> > the IPv4 link)?  At that point, would it make sense to accept
> > the message?
> 
> Sure.  The problem arises if the receiving IPv4 host tries to do
> some sort of sender-accessibility or callback verification.  It
> won't be able to reach the IPv6 host (or send NDNs to it) unless
> it either it is configured to submit those messages via an
> IPv6-capable gateway or the IPv6 host advertises IPv4 addresses
> (perhaps via a conversion relay in a low-preference MX record).

Translated:

The host needs an A record, or an MX record which points to at
least one A record. There's no point in relying its AAAA record
to act as an implicit MX record, not as long as there are hosts
out there which have no clue about IPv6.

>From my perspective, you agree with:
> Date: Sat, 5 Apr 2008 14:26:50 +0200
> From: Alex van den Bogaerdt <[email-masked]>
> To: [email-masked]
> Subject: Why implicit MX is a bad idea for IPv6
> Message-ID: <[email-masked]>

Date: Mon, 21 Apr 2008 10:18:23 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Reply-To: [email-masked]
Mail-Followup-To: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

On Mon, Apr 14, 2008 at 10:33:51PM -0400, Tony Hansen wrote:

>                                          One person who had a site set
> up with an IPv6-only connection and no MX record told me "I wanted to
> forward my e-mail to an account on that machine. It worked the first
> time, so I didn't see a need to change it."

So he setup a forward to <user@[machine-ip6-address]> and it worked.
Not really an argument _pro_ adding AAAA-fallback IMHO.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  IPv6 considerations (was: I-D Action:draft-klensin-rfc2821bis-10.txt)
Date:  Sat, 19 Apr 2008 23:24:24 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 97
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hector Santos wrote:

> Must all mail senders have a RECEIVER available 
> "somewhere" in order to receive a notification?

If you are talking about envelope sender addresses,
sure, that is the idea, otherwise an empty reverse-
path would do.

> Must all transaction expose a valid RECEIVER in
> the 2822 message reply fields (Reply-To:,  From:)
> in order for the user or some mailbot to send
> responses?

Yes, again the idea of Reply-To (or implicitly the
2822-From if no explicit Reply-To address is given)
is to send replies to it, as the name says.

Mailbots better use the reverse-path as explained
in RFC 3834 when talking to unknown strangers, I've
just "spamcopped" two auto-replies to the 2822-From.

> Just consider the many transactions with addresses
> such as:
>     no-reply @ validdomin.com
> that many feedbacks system use today, including bad
> guys and the bad/good direct marketing people.

The auto-replies reported as spam above were triggered
by a mail to the SPF help list.  It has nothing to do
with IPv6 or MX.

> I don't think I am saying anything odd here.
[...]
> RFC 3484 does not have not even one mentioning of MX
> records.

Apparently RFC 3484 is about IP, two layers below SMTP,
why should it mention MX ?  It also does not mention
X.75, V.90, or ISDN records.

> But check out RFC 3482

An informational RFC about E.164, why should I look in
this memo, is "3482" a typo ?

> Then also read the following:

I'm not going to read tons of RFCs I have never before
heard of, I believe you when you say that they do not
mention MX or SMTP.  

> In 4038 section 3.2, this note covers what we been
> partially debating:
 
>| 3.2.  DNS Does Not Indicate Which IP Version Will Be Used
[...]

We have even worked out how to solve this problem here:

dom.example.      IN MX   10 ipv4.dom.example.
                  IN A    208.247.131.9
                  IN AAAA 2001:DB8::CD30
ipv4.dom.example  IN A    208.247.131.9

> It touches base with using not MX but SRV as a discovery
> method.  But note again, not even one mentioning of MX
> records!!

They did not need to mention MX, because that is the one
case where the solution is obvious (using MX, see above).

> In RFC 4472, section 4.1 it says:

Fine, another solution, use smtp.dom.example. for SMTP,
change all dom.example. addresses to smtp.dom.example.,
or maybe just use an MX pointing to smtp.dom.example. :-)

>| in the specific case of SMTP relaying, the server itself
>| must typically also be configured to know all its names
>| to ensure that loops do not occur.

Also to ensure that [email-masked] (etc.)
work as expected, yes.

>| (Obviously, when wanting to reach a specific node, one 
>| should use the hostname rather than a service name.)
 
> Note that last sentence as well - a continuation of the
> implicit MX concept.

Just because a name contains www / ftp / smtp does not
necessarily mean that a host supports http / ftp / smtp,
let's say that IAB RFC 4367 info trumps RFC 4472 info:
"What's in a Name: False Assumptions about DNS Names"

 Frank

Date: Sat, 19 Apr 2008 05:17:49 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: Interesting Thread regarding unexpected MX lookups.
Sender: [email-masked]

I found an interesting recent thread among Apple people, OS X, the 
getaddrinfo() issue,  telnet applets acting with MTA-like behavior, and 
also the debate of the meaning MX records:

http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/619001401931/p/1

Apparently, the OP did a direct telnet connection on port 25 and the 
telnet application produced net packets with MX lookups apparently 
because the application is using getaddrinfo() function.

As the original poster said in the thread:

     If I want MTA behaviour I'll use an MTA. telnet and nc are
     not MTAs.

     Yes, they're used for diagnosing problems with an SMTP server,
     which is precisely why they should let me connect to the SMTP
     server I'm trying to diagnose, not play silly buggers with DNS.

The scary thing about all this is how lower layers is forcing the
explicit MX issue.

Especially with this dude saying this on page 2 of the thread:

     I also think your notion that telnet/nc to port 25 should
     ignore ESMTP rules is equally silly (or at least, have no way
     to be made to follow them): if I'm at the point where I want to
     send SMTP commands by hand, I'm also at the point where
     assuming that DNS lookups are working right is a bad idea.

This would be true if TELNET was going to fully act as MTA and perform 
the state machine exchange.

Go nuts.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Sheep look up (was: I-D Action:draft-klensin-rfc2821bis-10.txt)
Date:  Sat, 19 Apr 2008 11:08:53 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 45
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hector Santos wrote:

 [subject changed for a general remark about "the rules"] 
> Anyway, Tony decided.  When will it end?
> or isn't that sacred any more either?

IMO a shepherd is a volunteer for various procedural tasks,
a kind of "super-reviewer" for things that have to be done
by the sponsor (an area director) otherwise.

They prepare a "writeup" answering all questions in the
questionnnaire (see RFC 4858 for IETF WG drafts, a similar
ION for non-WG drafts went the way of all IONs recently).

For this job they need to check the ABNF and other formal
issues (idnits), they check public reviews, for the famous
"question 1F" they collect premature appeal cartooneys.

For a WG draft the shepherd is appointed by the WG Chairs,
and it typically is a Chair, it could also be a volunteer.
If the sponsoring AD has a problem with that (s)he is free
to do it the old way, without the help of the shepherd.

For a non-WG draft a shepherd can be appointed by the AD,
if there is no volunteer the sponsoring AD is free to do
it the old way, without the help of a shepherd.  

What shepherds do NOT is "decide" anything, apart from the
decision to volunteer.  For a non-WG draft only the author
decides what's in their drafts, and the sponsoring AD is
responsible for the "writeup", no matter who prepared it.

E.g., shepherds have no "write access" on the I-D tracker, 
maybe that will change for the "WG Chair is shepherd" case
in the future.  IOW, as far as the community is concerned,
the concept of a shepherd is a private arrangement between
the author and the sponsoring AD, and there are no appeals
against anything authors, editors, or shepherds might do -
the responsible parties are WG Chairs and ADs.

Only WG Chairs, ADs, IESG, and IAB can use the magic word
"consensus" in a meaningful way, anybody else trying this
(including me in this article ;-) is just talking.

 Frank

Date: Sat, 19 Apr 2008 03:19:02 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Douglas Otis <[email-masked]>
CC: Tony Finch <[email-masked]>, Paul Smith <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Douglas Otis wrote:

 > [snip]
 >
 > The future of SMTP and IPv6 is better protected by _not_
 > sanctioning AAAA as implied MX records and warning about the
 > possible deprecation of A records as implied MX records.   This
 > would move toward establishing the consistent treatment of A
 > and AAAA records, and properly acknowledging the rising
 > levels of SMTP abuse.

Hi Doug,

The way I see it, when you consider the overall desire that is being 
expressed, independent of what method is used to discover a host,  it 
all boils down to a SMTP client/server session have proper transaction 
variables.

So the ultimate question becomes:

     Must all mail senders have a RECEIVER available "somewhere"
     in order to receive a notification?

and if we wish to extend this to 2822,

     Must all transaction expose a valid RECEIVER in the 2822
     message reply fields (Reply-To:,  From:) in order for the
     user or some mailbot to send responses?

We are really talking about an authorization concept via a new SMTP 
compliancy proposal.

The technical details of MX, A, AAAA, IPv4, IPv6 is meaningless.  That's 
just the *how* in answering the above fundamental question(s).

Also, very important, it is an "authorization concept" for anonymous 
senders for local or hosted recipients because the way most systems 
behave today using traditional authorization or authentication methods, 
it is the when the client does not meet one or more of these criteria 
that any of this MX/A/AAAA issues would be important.

For our system, relay restrictions are completely bypassed when the 
client is authorized or authenticated using one of three methods:

   - IP allow relay tables,
   - ESMTP AUTH,
   - POP B4 SMTP

It is only when it is anonymous, do any "extra" sender checking come 
into play and in our case, only after the recipient is acceptable. This 
follows the principle described in Section 3.3 of 2821 and carried over 
to 2821bis:

    3.3.  Mail Transactions

    ..... Despite the apparent
    scope of this requirement, there are circumstances in which the
    acceptability of the reverse-path may not be determined until one or
    more forward-paths (in RCPT commands) can be examined.

[Side Point: To me, this is one of the most important statements in 
SMTP. Kudos the the author of that statement.  Any system that is doing 
return path checks at the SMTP level, will drastically improve it 
scalability and efficiency by following this "check recipient first, 
delayed return path verification" concept.]

Note, I am not questioning that an explicit MX requirement method is not 
a valid consideration.  I am questioning to what purpose?

Just consider the many transactions with addresses such as:

    no-reply @ validdomin.com

that many feedbacks system use today, including bad guys and the 
bad/good direct marketing people.

Well, an explicit MX does not resolve this problem of a response address 
not being reachable.

However, if it included other SMTP HOSTING requirements:

    Does it have a SERVICE PORT available?,
    Is the address acceptable at host?

then I think we would be closer to providing valid arguments behind the 
"WHY" we may want to even consider this idea.

I don't think I am saying anything odd here.

Much of this is all part of the basic concepts in RFC 3484 with its 
getaddrinfo() recommendations.  In fact, RFC 3484 does not have not even 
one mentioning of MX records.

But check out RFC 3482, specifically section 2 and section 8.

Then also read the following:

   RFC 3901 DNS IPv6 Transport Operational Guidelines
   RFC 4038 Application Aspects of IPv6 Transition
   RFC 4472 Operational Considerations and Issues with IPv6 DNS

In 4038 section 3.2, this note covers what we been partially debating:

    3.2.  DNS Does Not Indicate Which IP Version Will Be Used

    In a node, the DNS name resolver gathers the list of destination
    addresses.  DNS queries and responses are sent by using either IPv4
    or IPv6 to carry the queries, regardless of the protocol version of
    the data records [DNSTRANS].

    The DNS name resolution issue related to application transition is
    that by only doing a DNS name lookup a client application can not be
    certain of the version of the peer application.  For example, if a
    server application does not support IPv6 yet but runs on a dual-stack
    machine for other IPv6 services, and this host is listed with an AAAA
    record in the DNS, the client application will fail to connect to the
    server application.  This is caused by a mismatch between the DNS
    query result (i.e., IPv6 addresses) and a server application version
    (i.e., IPv4).

It touches base with using not MX but SRV as a discovery method.  But 
note again, not even one mentioning of MX records!!

But this statement is critical:

    The application should request all IP addresses without address
    family constraints and try all the records returned from the DNS, in
    some order, until a working address is found.  In particular, the
    application has to be able to handle all IP versions returned from
    the DNS.  This issue is discussed in more detail in [DNSOPV6].

This is where the SERVICE PORT and idea of using SERVICE NAMES comes 
into play.

In RFC 4472, section 4.1 it says:

    4.1.  Use of Service Names instead of Node Names

    ..

    For example, assume a node named "pobox.example.com" provides both
    SMTP and IMAP service.  Instead of configuring the MX records to
    point at "pobox.example.com", and configuring the mail clients to
    look up the mail via IMAP from "pobox.example.com", one could use,
    e.g., "smtp.example.com" for SMTP (for both message submission and
    mail relaying between SMTP servers) and "imap.example.com" for IMAP.
    Note that in the specific case of SMTP relaying, the server itself
    must typically also be configured to know all its names to ensure
    that loops do not occur.  DNS can provide a layer of indirection
    between service names and where the service actually is, and using
    which addresses.  (Obviously, when wanting to reach a specific node,
    one should use the hostname rather than a service name.)

Note that last sentence as well - a continuation of the implicit MX concept.

And here is an important section 4.3 is I fully agree with:

    4.3.  Adding the Records Only When Fully IPv6-enabled

    The recommendation is that AAAA records for a service should not be
    added to the DNS until all of following are true:

    1.  The address is assigned to the interface on the node.

    2.  The address is configured on the interface.

    3.  The interface is on a link that is connected to the IPv6
        infrastructure.

    In addition, if the AAAA record is added for the node, instead of
    service as recommended, all the services of the node should be IPv6-
    enabled prior to adding the resource record.

    For example, if an IPv6 node is isolated from an IPv6 perspective
    (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
    that it should not have an address in the DNS.

All that basically means that its going to leak into the IPv4 network 
cloud, it better be ready to allow for a reverse communications.

Then we get to section 5.1, and again the all encompassing getaddrinfo() 
recommendation:

5.1.  DNS Lookups May Query IPv6 Records Prematurely

    The system library that implements the getaddrinfo() function for
    looking up names is a critical piece when considering the robustness
    of enabling IPv6; .....

and finally on a slightly different but highly critical related note, 
see section of 7.1 regarding how PTR lookups may or may not be necessary 
  any more under IPv6.

   7.1.  Applicability of Reverse DNS

   ...

   It is not clear whether it makes sense to require or recommend that
   reverse DNS records be updated.  In many cases, it would just make
   more sense to use proper mechanisms for security (or topological
   information lookup) in the first place.  At minimum, the applications
   that use it as a generic authorization (in the sense that a record
   exists at all) should be modified as soon as possible to avoid such
   lookups completely.

All and all Doug, making a decision now about implicit MX in 2821bis 
might be the wrong move when one begins to implement IPv6 with the 
current recommendations.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 18 Apr 2008 17:23:00 -0600
From: Willie Gillespie <[email-masked]>
Organization: Engineering System Solutions
To: Douglas Otis <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Douglas Otis wrote:
> On Apr 18, 2008, at 3:27 AM, Tony Finch wrote:
> 
>>
>> On Fri, 18 Apr 2008, Paul Smith wrote:
>>>
>>> - Implicit MX. This causes me problems by (a) bunging up my mail
>>> server retry queue, and (b) loading my non-mail server hosts with the
>>> thousands of bounces to forged messages trying to be sent to them.
>>> (a) might be easy to spot, but is nearly impossible for me to fix
>>> (without 'stretching' the standard - eg by having different retry
>>> algorithms for implicit vs explicit MX records), (b) is hard to spot
>>> what's happening without a packet tracer and knowing how to use one
>>> and is hard to fix since i need to do something to add 'non-MX'
>>> records to all my hosts, which could be hundreds of 'non-MX' records.
>>
>> Different retry algorithms for MX-less domains is already standard
>> operational practise. For example see timeout_connect_A and refused_A
>> at
>> http://www.exim.org/exim-html-current/doc/html/spec_html/ch32.html#SECID162
>>
>>
>> I think you're exaggerating the problem that a few SYN packets cause.
> 
> 
> Paul makes valid points.  The size of the problem depends upon the
> non-SMTP host implementation and the size of its network.  After all,
> IPv6 permits a greater number of devices on the Internet.
> 
> John Levine offered an example:
> http://www.imc.org/ietf-smtp/mail-archive/msg04444.html
> 
> This example was a host not running SMTP continuously receiving
> undesired attempts for 30,000 spams per day.  This also likely includes
> traffic needed to establish whether port 25 connections are possible by
> legitimate MTAs checking return paths upon message reception.  If the
> host represented an intelligent parking meter over a slow IPv6 wireless
> network, this undesired traffic may not be considered negligible. 
> Several have suggested the means to avoid this undesired SMTP traffic is
> to publish bogus MX records for each host.  The bogus MX records direct
> undesired traffic to the root servers. (Yet another entity needing to
> pay for the AAAA implicit MX record convenience.)
> 
> The convenience afforded to administrators of IPv6 AAAA only SMTP
> servers comes at the expense of those receiving SMTP traffic and those
> administrating other protocols.  Ironically, those sensitive to abuse
> directed to SMTP are expected to endure it or redirect this traffic to
> root servers by publishing bogus MX records.  Standardizing on AAAA
> being implied MX records thereby increases overall administrative
> burdens, SMTP server overhead, and yet ultimately this is likely to
> prevent interoperation due to ensuing defensive strategies.  The future
> of SMTP and IPv6 is better protected by _not_ sanctioning AAAA as
> implied MX records and warning about the possible deprecation of A
> records as implied MX records.   This would move toward establishing the
> consistent treatment of A and AAAA records, and properly acknowledging
> the rising levels of SMTP abuse.
> 
> -Doug

+1

Cc: Paul Smith <[email-masked]>, [email-masked]
From: Douglas Otis <[email-masked]>
To: Tony Finch <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Date: Fri, 18 Apr 2008 15:32:49 -0700
Sender: [email-masked]

On Apr 18, 2008, at 3:27 AM, Tony Finch wrote:

>
> On Fri, 18 Apr 2008, Paul Smith wrote:
>>
>> - Implicit MX. This causes me problems by (a) bunging up my mail  
>> server retry queue, and (b) loading my non-mail server hosts with  
>> the thousands of bounces to forged messages trying to be sent to  
>> them. (a) might be easy to spot, but is nearly impossible for me to  
>> fix (without 'stretching' the standard - eg by having different  
>> retry algorithms for implicit vs explicit MX records), (b) is hard  
>> to spot what's happening without a packet tracer and knowing how to  
>> use one and is hard to fix since i need to do something to add 'non- 
>> MX' records to all my hosts, which could be hundreds of 'non-MX'  
>> records.
>
> Different retry algorithms for MX-less domains is already standard  
> operational practise. For example see timeout_connect_A and  
> refused_A at http://www.exim.org/exim-html-current/doc/html/spec_html/ch32.html#SECID162
>
> I think you're exaggerating the problem that a few SYN packets cause.

Paul makes valid points.  The size of the problem depends upon the non- 
SMTP host implementation and the size of its network.  After all, IPv6  
permits a greater number of devices on the Internet.

John Levine offered an example:
http://www.imc.org/ietf-smtp/mail-archive/msg04444.html

This example was a host not running SMTP continuously receiving  
undesired attempts for 30,000 spams per day.  This also likely  
includes traffic needed to establish whether port 25 connections are  
possible by legitimate MTAs checking return paths upon message  
reception.  If the host represented an intelligent parking meter over  
a slow IPv6 wireless network, this undesired traffic may not be  
considered negligible.  Several have suggested the means to avoid this  
undesired SMTP traffic is to publish bogus MX records for each host.   
The bogus MX records direct undesired traffic to the root servers.  
(Yet another entity needing to pay for the AAAA implicit MX record  
convenience.)

The convenience afforded to administrators of IPv6 AAAA only SMTP  
servers comes at the expense of those receiving SMTP traffic and those  
administrating other protocols.  Ironically, those sensitive to abuse  
directed to SMTP are expected to endure it or redirect this traffic to  
root servers by publishing bogus MX records.  Standardizing on AAAA  
being implied MX records thereby increases overall administrative  
burdens, SMTP server overhead, and yet ultimately this is likely to  
prevent interoperation due to ensuing defensive strategies.  The  
future of SMTP and IPv6 is better protected by _not_ sanctioning AAAA  
as implied MX records and warning about the possible deprecation of A  
records as implied MX records.   This would move toward establishing  
the consistent treatment of A and AAAA records, and properly  
acknowledging the rising levels of SMTP abuse.

-Doug

Date: Fri, 18 Apr 2008 15:47:23 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Lisa Dusseault <[email-masked]>
CC: Paul Smith <[email-masked]>, Keith Moore <[email-masked]>, Tony Finch <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Lisa Dusseault wrote:
> 
> My serious offer here is that if somebody sees a way towards consensus 
> on the implicit MX issue, please help find it or build it.  The result 
> of that consensus may not go into this document, but I will help to get 
> the consensus documented and published.

What are looking for here?

All I see here is an "Enforcement" argument.

     Thou shall not do implicit MX lookups anymore.
     Thou shall enforce MX records.

Even if this was written into 2821bis, I fail to grasp how any 
commercial vendor is their right mind is going to heed that without 
being concern of the potential harm to their customer base, and worst - 
increase support issues!

Maybe if there was some NEW identifier marker that would put the client 
into a whole new category, then we can say

        "ok, now that DUDE must have MX records"

Can we say this for an IPv6 layer connection?  Well, there might be 
opportunity to do this with minimal damage.  But we really don't know, 
do we?

We can't say that for IPv4 connections.  The long term autonomous nature 
of the SMTP system will broken.

Paul is off base with a presumption this has no cost impact.  It isn't
just 2-4 lines of code change.

At best, it can probably be mentioned as a DIRECTION so the contemporary 
vendors can assert a deprecated option.  But to completely
turn it off without any other information to work with?  I don't think so.

And off course, none of this stops DNS managers / SMTP operators from 
running a proper setup too.

Anyway, Tony decided.  When will it end? or isn't that sacred any more 
either?

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 18 Apr 2008 15:08:28 -0400
From: Keith Moore <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: Paul Smith <[email-masked]>, Tony Finch <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

I'll say that I don't want to see 2821bis held up any more over this.  A 
better treatment of IPv6-related issues in SMTP is needed, but it should 
be done in a separate document.

And in a separate document we'll be freer to say what we think is best 
because we won't have concerns about resetting 2821bis to proposed.
(I think this indicates a flaw in our process, BTW, but we're not going 
to change the process by holding up 2821bis).

Keith

p.s. More generally, I think we've seen enough by now to realize that 
neither a hodgepodge of documents where each one modifies its 
predecessors in various ways (think RFC 821, 974, 1123, and SMTP 
extensions) , nor a monolithic document that tries to be 
all-encompassing and is completely revised every several years, is a 
good way to define a standard for a complex, evolving, and vital service 
like Internet email.

Lisa Dusseault wrote:
> 
> On Apr 17, 2008, at 11:09 PM, Paul Smith wrote:
> 
>>
>> Keith Moore wrote:
>>>
>>> Oh, I saw that message.  I just didn't see the consensus.
>> It wasn't a consensus, it was a unilateral statement based on the fact 
>> that there wasn't a consensus.
> 
> Given that we're revising an ambiguous document, it was a conservative 
> decision, even if it was a unilateral statement and even if the 
> consensus on something new to recommend isn't clear.
> 
>>
>> I think it was totally the wrong action.
> 
> I also think arguing interminably, or otherwise failing to publish 2821 
> bis, would be the wrong action.  There are few situations where we just 
> can't get consensus in a timely manner in the IETF and have to do 
> something else, and the right thing to do as that "something else" is 
> case-dependent.
> 
> My serious offer here is that if somebody sees a way towards consensus 
> on the implicit MX issue, please help find it or build it.  The result 
> of that consensus may not go into this document, but I will help to get 
> the consensus documented and published.
> 
> Lisa
> 

Cc: Keith Moore <[email-masked]>, Tony Finch <[email-masked]>, [email-masked]
From: Lisa Dusseault <[email-masked]>
To: Paul Smith <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Date: Fri, 18 Apr 2008 12:01:16 -0700
Sender: [email-masked]

On Apr 17, 2008, at 11:09 PM, Paul Smith wrote:

>
> Keith Moore wrote:
>>
>> Oh, I saw that message.  I just didn't see the consensus.
> It wasn't a consensus, it was a unilateral statement based on the  
> fact that there wasn't a consensus.

Given that we're revising an ambiguous document, it was a conservative  
decision, even if it was a unilateral statement and even if the  
consensus on something new to recommend isn't clear.

>
> I think it was totally the wrong action.

I also think arguing interminably, or otherwise failing to publish  
2821 bis, would be the wrong action.  There are few situations where  
we just can't get consensus in a timely manner in the IETF and have to  
do something else, and the right thing to do as that "something else"  
is case-dependent.

My serious offer here is that if somebody sees a way towards consensus  
on the implicit MX issue, please help find it or build it.  The result  
of that consensus may not go into this document, but I will help to  
get the consensus documented and published.

Lisa

Date: Fri, 18 Apr 2008 11:27:11 +0100
From: Tony Finch <[email-masked]>
To: Paul Smith <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Fri, 18 Apr 2008, Paul Smith wrote:
>
> - Implicit MX. This causes me problems by (a) bunging up my mail server
> retry queue, and (b) loading my non-mail server hosts with the thousands
> of bounces to forged messages trying to be sent to them. (a) might be
> easy to spot, but is nearly impossible for me to fix (without
> 'stretching' the standard - eg by having different retry algorithms for
> implicit vs explicit MC records), (b) is hard to spot what's happening
> without a packet tracer and knowing how to use one and is hard to fix
> since i need to do something to add 'non-MX' records to all my hosts,
> which could be hundreds of 'non-MX' records.

Different retry algorithms for MX-less domains is already standard
operational practise. For example see timeout_connect_A and refused_A at
http://www.exim.org/exim-html-current/doc/html/spec_html/ch32.html#SECID162

I think you're exaggerating the problem that a few SYN packets cause.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER: EAST OR NORTHEAST 5 TO 7, OCCASIONALLY GALE 8 IN DOVER.
MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.

Date: Fri, 18 Apr 2008 07:09:15 +0100
From: Paul Smith <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Keith Moore wrote:
>
> Oh, I saw that message.  I just didn't see the consensus.
It wasn't a consensus, it was a unilateral statement based on the fact 
that there wasn't a consensus.

I think it was totally the wrong action.

There are two possible 'results' to the disagreement:

- No implicit MX. This causes me a problem with mail being delivered to 
me if I don't have an explicit MX record or an A record, only an AAAA 
record. This causes no mail to be delivered to me, so is easy to spot, 
and trivial to fix - I just need to add a single MX (or A) record
- Implicit MX. This causes me problems by (a) bunging up my mail server 
retry queue, and (b) loading my non-mail server hosts with the thousands 
of bounces to forged messages trying to be sent to them. (a) might be 
easy to spot, but is nearly impossible for me to fix (without 
'stretching' the standard - eg by having different retry algorithms for 
implicit vs explicit MC records), (b) is hard to spot what's happening 
without a packet tracer and knowing how to use one and is hard to fix 
since i need to do something to add 'non-MX' records to all my hosts, 
which could be hundreds of 'non-MX' records.

Now, which of those options sounds like it causes the worse problems?

'no implicit mx' may be slightly harder to implement in the mail server, 
but it IS *slightly*, and the cost of 3 or 4 lines of code isn't that 
much, so it isn't really much of an argument IMHO.

Date: Thu, 17 Apr 2008 22:04:47 -0400
From: Keith Moore <[email-masked]>
To: SM <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

SM wrote:

> The main problem stems from when you don't get NXDOMAIN.

well, if you're dealing with an ISP that violates the DNS specs, you 
can't expect any application to work correctly.

it's pretty difficult to write protocol specifications that work in the 
presence of gross violations of those specifications.

Keith

Date: Thu, 17 Apr 2008 21:52:48 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SM <[email-masked]>
CC: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

SM wrote:

> The main problem stems from when you don't get NXDOMAIN.

as well as ultimately, no SMTP service port.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 17 Apr 2008 17:26:30 -0700
To: Keith Moore <[email-masked]>
From: SM <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: [email-masked]
Sender: [email-masked]

Hi Keith,
At 14:17 17-04-2008, Keith Moore wrote:
>My point is that we're getting tripped up by an artifact of the way 
>that RFCs 974 was worded - and in the process we're making 
>inferences about the interpretation of those words that probably 
>weren't intended by the author.  If RFC 974 had said

That's the problem with RFCs.  No matter how the specifications are 
worded, they can give way to various interpretations.  As the 
collective memory fades away, we try to guess the intent of the author.

>...then I think we'd be paying attention to the salient issue in our 
>discussions today - which is that "give it the benefit of the doubt" 
>is no longer the right idea.  (granted we still have the backward 
>compatibility issue, but that's less important for v6 than for v4).

The only way to determine that would be to ask the author of that 
text.  I think it's a bit far-fetched as we will never get this work done then.

>p.s. Before sending this reply, I considered how I'd write the code 
>in both cases - one where the "get MX records" routine returned an 
>implicit MX in the case of no explicit MX records, and the other 
>where it did not. Mostly the differences seem to be

The main problem stems from when you don't get NXDOMAIN.

Regards,
-sm 

Date: Thu, 17 Apr 2008 17:17:52 -0400
From: Keith Moore <[email-masked]>
To: John Leslie <[email-masked]>
CC: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

John Leslie wrote:
>    Let me apologize up front for taking Keith seriously; but he has taken
> me seriously on several occasions, and I feel an obligation to return the
> favor:

gee thanks.  I think.

>    That pseudocode deserves to be read; though I'd pay more attention
> to the difference between "permanent_failure" and "temporary_failure".
> 
>> And if you're writing code to do this in an IPv4-only world, it's 
>> tempting to put a special case in the "get mx records" routine of the 
>> form "if there are no MX records, return a single "implicit" pseudo-MX 
>> record that points to that domain".
> 
>    Actually, I wouldn't have tended to program it that way. I think the
> point is it looked to be easier to _specify_ it that way.

That's just a hypothesis on my part.  I may be reading more into the RFC 
974 than is justified.

My point is that we're getting tripped up by an artifact of the way that 
RFCs 974 was worded - and in the process we're making inferences about 
the interpretation of those words that probably weren't intended by the 
author.  If RFC 974 had said

    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 simply 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.

instead of

    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.

...then I think we'd be paying attention to the salient issue in our 
discussions today - which is that "give it the benefit of the doubt" is 
no longer the right idea.  (granted we still have the backward 
compatibility issue, but that's less important for v6 than for v4).

In an IPv4+IPv6 world this becomes even a bit more important.
> 
>    Let's see if Keith can make this case...

Well, my point was that we're making inferences based on the "implicit 
MX" idea that might not really be warranted.  As I said above, I might 
be reading too much into the intent behind the RFC 974 wording.   If the 
only purpose of that code analysis is to support my assumptions about 
the motivation for the wording in RFC 974, it might not be worth the 
trouble to try to explain it.  (but if you're really curious, see the 
postscript below)

Keith

p.s. Before sending this reply, I considered how I'd write the code in 
both cases - one where the "get MX records" routine returned an implicit 
MX in the case of no explicit MX records, and the other where it did 
not. Mostly the differences seem to be

(a) if you get NXDOMAIN when trying to find addresses from an explicit 
MX record, this need not cause delivery failure - you just skip to the 
next MX record.  It's only a problem when you get NXDOMAIN for all of 
the MX records - and then it's still a subtly different error from the 
case where you get NXDOMAIN on the domain name that appears in the email 
address (and in the "implicit MX" record).

(b) similar to (a) but instead of NXDOMAIN errors you get a response 
with no answers to your query for address records.  again, for an 
ordinary MX record this isn't fatal, but for an "implicit MX" record it 
is fatal.  (but it's a slightly different case than (a) in that you 
probably want to issue a different error message).

(c) if the "get MX records" routine doesn't return an implicit MX 
record, you can avoid a few unnecessary DNS queries.  but if you have an 
internal DNS cache in your MTA this might not matter much.

Date: Thu, 17 Apr 2008 16:06:07 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

At 14:52 +0100 on 04/17/2008, Tony Finch wrote about Re: I-D 
Action:draft-klensin-rfc2821bis-10.txt:

>On Thu, 17 Apr 2008, Arnt Gulbrandsen wrote:
>>
>>  I still can't understand why so many people here think an AAAA 
>>should suffice.
>
>I think it's more that a host with A and AAAA should be able to receive
>email via AAAA even without an MX.
>
>Tony.

I think part of the problem is that there is a confusion between a 
host that happens to have a FQDN that was used in a user@FQDN email 
address and the SMTP Servers that are designated as the authorized 
method of delivering email to users with that FQDN email addresses.

There is no requirement that a host pointed to by a FQDN A or AAAA 
record be running an SMTP Server that is responsible for accepting 
mail addressed to a FQDN email address. The responsible SMTP Servers 
are supposedly designated by an MX record that points at the A and 
AAAA records of the hosts running SMTP MTAs that are responsible for 
the FQDN domain (hosts who might not have FQDN as their host name). 
The direct use of the hosts pointed to by an A record in the absence 
of a FQDN MX is for 20+ year old historical reasons that ASSUME that 
the hosts pointed to by the FQDN A records ARE running an MTA that is 
willing to accept FQDN email. Use of an AAAA record (or an A record) 
in the absence of an MX record is only viable (let alone valid) WHEN 
those A and/or AAAA hosts ARE running an MTA. In the case where this 
assumption is incorrect, the correct hosts for the FQDN MUST be 
located via an MX record for that FQDN (the simulation of a FQDN MX 0 
FQDN record in the absence of an physical/explicit MX record is thus 
only valid when the FQDN A and AAAA records DO point at hosts running 
MTAs).

While allowing the use of AAAA records in the absence of an MX (in 
the way that A records are currently allowed to be used) might work 
(although IMO a dangerous procedure), there should at least be some 
statement [in whatever document that authorizes this method of 
finding IPv6 reachable MTAs in lieu of using an explicit MX pointing 
at the IPv4 and IPv6 hosts running MTAs] that this failure to supply 
an MX is only allowed if ALL hosts with the FQDN name ARE running 
MTAs (IOW: If/When ANY of the FQDN names hosts are not running an 
MTA, a MX MUST be supplied and direct use of A and/or AAAA records 
with the FQDN host name is NOT supported).

Since it seems (and I agree with this stance) that attempts to 
deprecate the A-Fallback behavior is not politically viable right 
now, the best short-term solution is to discourage the use of A (and 
definitely AAAA) records and to document the situations when they can 
be used (ie: When the Domain DNS Administrator KNOWS [not just 
ASSUMES] that the A and AAAA records point at MTA running hosts), and 
recommend the use of MX records to insure that only MTA running hosts 
are contacted to receive email.

Date: Thu, 17 Apr 2008 15:41:18 -0400
From: John Leslie <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: John C Klensin <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

   Let me apologize up front for taking Keith seriously; but he has taken
me seriously on several occasions, and I feel an obligation to return the
favor:

Keith Moore <[email-masked]> wrote:
> 
> I've always thought the "implicit MX generation" language was a bit 
> contrived.  Really what was needed was not an "implicit MX" per se, but 
> rather, backward compatibility with the pre-MX behavior that if you 
> wanted to send mail to user@domain and you had an IP address for that 
> domain, you opened up a connection to port 25 at that IP address and 
> started talking SMTP to it.

   This was indeed needed, back when RFC821 was written.

   It's not clear what else may have been needed then, but arguably
that would have been sufficient -- then.

> If you're a programmer and writing code to handle this, it's pretty 
> natural to want a routine that gets you an ordered list of MX records. 
>   That way you can say something like:
> 
> mxlist = get_mx_records_in_order (domain)
> for each mx in mxlist {
>     status = try to deliver mail to mx;
>     if status = success
>        break
>     else if status = permanent_failure
>        bounce_message()
>        break
>     else if status = temporary_failure
>        continue
> }

   That pseudocode deserves to be read; though I'd pay more attention
to the difference between "permanent_failure" and "temporary_failure".

> And if you're writing code to do this in an IPv4-only world, it's 
> tempting to put a special case in the "get mx records" routine of the 
> form "if there are no MX records, return a single "implicit" pseudo-MX 
> record that points to that domain".

   Actually, I wouldn't have tended to program it that way. I think the
point is it looked to be easier to _specify_ it that way.

> But what is really happening here is that the special-casing is being 
> done in the wrong place.  Even in an IPv4-only world it is better to 
> treat the "MX" and "no MX" cases separately in the delivery routine 
> rather than to try to hide the differences in the mx lookup routine.

   I agree with Keith here, and would implement it that way. There's
nothing in 821 or 2821 to stop me...

> In an IPv4+IPv6 world this becomes even a bit more important.

   Let's see if Keith can make this case...

> John C Klensin <[email-masked]> wrote:
> 
>> And I believe that "interpret some MXs as applying only to the A
>> records associated with the target host while interpreting
>> others as applying to all address records" as leading us into a
>> world of confusion and harm.
> 
> I agree with that, but because I don't think the "implicit MX record" 
> was a good way to describe the algorithm, I don't see a problem here. 
> If you get real MX records and they point to domains that have A and/or 
> AAAA records you should assume that all of those records are valid. 
> It's only the "implicit MX" record that causes a problem.

   ... be patient...

>> (ii) It would be mildly insane operationally (or at least
>> stupidly careless) for someone to configure the DNS records for
>> an IPv6-only host without MX records that specify IPv4 access to
>> that host.
> 
> In the near term, yes. Though perhaps this might be reasonable by the 
> time RFC 2822bis gets revised again...

   True, but surely there's more to Keith's case than that!

> Keith

   Or is there?

--
John Leslie <[email-masked]>

Date: Thu, 17 Apr 2008 14:25:16 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Oh, I saw that message.  I just didn't see the consensus.

Tony Finch wrote:
> On Thu, 17 Apr 2008, Keith Moore wrote:
>> Tony Finch wrote:
>>> That's the consensus result of the argument.
>> I must have missed that consensus.
> 
> You didn't: you replied to other-Tony's announcement saying you disagree
> with it.
> 
> Tony.

Date: Thu, 17 Apr 2008 14:24:34 -0400
From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked], Tony Finch <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

> 
> Speaking for myself and not presuming to speak for "many
> people", I think the following statements are both true and that
> they are perfectly consistent with each other.
> 
> (i) It would be a fairly bad idea for the protocol to require an
> MX record for AAAA but not for A.  Part of my reasoning is that
> some of the arguments for prohibiting implicit MX generation on
> AAAA fall apart for hosts that also have IPv4 addresses, since
> those addresses will cause the the MXs to be generated anyway.

I've always thought the "implicit MX generation" language was a bit 
contrived.  Really what was needed was not an "implicit MX" per se, but 
rather, backward compatibility with the pre-MX behavior that if you 
wanted to send mail to user@domain and you had an IP address for that 
domain, you opened up a connection to port 25 at that IP address and 
started talking SMTP to it.

If you're a programmer and writing code to handle this, it's pretty 
natural to want a routine that gets you an ordered list of MX records. 
   That way you can say something like:

mxlist = get_mx_records_in_order (domain)
for each mx in mxlist {
     status = try to deliver mail to mx;
     if status = success
        break
     else if status = permanent_failure
        bounce_message()
        break
     else if status = temporary_failure
        continue
}

And if you're writing code to do this in an IPv4-only world, it's 
tempting to put a special case in the "get mx records" routine of the 
form "if there are no MX records, return a single "implicit" pseudo-MX 
record that points to that domain".  Then the code that calls this 
routine will "do the right thing"...more or less.  (I say "more or less" 
because there are subtly different error conditions for the "real MX" 
case than for the "implicit pseudo-MX" case that might require more 
special-casing to handle errors correctly under all conditions.)

But what is really happening here is that the special-casing is being 
done in the wrong place.  Even in an IPv4-only world it is better to 
treat the "MX" and "no MX" cases separately in the delivery routine 
rather than to try to hide the differences in the mx lookup routine.  In 
an IPv4+IPv6 world this becomes even a bit more important.

> And I believe that "interpret some MXs as applying only to the A
> records associated with the target host while interpreting
> others as applying to all address records" as leading us into a
> world of confusion and harm.

I agree with that, but because I don't think the "implicit MX record" 
was a good way to describe the algorithm, I don't see a problem here. 
If you get real MX records and they point to domains that have A and/or 
AAAA records you should assume that all of those records are valid. 
It's only the "implicit MX" record that causes a problem.

> (ii) It would be mildly insane operationally (or at least
> stupidly careless) for someone to configure the DNS records for
> an IPv6-only host without MX records that specify IPv4 access to
> that host.

In the near term, yes.   Though perhaps this might be reasonable by the 
time RFC 2822bis gets revised again...

Keith

Date: Thu, 17 Apr 2008 14:19:30 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Keith Moore <[email-masked]>
CC: Dave Crocker <[email-masked]>, Henning Schulzrinne <[email-masked]>, Tony Hansen <[email-masked]>, SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Keith Moore wrote:
> Dave Crocker wrote:
> 
>> Yeah, this "running code" thing is over-rated.
> 
> indeed it is.  many people are so accustomed to accepting the problems 
> with today's large-scale email operation that they fail to see how 
> things could be any other way.  after all, it "works"...sort of.

+1

>> It also presumes that those implementing code operate wholly 
>> independently of those who will operate or use that running code.
> 
> no.  it only presumes that when the standard says one thing and the 
> needs of operators say something else, that the implementor is placed in 
> an awkward position.

+1000

Thank you for seeing this Keith.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 17 Apr 2008 19:01:15 +0100
From: Tony Finch <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Thu, 17 Apr 2008, Keith Moore wrote:
> Tony Finch wrote:
> >
> > That's the consensus result of the argument.
>
> I must have missed that consensus.

You didn't: you replied to other-Tony's announcement saying you disagree
with it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE: NORTHEASTERLY 4, INCREASING 5 OR 6 IN NORTH. MODERATE.
FAIR. GOOD.

Date: Thu, 17 Apr 2008 13:54:34 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

I must have missed that consensus.

Tony Finch wrote:
> On Thu, 17 Apr 2008, Keith Moore wrote:
>> Tony Finch wrote:
>>> I think it's more that a host with A and AAAA should be able to receive
>>> email via AAAA even without an MX.
>> why?
> 
> That's the consensus result of the argument.
> 
> Tony.

Date: Thu, 17 Apr 2008 13:50:27 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: IPv6 addresses and IPv4 hosts
Sender: [email-masked]

John C Klensin wrote:
> 
> --On Thursday, 17 April, 2008 08:19 -0400 Hector Santos
> <[email-masked]> wrote:
> 
>> Arnt Gulbrandsen wrote:
>>> I'm willing to take that on, unless anyone minds.
>>>
>>> Arnt
>> If you wish help, I would be willing to pencil in the time.
>>
>> I did begin last week an outline that I can pass on with
>> collected research of past work and industry experiences and
>> presentations highlight the major concerns and technical
>> issues with the current proposals.
>>
>> I personally would like to suggest that this BCP be a guide to
>> help multiple audiences with a smooth transition to Ipv6
>>
>>    - DNS Administration
>>    - System implementor/integrators, network engineers
>>    - Software Developers
>>    - Operators
>>    - End Users
> 
> Hector, fwiw, despite the pattern in some desktop systems to
> require that everyone and their grandmother have the skills of
> system and network administrators, I suggest that path is
> ultimately a failure.  As a result, I believe that if end users
> need to worry about what is happening at the Internet layer and
> how to adjust to it, it would be a sign that all of the other
> layers and actors in this process have failed.  I would rather
> concentrate on not failing than on trying to inform end users --
> people who see the mail system only through the MUAs or web
> interfaces they use and the error messages they receive -- about
> what is going on here.
> 
> There might be need for what the IETF used to call an FYI RFC to
> explain some of the disconnects and the messages they cause to
> those end users, but I'd think the entire effort would progress
> better and more efficiently if they were kept separate.
> 
>     john

I Agree.

The inclusion of end-users was more for responsible parties/implementers 
to gain insight on what impact it has on their user base and how they 
may better address it when you begin to consider IPv6.  For example:

- how will this alter POP B4 SMTP Methods which is a very big part
   of reducing help desk support cost for many cost conscious ISPs.

and thats just one of many questions related to end-user impact.

As you would probably agree, such insight will help people prepare 
information they might need for their users and company.  I didn't want 
to dig more into that other than throw out the coverage.

It is my opinion if one goal here to we help the industry migration, 
then at this point we need to take our blinders off and understand not 
everyone is at the same level as the early explorers. I don't need 
lacking direct IPv6 experience forfeits or trump long time engineering 
insights and planning.  This is highly complex stuff and I believe it 
will take us to do a good job in presenting a clear consolidated 
documentation on how to get from point A to AB to B.

Just ask these fundamentals questions:

- How do you get an IPv6 address(es)?

- How do you implement it?

- What's the relative cost impact?  No specifics, but cost is no doubt 
going to be a prohibiting factor for many.  This might suggest IPv4 
might not go away for a lot longer than anyone here thinks.

- Can you lose IPv4 addresses once you request your IPv6 allocation? 
Again, not a political question, but how that alter your plans for FULL 
or HYBRID IPv6 hosting services?

- Do you need extra software besides getting your SMTP vendor to support 
IPv6?

- Will you need to switch SMTP vendor?

- Do you need to upgrade to new (hardware) routers?

- Do you need to write anything yourself?

- How do we handle users?

- Do you need to have separate processes running, IPv4 and IPv6 as 
suggested by one of the RFCs?

- Or will it work just fine as a single process IPv4/6 hybrid?

- What is 6to4? Is that part of the total implementation?

- Can I use just IPv6 and depend on my uplink offering a dual stack gateway?

Oh gosh, a whole slew of general questions, and I am not saying all of 
this needs to be addressed  but to rather bring it out all so we can get 
a better picture of what are all the issues to create the focused document.

I mean, I think we just touch based with just a part of it:

- How does the IPv6 stack change the security picture?

- How does all the new "Features" of IPv6 change SMTP mail distribution?

- Is "PTR" lookup a viable idea? Is it necessary now?

- Can systems need to do a CBV or can they stop doing return path 
verification and begin using the inherent IPv6 stack IP connectivity 
information?  Ethernet tracking/tracing?

- Do we need new SMTP EHLO extensions? Can a new extension help with an 
orderly migration?

- How does it change any other SMTP related extension?

- What effect will it have on such technology as:

    - SPF, SENDERID?
    - DKIM, DOMAINKEYS?
    - SpamAssassin?
    - Sieve?

- Some people have already suggested that getaddrinfo() be patched to
   remove redundancy in AAAA lookups? Is this a valid issue to address?
   How does that change the RFC 3484 recommendations?

- Is there any change in TCP timeouts?  Does IPv6 stack goes idle?  Do 
we need to change state machine timeouts?

and I haven't even begun to outline the concerns I have at the coding 
area and how IPv6 can change the SMTP model as a first in where IPv6 
dictates implementation methods, i.e. how discovery is implemented with 
getaddrinfo().  Can this "document" be written and described where its 
doesn't need to be locked in stone with a socket level 2 API function?

Again, the above is just a small list of questions I think that should 
be on the table, some are very important, some can be kick out, and I'm 
sure there are others that have better questions that is more focused 
with their own experiences and noticed I didn't even bother to bring up 
the IMPLICIT MX issue but no doubt that would be a part of all this.

I just think the IETF can do a better job to promote this type of 
consolidated work to help with the desire to move people to the IPv6 
world at a more reasonable and understood manner rather than just hope 
it will take place on a wing and prayer with mixed information.

On a personal level, we have a Class C group of IPv4 addresses, and I 
don't even know all that is needed or that I could even move into IPv6 
without getting other entities involved, like my ISP uplink, MCI/UUNET 
now own by Verizon. I need to find out is CISCO has updates for my 
router or are they going to force a hardware change.  Of course, the 
specifics like this is not what we want to write, but maybe how the 
general situation applies in IPv6/4 implementation.

And of course, finally, we will need wisdom from people like you to help 
  keeping it all focused.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 17 Apr 2008 13:47:51 -0400
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: Henning Schulzrinne <[email-masked]>, Tony Hansen <[email-masked]>, SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Dave Crocker wrote:

> Yeah, this "running code" thing is over-rated.

indeed it is.  many people are so accustomed to accepting the problems 
with today's large-scale email operation that they fail to see how 
things could be any other way.  after all, it "works"...sort of.

> It does have one characteristic that seems to be missing from your own 
> varied assertions about nasty impact:  observable data.

there's plenty of observable data to support the assertions about nasty 
impact.

> It also presumes that those implementing code operate wholly 
> independently of those who will operate or use that running code.

no.  it only presumes that when the standard says one thing and the 
needs of operators say something else, that the implementor is placed in 
an awkward position.

> And the claim of more spam was directly addressed as being wrong.
> 
> So perhaps you can show an empirical basis for your claims of doom and 
> gloom?

so perhaps you can show an empirical basis for your claim of superiority ?

I didn't think so.

Keith

Date: Thu, 17 Apr 2008 18:47:26 +0100
From: Tony Finch <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Thu, 17 Apr 2008, Keith Moore wrote:
> Tony Finch wrote:
> >
> > I think it's more that a host with A and AAAA should be able to receive
> > email via AAAA even without an MX.
>
> why?

That's the consensus result of the argument.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: EAST OR NORTHEAST 5 TO 7, OCCASIONALLY GALE 8 IN SOUTH. MODERATE OR
ROUGH. SHOWERS. GOOD.

Date: Thu, 17 Apr 2008 13:44:21 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked], John C Klensin <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Tony Finch wrote:
> On Thu, 17 Apr 2008, Arnt Gulbrandsen wrote:
>> I still can't understand why so many people here think an AAAA should suffice.
> 
> I think it's more that a host with A and AAAA should be able to receive
> email via AAAA even without an MX.

why?

Date: Thu, 17 Apr 2008 12:24:37 -0400
From: John C Klensin <[email-masked]>
To: Hector Santos <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: IPv6 addresses and IPv4 hosts
Sender: [email-masked]

--On Thursday, 17 April, 2008 08:19 -0400 Hector Santos
<[email-masked]> wrote:

> Arnt Gulbrandsen wrote:
>> I'm willing to take that on, unless anyone minds.
>> 
>> Arnt
> 
> If you wish help, I would be willing to pencil in the time.
> 
> I did begin last week an outline that I can pass on with
> collected research of past work and industry experiences and
> presentations highlight the major concerns and technical
> issues with the current proposals.
> 
> I personally would like to suggest that this BCP be a guide to
> help multiple audiences with a smooth transition to Ipv6
> 
>    - DNS Administration
>    - System implementor/integrators, network engineers
>    - Software Developers
>    - Operators
>    - End Users

Hector, fwiw, despite the pattern in some desktop systems to
require that everyone and their grandmother have the skills of
system and network administrators, I suggest that path is
ultimately a failure.  As a result, I believe that if end users
need to worry about what is happening at the Internet layer and
how to adjust to it, it would be a sign that all of the other
layers and actors in this process have failed.  I would rather
concentrate on not failing than on trying to inform end users --
people who see the mail system only through the MUAs or web
interfaces they use and the error messages they receive -- about
what is going on here.

There might be need for what the IETF used to call an FYI RFC to
explain some of the disconnects and the messages they cause to
those end users, but I'd think the entire effort would progress
better and more efficiently if they were kept separate.

    john

Date: Thu, 17 Apr 2008 10:29:45 -0400
From: John Leslie <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], John C Klensin <[email-masked]>
Subject: Re: IPv6 addresses and IPv4 hosts (was: Re: I-D Action:draft-klensin-rfc2821bis-10.txt)
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> wrote:
[> John C Klensin <[email-masked]> wrote:]
>  
[>> Could I suggest that someone, ideally someone with some of that]
[>> experience first-hand, take the lead and start drawing an I-D]
[>> together that builds on 3974, discusses the configuration issues]
[>> (and traps) as they are understood today, and moves toward a BCP?]
> 
[>> If Tony, Lisa, and the group were amenable, I'd be delighted to]
[>> slip a sentence into 2821bis that indicated that further work]
[>> was going on in this area with a "work in progress" pointer to]
[>> an I-D.  Of course, first there would have to be the clear]
[>> intent to do work, not just exchange comments on the mailing]
[>> list, and an I-D.]
> 
> I'm willing to take that on, unless anyone minds.

   I'll be happy to help.

--
John Leslie <[email-masked]>

Date: Thu, 17 Apr 2008 07:14:17 -0700
From: Dave Crocker <[email-masked]>
To: Henning Schulzrinne <[email-masked]>
CC: Tony Hansen <[email-masked]>, SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Henning Schulzrinne wrote:
> This decision raises a somewhat larger issue, namely whether deferring  
> to implementor desires is always the right thing to do. Compared to  
> implementers, there are many more users and system administrators. For  
> the reasons discussed earlier and alluded to below, they now lose in  
> having poorer error handling and more abuse. 

Yeah, this "running code" thing is over-rated.

It does have one characteristic that seems to be missing from your own varied 
assertions about nasty impact:  observable data.

It also presumes that those implementing code operate wholly independently of 
those who will operate or use that running code.  (An extended pattern of such 
independence is usually a good way of going out of business.)

And the claim of more spam was directly addressed as being wrong.

So perhaps you can show an empirical basis for your claims of doom and gloom?

Oh.  Right.  During the very extended discussion threads, none was produced.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 17 Apr 2008 14:52:17 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], John C Klensin <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Thu, 17 Apr 2008, Arnt Gulbrandsen wrote:
>
> I still can't understand why so many people here think an AAAA should suffice.

I think it's more that a host with A and AAAA should be able to receive
email via AAAA even without an MX.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES BAILEY: SOUTHEAST BACKING EAST 5 TO 7, DECREASING 4 FOR A TIME.
MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN BAILEY AT FIRST. MAINLY FAIR.
GOOD.

Date: Thu, 17 Apr 2008 08:19:08 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC:  [email-masked], John C Klensin <[email-masked]>
Subject: Re: IPv6 addresses and IPv4 hosts
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> I'm willing to take that on, unless anyone minds.
> 
> Arnt

If you wish help, I would be willing to pencil in the time.

I did begin last week an outline that I can pass on with collected 
research of past work and industry experiences and presentations 
highlight the major concerns and technical issues with the current 
proposals.

I personally would like to suggest that this BCP be a guide to help 
multiple audiences with a smooth transition to Ipv6

   - DNS Administration
   - System implementor/integrators, network engineers
   - Software Developers
   - Operators
   - End Users

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 17 Apr 2008 08:06:25 -0400
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
cc: Tony Finch <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

--On Thursday, 17 April, 2008 13:16 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

> Tony Finch writes:
>> On Thu, 17 Apr 2008, John C Klensin wrote:
>> 
>>>  And, unless I misread your note, I think that puts us in
>>>  violent agreement.
>> 
>> Yes :-)
>> 
>> (Assuming that by "lower priority MX" you mean
>> higher-numbered.)
> 
> I agree too. IPv6 sites have to have MXes and be
> IPv4-reachable somehow.
> 
> I still can't understand why so many people here think an AAAA
> should suffice.

Speaking for myself and not presuming to speak for "many
people", I think the following statements are both true and that
they are perfectly consistent with each other.

(i) It would be a fairly bad idea for the protocol to require an
MX record for AAAA but not for A.  Part of my reasoning is that
some of the arguments for prohibiting implicit MX generation on
AAAA fall apart for hosts that also have IPv4 addresses, since
those addresses will cause the the MXs to be generated anyway.
And I believe that "interpret some MXs as applying only to the A
records associated with the target host while interpreting
others as applying to all address records" as leading us into a
world of confusion and harm.   I understand all of the
counterarguments and do not want to restart the debate -- no one
is likely to convince me at this point and I don't expect to
convince anyone else-- but I still, personally, reach that
conclusion.

(ii) It would be mildly insane operationally (or at least
stupidly careless) for someone to configure the DNS records for
an IPv6-only host without MX records that specify IPv4 access to
that host.  An exception would arise if IPv6 were being used as
a spam control technique (i.e., "if anyone can't figure out how
to send me mail over IPv6, I don't want to hear from them"), but
the benefits of such a technique would presumably be
short-lived.    As IPv6 spreads, it will become mildly insane
for the DNS records for an IPv4-only host to by configured
without similar MX records.  So I am guessing that, over the
next several years, we will see an increase in use of explicit
MX records for hosts that really want to send or receive mail,
regardless of what the standard says about implicit MXs.  And I,
again personally, consider that A Good Thing.

   john

p.s. Thanks for the offer.  I think that would be great.

Date: Thu, 17 Apr 2008 07:58:15 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC: Tony Finch <[email-masked]>, Willie Gillespie <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

John C Klensin wrote:

> Whatever I said, I didn't intend it to convey the expectation
> that the responsibility would need to lie with the IPv4-only
> recipient site.    I have come to believe that it is appropriate
> for a receiving site to do at least superficial verification of
> the possibility of delivering an NDN before accepting a message
> for delivery for which an NDN might be necessary (i.e., for
> which delivery cannot be assured while the SMTP connection is
> still open).  I think that testing the reverse path and making a
> decision to not accept the message if the test fails is entirely
> consistent with the "take responsibility" language of 2821 (and
> 1123).

Well I'll be. I must be still dreaming! PITCH ME! :-)

> I think that implies that, for the near future at least, if
> [email-masked] wants to have a reasonable expectation
> that mail it sends will be accepted by mail servers running in
> IPv4-only  environments, then it (the sender) must expect to
> either be dual-stack (and advertise the IPv4 address too) or to
> have a lower-priority MX advertised that will accept IPv4
> traffic.

Thank you!

Consider if that reasonable expectation is not met, we will be breeding 
a new environment of send only systems, including the exploitation of 
such new send-only behavior.  Legitimate Ipv6 systems would not only 
risk losing response/feedback communications, but it will put itself at 
greater harm by getting itself blacklisted or blocked.

I can not phantom how we would allow such a new pattern of exploitable 
behavior to persist and grow simply because we relaxed the methodology 
we had in IPv4 based SMTP systems in the name of one way only 
communications IPv6 system.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 17 Apr 2008 13:16:33 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: Tony Finch <[email-masked]>, John C Klensin <[email-masked]>
Sender: [email-masked]

Tony Finch writes:
> On Thu, 17 Apr 2008, John C Klensin wrote:
>
>>  And, unless I misread your note, I think that puts us in violent agreement.
>
> Yes :-)
>
> (Assuming that by "lower priority MX" you mean higher-numbered.)

I agree too. IPv6 sites have to have MXes and be IPv4-reachable somehow.

I still can't understand why so many people here think an AAAA should suffice.

Arnt

Date: Thu, 17 Apr 2008 13:16:15 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IPv6 addresses and IPv4 hosts (was: Re: I-D Action:draft-klensin-rfc2821bis-10.txt)
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

I'm willing to take that on, unless anyone minds.

Arnt

Date: Thu, 17 Apr 2008 06:56:35 -0400
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

--On Thursday, 17 April, 2008 11:42 +0100 Tony Finch
<[email-masked]> wrote:

> On Thu, 17 Apr 2008, John C Klensin wrote:
>> 
>> And, unless I misread your note, I think that puts us in
>> violent agreement.
> 
> Yes :-)
> 
> (Assuming that by "lower priority MX" you mean
> higher-numbered.)

Indeed.

    john

Date: Thu, 17 Apr 2008 11:42:53 +0100
From: Tony Finch <[email-masked]>
To: John C Klensin <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Thu, 17 Apr 2008, John C Klensin wrote:
>
> And, unless I misread your note, I think that puts us in violent
> agreement.

Yes :-)

(Assuming that by "lower priority MX" you mean higher-numbered.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES BAILEY: SOUTHEAST BACKING EAST 5 TO 7, DECREASING 4 FOR A TIME.
MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH IN BAILEY AT FIRST. MAINLY FAIR.
GOOD.

Date: Thu, 17 Apr 2008 06:37:18 -0400
From: John C Klensin <[email-masked]>
To: Tony Finch <[email-masked]>, Willie Gillespie <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

--On Thursday, 17 April, 2008 11:25 +0100 Tony Finch
<[email-masked]> wrote:

> On Wed, 16 Apr 2008, Willie Gillespie wrote:
>> Tony Finch wrote:
>> > On Wed, 16 Apr 2008, Ned Freed wrote:
>> >>> I doubt that it makes sense to accept email from
>> >>> [email-masked] on a system that can only
>> >>> communicate with IPv4 addresses.
>> 
>> I foresee some company setting up an IPv6 to IPv4 e-mail
>> relay for individuals or other companies that only have IPv6
>> addresses.
> 
> I agree with John that this is likely to happen.
> 
>> For an IPv4-only receiving system, would this appear as an
>> e-mail from [email-masked] (even though it comes over
>> the IPv4 link)?  At that point, would it make sense to accept
>> the message?
> 
> The sender's relay has to be two-way, so the IPv6-only site's
> MXs would have to refer to the relay's IPv4 address as well as
> the site's own IPv6 address. Then the sender's email addresses
> can be verified successfully by IPv4-only sites.
> 
> I don't think John is right to expect IPv4-only recipient
> sites to obtain a 4-to-6 SMTP relay service any time soon.
> IPv6 sites will have to deal with the interop burden until v4
> is the minority.
> 
> For example, there are likely to be problems if
> [email-masked] AAAA-only addresses leak out, and these
> are likely to be worse than the problems that A-only addresses
> like [email-masked] have.

Whatever I said, I didn't intend it to convey the expectation
that the responsibility would need to lie with the IPv4-only
recipient site.    I have come to believe that it is appropriate
for a receiving site to do at least superficial verification of
the possibility of delivering an NDN before accepting a message
for delivery for which an NDN might be necessary (i.e., for
which delivery cannot be assured while the SMTP connection is
still open).  I think that testing the reverse path and making a
decision to not accept the message if the test fails is entirely
consistent with the "take responsibility" language of 2821 (and
1123).

I think that implies that, for the near future at least, if
[email-masked] wants to have a reasonable expectation
that mail it sends will be accepted by mail servers running in
IPv4-only  environments, then it (the sender) must expect to
either be dual-stack (and advertise the IPv4 address too) or to
have a lower-priority MX advertised that will accept IPv4
traffic.

And, unless I misread your note, I think that puts us in violent
agreement.

    john

Date: Thu, 17 Apr 2008 11:25:35 +0100
From: Tony Finch <[email-masked]>
To: Willie Gillespie <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Wed, 16 Apr 2008, Willie Gillespie wrote:
> Tony Finch wrote:
> > On Wed, 16 Apr 2008, Ned Freed wrote:
> >>> I doubt that it makes sense to accept email from [email-masked]
> >>> on a system that can only communicate with IPv4 addresses.
>
> I foresee some company setting up an IPv6 to IPv4 e-mail relay for
> individuals or other companies that only have IPv6 addresses.

I agree with John that this is likely to happen.

> For an IPv4-only receiving system, would this appear as an e-mail from
> [email-masked] (even though it comes over the IPv4 link)?  At
> that point, would it make sense to accept the message?

The sender's relay has to be two-way, so the IPv6-only site's MXs would
have to refer to the relay's IPv4 address as well as the site's own IPv6
address. Then the sender's email addresses can be verified successfully by
IPv4-only sites.

I don't think John is right to expect IPv4-only recipient sites to obtain
a 4-to-6 SMTP relay service any time soon. IPv6 sites will have to deal
with the interop burden until v4 is the minority.

For example, there are likely to be problems if [email-masked]
AAAA-only addresses leak out, and these are likely to be worse than the
problems that A-only addresses like [email-masked] have.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BISCAY FITZROY: CYCLONIC 5 TO 7, OCCASIONALLY GALE 8, PERHAPS SEVERE GALE 9
LATER. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.

Date: Thu, 17 Apr 2008 10:48:54 +0100
From: Paul Smith <[email-masked]>
To: Henning Schulzrinne <[email-masked]>
CC: Douglas Otis <[email-masked]>, Tony Hansen <[email-masked]>, SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Henning Schulzrinne wrote:
>
> This decision raises a somewhat larger issue, namely whether deferring 
> to implementor desires is always the right thing to do. Compared to 
> implementers, there are many more users and system administrators. For 
> the reasons discussed earlier and alluded to below, they now lose in 
> having poorer error handling and more abuse. I thought standards 
> writers and implementer were supposed to serve end users (and maybe 
> the large number of people having to install and manage things), not 
> the other way around. Maybe this is another instance of the 
> oft-bemoaned absence of operators from the IETF discussion. End users 
> seem to be even more absent, even indirectly.
Agreed. I see this as a big step in the wrong direction. No one has 
given a good reason for doing it other than 'its similar to what happens 
in IPv4', 'it makes life easier for people with awful internal 
procedures' and 'it saves us 3 lines of code in our software'. None of 
those are good enough reasons IMHO, given all the reasons not to do it.

It might end up not being a big deal except for mail server 
administrators at big companies or ISPs, but it *might* be a massive 
deal, and given the easy change we could make now, I think it's a big 
opportunity being missed.

Cc: Tony Hansen <[email-masked]>, SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
From: Henning Schulzrinne <[email-masked]>
To: Douglas Otis <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Date: Wed, 16 Apr 2008 21:39:35 -0400
Sender: [email-masked]

This decision raises a somewhat larger issue, namely whether deferring  
to implementor desires is always the right thing to do. Compared to  
implementers, there are many more users and system administrators. For  
the reasons discussed earlier and alluded to below, they now lose in  
having poorer error handling and more abuse. I thought standards  
writers and implementer were supposed to serve end users (and maybe  
the large number of people having to install and manage things), not  
the other way around. Maybe this is another instance of the oft- 
bemoaned absence of operators from the IETF discussion. End users seem  
to be even more absent, even indirectly.

Henning

On Apr 15, 2008, at 7:15 PM, Douglas Otis wrote:
>
> On Apr 14, 2008, at 7:33 PM, Tony Hansen wrote:
>
>> The SMTP implementations that have made the transition to support
>> IPv6 appear to already have done it in a way that supports AAAA
>> records for the implicit MX case. In some cases they are following
>> RFC 3974, and other cases they are just using getaddrinfo() and
>> letting it do the rest. Note that RFC 3974 itself was supposedly
>> "based on experience in deploying IPv6". At least one of these MTAs
>> is in common use around the network in the IPv4 world.
>>
>> In essence, these implementations are following the RFC 821 and RFC
>> 974 (sans WKS) rules of looking for address records. They've ignored
>> the A-only wording of RFC 2821 and are acting like we specify
>> currently in 2821bis-09.
>>
>> In my queries I haven't yet found any IPv6-capable SMTP server that
>> doesn't do it.
>>
>> I've seen examples of sites that are in regular use that mail would
>> break in an IPv6-only world if implicit MX to AAAA did not work.
>>
>> From this viewpoint, running code wins.
>
> Abusive running code wins as well.  Indeed, many bad-actors will
> appreciate not being limited to A or MX records, as specifically
> specified in RFC 2821 discovery mechanisms.  Whether the specifics of
> this specification were in error is a separate issue, where endorsing
> AAAA records as a valid discovery mechanism represents a substantial
> change, and one likely to prove unsuccessful when more widely adopted
> and then abused.  The A resource record enabled a transition to MX
> resource records.  The necessity of the implied MX record is no longer
> justifiable.  Permitting A records as a means to discover SMTP servers
> often generates a steady amount of abuse by bad-actors that use A
> record only host-names as spoofed domains in their email-address.
>
> To overcome what is destine to become an undesirable MX fall-back
> mode, some have suggested bogus MX records could be published
> instead.  Bogus MX records would then become perhaps the _only_ means
> to protect hosts not involved in the public reception of SMTP
> messages.  Much of the undesired traffic does not directly emanate
> from clients controlled by bad-actors.  Often, undesired traffic
> results from attempts to validate oft spoofed email sources.  The
> level of this undesired traffic can be substantial.
>
>> I'm also swayed by the principle of "least surprise". Some of the
>> responses I've gotten have been along the lines of "Why's this a
>> question? Of course you do AAAA lookup". One person who had a site
>> set up with an IPv6-only connection and no MX record told me "I
>> wanted to forward my e-mail to an account on that machine. It worked
>> the first time, so I didn't see a need to change it." As mentioned
>> above, at least one of the IPv6-capable MTAs is in common use around
>> the network in the IPv4 world, and turning on IPv6 on those boxes
>> should not cause surprises.
>
> Those wanting inbound SMTP on their IPv6 only hosts can routinely
> include MX records in addition to their AAAA records.  Keeping a
> requirement to publish either A or MX records would alleviate the rest
> of the world from seeking protection by publishing bogus MX records
> for all hosts where inbound SMTP is not desired.  High levels of abuse
> often require public inbound receivers to specialize in defending
> against the abusive traffic.  The percentage of public SMTP servers
> represent a shrinking minority of hosts that might benefit from a
> convenience of not needing to publish MX records.  However, to improve
> both the performance of SMTP servers in general, and acceptance rates
> of IPv6 only hosts, publishing MX records for an email domain is
> likely to become increasingly critical.  "Least surprise" is assured
> by discovery methods that work on a large scale while also limiting
> avenues for abuse.  Having AAAA records imply MX resource records on a
> large scale without rampant abuse would be astonishing.
>
>> Last of all, I'm swayed by the discussions around RFC 974 and the
>> DRUMS archive search around the question of what led to the wording
>> change in 2821bis saying explicitly to do A lookups. These indicate
>> that the intent of adding the A record description was to be
>> descriptive, not prescriptive nor proscriptive.
>
> SMTP represents a great achievement.  Much of this achievement has
> occurred by minimizing administrative efforts needed to establish SMTP
> services.  These minimal administrative efforts now play a significant
> role in fostering current levels of abuse afflicting SMTP.
> Standardizing on AAAA as an MX fall-back moves SMTP and IPv6 in the
> wrong direction.  Sensitivity to abuse adopts a practice of "opt-in"
> rather than "opt-out".   AAAA as an MX fall-back may necessitate SMTP
> IPv6 hosts the need to publish bogus MX records for the specific
> purpose of "opting out".
>
>> So the bottom line is that I see sufficient support for including
>> AAAA lookups when implicit MX comes into play.
>
> It seems the specification should attempt to differentiate what might
> be achievable within private versus public server configurations.
>
>> It's been suggested that 2821bis revert back to either the implicit
>> MX description found in RFC 821 or RFC 974, although Glen Anderson
>> had some suggested improvements to that latter's description that do
>> make it clearer. Any of these three would satisfy this decision, and
>> I'll let John choose the wording he prefers.
>
> While ensuring that the 'S' in SMTP upholds the concept of Simple,
> avoiding greater levels of abuse will help further that goal.  While
> those that live and breath SMTP don't want to see any administrative
> dependencies added, this costs hosts running unrelated protocols that
> must then terminate a seemingly endless stream of SMTP related abuse.
> The success of SMTP requires greater administrative care be taken.  To
> take this to the logical conclusion, the transition to IPv6 with a
> reduction in SMTP related abuse would be further aided by deprecating
> use of A records as an MX fall-back mechanism published in a follow-on
> draft, where the current draft could warn of this possible change.
>
> -Doug
>
>
>
> _______________________________________________
> IETF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Block IPv6-only at the border
Date:  Thu, 17 Apr 2008 02:06:41 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 35
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:

> which of the two of you did I hear volunteer to start
> writing a coherent and unified "best practices" I-D?

| ideally someone with some of that experience first-hand

> Please take this off the list and start writing.

Nothing to do from my POV:
  
| If an SMTP server has accepted the task of relaying the
| mail and later finds that the destination is incorrect
| or that the mail cannot be delivered for some other
| reason, then it MUST construct an "undeliverable mail"
| notification message and send it to the originator of
| the undeliverable mail (as indicated by the reverse-
| path).
[...]
| When the receiver-SMTP accepts a piece of mail (by 
| sending a "250 OK" message in response to DATA), 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.

If you would mean something else you would have written
something else, and I made sure that this isn't the case.

"My network is IPvX and can't do IPvNOTX" is predictable
under normal circumstances as in Arnt's example => your
SMTP did the right thing when it rejected IPv6-only mail.

 Frank

Date: Wed, 16 Apr 2008 18:12:22 -0400
From: John C Klensin <[email-masked]>
To: Sabahattin Gucukoglu <[email-masked]>, Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: Block IPv6-only at the border (was: I-D Action:draft-klensin-rfc2821bis-10.txt)
Sender: [email-masked]

And which of the two of you did I hear volunteer to start
writing a coherent and unified "best practices" I-D?  Please
take this off the list and start writing.

   john

--On Wednesday, 16 April, 2008 22:30 +0100 Sabahattin Gucukoglu
<[email-masked]> wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Frank,
> 
> On 16 Apr 2008 at 20:46, Frank Ellermann
> <[email-masked]> said:
> 
>> "Tony Finch" wrote:
>> 
>> > I doubt that it makes sense to accept email from 
>> > [email-masked] on a system that can only
>> > communicate with IPv4 addresses.
>> 
>> In stark contrast to Ned's view I think that you
>> MUST reject such mails - unless you can guarantee
>> delivery without auto-response (no NDR, no DSN,
>> no MDN, no vacation, no forward, in essence an 
>> empty reverse-path, near to rewrite MAIL FROM:<>)
> 
> No, I don't agree.  Your only real obligation is to ensure
> that your  output relay doesn't attempt a delivery and so
> waste resources when it  can't do it by simply guaranteeing
> that IPv6 hosts aren't considered in  email routing at time of
> delivery (EG worst case is a double-bounce  listing "No data"
> as reason because the resolver routines have ignored the  IPv6
> addresses, if double-bounces were enabled - and they should
> be!).   That doesn't mean not accepting mail from IPv6-only
> hosts, any more than  it means not accepting mail from an
> invalid mailbox.  IMHO, it's your  responsibility to ensure
> that mail can and will be accepted and to make  sure that it
> will be delivered so that the minimal number of DSNs/whatever 
> have to be generated to accomodate your configuration problems
> under  whatever circumstance.  It is less wise to depend on a
> sender check that  doesn't make sense semantically (there
> never has been and never will be a  requirement in a spec
> enforcing it, and for good reason, even if it makes  sense for
> policy) and which is only really useful as a feeble antispam 
> check nowadays anyway in these days of deliberate DSN disposal.
> 
>> Same idea as in EAI, after a reject "the sender
>> can make another plan".  After accepting it the
>> IPv6-only mail vanished in a black hole for all
>> non-trivial cases.  
> 
> Cheers,
> Sabahattin
> 
> - -- 
> Sabahattin Gucukoglu
> <mail<at>sabahattin<dash>gucukoglu<dot>com> Address
> harvesters, snag this: [email-masked]
> Phone: +44 20 88008915
> Mobile: +44 7986 053399
> http://sabahattin-gucukoglu.com/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8
> Comment: QDPGP - http://community.wow.net/grt/qdpgp.html
> 
> iQA/AwUBSAZv2iNEOmEWtR2TEQLidgCgk0IXZEEBqCfv9cXv1S652LVYTiUAn1
> bT wv9u+hrPwyAmpqq1p98Rkph6
> uhu
> -----END PGP SIGNATURE-----
> 

From: "Sabahattin Gucukoglu" <[email-masked]>
To: [email-masked]
Date: Wed, 16 Apr 2008 22:30:02 +0100
Subject: Re: Block IPv6-only at the border (was: I-D Action:draft-klensin-rfc2821bis-10.txt)
Content-description: Mail message body
Sender: [email-masked]

Hi Frank,

On 16 Apr 2008 at 20:46, Frank Ellermann <[email-masked]> said:

> "Tony Finch" wrote:
> 
> > I doubt that it makes sense to accept email from 
> > [email-masked] on a system that can only
> > communicate with IPv4 addresses.
> 
> In stark contrast to Ned's view I think that you
> MUST reject such mails - unless you can guarantee
> delivery without auto-response (no NDR, no DSN,
> no MDN, no vacation, no forward, in essence an 
> empty reverse-path, near to rewrite MAIL FROM:<>)

No, I don't agree.  Your only real obligation is to ensure that your 
output relay doesn't attempt a delivery and so waste resources when it 
can't do it by simply guaranteeing that IPv6 hosts aren't considered in 
email routing at time of delivery (EG worst case is a double-bounce 
listing "No data" as reason because the resolver routines have ignored the 
IPv6 addresses, if double-bounces were enabled - and they should be!).  
That doesn't mean not accepting mail from IPv6-only hosts, any more than 
it means not accepting mail from an invalid mailbox.  IMHO, it's your 
responsibility to ensure that mail can and will be accepted and to make 
sure that it will be delivered so that the minimal number of DSNs/whatever 
have to be generated to accomodate your configuration problems under 
whatever circumstance.  It is less wise to depend on a sender check that 
doesn't make sense semantically (there never has been and never will be a 
requirement in a spec enforcing it, and for good reason, even if it makes 
sense for policy) and which is only really useful as a feeble antispam 
check nowadays anyway in these days of deliberate DSN disposal.

> Same idea as in EAI, after a reject "the sender
> can make another plan".  After accepting it the
> IPv6-only mail vanished in a black hole for all
> non-trivial cases.  

Cheers,
Sabahattin

- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Wed, 16 Apr 2008 16:45:07 -0400
From: John C Klensin <[email-masked]>
To: Willie Gillespie <[email-masked]>, Tony Finch <[email-masked]>
cc: Ned Freed <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

--On Wednesday, 16 April, 2008 14:31 -0600 Willie Gillespie
<[email-masked]> wrote:

> Tony Finch wrote:
>> On Wed, 16 Apr 2008, Ned Freed wrote:
>>>> I doubt that it makes sense to accept email from
>>>> [email-masked] on a system that can only
>>>> communicate with IPv4 addresses.
> 
> I foresee some company setting up an IPv6 to IPv4 e-mail relay
> for individuals or other companies that only have IPv6
> addresses.

Very likely, IMO

> For an IPv4-only receiving system, would this appear as an
> e-mail from [email-masked] (even though it comes over
> the IPv4 link)?  At that point, would it make sense to accept
> the message?

Sure.  The problem arises if the receiving IPv4 host tries to do
some sort of sender-accessibility or callback verification.  It
won't be able to reach the IPv6 host (or send NDNs to it) unless
it either it is configured to submit those messages via an
IPv6-capable gateway or the IPv6 host advertises IPv4 addresses
(perhaps via a conversion relay in a low-preference MX record).

Did I hear you volunteer to organize the I-D leading to a BCP
that I suggested earlier?

    john

Date: Wed, 16 Apr 2008 14:31:31 -0600
From: Willie Gillespie <[email-masked]>
Organization: Engineering System Solutions
To: Tony Finch <[email-masked]>
CC: Ned Freed <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Tony Finch wrote:
> On Wed, 16 Apr 2008, Ned Freed wrote:
>>> I doubt that it makes sense to accept email from [email-masked]
>>> on a system that can only communicate with IPv4 addresses.

I foresee some company setting up an IPv6 to IPv4 e-mail relay for
individuals or other companies that only have IPv6 addresses.

For an IPv4-only receiving system, would this appear as an e-mail from
[email-masked] (even though it comes over the IPv4 link)?  At
that point, would it make sense to accept the message?

Willie Gillespie

<snip rest of message>

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Block IPv6-only at the border (was: I-D Action:draft-klensin-rfc2821bis-10.txt)
Date:  Wed, 16 Apr 2008 20:46:14 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 18
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

"Tony Finch" wrote:

> I doubt that it makes sense to accept email from 
> [email-masked] on a system that can only
> communicate with IPv4 addresses.

In stark contrast to Ned's view I think that you
MUST reject such mails - unless you can guarantee
delivery without auto-response (no NDR, no DSN,
no MDN, no vacation, no forward, in essence an 
empty reverse-path, near to rewrite MAIL FROM:<>)

Same idea as in EAI, after a reject "the sender
can make another plan".  After accepting it the
IPv6-only mail vanished in a black hole for all
non-trivial cases.  

 Frank

Date: Wed, 16 Apr 2008 14:09:51 -0400
From: John Leslie <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: IPv4 / IPv6 interaction
Sender: [email-masked]

Tony Finch <[email-masked]> wrote:
> On Wed, 16 Apr 2008, Ned Freed wrote:
>> On Tue, 15 Apr 2008, Arnt Gulbrandsen wrote:
>>
>>> I doubt that it makes sense to accept email from [email-masked]
>>> on a system that can only communicate with IPv4 addresses.

   (It would help to be clear whether "from" refers to HELO, MailFrom,
or some miscellaneous header.)

>> In a single system case with fully symmetric routing, perhaps not.
>> But as I mentioned previously, there are many cases where multiple
>> systems with highly asymmetric routing are used to provide a mail
>> service.

   Absolutely (for any of the cases I listed).

>> In such a setup it is entirely possible that a system hosting an
>> inbound MTA would have DNS query access but no outbound IPv6 access
>> even if such access exists somewhere else in the setup.

   We would be ill-advised to assume even that IPv4-only systems have
no reason to query (and perhaps even use in some fashion) AAAA RRs.

> Of course, but in that case the postmaster would know that it is
> possible to communicate indirectly with IPv6 addresses and would
> therefore not disable IPv6 DNS lookup support.

   (We're really talking about an implementation detail outside the
spec here.)

   In a legacy IPv4 system _right_now_ suppressing AAAA RRs might
make sense. I do not agree it makes sense next year. Even if the
postmaster _today_ does not know of a host speaking both IPv4 and
IPv6 that will agree to relay his/her email, that doesn't mean that
software like Exim shouldn't give an error message describing the
problem as lacking a path to reach an IPv6 address.

--
John Leslie <[email-masked]>

Date: Wed, 16 Apr 2008 13:47:15 -0400
From: John Leslie <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Hector Santos <[email-masked]> wrote:
> John Leslie wrote:
> 
>> My hope has been that an IPv6-only host speaking SMTP to the rest of
>> the world would:
>>
>> - look for an MX RR pointing to an AAAA RR
>>   - if it finds one, use that AAAA RR
>>   - if not, look for an MX (explicit or implied) pointing to an A RR
>>     - if it finds one, pass the email to a friendly relay speaking IPv4
>>     _ if not, give the usual error
>>
>> - advertise an MX RR pointing to an A RR
>>   (in addition to any pointing to AAAA RRs)
> 
> I'm confused. To me, when you say "IPv6-only", that implies it doesn't 
> support IPv4 in any direct way.  Isn't that correct?

   Mostly...

   The distinction I intend is that the host has no IPv4 connectivity.

>> This strikes me as a more reasonable long-term algorithm than
>> requiring all mail from an IPv6 user to go through a SMTP server with
>> both IPv4 and IPv6 connectivity.
>>
>> It may be that the consensus here prefers Hector's solution: if so,
>> I suppose I should shut up. But please think long-term: we want something
>> that can work today and continue working for 20 years, by which time
>> IPv4 should be as rare as IPv6 is today.
> 
> I don't think I have been any different from what you desire.  We might 
> said it in different ways but I think we all want the same thing.

   It's hard to tell...

   Undeniably, we could stipulate that an IPv6-only domain MUST pass
all outgoing email to an IPv4-capable host. That is not what I want.
Your posting led me to believe it was what you wanted.

> My only real point about the IPv6 related considerations was how it 
> would be stated in a kludged up, "spaghetti" 2821bis in such a way
> that will promote interoperability issues with the dominant IPv4
> market for now and the foreseeable future.

   It's hard, again, to tell what you mean by this. I certainly do
not desire a "spaghetti" 2821bis. To me, a 2821bis that's hard to
understand and implement _can't_ promote interoperability.

> I think Tony's decision was the right one - FOR 2821bis.

   I'm forced to face the unfortunate fact that anything I write will
be interpreted as an attack on Tony by some people (fortunately _not_
by Tony himself).

   The folks who are best at protocol design _don't_ automatically
forget an idea when the majority rejects it. (And neither do I.)
They do, however, shift their concentration to a different area.
I believe I have done so. Others may disagree...

> I could elaborate more about IPv6 concerns but overall I think we
> still do not know what all the real issues with IPv6 implementations
> in a IPv4 world [may be]

   We don't need to know "all" the issues in order to design "an"
algorithm for interaction. I have suggested one. (Its mirror image
should work in the opposite direction.)

> and this is why I wish to see a new effort for a modern, consolidated
> SMTP Ipv6/4 technical/functional/migration spec.

   Are you volunteering?

> The key word is consolidated, and I think this spec can augment
> 2821bis draft standard.

   "Augment" is certainly OK... "Override" probably isn't.

-- 
John Leslie <[email-masked]>

Date: Wed, 16 Apr 2008 13:28:51 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: IPv6 addresses and IPv4 hosts (was: Re: I-D Action:draft-klensin-rfc2821bis-10.txt)
Sender: [email-masked]

Hi.

This discussion is very interesting.  It is clear that
considerable experience, as well as considerable opportunity for
theorizing about edge cases, has accumulated since RFC 3974 was
completed.  It would be a pity to lose whatever wisdom that
experience to the back-and-forth of the mailing list.

Could I suggest that someone, ideally someone with some of that
experience first-hand, take the lead and start drawing an I-D
together that builds on 3974, discusses the configuration issues
(and traps) as they are understood today, and moves toward a BCP?

If Tony, Lisa, and the group were amenable, I'd be delighted to
slip a sentence into 2821bis that indicated that further work
was going on in this area with a "work in progress" pointer to
an I-D.  Of course, first there would have to be the clear
intent to do work, not just exchange comments on the mailing
list, and an I-D.

     john

Date: Wed, 16 Apr 2008 15:36:40 +0100
From: Tony Finch <[email-masked]>
To: Ned Freed <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Wed, 16 Apr 2008, Ned Freed wrote:
>
> > I doubt that it makes sense to accept email from [email-masked]
> > on a system that can only communicate with IPv4 addresses.
>
> In a single system case with fully symmetric routing, perhaps not. But as I
> mentioned previously, there are many cases where multiple systems with highly
> asymmetric routing are used to provide a mail service. In such a setup it is
> entirely possible that a system hosting an inbound MTA would have DNS query
> access but no outbound IPv6 access even  if such access exists somewhere else
> in the setup.

Of course, but in that case the postmaster would know that it is possible
to communicate indirectly with IPv6 addresses and would therefore not
disable IPv6 DNS lookup support.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: SOUTHEAST 5 TO 7, PERHAPS GALE 8 LATER IN MALIN. MODERATE OR
ROUGH BUT SLIGHT IN EAST AT FIRST. MAINLY FAIR. GOOD.

From: [email-masked]
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 16 Apr 2008 07:27:31 -0700 (PDT)
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
To: Tony Finch <[email-masked]>
Sender: [email-masked]

> On Tue, 15 Apr 2008, Arnt Gulbrandsen wrote:
> >
> > Exim users can comply by disabling the sender_verify variable

> That's a version 3 option so it hasn't been supported for many years.
> If Exim 4 is compiled to support IPv6 then it will accept AAAA-only
> addresses, though you can disable this on IPv4-only hosts.

> I doubt that it makes sense to accept email from [email-masked]
> on a system that can only communicate with IPv4 addresses.

In a single system case with fully symmetric routing, perhaps not. But as I
mentioned previously, there are many cases where multiple systems with highly
asymmetric routing are used to provide a mail service. In such a setup it is
entirely possible that a system hosting an inbound MTA would have DNS query
access but no outbound IPv6 access even  if such access exists somewhere else
in the setup. (I freely admit I'm extrapolating here given the extremely
limited amount of production deployment of IPv6 at present, but I'd be
surprised if this didn't end up happening after seeing how IPv4-only setups
work.)

				Ned

Date: Wed, 16 Apr 2008 15:04:28 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

On Tue, 15 Apr 2008, Arnt Gulbrandsen wrote:
>
> Exim users can comply by disabling the sender_verify variable

That's a version 3 option so it hasn't been supported for many years.
If Exim 4 is compiled to support IPv6 then it will accept AAAA-only
addresses, though you can disable this on IPv4-only hosts.

I doubt that it makes sense to accept email from [email-masked]
on a system that can only communicate with IPv4 addresses.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: SOUTHEAST 5 TO 7, PERHAPS GALE 8 LATER IN MALIN. MODERATE OR
ROUGH BUT SLIGHT IN EAST AT FIRST. MAINLY FAIR. GOOD.

Date: Wed, 16 Apr 2008 00:00:11 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: RFC2821bis-10 S5.1 Revision: "Unusable" MXs
Sender: [email-masked]

At 00:45 +0100 on 04/16/2008, Sabahattin Gucukoglu wrote about 
RFC2821bis-10 S5.1 Revision: "Unusable" MXs:

>Hi all,
>
>I'm looking over RFC2821bis-10 now.
>
>Section 5.1 now has this (not sure if there's previous context from older
>drafts):
>
>| If MX records are present, but none of them are usable, or the implicit
>| MX is unusable, this situation MUST be reported as an error.
>
>What exactly does that mean?  More specifically, what does "Usable" mean?

If the explicit MX or implicit MX (ie: Using existent A or AAAA [but 
not both since only one type exists]) that is defined for the email 
address's FQDN points at only IPv4 IPNs when the SMTP MTA only talks 
IPv6 (or a IPV4-only MTA finds only IPv6 IPNs) then you have an 
unusable condition since none of the IPNs found can be used by the 
MTA.

Date: Tue, 15 Apr 2008 23:09:21 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John Leslie <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

John,

John Leslie wrote:

> My hope has been that an IPv6-only host speaking SMTP to the rest of
> the world would:
> 
>  - look for an MX RR pointing to an AAAA RR
>    - if it finds one, use that AAAA RR
>    - if not, look for an MX (explicit or implied) pointing to an A RR
>      - if it finds one, pass the email to a friendly relay speaking IPv4
>      _ if not, give the usual error
> 
>  - advertise an MX RR pointing to an A RR
>    (in addition to any pointing to AAAA RRs)

I'm confused. To me, when you say "IPv6-only", that implies it doesn't 
support IPv4 in any direct way.  Isn't that correct?

> 
>    This strikes me as a more reasonable long-term algorithm than
> requiring all mail from an IPv6 user to go through a SMTP server with
> both IPv4 and IPv6 connectivity.
> 
>    It may be that the consensus here prefers Hector's solution: if so,
> I suppose I should shut up. But please think long-term: we want something
> that can work today and continue working for 20 years, by which time
> IPv4 should be as rare as IPv6 is today.

John,

I don't think I have been any different from what you desire.  We might 
said it in different ways but I think we all want the same thing.

My only real point about the IPv6 related considerations was how it 
would be stated in a kludged up, "spaghetti" 2821bis in such a way that 
will promote interoperability issues with the dominant IPv4 market for 
now and the foreseeable future.

I think Tony's decision was the right one - FOR 2821bis.

I could elaborate more about IPv6 concerns but overall I think we still 
do not know what all the real issues with IPv6 implementations in a IPv4 
world and this is why I wish to see a new effort for a modern, 
consolidated SMTP Ipv6/4 technical/functional/migration spec.  The key 
word is consolidated, and I think this spec can augment 2821bis draft 
standard.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

From: "Sabahattin Gucukoglu" <[email-masked]>
To: [email-masked]
Date: Wed, 16 Apr 2008 00:45:38 +0100
Subject: RFC2821bis-10 S5.1 Revision: "Unusable" MXs
Content-description: Mail message body
Sender: [email-masked]

Hi all,

I'm looking over RFC2821bis-10 now.

Section 5.1 now has this (not sure if there's previous context from older 
drafts):

| If MX records are present, but none of them are usable, or the implicit
| MX is unusable, this situation MUST be reported as an error.

What exactly does that mean?  More specifically, what does "Usable" mean? 

Cheers,
Sabahattin

- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Cc: SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
From: Douglas Otis <[email-masked]>
To: Tony Hansen <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Date: Tue, 15 Apr 2008 16:15:23 -0700
Sender: [email-masked]

On Apr 14, 2008, at 7:33 PM, Tony Hansen wrote:

> The SMTP implementations that have made the transition to support  
> IPv6 appear to already have done it in a way that supports AAAA  
> records for the implicit MX case. In some cases they are following  
> RFC 3974, and other cases they are just using getaddrinfo() and  
> letting it do the rest. Note that RFC 3974 itself was supposedly  
> "based on experience in deploying IPv6". At least one of these MTAs  
> is in common use around the network in the IPv4 world.
>
> In essence, these implementations are following the RFC 821 and RFC  
> 974 (sans WKS) rules of looking for address records. They've ignored  
> the A-only wording of RFC 2821 and are acting like we specify  
> currently in 2821bis-09.
>
> In my queries I haven't yet found any IPv6-capable SMTP server that  
> doesn't do it.
>
> I've seen examples of sites that are in regular use that mail would  
> break in an IPv6-only world if implicit MX to AAAA did not work.
>
> From this viewpoint, running code wins.

Abusive running code wins as well.  Indeed, many bad-actors will  
appreciate not being limited to A or MX records, as specifically  
specified in RFC 2821 discovery mechanisms.  Whether the specifics of  
this specification were in error is a separate issue, where endorsing  
AAAA records as a valid discovery mechanism represents a substantial  
change, and one likely to prove unsuccessful when more widely adopted  
and then abused.  The A resource record enabled a transition to MX  
resource records.  The necessity of the implied MX record is no longer  
justifiable.  Permitting A records as a means to discover SMTP servers  
often generates a steady amount of abuse by bad-actors that use A  
record only host-names as spoofed domains in their email-address.

To overcome what is destine to become an undesirable MX fall-back  
mode, some have suggested bogus MX records could be published  
instead.  Bogus MX records would then become perhaps the _only_ means  
to protect hosts not involved in the public reception of SMTP  
messages.  Much of the undesired traffic does not directly emanate  
from clients controlled by bad-actors.  Often, undesired traffic  
results from attempts to validate oft spoofed email sources.  The  
level of this undesired traffic can be substantial.

> I'm also swayed by the principle of "least surprise". Some of the  
> responses I've gotten have been along the lines of "Why's this a  
> question? Of course you do AAAA lookup". One person who had a site  
> set up with an IPv6-only connection and no MX record told me "I  
> wanted to forward my e-mail to an account on that machine. It worked  
> the first time, so I didn't see a need to change it." As mentioned  
> above, at least one of the IPv6-capable MTAs is in common use around  
> the network in the IPv4 world, and turning on IPv6 on those boxes  
> should not cause surprises.

Those wanting inbound SMTP on their IPv6 only hosts can routinely  
include MX records in addition to their AAAA records.  Keeping a  
requirement to publish either A or MX records would alleviate the rest  
of the world from seeking protection by publishing bogus MX records  
for all hosts where inbound SMTP is not desired.  High levels of abuse  
often require public inbound receivers to specialize in defending  
against the abusive traffic.  The percentage of public SMTP servers  
represent a shrinking minority of hosts that might benefit from a  
convenience of not needing to publish MX records.  However, to improve  
both the performance of SMTP servers in general, and acceptance rates  
of IPv6 only hosts, publishing MX records for an email domain is  
likely to become increasingly critical.  "Least surprise" is assured  
by discovery methods that work on a large scale while also limiting  
avenues for abuse.  Having AAAA records imply MX resource records on a  
large scale without rampant abuse would be astonishing.

> Last of all, I'm swayed by the discussions around RFC 974 and the  
> DRUMS archive search around the question of what led to the wording  
> change in 2821bis saying explicitly to do A lookups. These indicate  
> that the intent of adding the A record description was to be  
> descriptive, not prescriptive nor proscriptive.

SMTP represents a great achievement.  Much of this achievement has  
occurred by minimizing administrative efforts needed to establish SMTP  
services.  These minimal administrative efforts now play a significant  
role in fostering current levels of abuse afflicting SMTP.   
Standardizing on AAAA as an MX fall-back moves SMTP and IPv6 in the  
wrong direction.  Sensitivity to abuse adopts a practice of "opt-in"  
rather than "opt-out".   AAAA as an MX fall-back may necessitate SMTP  
IPv6 hosts the need to publish bogus MX records for the specific  
purpose of "opting out".

> So the bottom line is that I see sufficient support for including  
> AAAA lookups when implicit MX comes into play.

It seems the specification should attempt to differentiate what might  
be achievable within private versus public server configurations.

> It's been suggested that 2821bis revert back to either the implicit  
> MX description found in RFC 821 or RFC 974, although Glen Anderson  
> had some suggested improvements to that latter's description that do  
> make it clearer. Any of these three would satisfy this decision, and  
> I'll let John choose the wording he prefers.

While ensuring that the 'S' in SMTP upholds the concept of Simple,  
avoiding greater levels of abuse will help further that goal.  While  
those that live and breath SMTP don't want to see any administrative  
dependencies added, this costs hosts running unrelated protocols that  
must then terminate a seemingly endless stream of SMTP related abuse.   
The success of SMTP requires greater administrative care be taken.  To  
take this to the logical conclusion, the transition to IPv6 with a  
reduction in SMTP related abuse would be further aided by deprecating  
use of A records as an MX fall-back mechanism published in a follow-on  
draft, where the current draft could warn of this possible change.

-Doug

Date: Tue, 15 Apr 2008 17:51:12 -0400
From: John Leslie <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Hector Santos <[email-masked]> wrote:
> 
> And this is why I was proposing the text that if a IPv6 aware client was 
> sending to mail out to a IPv4 client (because it used a IPv4 socket 
> connection), it SHOULD NOT make any presumption that the receiver would 
> be able to *communicate* back (in sending a bounce or user reply) using 
> IPv6.  If it doesn't provide a compatible IPv4 layer, then its should 
> expect loss of mail.

   (I shall try -- really I shall -- to avoid an IPv6 religious war here.)

> Unless you have a middle man or proxie handling all the outbound and 
> inbound for you, you will need to have a dual stack smtp system for 
> direct contacts from IPv4 systems.

   My hope has been that an IPv6-only host speaking SMTP to the rest of
the world would:

 - look for an MX RR pointing to an AAAA RR
   - if it finds one, use that AAAA RR
   - if not, look for an MX (explicit or implied) pointing to an A RR
     - if it finds one, pass the email to a friendly relay speaking IPv4
     _ if not, give the usual error

 - advertise an MX RR pointing to an A RR
   (in addition to any pointing to AAAA RRs)

   This strikes me as a more reasonable long-term algorithm than
requiring all mail from an IPv6 user to go through a SMTP server with
both IPv4 and IPv6 connectivity.

   It may be that the consensus here prefers Hector's solution: if so,
I suppose I should shut up. But please think long-term: we want something
that can work today and continue working for 20 years, by which time
IPv4 should be as rare as IPv6 is today.

--
John Leslie <[email-masked]>

Date: Tue, 15 Apr 2008 17:44:44 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

<sarcasm>

gee, I don't know... if current practice is to require that senders have 
A or MX records, maybe we ought to insist on it in the standard.  I 
mean, isn't the purpose of the standard to dictate current practice?

and isn't this the sort of change that should cause a recycle to proposed?

</sarcasm>

seriously, why is this the sort of bug that should dictate a change to 
the standard, whereas the problems associated with fallback to address 
records are the sort of bug that should be encouraged by the standard?

Keith

Arnt Gulbrandsen wrote:
> 
> I agree that the wording in -10 reflects the rough consensus.
> 
> However, I think 2821bis needs a little extra text to notify operators 
> that they may need to upgrade or reconfigure to comply with 2821bis. For 
> example bs.jck.com currently refuses mail from AAAA-only addresses:
> 
> $ vrfy -vv -S [email-masked] [email-masked]
> rcpt [email-masked]' at 'bs.jck.com'
> connecting to bs.jck.com (209.187.148.211) port 25
> <<< 220 bs.jck.com ESMTP Exim 4.34 Tue, 15 Apr 2008 12:39:35 -0400
>>>> EHLO libertango.oryx.com
> <<< 250-bs.jck.com Hello libertango.oryx.com [195.30.37.9]
> <<< 250-SIZE 52428800
> <<< 250-8BITMIME
> <<< 250-PIPELINING
> <<< 250-AUTH CRAM-MD5
> <<< 250 HELP
>>>> MAIL From:<[email-masked]>
> <<< 250 OK
>>>> RCPT To:<[email-masked]>
> <<< 550-Verification failed for <[email-masked]>
> ...
> 
> ipv6.l.google.com has only an AAAA RR. The same test works when I use 
> [email-masked] as sender address.
> 
> (I tried some other recent posters. Some accept mail from test@ipv6, 
> including Dave, some others don't, including you and me.)
> 
> Exim users can comply by disabling the sender_verify variable, postfix 
> users can disable reject_unknown_sender_domain, I don't know the 
> relevant variable for any other MTAs.
> 
> Arnt
> 

Cc: Dave Crocker <[email-masked]>, Tony Hansen <[email-masked]>, SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
From: Lisa Dusseault <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Date: Tue, 15 Apr 2008 13:22:03 -0700
Sender: [email-masked]

Hi Keith,

I've been working with Tony and John very closely on this issue, and  
whether it smells foul or not, I think this is the best we can do.   
Tony was very diligent about having conversation on all aspects and  
looking at a number of different resolutions including the one he  
recommends.

The goal of updating RFC2821 to keep it relevant is certainly one, but  
only one, of a bunch of constraints and criteria.  "Consensus" and  
"Timeliness" are two others which are in play for this particular  
issue.  We have no clear consensus for changes that would make  
RFC2821bis more relevant on this particular issue, and we have already  
lost much time.

If you believe you can drive consensus on this issue to a different  
resolution, please take that on yourself and we'll participate and pay  
attention.

Thanks,

Lisa

On Apr 14, 2008, at 9:59 PM, Keith Moore wrote:

>
>
> Dave Crocker wrote:
>
>> Tony Hansen wrote:
>>> From this viewpoint, running code wins.
>>>
>>> I'm also swayed by the principle of "least surprise".
>> ...
>>> Last of all, I'm swayed by the discussions around RFC 974 and the  
>>> DRUMS
>>> archive search
>> ...
>>> So the bottom line is that I see sufficient support for including  
>>> AAAA
>>> lookups when implicit MX comes into play.
>>
>> Wow.
>>
>> Diligently thorough.  Carefully reasoned.  Historically solid.   
>> (Running
>> code that interoperated was what resolved a problem with checksum for
>> the original TCP spec...)
>
> and it completely ignored the entire purpose for updating 2821 - to  
> keep
> it relevant.
>
> I call foul.
>
> Keith
> _______________________________________________
> IETF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

Date: Tue, 15 Apr 2008 16:17:07 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Arnt Gulbrandsen <[email-masked]>
CC:  [email-masked], [email-masked], [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> [email-masked] writes:
>> Not necessarily.  That host may apply a different policy for mail 
>> coming through the other MX hosts.  Otherwise, it would cause 
>> backscatter.  BTW, the problem may be applicable to IPv4 as well.
> 
> Oh wait, I misunderstood what you're saying. And you probably 
> misunderstood me.
> 
> jck.com doesn't have an IPv6 MX, so the only way to deliver mail to it 
> is to open an IPv4 SMTP connection.
> 
> Suppose I have only an IPv6 address and want to send John mail (sorry to 
> pick on you, John). I open an IPv6 connection to my ISP's smarthost and 
> send some mail from my address to a jck.com address. My ISP's smarthost 
> has an IPv4 address, so it opens an IPv4 connection to the best 
> reachable MX for jck.com. The connection from my ISP's smarthost to the 
> jck.com MX is what I pasted, and where the problem shows up.

Exactly. You SHOULD NOT expect IPv6 feedback behavior to be automatic or 
reliable, especially from a IPv6 Only client to dual stack smarthost. It 
will only work if replies are going back thru the same compatible host 
routing which is generally not the case under a smarthost.

> And the text I think should be there would be a sentence like this in 
> sections 4.1.1.2: "Note that the reverse-path may be reachable only via 
> IPv6, even if the SMTP connection uses IPv4", possibly with some 
> emphasis to point out that perfectly valid 2821 code/configurations 
> don't support this. 4.1.1.3 would need similar language for "forward-path".
> 
> Arnt

And this is why I was proposing the text that if a IPv6 aware client was 
sending to mail out to a IPv4 client (because it used a IPv4 socket 
connection), it SHOULD NOT make any presumption that the receiver would 
be able to *communicate* back (in sending a bounce or user reply) using 
IPv6.  If it doesn't provide a compatible IPv4 layer, then its should 
expect lost of mail.

Unless you have a middle man or proxie handling all the outbound and 
inbound for you, you will need to have a dual stack smtp system for 
direct contacts from IPv4 systems.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Tue, 15 Apr 2008 21:25:34 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

[email-masked] writes:
> Not necessarily.  That host may apply a different policy for mail 
> coming through the other MX hosts.  Otherwise, it would cause 
> backscatter.  BTW, the problem may be applicable to IPv4 as well.

Oh wait, I misunderstood what you're saying. And you probably misunderstood me.

jck.com doesn't have an IPv6 MX, so the only way to deliver mail to it 
is to open an IPv4 SMTP connection.

Suppose I have only an IPv6 address and want to send John mail (sorry to 
pick on you, John). I open an IPv6 connection to my ISP's smarthost and 
send some mail from my address to a jck.com address. My ISP's smarthost 
has an IPv4 address, so it opens an IPv4 connection to the best 
reachable MX for jck.com. The connection from my ISP's smarthost to the 
jck.com MX is what I pasted, and where the problem shows up.

And the text I think should be there would be a sentence like this in 
sections 4.1.1.2: "Note that the reverse-path may be reachable only via 
IPv6, even if the SMTP connection uses IPv4", possibly with some 
emphasis to point out that perfectly valid 2821 code/configurations 
don't support this. 4.1.1.3 would need similar language for 
"forward-path".

Arnt

Date: Tue, 15 Apr 2008 11:50:06 -0700
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: [email-masked]
Sender: [email-masked]

Hi Arnt,
At 11:32 15-04-2008, Arnt Gulbrandsen wrote:
>Yes, and the IPv6-only relay would then connect to bs.jck.com and 
>issuing the conversation that ends with 550.

Not necessarily.  That host may apply a different policy for mail 
coming through the other MX hosts.  Otherwise, it would cause 
backscatter.  BTW, the problem may be applicable to IPv4 as well.

Regards,
-sm 

Date: Tue, 15 Apr 2008 20:32:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

[email-masked] writes:
> Hi Arnt,
> At 10:01 15-04-2008, Arnt Gulbrandsen wrote:
>> However, I think 2821bis needs a little extra text to notify 
>> operators that they may need to upgrade or reconfigure to comply 
>> with 2821bis. For example bs.jck.com currently refuses mail from 
>> AAAA-only addresses:
>
> There's nothing wrong with that if the host is only IPv4 aware.  The 
> IPv6-only sender would be connecting to the IPv6 relay for that 
> domain to send mail as follows:
>
> MAIL FROM:<[email-masked]>
> 250 OK
> RCPT TO:<[email-masked]>
> 250 Accepted

Yes, and the IPv6-only relay would then connect to bs.jck.com and 
issuing the conversation that ends with 550.

>> Exim users can comply by disabling the sender_verify variable, 
>> postfix users can disable reject_unknown_sender_domain, I don't know 
>> the relevant variable for any other MTAs.
>
> That might cause more problem than it solves.

I agree.

Arnt

Date: Tue, 15 Apr 2008 11:23:32 -0700
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: [email-masked]
Sender: [email-masked]

Hi Arnt,
At 10:01 15-04-2008, Arnt Gulbrandsen wrote:
>However, I think 2821bis needs a little extra text to notify 
>operators that they may need to upgrade or reconfigure to comply 
>with 2821bis. For example bs.jck.com currently refuses mail from 
>AAAA-only addresses:

There's nothing wrong with that if the host is only IPv4 aware.  The 
IPv6-only sender would be connecting to the IPv6 relay for that 
domain to send mail as follows:

MAIL FROM:<[email-masked]>
250 OK
RCPT TO:<[email-masked]>
250 Accepted

>Exim users can comply by disabling the sender_verify variable, 
>postfix users can disable reject_unknown_sender_domain, I don't know 
>the relevant variable for any other MTAs.

That might cause more problem than it solves.

Regards,
-sm 

Date: Tue, 15 Apr 2008 13:41:20 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Tony Hansen <[email-masked]>
CC: SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Tony, John,

I appreciate the hard work (and time) you guys put into this. I also 
support the "least surprise" principle and feel this is the best 
decision at this time related to this issue.

I can only hope someone can take the lead or be the point behind a new 
*consolidated* SMTP IPv6/4 technical spec effort.

Thanks

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Tony Hansen wrote:
> 
> <shepherd hat on>
> 
> During the second last call for rfc2821bis, there has been much
> discussion of how the "implicit MX" handling is to be handled in an
> IPv6-capable and IPv6-only environment.
> 
> This has generated much heat, as well as numerous proposals that were
> both productive and counter-productive, and that were both in scope and
> out of scope.
> 
> I came at this question with an open mind, trying to weigh each of the
> arguments being made both for and against different stances. My
> measuring stick in each case against has been: How does this measure
> against what is required to advance 2821bis to Draft Standard? What is
> the current usage? What do the implementation reports have to say on
> this issue?
> 
> The SMTP implementations that have made the transition to support IPv6
> appear to already have done it in a way that supports AAAA records for
> the implicit MX case. In some cases they are following RFC 3974, and
> other cases they are just using getaddrinfo() and letting it do the
> rest. Note that RFC 3974 itself was supposedly "based on experience in
> deploying IPv6". At least one of these MTAs is in common use around the
> network in the IPv4 world.
> 
> In essence, these implementations are following the RFC 821 and RFC 974
> (sans WKS) rules of looking for address records. They've ignored the
> A-only wording of RFC 2821 and are acting like we specify currently in
> 2821bis-09.
> 
> In my queries I haven't yet found any IPv6-capable SMTP server that
> doesn't do it.
> 
> I've seen examples of sites that are in regular use that mail would
> break in an IPv6-only world if implicit MX to AAAA did not work.
> 
>  From this viewpoint, running code wins.
> 
> I'm also swayed by the principle of "least surprise". Some of the
> responses I've gotten have been along the lines of "Why's this a
> question? Of course you do AAAA lookup". One person who had a site set
> up with an IPv6-only connection and no MX record told me "I wanted to
> forward my e-mail to an account on that machine. It worked the first
> time, so I didn't see a need to change it." As mentioned above, at least
> one of the IPv6-capable MTAs is in common use around the network in the
> IPv4 world, and turning on IPv6 on those boxes should not cause surprises.
> 
> Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS
> archive search around the question of what led to the wording change in
> 2821bis saying explicitly to do A lookups. These indicate that the
> intent of adding the A record description was to be descriptive, not
> prescriptive nor proscriptive.
> 
> So the bottom line is that I see sufficient support for including AAAA
> lookups when implicit MX comes into play.
> 
> It's been suggested that 2821bis revert back to either the implicit MX
> description found in RFC 821 or RFC 974, although Glen Anderson had some
> suggested improvements to that latter's description that do make it
> clearer. Any of these three would satisfy this decision, and I'll let
> John choose the wording he prefers.
> 
> </shepherd hat off>
> 
>     Tony Hansen
>     [email-masked]
> 
> 
> 

Date: Tue, 15 Apr 2008 19:01:58 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Cc: [email-masked]
Sender: [email-masked]

I agree that the wording in -10 reflects the rough consensus.

However, I think 2821bis needs a little extra text to notify operators 
that they may need to upgrade or reconfigure to comply with 2821bis. 
For example bs.jck.com currently refuses mail from AAAA-only addresses:

$ vrfy -vv -S [email-masked] [email-masked]
rcpt [email-masked]' at 'bs.jck.com'
connecting to bs.jck.com (209.187.148.211) port 25
<<< 220 bs.jck.com ESMTP Exim 4.34 Tue, 15 Apr 2008 12:39:35 -0400
>>> EHLO libertango.oryx.com
<<< 250-bs.jck.com Hello libertango.oryx.com [195.30.37.9]
<<< 250-SIZE 52428800
<<< 250-8BITMIME
<<< 250-PIPELINING
<<< 250-AUTH CRAM-MD5
<<< 250 HELP
>>> MAIL From:<[email-masked]>
<<< 250 OK
>>> RCPT To:<[email-masked]>
<<< 550-Verification failed for <[email-masked]>
...

ipv6.l.google.com has only an AAAA RR. The same test works when I use 
[email-masked] as sender address.

(I tried some other recent posters. Some accept mail from test@ipv6, 
including Dave, some others don't, including you and me.)

Exim users can comply by disabling the sender_verify variable, postfix 
users can disable reject_unknown_sender_domain, I don't know the 
relevant variable for any other MTAs.

Arnt

Date: Tue, 15 Apr 2008 09:37:55 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-klensin-rfc2821bis-10.txt
Sender: [email-masked]

Diffs between -09 and -10 can be found by clicking on Diff1 or Diff2 at 
the top of tools.ietf.org/html/draft-klensin-rfc2821bis

G.12. Changes from version -09 to -10	
     1. Changed uses of "character length" to "octet length" and
     wrote a brief introduction
     2. Modified text in Appendix A to permit extensions that would	
     permit non-ASCII characters in command arguments or replies.
     3. Moved reference to RFC 1870 to Normative, since it is
     referenced in a SHOULD.
     4. Changed the description of MX handling using Glenn Anderson's	
     text. No substantive change, just clarity.	
		
	Tony Hansen
	[email-masked]

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Simple Mail Transfer Protocol
> 	Author(s)       : J. Klensin
> 	Filename        : draft-klensin-rfc2821bis-10.txt
> 	Pages           : 98
> 	Date            : 2008-04-14
> 
> This document is a specification of the basic protocol for Internet
> electronic mail transport.  It consolidates, updates, and clarifies
> several previous documents, making all or parts of most of them
> obsolete.  It covers the SMTP extension mechanisms and best practices
> for the contemporary Internet, but does not provide details about
> particular extensions.  Although SMTP was designed as a mail
> transport and delivery protocol, this specification also contains
> information that is important to its use as a "mail submission"
> protocol for "split-UA" mail reading systems and mobile environments.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-10.txt

Date: Tue, 15 Apr 2008 13:58:17 +0100
From: "Peter Bowyer" <[email-masked]>
To: [email-masked]
Subject: Re: Requiring PTR
Sender: [email-masked]

On 15/04/2008, Carl S. Gutekunst <[email-masked]> wrote:
>
> Robert A. Rosenberg wrote:
> > Unfortunately many so called business tiers are served from a dynamic
> block (or at least a dynamic block that is not flagged as business tier). In
> fact, many home tiers are allowed to run servers (I am one as an OptOnline
> BOOST user) yet are not served from an IP block that MAPS has flagged as
> allowed to run an MTA and thus relay messages to other MTAs or AoL.
> >
>
> Hey, I never said the list was accurate. :-|
>
> Early on there were several dynamic block lists, but eventually they all
> gave up except for MAPS. It's just way too labor intensive to maintain.

http://www.spamhaus.org/pbl/index.lasso definitely hasn't given up,
and has a self-service mechanism for asserting individual IPs as
'safe'.

-- 
Peter Bowyer
Email: [email-masked]
Follow me on Twitter: twitter.com/peeebeee

Date: Tue, 15 Apr 2008 08:41:44 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Carl S. Gutekunst" <[email-masked]>
CC: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: Requiring PTR
Sender: [email-masked]

Carl S. Gutekunst wrote:
> 
> Robert A. Rosenberg wrote:
>> Unfortunately many so called business tiers are served from a dynamic 
>> block (or at least a dynamic block that is not flagged as business 
>> tier). In fact, many home tiers are allowed to run servers (I am one 
>> as an OptOnline BOOST user) yet are not served from an IP block that 
>> MAPS has flagged as allowed to run an MTA and thus relay messages to 
>> other MTAs or AoL. 
> 
> Hey, I never said the list was accurate. :-|
> 
> Early on there were several dynamic block lists, but eventually they all 
> gave up except for MAPS. It's just way too labor intensive to maintain. 

Computers and software can help in this labor elimination automation 
need. :-)

> The ISPs are constantly moving things around, and most really aren't 
> interested in giving third parties up-to-date information where their 
> allocation ranges are. As a result, the main source for corrections on 
> that kind of list are end user complaints.

Well, this laziness is the sort of stuff that inevitably bites the wrong 
people who will propose new bills, laws and IETF drafts, etc, etc.

But who cares right?  The issue was resolved at the individual level.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 14 Apr 2008 22:18:36 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
CC: [email-masked]
Subject: Re: Requiring PTR
Sender: [email-masked]

Robert A. Rosenberg wrote:
> Unfortunately many so called business tiers are served from a dynamic 
> block (or at least a dynamic block that is not flagged as business 
> tier). In fact, many home tiers are allowed to run servers (I am one 
> as an OptOnline BOOST user) yet are not served from an IP block that 
> MAPS has flagged as allowed to run an MTA and thus relay messages to 
> other MTAs or AoL. 

Hey, I never said the list was accurate. :-|

Early on there were several dynamic block lists, but eventually they all 
gave up except for MAPS. It's just way too labor intensive to maintain. 
The ISPs are constantly moving things around, and most really aren't 
interested in giving third parties up-to-date information where their 
allocation ranges are. As a result, the main source for corrections on 
that kind of list are end user complaints.

<csg>

Date: Tue, 15 Apr 2008 00:59:28 -0400
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
CC: Tony Hansen <[email-masked]>, SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Dave Crocker wrote:

> Tony Hansen wrote:
>>  From this viewpoint, running code wins.
>>
>> I'm also swayed by the principle of "least surprise". 
> ...
>> Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS
>> archive search 
> ...
>> So the bottom line is that I see sufficient support for including AAAA
>> lookups when implicit MX comes into play.
> 
> Wow.
> 
> Diligently thorough.  Carefully reasoned.  Historically solid.  (Running 
> code that interoperated was what resolved a problem with checksum for 
> the original TCP spec...)

and it completely ignored the entire purpose for updating 2821 - to keep 
it relevant.

I call foul.

Keith

Date: Tue, 15 Apr 2008 00:26:40 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Requiring PTR
Sender: [email-masked]

At 00:17 +0100 on 04/13/2008, Sabahattin Gucukoglu wrote about Re: 
Requiring PTR:

>As a blind person, I find that the other thing that doesn't bother the
>majority of people that does bother me is graphical CAPTCHAs.  Most people
>find them a nuisance; I find them a positive frustration.

While I can agree with your views about CAPTCHAs, I must point out 
that in at least some of the cases that I have seen them used in, 
they are used in a Section 508 compliant way in that they are 
accompanied by a link that will READ the contents to you for entry. 
This alternative at least, at least in my opinion, shows some intent 
to not disenfranchise those who are unable to make use of the 
displayed CAPTCHA while still serving whatever needs the site owner 
feels the scrambled pictures provide.

At 04:09 -0400 on 04/14/2008, Hector Santos wrote about Re: Requiring PTR:

>An FYI, the new web SFI (speech friendly interface as we use to call it)
>effort is called officially called by the ARIA (Accessible Rich Internet
>Applications).

Simply supplying a link that when clicked plays a sound recording 
that reads out the letters/numbers in the image would work (and as I 
stated above) has been done on some sites already. I am not sure if 
this method qualifies as SFI or not. I am not sure if SFI applies to 
this situation or not since I have the impression that it has to do 
with HTML/CSS markup not providing an alternative to viewing a 
dynamically created CAPTCHA image by also creating a dynamic audio 
version of its contents.

Date: Tue, 15 Apr 2008 00:02:10 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Requiring PTR
Sender: [email-masked]

At 11:33 -0700 on 04/12/2008, Carl S. Gutekunst wrote about Re: Requiring PTR:

>Hector Santos wrote:
>>Many systems, and naively believed AOL too, I believe used services 
>>like from MAPS RBL which lookup the zone owner to determine if this 
>>was a home or business tier.
>
>They do -- or rather, dynamic vs. static. If you're in the MAPS 
>dynamic IP range, you won't even get a TCP connection; you'll be 
>blocked at the firewall.

Unfortunately many so called business tiers are served from a dynamic 
block (or at least a dynamic block that is not flagged as business 
tier). In fact, many home tiers are allowed to run servers (I am one 
as an OptOnline BOOST user) yet are not served from an IP block that 
MAPS has flagged as allowed to run an MTA and thus relay messages to 
other MTAs or AoL.

Date: Mon, 14 Apr 2008 20:50:51 -0700
From: Dave Crocker <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: SMTP Interest Group <[email-masked]>, IETF General Discussion Mailing List <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

Tony Hansen wrote:
>  From this viewpoint, running code wins.
> 
> I'm also swayed by the principle of "least surprise". 
...
> Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS
> archive search 
...
> So the bottom line is that I see sufficient support for including AAAA
> lookups when implicit MX comes into play.

Wow.

Diligently thorough.  Carefully reasoned.  Historically solid.  (Running code 
that interoperated was what resolved a problem with checksum for the original 
TCP spec...)

Nice job, Tony!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 14 Apr 2008 22:33:51 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
CC: IETF General Discussion Mailing List <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Sender: [email-masked]

<shepherd hat on>

During the second last call for rfc2821bis, there has been much
discussion of how the "implicit MX" handling is to be handled in an
IPv6-capable and IPv6-only environment.

This has generated much heat, as well as numerous proposals that were
both productive and counter-productive, and that were both in scope and
out of scope.

I came at this question with an open mind, trying to weigh each of the
arguments being made both for and against different stances. My
measuring stick in each case against has been: How does this measure
against what is required to advance 2821bis to Draft Standard? What is
the current usage? What do the implementation reports have to say on
this issue?

The SMTP implementations that have made the transition to support IPv6
appear to already have done it in a way that supports AAAA records for
the implicit MX case. In some cases they are following RFC 3974, and
other cases they are just using getaddrinfo() and letting it do the
rest. Note that RFC 3974 itself was supposedly "based on experience in
deploying IPv6". At least one of these MTAs is in common use around the
network in the IPv4 world.

In essence, these implementations are following the RFC 821 and RFC 974
(sans WKS) rules of looking for address records. They've ignored the
A-only wording of RFC 2821 and are acting like we specify currently in
2821bis-09.

In my queries I haven't yet found any IPv6-capable SMTP server that
doesn't do it.

I've seen examples of sites that are in regular use that mail would
break in an IPv6-only world if implicit MX to AAAA did not work.

 From this viewpoint, running code wins.

I'm also swayed by the principle of "least surprise". Some of the
responses I've gotten have been along the lines of "Why's this a
question? Of course you do AAAA lookup". One person who had a site set
up with an IPv6-only connection and no MX record told me "I wanted to
forward my e-mail to an account on that machine. It worked the first
time, so I didn't see a need to change it." As mentioned above, at least
one of the IPv6-capable MTAs is in common use around the network in the
IPv4 world, and turning on IPv6 on those boxes should not cause surprises.

Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS
archive search around the question of what led to the wording change in
2821bis saying explicitly to do A lookups. These indicate that the
intent of adding the A record description was to be descriptive, not
prescriptive nor proscriptive.

So the bottom line is that I see sufficient support for including AAAA
lookups when implicit MX comes into play.

It's been suggested that 2821bis revert back to either the implicit MX
description found in RFC 821 or RFC 974, although Glen Anderson had some
suggested improvements to that latter's description that do make it
clearer. Any of these three would satisfy this decision, and I'll let
John choose the wording he prefers.

</shepherd hat off>

	Tony Hansen
	[email-masked]

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: RFC2821bis-09: Lines and Submission
Date:  Tue, 15 Apr 2008 02:27:50 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 44
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<[email-masked]> wrote:

> A reference is normative when an understanding of it is
> needed to implement some aspect of the specification at
> hand. This is not the case with SMTP submit - you need
> understand nothing of it to implement SMTP proper.

If the MTA proper is used as MSA, depending on the port,
or for port 25 depending on the client, and the implementor
of said MTA never bothered to look in RFC 4409, then I fear
bad things can happen...  Okay, making RFC 4409 normative
won't necessarily help in this situation.

Maybe adding an *informative* RFC 5068 reference near the
"SHOULD 4409" would help, for obvious reasons RFC 4409 has
no pointer to 5068.

> I see nothing in RFC 2119 that restricts the terms in 
> such a way as to preclude such usage.

Yes, and of course RFC 2119 could not talk about the fine
art of splitting references into normative and informative.
 
 [similar question about 3461 and 3464]
> We're now talking about something that SHOULD be done in
> order ancillary to proper implementation of this
> specification. It therefore makes considerable sense for
> these to be normative, and I certainly would not object
> to doing so.  OTOH, these are still describe a separate
> facility so I'm not completely convinced our process
> requires this change.

For [37] = RFC 3464 John convinced me that "for example"
means what it says => informative.  For [35] = RFC 3461 he
might have missed the use in the ABNF <xtext> SHOULD.  And
for [36] = RFC 3463 it is IMO similar, 3461+3463 normative.

> OTOH, these are still describe a separate facility so I'm
> not completely convinced our process requires this change.

Look at the ten uses of [35], [36], and [37], I think they
are pretty clear.

 Frank

From: [email-masked]
Cc: [email-masked]
Date: Mon, 14 Apr 2008 15:52:29 -0700 (PDT)
Subject: Re: RFC2821bis-09: Lines and Submission
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> John C Klensin wrote:

>  [submission]
> > If people are convinced that additional text is needed to
> > explain this subject

> The second paragraph in chapter 2.1 ends with:

> | the less-capable clients discussed above SHOULD be using
> | the message submission protocol (RFC 4409 [42]) rather
> | than SMTP.

> IMHO that is fine.  Please move RFC 4409 from "informative"
> to "normative".

Such a move is neither appropriate nor acceptable.

A reference is normative when an understanding of it is needed to implement
some aspect of the specification at hand. This is not the case with SMTP
submit - you need understand nothing of it to implement SMTP proper.

Now, what's a little odd here is the use of terms that are customarily used to
measure compliance with the specification at hand to instead say that a certain
class of implementors really should be looking at a different document.
However, I see nothing in RFC 2119 that restricts the terms in such a way as to
preclude such usage. And since the admonition is appropriate ...

> RFC 3461 and RFC 3464 are apparently also
> covered by a SHOULD and therefore "normative".

We're now talking about something that SHOULD be done in order ancillary to
proper implementation of this specification. It therefore makes considerable
sense for these to be normative, and I certainly would not object to doing so.
OTOH, these are still describe a separate facility so I'm not completely
convinced our process requires this change.

				Ned

Date: Mon, 14 Apr 2008 17:09:58 +0100
From: Tony Finch <[email-masked]>
To: John Leslie <[email-masked]>
cc: John Levine <[email-masked]>, [email-masked]
Subject: Re: Do domains in SMTP have to exist ?
Sender: [email-masked]

On Sat, 12 Apr 2008, John Leslie wrote:
>
>    I most seriously doubt that consensus could be found to _require_
> such testing as part of 2821bis.

Though it is operationally a sensible thing to do.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
NORTH ROCKALL: SOUTHWEST VEERING NORTHWEST 5 OR 6, LATER BACKING SOUTHEAST 3
OR 4. MODERATE. SHOWERS. GOOD.

Date: Mon, 14 Apr 2008 04:09:24 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Sabahattin Gucukoglu <[email-masked]>
CC:  [email-masked], [email-masked]
Subject: Re: Requiring PTR
Sender: [email-masked]

Hector Santos wrote:
> 
> Sabahattin Gucukoglu wrote:
>> Hi Hector,
>>
>> As a blind person, I find that the other thing that doesn't bother the 
>> majority of people that does bother me is graphical CAPTCHAs.  Most 
>> people find them a nuisance; I find them a positive frustration.  
>> Given that these too are almost completely pointless, I won't inflict 
>> them upon others.
> 
> It catchy.  This web site has it, so that other site must have it.
> 
> As it use to be called in the DOS days, Speech Friendly Interfacing 
> (SFI) was something we supported in our mail reader products with direct 
> BIOS support and support with vendors such as Vocal Eyes.   I have to 
> admit the WEB neglected the market, but I don't think the Vocal Eyes 
> people stopped.
> 
> I think there is good news in the web horizon for the visual impaired. 
> New web standards are being put together specifically intended to better 
> support keyboard and cursors.  John Resig, the principal behind jQuery 
> and the new Javascript updates recently wrote about the current effort. 
> The new beta browsers FireFox 3.0 and IE 8.0 have support for the new 
> WEB "SFI" standards, but I forget the official name it is under.

An FYI, the new web SFI (speech friendly interface as we use to call it) 
effort is called officially called by the ARIA (Accessible Rich Internet 
Applications).

Some useful Links:

    http://www.w3.org/WAI/
    http://www.w3.org/TR/wai-aria/
    http://www.w3.org/WAI/intro/aria  <<-- overview
    http://ejohn.org/blog/javascript-in-internet-explorer-8/

I know this is not directly SMTP related, but maybe just for this note 
only, it might serve useful for SMTP product vendors here to become 
aware of such efforts, if not already, and to suggest improvements for 
their future SMTP related WEB configuration features to include WAI-ARIA 
support. :-)

You might be interested in testing some example ARIA ready test pages at:

          http://test.cita.uiuc.edu/aria/

This site show how typical HTML components, tables, input fields, 
select, check and radio boxes are done using the proposed ARIA coding 
syntax.  Overall from what I can see, it returns the UI design focus to 
make sure your tabbing and cursor is done properly.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 14 Apr 2008 02:27:19 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC2821bis-09: Lines and Submission
Sender: [email-masked]

Frank Ellermann wrote:
> John C Klensin wrote:
> 
>  [RFC 3461, 3464, and 4409 references only informative]
>> its appearance in that particular SHOULD does not make the
>> reference normative -- one does not need to understand RFC 4409
>> in order to make a competent and conforming implementation of
>> 2821/ 2821bis.
> 
> Implementing 2821bis is one thing, but many readers might be
> only interested in understanding how SMTP is supposed to work
> today - admins, postmasters, users, and email-arch authors.

How about developers?  Why is there this "air" that everything is 
written in a "PERL" script?

However, overall, I think it is excellent proposition in that we do need 
a NEW SPEC that is clean but still makes it compatible with the way we 
expect yesterday and today.

> OTOH I don't see why RFC 1123 is "normative":  It broke a
> clear concept of responsibility in RFC 821, its attempt to
> simplify RFC 974 wasn't too good after all, and 2821bis
> replaces everything in the relevant RFC 1123 chapter 5.
> IMO RFC 1123 belongs to the set of informative references
> (974, 1047, 1652, 1869, 1870, 2821) obsoleted by 2821bis.

To me, a few years back RFC 1123 was the closet thing to a "Holy Bible." 
  1123 was more important than 2821, but then again, 2821 was still new.

It should be noted that we are a multi-hosting software vendor, POP3, 
SMTP, FTP, TELNET, etc, so RFC 1123 served as a good summary as a 
complete Hosting Guide.

But I think we need a new SMTP summary guide.   In some respect we get 
lost in the "history", which is important, but use it too much to 
interfere with progress. And I'm not speaking of progress that breaks 
history, but progress that offers migration and backward compatibility.

Thats not an easy thing to do.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 14 Apr 2008 01:51:09 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Sabahattin Gucukoglu <[email-masked]>
CC:  [email-masked], [email-masked]
Subject: Re: Requiring PTR
Sender: [email-masked]

Sabahattin Gucukoglu wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Hector,
> 
> As a blind person, I find that the other thing that doesn't bother the 
> majority of people that does bother me is graphical CAPTCHAs.  Most people 
> find them a nuisance; I find them a positive frustration.  Given that 
> these too are almost completely pointless, I won't inflict them upon 
> others.

It catchy.  This web site has it, so that other site must have it.

As it use to be called in the DOS days, Speech Friendly Interfacing 
(SFI) was something we supported in our mail reader products with direct 
BIOS support and support with vendors such as Vocal Eyes.   I have to 
admit the WEB neglected the market, but I don't think the Vocal Eyes 
people stopped.

I think they is good news in the web horizon for the visual impaired. 
New web standards are being put together specifically intended to better 
support keyboard and cursors.  John Resig, the principal behind jQuery 
and the new Javascript updates recently wrote about the current effort. 
The new beta browsers FireFox 3.0 and IE 8.0 have support for the new 
WEB "SFI" standards, but I forget the official name it is under.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: RFC2821bis-09: Lines and Submission
Date:  Sun, 13 Apr 2008 22:58:20 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 55
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:

 [RFC 3461, 3464, and 4409 references only informative]
> its appearance in that particular SHOULD does not make the
> reference normative -- one does not need to understand RFC 4409
> in order to make a competent and conforming implementation of
> 2821/ 2821bis.

Implementing 2821bis is one thing, but many readers might be
only interested in understanding how SMTP is supposed to work
today - admins, postmasters, users, and email-arch authors.

Here RFC xxxx about X says that users SHOULD do Y in RFC yyyy.
For that they need to read and understand RFC yyyy, otherwise
they could end up not doing Y without a good excuse.  

In the case yyyy = 4409 it is also relevant for implementors,
if what they implement is all in one box, MX, MSA, and final
delivery MTA.   

> The cast that 3461 and 3464 are normative is a little
> stronger but, if you read the relevant sentence, what is
> it basically saying is that, if you find another standard
> that is applicable to NDNs and the particular situation,
> then you should use it.

The statement in 3.6.3 says "for example", but admittedly
I'm not aware of other "examples".  RFC 3461 [35] is also
needed in an ABNF comment: 

| the "xtext" syntax [35] SHOULD be used.

That is as normative as it can get, implementors won't know
when and why they violate this SHOULD without first looking
in RFC 3461.

RFC 3463 appears in the "for example" SHOULD statement, but
also in another SHOULD about extended error codes:

| the system described in RFC 3463 [36] SHOULD be used in
| preference to the invention of new codes.

That is normative for anybody considering new error codes.
Chapters 2.3.7 and 3.5.1 contain further pointers to RFC
3463.  The RFC 3464 [37] "for example" may be informative,
but RFC 3461 [35] and RFC 3463 [36] are IMO normative.

OTOH I don't see why RFC 1123 is "normative":  It broke a
clear concept of responsibility in RFC 821, its attempt to
simplify RFC 974 wasn't too good after all, and 2821bis
replaces everything in the relevant RFC 1123 chapter 5.
IMO RFC 1123 belongs to the set of informative references
(974, 1047, 1652, 1869, 1870, 2821) obsoleted by 2821bis.

 Frank

Date: Sun, 13 Apr 2008 00:29:57 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: RFC2821bis-09: Lines and Submission
Sender: [email-masked]

--On Sunday, 13 April, 2008 04:44 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> John C Klensin wrote:
> 
>  [submission]
>> If people are convinced that additional text is needed to
>> explain this subject
> 
> The second paragraph in chapter 2.1 ends with:
> 
> | the less-capable clients discussed above SHOULD be using
> | the message submission protocol (RFC 4409 [42]) rather
> | than SMTP.
> 
> IMHO that is fine.  Please move RFC 4409 from "informative"
> to "normative".  RFC 3461 and RFC 3464 are apparently also
> covered by a SHOULD and therefore "normative".

IMO, its appearance in that particular SHOULD does not make the
reference normative -- one does not need to understand RFC 4409
in order to make a competent and conforming implementation of
2821/ 2821bis.  The cast that 3461 and 3464 are normative is a
little stronger but, if you read the relevant sentence, what is
it basically saying is that, if you find another standard that
is applicable to NDNs and the particular situation, then you
should use it.  The standards themselves are examples, not
something needed to implement 2821bis, and hence not normative.

     john

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Requiring PTR
Date:  Sun, 13 Apr 2008 06:05:24 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 56
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hector Santos wrote:

> only after I clicked SEND

Same here, I found your explanation after I clicked "send".
 
> It may also raise the question when the "World's largest
> ESP" and a growing amount of other ESPs/ISP mail receivers
> forcing this PTR record, should be 'Highlighted' in 2821bis.

I think that is unnecessary.  2821bis-09 already covers it
in chapter 4.1.4:

| An SMTP server MAY verify that the domain name argument
| in the EHLO command actually corresponds to the IP address
| of the client.  However, if the verification fails the
| server MUST NOT refuse to accept a message on that basis.

Where "receiver policy" overrules a MUST NOT it won't help
to add "really" in the draft.  What AOL does is apparently
different, they "only" require that a name exists, not that
it matches.  A variation of the MTAMARK theme.  

Let's keep 2821bis as is for this issue, it's discussed in
other drafts:

draft-ietf-dnsop-inaddr-required-07 (2005), replaced by:
draft-ietf-dnsop-reverse-mapping-considerations-06 (WGLC)

An "iprev" mechanism is specified in
draft-kucherawy-sender-auth-header-14 (2008)

Hopefully Murray can submit a PubReq soon, it depends on
DKIM-ADSP, after s/SSP/ASP/g it now needs s/ASP/ADSP/g :-|

I think the OpenSPF folks liked the draft, as far as SPF
and PRA are concerned, i.e. not necessarily "iprev".  I've
no problem with "iprev", but it could cause a flamewar in
Last Call if somebody wants this. 

> I guess there is also some selfishness here because as
> with most things, if it doesn't happen to you, if you
> don't feel it, most people who careless about it.

We should have pushed harder for something like MTAMARK
in 2005, but we didn't.  Now we get what's left.  If you
don't like "iprev" here is something you might like, TMA:

http://blogs.msdn.com/tzink/archive/2007/10/26/sender-authentication-part-32-tma-explained.aspx

For the known reasons I don't like it when receivers do
weird things based on unrelated info published by the
alleged or real sender, but I also know that YMMV.  <eg>

 Frank

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: RFC2821bis-09: Lines and Submission
Date:  Sun, 13 Apr 2008 04:44:53 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 17
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:

 [submission]
> If people are convinced that additional text is needed to
> explain this subject

The second paragraph in chapter 2.1 ends with:

| the less-capable clients discussed above SHOULD be using
| the message submission protocol (RFC 4409 [42]) rather
| than SMTP.

IMHO that is fine.  Please move RFC 4409 from "informative"
to "normative".  RFC 3461 and RFC 3464 are apparently also
covered by a SHOULD and therefore "normative".

 Frank

From: "Sabahattin Gucukoglu" <[email-masked]>
To: John C Klensin <[email-masked]>
Date: Sun, 13 Apr 2008 03:15:47 +0100
Subject: Re: RFC2821bis-09: Lines and Submission
CC: [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Hi John,

On 12 Apr 2008 at 20:37, John C Klensin <[email-masked]> said:

> --On Sunday, 13 April, 2008 00:37 +0100 Sabahattin Gucukoglu
> <[email-masked]> wrote:
> 
> > I haven't yet done a complete editorial proofread (I'll get
> > around to that  soon, honest, although I'm quite sure all the
> > obvious errors will get  fixed by the editor; will send a list
> > when it's finished)
> 
> Please note that it is past the end of the second Last Call on
> this document.  Any proofreading comments that come in after -10
> is posted will be passed on to the RFC Editor, but may or may
> not be incorporated.

I have already observed corrections for previously noted editorial nits in
- -08 and earlier that were made in -09, so I suspect that this won't turn 
out to be a major problem after all.  Still, I have commenced rereading of 
the draft anew with the aim of tracking only differences in future.

[...]
> > 2.3.8 says:
> > 
> > | In addition, the appearance of "bare" "CR" or "LF"
> > | characters in text (i.e., either without the other) has a
> > | long history of causing problems in mail implementations and
> > | applications that use the mail system as a tool.  SMTP
> > | client implementations MUST NOT transmit these characters
> > | except when they are intended as line terminators and then
> > | MUST, as indicated above, transmit them only as a <CRLF>
> > | sequence.
> > 
> > Which does this mean?
> > 
> > 1.  As an SMTP client, it's entirely my responsibility to
> > verify that all  lines, even those sent with the DATA command,
> > always end exclusively with  <CRLF>, irrespective of what I've
> > been fed as input (whether by SMTP or by  other means, I.E.
> > standard input on UNIX, etc) to signify the end of a  line.
> > 
> > 2.  Sending <CRLF> is only necessary when I intend
> > end-of-line, which is  true for commands or the end-of-DATA
> > indicator, but I am not obliged to  tamper with message data
> > and can safely assume that all servers can and  should accept
> > arbitrary ASCII message content with arbitrary line length.
> 
> The first.  This is a firm requirement and has been since we
> were transporting email over FTP.  Note that receiving
> implementations that allocate buffers for lines, consistent with
> the minimum limits elsewhere in the document, count between CRLF
> pairs, so the implications for the server side are significant.
> If one wants to send something in the DATA other than
> CRLF-terminated lines, there are standardized extensions for
> doing so.  Of course, many receiving systems are, in the
> interest of robustness, quite permissive about this, but that
> behavior lies outside the standard: the receiving system has the
> right to expect that it will be sent message data with
> CRLF-terminated lines.

Okay, this is what I imagine was intended and have provided for, but in 
that case the paragraph immediately preceeding the one quoted appears to 
contradict this intention, since it requires that servers not recognise 
anything other than <CRLF> as a line terminator.  This would make perfect 
sense, were it not the server's responsibility to normalise improperly 
submitted message data, which is now the exception to the general case of 
handling lines in buffers terminated exclusively by <CRLF> (and in 
particular, the <CRLF>.<CRLF> to finish the message data).

As it happens, I am able to find stray CR or LF characters very easily in 
DATA lines and have a choice of either converting them to pairs or 
rejecting the entire message.  I'd prefer to reject the message, but I 
suspect I'll be accused of not being liberal if I do, as qmail once was 
for doing the same.

Cheers,
Sabahattin

- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Sat, 12 Apr 2008 20:37:25 -0400
From: John C Klensin <[email-masked]>
To: Sabahattin Gucukoglu <[email-masked]>, [email-masked]
Subject: Re: RFC2821bis-09: Lines and Submission
Sender: [email-masked]

--On Sunday, 13 April, 2008 00:37 +0100 Sabahattin Gucukoglu
<[email-masked]> wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> I haven't yet done a complete editorial proofread (I'll get
> around to that  soon, honest, although I'm quite sure all the
> obvious errors will get  fixed by the editor; will send a list
> when it's finished)

Please note that it is past the end of the second Last Call on
this document.  Any proofreading comments that come in after -10
is posted will be passed on to the RFC Editor, but may or may
not be incorporated.

> but two issues  which are tickling my
> sense of discomfort most particularly are Lines  (2.3.8) and
> an absent mention in 2.1 about the non-use of MX records for 
> initial submission.  I have noted other issues which I don't
> feel, at  least until I've reread the complete draft, to
> warrant discussion for the  current draft-standard-to-be at
> the moment, although I'll point them out  in due course.
> 
> 2.3.8 says:
> 
> | In addition, the appearance of "bare" "CR" or "LF"
> characters in text | (i.e., either without the other) has a
> long history of causing | problems in mail implementations and
> applications that use the mail | system as a tool.  SMTP
> client implementations MUST NOT transmit | these characters
> except when they are intended as line terminators | and then
> MUST, as indicated above, transmit them only as a <CRLF> |
> sequence.
> 
> Which does this mean?
> 
> 1.  As an SMTP client, it's entirely my responsibility to
> verify that all  lines, even those sent with the DATA command,
> always end exclusively with  <CRLF>, irrespective of what I've
> been fed as input (whether by SMTP or by  other means, I.E.
> standard input on UNIX, etc) to signify the end of a  line.
> 
> 2.  Sending <CRLF> is only necessary when I intend
> end-of-line, which is  true for commands or the end-of-DATA
> indicator, but I am not obliged to  tamper with message data
> and can safely assume that all servers can and  should accept
> arbitrary ASCII message content with arbitrary line length.

The first.  This is a firm requirement and has been since we
were transporting email over FTP.  Note that receiving
implementations that allocate buffers for lines, consistent with
the minimum limits elsewhere in the document, count between CRLF
pairs, so the implications for the server side are significant.
If one wants to send something in the DATA other than
CRLF-terminated lines, there are standardized extensions for
doing so.  Of course, many receiving systems are, in the
interest of robustness, quite permissive about this, but that
behavior lies outside the standard: the receiving system has the
right to expect that it will be sent message data with
CRLF-terminated lines.

> Although 1 is how I read it most and how it's probably
> intended, it  worries me: this is yet another intrusion of the
> mail system upon message  content, and I should like not to be
> burdened with it.

If it is an intrusion, it has been an intrusion for around 35
years.   Given installed base and deployment issues, it cannot
be changed in 2821bis.

>...
> Section 2.1 of 2821bis doesn't make it clear that the MX
> records aren't  typically used for client connections to
> submission servers.  Given that  MX is mentioned as the means
> of finding gateways and final delivery  systems by extension,
> it seems only proper to exclude submission servers,  which
> almost never are located using this method and don't fit
> cleanly  into the definition of a relay.

While there is considerable flexibility in practice and, indeed,
very few MUAs communicating with submission servers do MX
evaluation to find them, today's preferred practice is to use
RFC 4409 servers for message submission, not SMTP (2821) ones.
Further, because the relationship between a submitting MUA and
the submission server is considered a private agreement by 2821,
the mechanisms used by the client to find the server are
basically part of that agreement.  

If people are convinced that additional text is needed to
explain this subject, I'd be happy to incorporate suggestion as
long as people are also convinced that any further delays it
would introduce are worth it.

       john

Date: Sat, 12 Apr 2008 17:21:39 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
CC: [email-masked]
Subject: Re: Do domains in SMTP have to exist ?
Sender: [email-masked]

Folks,

While John has asked a reasonable question, I fear it is not the one that might 
need answering for the DKIM effort.  (I believe that John is not the only one 
tending to ask larger questions than the DKIM group needs to answer...)

In particular, note the Subject line of this thread.  Yet the current DKIM work 
is about rfc2822.From addresses, not rfc2821 fields.

The issue that is beyond the scope of John's question, but probably goes to the 
heart of what the DKIM group is doing, is what the limits are of the 
specification it is currently working on -- now called Author Domain Signing 
Practices, ADSP. This initially began as a means of publishing a record that 
says whether an owner of a domain name signs mail under that domain name.

The effort now attempts to have a single published record cover multiple names 
under a given domain, as well as checking for the very existence of that domain 
(or any under it.)

Some of us believe this to be rather far afield of the working group's scope, as 
well as far afield of what is technically practical.

But, of course, [email-masked] isn't the place to pursue this.

But [email-masked] is.  Please do feel invited to join the discussion there.

d/

John Levine wrote:
> Hi.  I have a new niggly question.
> 
> Over in DKIM land there is a battle going on with respect to the
> treatment of domains that don't exist, with "don't exist" meaning
> something like an authoritative DNS server doesn't return an MX or A
> or AAAA or CNAME for the name.
> 
> Looking through the current draft, it looks to me like everyone
> assumes that domain names have to exist, with the explicit exception
> of the HELO/EHLO name, but it never says so in so many words.
> 
> Is this a deliberate omission, or is it so obvious that it wasn't
> worth stating explicitly?
> 
> R's,
> John
> 
> PS: The domains in the DKIM discussion are 2822 domains, but the
> 2822upd draft punts the interpretation of domain names over here.
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 12 Apr 2008 20:17:05 -0400
From: John Leslie <[email-masked]>
To: John Levine <[email-masked]>
Cc: [email-masked]
Subject: Re: Do domains in SMTP have to exist ?
Sender: [email-masked]

John Levine <[email-masked]> wrote:
> 
> Over in DKIM land there is a battle going on with respect to the
> treatment of domains that don't exist, with "don't exist" meaning
> something like an authoritative DNS server doesn't return an MX or A
> or AAAA or CNAME for the name.

   I'm guessing you mean the thread containing

http://mipassoc.org/pipermail/ietf-dkim/2008q2/009986.html

where you wrote:
] Jim Fenton wrote:
]>> If ADSP can depend on a well-specified requirement for
]>> checking for the existence of the domain, please indicate
]>> where this is specified.
]
] The current 2821bis draft says in sec 5:
]
]  Only resolvable, fully-qualified, domain names (FQDNs) are permitted
]  when domain names are used in SMTP.  In other words, names that can
]  be resolved to MX RRs or address (i.e.  A or AAAA) RRs (as discussed
]  in Section 5) are permitted, as are CNAME RRs whose targets can be
]  resolved, in turn, to MX or address RRs.  Local nicknames or
]  unqualified names MUST NOT be used. 

which, in fact, comes from section 2.3.5.

> Looking through the current draft, it looks to me like everyone
> assumes that domain names have to exist, with the explicit exception
> of the HELO/EHLO name, but it never says so in so many words.

   This language is also found in RFC 2821 Section 3.6; and it does,
IMHO, say that a domain which does not exist in the DNS is out-of-spec.

   However, I see no plausible reading of this text to _require_
testing for the existence of a domain, which is what I believe the
DKIM WG was hoping for.

   (OTOH, it _would_ seem to legitimize any existence-testing that
the DKIM WG might require as _part_of_ using the DKIM protocol.)

> Is this a deliberate omission, or is it so obvious that it wasn't
> worth stating explicitly?

   I most seriously doubt that consensus could be found to _require_
such testing as part of 2821bis.

--
John Leslie <[email-masked]>

From: "Sabahattin Gucukoglu" <[email-masked]>
To: [email-masked]
Date: Sun, 13 Apr 2008 00:37:39 +0100
Subject: RFC2821bis-09: Lines and Submission
Content-description: Mail message body
Sender: [email-masked]

Hi all,

I haven't yet done a complete editorial proofread (I'll get around to that 
soon, honest, although I'm quite sure all the obvious errors will get 
fixed by the editor; will send a list when it's finished) but two issues 
which are tickling my sense of discomfort most particularly are Lines 
(2.3.8) and an absent mention in 2.1 about the non-use of MX records for 
initial submission.  I have noted other issues which I don't feel, at 
least until I've reread the complete draft, to warrant discussion for the 
current draft-standard-to-be at the moment, although I'll point them out 
in due course.

2.3.8 says:

| In addition, the appearance of "bare" "CR" or "LF" characters in text
| (i.e., either without the other) has a long history of causing
| problems in mail implementations and applications that use the mail
| system as a tool.  SMTP client implementations MUST NOT transmit
| these characters except when they are intended as line terminators
| and then MUST, as indicated above, transmit them only as a <CRLF>
| sequence.

Which does this mean?

1.  As an SMTP client, it's entirely my responsibility to verify that all 
lines, even those sent with the DATA command, always end exclusively with 
<CRLF>, irrespective of what I've been fed as input (whether by SMTP or by 
other means, I.E. standard input on UNIX, etc) to signify the end of a 
line.

2.  Sending <CRLF> is only necessary when I intend end-of-line, which is 
true for commands or the end-of-DATA indicator, but I am not obliged to 
tamper with message data and can safely assume that all servers can and 
should accept arbitrary ASCII message content with arbitrary line length.

Although 1 is how I read it most and how it's probably intended, it 
worries me: this is yet another intrusion of the mail system upon message 
content, and I should like not to be burdened with it.  Wrapper programs 
can be invoked by the user to perform the initial conversion between line 
conventions for a non-SMTP submission, and that should suffice for getting 
the desired effect without introducing further complexity into an 
otherwise completely transparent message transfer procedure that doesn't 
require knowledge of conventions for supporting all octette-oriented 
features of SMTP (ESMTP size, CHUNKING, etc).  It is convenient to use 
library routines to simply send and receive every line only with <CRLF> 
and to respond accordingly; every line not ending with <CRLF> is simply 
part of the line following the previous line that was.

Section 2.1 of 2821bis doesn't make it clear that the MX records aren't 
typically used for client connections to submission servers.  Given that 
MX is mentioned as the means of finding gateways and final delivery 
systems by extension, it seems only proper to exclude submission servers, 
which almost never are located using this method and don't fit cleanly 
into the definition of a relay.

Cheers,
Sabahattin

- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

From: "Sabahattin Gucukoglu" <[email-masked]>
To: Hector Santos <[email-masked]>, <[email-masked]>
Date: Sun, 13 Apr 2008 00:17:58 +0100
Subject: Re: Requiring PTR
CC: [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Hi Hector,

On 12 Apr 2008 at 10:05, Hector Santos <[email-masked]> said:
> I guess there is also some selfishness here because as with most things, if
> it doesn't happen to you, if you don't feel it, most people who careless
> about it.

I'll never forget what I suffered when using a dynamic IP address on a 
cable modem connection.  Now that I've moved to a static IP address on a 
DSL provider which allows changing of Reverse DNS mappings (using CNAMEs - 
not optimal, but better than nothing!), and am suffering almost zero 
delivery issues, my promise has been never to depend on checks that would 
put to suffering any others who may be less fortunate and/or who try to 
use their connections to best advantage.  I pay less than I used to when 
on that cable connection, but it required me to change connection 
technology to DSL of sufficiently reliable class (business) and telecoms 
provider.

The RDNS check is basically pointless without the paranoia (RDNS<->A) 
check, which generates too many false positives to be useful.  The Dynamic 
IP check is punishing people with guts and increasing the class divide 
between consumers and businesses needlessly.

As a blind person, I find that the other thing that doesn't bother the 
majority of people that does bother me is graphical CAPTCHAs.  Most people 
find them a nuisance; I find them a positive frustration.  Given that 
these too are almost completely pointless, I won't inflict them upon 
others.

Cheers,
Sabahattin

- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

Date: Sat, 12 Apr 2008 18:53:00 -0400
From: John C Klensin <[email-masked]>
To: John Levine <[email-masked]>, [email-masked]
Subject: Re: Do domains in SMTP have to exist ?
Sender: [email-masked]

--On Saturday, 12 April, 2008 16:23 +0000 John Levine
<[email-masked]> wrote:

> Hi.  I have a new niggly question.
> 
> Over in DKIM land there is a battle going on with respect to
> the treatment of domains that don't exist, with "don't exist"
> meaning something like an authoritative DNS server doesn't
> return an MX or A or AAAA or CNAME for the name.
> 
> Looking through the current draft, it looks to me like everyone
> assumes that domain names have to exist, with the explicit
> exception of the HELO/EHLO name, but it never says so in so
> many words.
> 
> Is this a deliberate omission, or is it so obvious that it
> wasn't worth stating explicitly?

John,

I think this goes to the core of the disagreement you summarized
in a recent note.    The spec definitely doesn't say "we expect
you to check those FQDNs to be sure that the return something.
Obviously, as you note, it doesn't prohibit that check either.  

There is also a question of just what "existing" means, i.e.,
how far one should pursue a validity test.   In particular if a
mail command (other than EHLO/HELO) includes an FQDN for
foo.example.com and there is a DNS record of 
    foo.example.com.  IN MX 5 bar.example.com.
and no other records for foo.example.com, does bar.example.com
have to exist and be associated with an address record in order
for us to believe that foo.example.com exists?

With the understanding that we disagree about parts of the
model, if I look at this in robustness principal terms, I
suppose one would have to say to anyone passing a domain name
across the interface that they really ought to be sure it is
valid but to a receiving entity that they should not get more
upset than necessary if it isn't.   And then Frank and I, and
probably you and I, could disagree about what is necessary.
    
And, of course, if one really wanted to require a domain name
that points to something that runs an SMTP server and wants to
receive mail, then one would almost certainly want to deprecate
address literals because they would no longer make any sense.

But one then ends up back at the issue that Ned raised some
weeks ago (at least if I understood his comment), which is that
we've got email senders and receivers that, by prior agreement
and for perfectly good reasons, ignore whatever MX records might
be present and reach each other directly by addresses (whether
they explicitly use the DNS to find those addresses or not).

Given that train of reasoning, I think you should assume that
the omission was deliberate, whether it actually was or not.

    john

Date: Sat, 12 Apr 2008 13:30:59 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Do domains in SMTP have to exist ?
Sender: [email-masked]

At 09:23 12-04-2008, John Levine wrote:
>Over in DKIM land there is a battle going on with respect to the
>treatment of domains that don't exist, with "don't exist" meaning
>something like an authoritative DNS server doesn't return an MX or A
>or AAAA or CNAME for the name.

I'm answering from a RFC 2821bis perspective.  Section 5.1 of 
draft-09 mentions how to locate the target host.  If the 
authoritative DNS server returns a NXDOMAIN, the message would be 
returned as undeliverable.

>Looking through the current draft, it looks to me like everyone
>assumes that domain names have to exist, with the explicit exception
>of the HELO/EHLO name, but it never says so in so many words.

The current draft focuses on how to find a path to deliver the 
message.  Even if the domain exists, it doesn't necessary imply that 
the message can be delivered, for example if we have an IPv4 client 
trying to reach an IPv6 only.  Section 5.2 mentions that.

>Is this a deliberate omission, or is it so obvious that it wasn't
>worth stating explicitly?

Section 2.3.5 discusses about domain names.  A domain name, used in 
RCPT TO:, which does not fit that description will result in delivery failure.

>PS: The domains in the DKIM discussion are 2822 domains, but the
>2822upd draft punts the interpretation of domain names over here.

If the domain part of the addr-spec is used to convey addressing 
information for SMTP, it has to conform to its specifications.

Regards,
-sm 

Date: Sat, 12 Apr 2008 11:33:32 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: Requiring PTR
Sender: [email-masked]

Hector Santos wrote:
> Many systems, and naively believed AOL too, I believe used services 
> like from MAPS RBL which lookup the zone owner to determine if this 
> was a home or business tier.

They do -- or rather, dynamic vs. static. If you're in the MAPS dynamic 
IP range, you won't even get a TCP connection; you'll be blocked at the 
firewall.

> Its stupid I think and x821 always allowed PTR checking as an option, 
> but it was so unreliable, it wasn't a real issue and hardly used in my 
> experience. 

AOL has been checking for a valid PTR for at least five years. It was 
their judgment that a lack of PTR record was a reliable indicator of a 
spam source. They also experimented with verifying that the PTR and the 
forward A record match, but that got way too many false positives.

FWIW, I ran a bunch of tests using our traps and a pretty good spam/ham 
corpus at Habeas, and reached the same conclusion.

<csg>

Date: 12 Apr 2008 16:23:13 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Do domains in SMTP have to exist ?
Sender: [email-masked]

Hi.  I have a new niggly question.

Over in DKIM land there is a battle going on with respect to the
treatment of domains that don't exist, with "don't exist" meaning
something like an authoritative DNS server doesn't return an MX or A
or AAAA or CNAME for the name.

Looking through the current draft, it looks to me like everyone
assumes that domain names have to exist, with the explicit exception
of the HELO/EHLO name, but it never says so in so many words.

Is this a deliberate omission, or is it so obvious that it wasn't
worth stating explicitly?

R's,
John

PS: The domains in the DKIM discussion are 2822 domains, but the
2822upd draft punts the interpretation of domain names over here.

Date: Sat, 12 Apr 2008 09:15:21 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Requiring PTR
Sender: [email-masked]

At 07:05 12-04-2008, Hector Santos wrote:
>It may also raise the question when the "World's largest ESP" and a 
>growing  amount of other ESPs/ISP mail receivers forcing this PTR 
>record, should be 'Highlighted' in 2821bis.

RFC 2821bis is not about what the "world's largest ESP" does.  It 
does not highlight current practice because such practices can change 
over time.

>I mean, there are some who believe the MX is required for security 
>reasons.  Well, why not PTR?

I gather that you mean abuse reasons instead of security reasons.

>Its stupid I think and x821 always allowed PTR checking as an 
>option, but it was so unreliable, it wasn't a real issue and hardly 
>used in my experience.

The RFC allows local policy.  It's up to the site to determine 
whether the policy is reliable or not.

>But I am at a point now where I'm no longer sure what make sense any 
>more or that it really matter any more.   What pisses me off is this 
>new growing behavior is pushing the support burden on smaller 
>vendors and people like myself and brother.

That's unfortunately how things are.  I could point out that a lot of 
people, including the author of this message, argued for proposals 
that can cause such a burden.

>I guess there is also some selfishness here because as with most 
>things, if it doesn't happen to you, if you don't feel it, most 
>people who careless about it.

Well said!

Regards,
-sm 

Date: Sat, 12 Apr 2008 10:05:52 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC:  [email-masked]
Subject: Requiring PTR
Sender: [email-masked]

Frank Ellermann wrote:
> Hector Santos wrote:
> 
>  [after exploring the wonders of "receiver policy"]
>> more interesting, is the mixed response codes for the DATA command:
>  
>>   C: DATA
>>   S: 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
>>   S: 421-:  (DNS:NR) http://postmaster.info.aol.com/errors/421dnsnr.html
>>   S: 421 SERVICE NOT AVAILABLE
> 
> Buggy, isn't it ?  
> 
> BTW, why does the sender policy of fbgcollection.com talk
> about ptr in various ways when that's not supposed to work ?
> 
>> While I was more concern with timeout issues, the issue
>> is the same - MIXED reply codes which was "semantically"
>> possible in 821
> 
> What we discussed was one reply with different codes, in
> the example 354-... 421-... 421, what you found here is an
> unsolicited reply 421 after 354.  No problem in 2821bis-09.

Sorry for my false alarm and confusion.

Right, I have no idea what went through my head while I was on GoDaddy 
hold, listening to Gigolo music, staring at this log when I decided to 
post this PTR issue and also throw in this mixed codes and not 
read/comprehend my writing BEFORE clicking "SEND".  I did only after I 
clicked SEND when I realized I was off base hence the followup correction.

Regarding PTR records,  although I knew there were ESPs and other mail 
receivers now enforcing it, I always felt it wasn't a big issue for 
business accounts.   Many systems, and naively believed AOL too, I 
believe used services like from MAPS RBL which lookup the zone owner to 
determine if this was a home or business tier.

So you didn't see much reports about this and even if it was, the admin 
of the system would get a PTR record one way or another.

But in the last two weeks or so, we had several reports.  One of them 
being my brother, I personally investigated for him.  I naturally told 
him he needs to contact his ISP (AT&T) for his IP address. But possibly, 
his delay in accepting that answer, probably because he didn't know why 
A) it had to be done now and never before, and B) it couldn't be 
resolved at GoDaddy where he was managing his DNS setup, got me to waste 
time to talk to GoDaddy completely forgetting they were not capable of 
doing this.   John K reminded me the ISP is responsible.

This does raise the question if AOL, who had this policy for a long 
time, recently lower the cost of operation by discontinuing using the 
fee based MAPS RBL service and now applied the PTR rule across the board 
with a general PTR lookup regardless of the IP type.  This sounds to me 
what has happen because as Vince said, this wasn't an issue before or it 
wasn't one that was realized until this week.

It may also raise the question when the "World's largest ESP" and a 
growing  amount of other ESPs/ISP mail receivers forcing this PTR 
record, should be 'Highlighted' in 2821bis.

I mean, there are some who believe the MX is required for security 
reasons.  Well, why not PTR?

Its stupid I think and x821 always allowed PTR checking as an option, 
but it was so unreliable, it wasn't a real issue and hardly used in my 
experience.

But I am at a point now where I'm no longer sure what make sense any 
more or that it really matter any more.   What pisses me off is this new 
growing behavior is pushing the support burden on smaller vendors and 
people like myself and brother.

I guess there is also some selfishness here because as with most things, 
if it doesn't happen to you, if you don't feel it, most people who 
careless about it.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Mixed Return Codes
Date:  Fri, 11 Apr 2008 23:37:12 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 25
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hector Santos wrote:

 [after exploring the wonders of "receiver policy"]
> more interesting, is the mixed response codes for the DATA command:
 
>   C: DATA
>   S: 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
>   S: 421-:  (DNS:NR) http://postmaster.info.aol.com/errors/421dnsnr.html
>   S: 421 SERVICE NOT AVAILABLE

Buggy, isn't it ?  

BTW, why does the sender policy of fbgcollection.com talk
about ptr in various ways when that's not supposed to work ?

> While I was more concern with timeout issues, the issue
> is the same - MIXED reply codes which was "semantically"
> possible in 821

What we discussed was one reply with different codes, in
the example 354-... 421-... 421, what you found here is an
unsolicited reply 421 after 354.  No problem in 2821bis-09.

 Frank

Content-class: urn:content-classes:message
Subject: RE: Mixed Return Codes
Date: Fri, 11 Apr 2008 15:42:55 -0400
From: "MH Michael Hammer (5304)" <[email-masked]>
To: "Hector Santos" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hector,

This is not something new. I can't tell you when they started showing
this banner/implementing requiring PTRs but it has been a very long
time.

Mike

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Hector Santos
> Sent: Friday, April 11, 2008 3:33 PM
> To: [email-masked]
> Subject: Mixed Return Codes
> 
> 
> Not for nothing, but I did bring this up and was shot down.   Now we
> have the "World's Large Email ISP" AOL exactly what I said will begin
to
> happen:
> 
> S: 220-rly-ma02.mx.aol.com ESMTP mail_relay_in-ma02.3; Fri,
>         11 Apr 2008 -0400
> S: 220-America Online (AOL) and its affiliated companies do not
> S: 220-     authorize the use of its proprietary computers and
computer
> S: 220-     networks to accept, transmit, or distribute unsolicited
bulk
> S: 220-     e-mail sent from the internet.  Effective immediately:
AOL
> S: 220-     may no longer accept connections from IP addresses which
> S: 220      have no reverse-DNS (PTR record) assigned.
> C: EHLO fbgcollection.com
> S: 250-rly-ma02.mx.aol.com peer name unknown
> S: 250 HELP
> C: MAIL FROM:<[email-masked]>
> S: 250 OK
> C: RCPT TO:<[email-masked]>
> S: 250 OK
> C: DATA
> S: 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
> S: 421-:  (DNS:NR)
http://postmaster.info.aol.com/errors/421dnsnr.html
> S: 421 SERVICE NOT AVAILABLE
> C: QUIT
> S: 221 SERVICE CLOSING CHANNEL
> 
> The issue started with my brother reporting he was having outbound
mail
> issues with AOL and COMCAST.NET and wanted me to check it out.
> 
> As you can see, they are requiring a PTR record. Brother Vince has
> domain DNS setup at Godaddy and after 1 hour of talking with them they
> have no way to setup a PTR record - obviously they don't know what
they
> are talking about.  This is a business account with static IPs and I
see
> this PTR crap is that - crap.
> 
> But more interesting, is the mixed response codes for the DATA
command:
> 
>   C: DATA
>   S: 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
>   S: 421-:  (DNS:NR)
http://postmaster.info.aol.com/errors/421dnsnr.html
>   S: 421 SERVICE NOT AVAILABLE
> 
> Lisa, now do you see this as been BIG enough and not just isolated to
> just "small vendors?"
> 
> Or is a AOL person lurking here with the powers to fix the above, do
so?
> 
> Of course, it may be too late to address this, but this was all
> predicted as more and more DATA level processing is happening. While I
> was more concern with timeout issues, the issue is the same - MIXED
> reply codes which was "semantically" possible in 821 but now
> specifically made clear in 2821bis as a NO-NO.
> 
> --
> Sincerely
> 
> Hector Santos, CTO
> http://www.santronics.com
> http://santronics.blogspot.com

Date: Fri, 11 Apr 2008 15:40:04 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: Re: Mixed Return Codes - CORECTION
Sender: [email-masked]

NEVER MIND - There is no mixed reply codes here. AOL was correct with 
its DATA response.  I was exhausted with getting godaddy to address this 
PTR issue and wasn't thinking straight.  My apology for false alarm. 
I'm taking a long break this weekend.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Hector Santos wrote:
> Not for nothing, but I did bring this up and was shot down.   Now we 
> have the "World's Large Email ISP" AOL exactly what I said will begin to 
> happen:
> 
> S: 220-rly-ma02.mx.aol.com ESMTP mail_relay_in-ma02.3; Fri,
>        11 Apr 2008 -0400
> S: 220-America Online (AOL) and its affiliated companies do not
> S: 220-     authorize the use of its proprietary computers and computer
> S: 220-     networks to accept, transmit, or distribute unsolicited bulk
> S: 220-     e-mail sent from the internet.  Effective immediately:  AOL
> S: 220-     may no longer accept connections from IP addresses which
> S: 220      have no reverse-DNS (PTR record) assigned.
> C: EHLO fbgcollection.com
> S: 250-rly-ma02.mx.aol.com peer name unknown
> S: 250 HELP
> C: MAIL FROM:<[email-masked]>
> S: 250 OK
> C: RCPT TO:<[email-masked]>
> S: 250 OK
> C: DATA
> S: 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
> S: 421-:  (DNS:NR)  http://postmaster.info.aol.com/errors/421dnsnr.html
> S: 421 SERVICE NOT AVAILABLE
> C: QUIT
> S: 221 SERVICE CLOSING CHANNEL
> 
> The issue started with my brother reporting he was having outbound mail 
> issues with AOL and COMCAST.NET and wanted me to check it out.
> 
> As you can see, they are requiring a PTR record. Brother Vince has 
> domain DNS setup at Godaddy and after 1 hour of talking with them they 
> have no way to setup a PTR record - obviously they don't know what they 
> are talking about.  This is a business account with static IPs and I see 
> this PTR crap is that - crap.
> 
> But more interesting, is the mixed response codes for the DATA command:
> 
>  C: DATA
>  S: 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
>  S: 421-:  (DNS:NR) http://postmaster.info.aol.com/errors/421dnsnr.html
>  S: 421 SERVICE NOT AVAILABLE
> 
> Lisa, now do you see this as been BIG enough and not just isolated to 
> just "small vendors?"
> 
> Or is a AOL person lurking here with the powers to fix the above, do so?
> 
> Of course, it may be too late to address this, but this was all 
> predicted as more and more DATA level processing is happening. While I 
> was more concern with timeout issues, the issue is the same - MIXED 
> reply codes which was "semantically" possible in 821 but now 
> specifically made clear in 2821bis as a NO-NO.
> 

Date: Fri, 11 Apr 2008 15:32:50 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: Mixed Return Codes
Sender: [email-masked]

Not for nothing, but I did bring this up and was shot down.   Now we 
have the "World's Large Email ISP" AOL exactly what I said will begin to 
happen:

S: 220-rly-ma02.mx.aol.com ESMTP mail_relay_in-ma02.3; Fri,
        11 Apr 2008 -0400
S: 220-America Online (AOL) and its affiliated companies do not
S: 220-     authorize the use of its proprietary computers and computer
S: 220-     networks to accept, transmit, or distribute unsolicited bulk
S: 220-     e-mail sent from the internet.  Effective immediately:  AOL
S: 220-     may no longer accept connections from IP addresses which
S: 220      have no reverse-DNS (PTR record) assigned.
C: EHLO fbgcollection.com
S: 250-rly-ma02.mx.aol.com peer name unknown
S: 250 HELP
C: MAIL FROM:<[email-masked]>
S: 250 OK
C: RCPT TO:<[email-masked]>
S: 250 OK
C: DATA
S: 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
S: 421-:  (DNS:NR)  http://postmaster.info.aol.com/errors/421dnsnr.html
S: 421 SERVICE NOT AVAILABLE
C: QUIT
S: 221 SERVICE CLOSING CHANNEL

The issue started with my brother reporting he was having outbound mail 
issues with AOL and COMCAST.NET and wanted me to check it out.

As you can see, they are requiring a PTR record. Brother Vince has 
domain DNS setup at Godaddy and after 1 hour of talking with them they 
have no way to setup a PTR record - obviously they don't know what they 
are talking about.  This is a business account with static IPs and I see 
this PTR crap is that - crap.

But more interesting, is the mixed response codes for the DATA command:

  C: DATA
  S: 354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
  S: 421-:  (DNS:NR) http://postmaster.info.aol.com/errors/421dnsnr.html
  S: 421 SERVICE NOT AVAILABLE

Lisa, now do you see this as been BIG enough and not just isolated to 
just "small vendors?"

Or is a AOL person lurking here with the powers to fix the above, do so?

Of course, it may be too late to address this, but this was all 
predicted as more and more DATA level processing is happening. While I 
was more concern with timeout issues, the issue is the same - MIXED 
reply codes which was "semantically" possible in 821 but now 
specifically made clear in 2821bis as a NO-NO.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 11 Apr 2008 11:49:09 -0400
From: John Leslie <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Subject: SMTP Service Advertisement
Sender: [email-masked]

John C Klensin <[email-masked]> wrote:
> 
> We have tried variations on "look over here (e.g., in the DNS)
> to see, definitively, if something is available over there
> (e.g., some service)" several times, with similar results.
> Those results closely parallel discoveries in [other] areas of
> computer science (see e.g., Ed Codd's original paper on
> relational database models). If one has two different, but
> intimately related, pieces of information that are stored in
> different places and often maintained by different people in
> different roles, things _will_ get out of synch and to bad
> effect.  Often it doesn't even require different people -- it is
> just too hard to keep track when things need to be updated in
> different types of systems.

   ++observation

> Like it or not, there is a big difference between using the DNS
> to advertise the availability or location of a service and
> believing that the absence of information in the DNS is a
> definitive indication that the service doesn't exist at that
> node.

   This is such a good statement of the issue that I can't resist
responding to it.

   I don't recall ever seeing a consensus on which of these we
_want_ email to be.

   Clearly, when we write email to <somebody@[123.45.678.9] we
intend it to go to that "machine" _if_ it supports SMTP. (If
whatever server answers on port 25 of that interface doesn't
know what to make of such an address, it is at least _the_
best authority on what to do with it.)

   IMHO, when we write email to <[email-masked]> we want it to
go to an appropriate server for the _domain_ IBM.com. If there
happens to be an A)ddress record for IBM.com, that really isn't
where we want it to go; and we trust IBM.com to do the right
magic in DNS to ensure it instead goes to an "official" SMTP
server.

   That, IMHO, is the perfect example of what John K is saying:
that this sort of DNS magic _will_ get out of sync. Thus, IMHO,
we are ill-advised to design an email system which depends upon
it staying in sync.

   It is easily demonstrated that many cases exist where an
A)ddress RR gets out of sync, and points to some "machine" which
has no clue what to do with email addressed to that domain --
_whether_or_not_ it happens to listen on port 25. Whatever error
it may _or_may_not_ return is unlikely to be helpful to someone
trying to send email to that domain.

   Thus, IMHO, we SHOULD clearly state that <[email-masked]>
means the email is intended for the _domain_ example.com; and
that if the DNS gets out of sync with the routing, the _DNS_ is
authoritative, not the routing.

   (That still leaves us an opportunity to argue whether the
absence of an MX record indicates the absence of an official
email service, BTW...)

> It will be that way until and unless we redesign the network
> architecture to treat the DNS as part of TCP or IP such that,
> e.g., the act of turning on a listener for a particular service
> is the act that creates corresponding records in the DNS.

   John K is baying at the wrong moon, IMHO. Turning on a process
listening on port 25 is quite a different matter than deciding
that you want email coming to a domain.

   Neither can I imagine any case in which it would make sense
to automatically advertise an MX RR when a port 25 service is
detected. (I can barely imagine any _way_ to do this!)

> That is the message in the failure of WKS as a definitive
> service-availability indicator and what I was trying to point
> you to when I pointed you to 1123.

   (I include this only to avoid a charge that I quoted John K
out of context: it's quite unrelated to any point I intended
to make.)

--
John Leslie <[email-masked]>

Date: Fri, 11 Apr 2008 08:44:40 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: What is the history of 2821 and implict MX?
Sender: [email-masked]

--On Friday, 11 April, 2008 00:47 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

> 
> At 19:12 -0400 on 04/09/2008, John C Klensin wrote about Re:
> What is the history of 2821 and implict MX?:
> 
>> --On Wednesday, 09 April, 2008 17:21 -0400 "Robert A.
>> Rosenberg" <[email-masked]> wrote:
>> 
>>> 
>>>  At 14:29 -0500 on 04/08/2008, Pete Resnick wrote about Re:
>>>  What is the history of 2821 and implict MX?:
>>> 
>>>>  The MX rule of 974 is perfectly reasonable to apply to IPv4
>>>>  and IPv6.
>>> 
>>> 
>>>  RFC 974 also requires the use of a WKS record to verify that
>>>  the IPN address has a MTA running on it.
>> 
>> Please read RFC 1123 (section numbers mentioned in an earlier
>> note).  Use of WKS was explicitly deprecated; the MX rule was
>> not changed.
>> 
>>     john
> 
> I am aware of RFC 1123 and you are quoting me (and referencing
> RFC 1123) out of context since that statement was immediately
> followed by "Since we do not use WKS records for this purpose
> ..." thus indicating (but not explicitly mentioning RFC 1123
> as the reason) I was aware of the WKS deprecation (although it
> might have been better to have said "no longer" not "do not").

Robert,

I think you misunderstood the comment I was trying to make.
That was probably my fault for not being more explicit, for
which I apologize.   I was responding more to "...for this
purpose" than the specifics of using WKS or not.   

More specifically...

We have tried variations on "look over here (e.g., in the DNS)
to see, definitively, if something is available over there
(e.g., some service)" several times, with similar results.
Those results closely parallel discoveries in [other] areas of
computer science (see e.g., Ed Codd's original paper on
relational database models). If one has two different, but
intimately related, pieces of information that are stored in
different places and often maintained by different people in
different roles, things _will_ get out of synch and to bad
effect.  Often it doesn't even require different people -- it is
just too hard to keep track when things need to be updated in
different types of systems.

One may need to read a bit between the lines of 1123, but the
comments surrounding the deprecation of WKS should be
interpreted at least as much as "didn't work this time either,
let's not try it again" as "well, that didn't work, better luck
next time". 

Like it or not, there is a big difference between using the DNS
to advertise the availability or location of a service and
believing that the absence of information in the DNS is a
definitive indication that the service doesn't exist at that
node.  It will be that way until and unless we redesign the
network architecture to treat the DNS as part of TCP or IP such
that, e.g., the act of turning on a listener for a particular
service is the act that creates corresponding records in the
DNS.     That is the message in the failure of WKS as a
definitive service-availability indicator and what I was trying
to point you to when I pointed you to 1123.

       john

Date: Fri, 11 Apr 2008 00:47:17 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: What is the history of 2821 and implict MX?
Sender: [email-masked]

At 19:12 -0400 on 04/09/2008, John C Klensin wrote about Re: What is 
the history of 2821 and implict MX?:

>--On Wednesday, 09 April, 2008 17:21 -0400 "Robert A. Rosenberg"
><[email-masked]> wrote:
>
>>
>>  At 14:29 -0500 on 04/08/2008, Pete Resnick wrote about Re:
>>  What is the history of 2821 and implict MX?:
>>
>>>  The MX rule of 974 is perfectly reasonable to apply to IPv4
>>>  and IPv6.
>>
>>
>>  RFC 974 also requires the use of a WKS record to verify that
>>  the IPN address has a MTA running on it.
>
>Please read RFC 1123 (section numbers mentioned in an earlier
>note).  Use of WKS was explicitly deprecated; the MX rule was
>not changed.
>
>     john

I am aware of RFC 1123 and you are quoting me (and referencing RFC 
1123) out of context since that statement was immediately followed by 
"Since we do not use WKS records for this purpose ..." thus 
indicating (but not explicitly mentioning RFC 1123 as the reason) I 
was aware of the WKS deprecation (although it might have been better 
to have said "no longer" not "do not").

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: What is the history of 2821 and implict MX?
Date:  Thu, 10 Apr 2008 03:32:00 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 10
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote:
 
> Use of WKS was explicitly deprecated

There is a trend in RFC 1123 wrt SMTP, oversimplification.

"Simply try to use a service to see if it's there" is not
so simple when that can take about 100 hours in 2821bis.

 Frank

Date: Wed, 09 Apr 2008 19:12:31 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: What is the history of 2821 and implict MX?
Sender: [email-masked]

--On Wednesday, 09 April, 2008 17:21 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

> 
> At 14:29 -0500 on 04/08/2008, Pete Resnick wrote about Re:
> What is the history of 2821 and implict MX?:
> 
>> The MX rule of 974 is perfectly reasonable to apply to IPv4
>> and IPv6.
> 
> 
> RFC 974 also requires the use of a WKS record to verify that
> the IPN address has a MTA running on it.

Please read RFC 1123 (section numbers mentioned in an earlier
note).  Use of WKS was explicitly deprecated; the MX rule was
not changed.

    john

Date: Wed, 09 Apr 2008 18:22:31 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Douglas Otis <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Douglas Otis wrote:

>> Of course, that is not practical.
> 
> What is not practical?  

Probably wrong term.  As a mandate, dynamic SMTP level MX security 
checking may not be a scalable feasible option for many organizations.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Wed, 9 Apr 2008 17:21:55 -0400
To: <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: What is the history of 2821 and implict MX?
Sender: [email-masked]

At 14:29 -0500 on 04/08/2008, Pete Resnick wrote about Re: What is 
the history of 2821 and implict MX?:

>The MX rule of 974 is perfectly reasonable to apply to IPv4 and IPv6.

RFC 974 also requires the use of a WKS record to verify that the IPN 
address has a MTA running on it. Since we do not use WKS records for 
this purpose, I'd suggest that for IPv4 only MTAs (handling a FQDN) 
the RFC 974 rule of the MX being optional be observed BUT once FQDN 
maps to an AAAA record (or both AAAA and A) that the MX be required 
in the case where all the IPNs that are mapped to FQDN are NOT 
running a MTA so that the RHS can supply a FQDN1 other than FQDN 
(IOW: Use the list of RHS FQDNs to supply the function that WKS would 
have supplied). Thus the MX is still optional if all IPNs mapped to 
the FQDN are running a MTA.

IMO: The implicit MX (ie: Generating a FQDN MX 0 FQDN) per RFC 974 is 
ONLY valid if every host that is mapped via the FQDN IN is a MTA. So 
long ANY are not running a MTA then the lack of a MX that points ONLY 
at MTAs is a definition problem (since non-MTA running IPNs in the 
FQDN IN list can be erroneously contacted to try to pass them relayed 
email).

Note that this is a change in my prior "MUST have MX for AAAA 
records" stance. I now would like to see EITHER a MUST have an MX if 
there is a IPv6 Server requirement OR an EXPLICIT statement that the 
MX is optional only when all IPNs are running a MTA.

To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 08 Apr 2008 22:37:07 -0700
Sender: [email-masked]

Hector Santos <[email-masked]> writes:

> It appears to me that Microsoft wishes virtualize IPv6 (and IPv4) from
> an application viewpoint. i.e, separate the communication layer.

Up-front disclaimer: I am purely and exclusively a UNIX developer and
wouldn't know what to do with a Windows system without a fair bit of
study.  The last time I used Windows for long enough to understand what it
was doing was Windows 3.1.  So I can only really answer from the
perspective of how the APIs are implemented on UNIX or Linux and what's in
RFC 3493.

> When its all said and done, an SMTP client would never need to know
> about MX, A or AAAA records or any other record current or future for
> that matter.
>
> If you want to send mail or even just check for SMTP hosting, all you need
> is two variables possible three, and the getaddrinfo() function call.
>
>    - host name
>    - service port
>    - flags for IPv4 only, IPv6 or both (passive mode).

Passive mode is used by servers that want to listen to an interfaces, and
it's orthogonal to IPv4 or IPv6.  You can have any combination of
AI_PASSIVE and family hints; one doesn't imply the other.

> If done correctly, ideally the SMTP client will never need to worry
> explicit MX or implicit MX records.
>
> Am I on track?

Well, at least with the getaddrinfo implementation on UNIX, this doesn't
work for SMTP because getaddrinfo doesn't handle service-specific DNS
resolution.  I suppose in theory it *could* given that you tell it what
service you want to use, but that's just not how the code works or how the
APIs are specified (and hence probably isn't how the code can ever work in
the absence of a new hint flag).  The service (either specified as a
number or as a symbolic name) only does service resolution and fills in
the port element of the structure.  It doesn't do SRV or MX lookups or
anything of the type.

So, to connect to the mail server for a given address, the IPv6-enabled
client still has to follow the same logic as an existing IPv4-only client,
namely try to resolve the MX record, use the hostname in the
lowest-priority (bleh) MX record if one is found (and possibly iterate if
the first one fails), and fall back to trying to connect directly to the
RHS if that fails.  The MX lookup isn't done for you in getaddrinfo.

> If so, my next question has to do with what are the requirements to make
> it work.
>
> More specifically, right now our smtp code is using level 1 socket
> commands.  We have our own DNS resolver.
>
> Would a first step be to port over to level 2, and removing or rather
> replace our GetDNSRecord() function with getaddrinfo() but use a IPv4
> only flag?

getaddrinfo, at least in the UNIX world, is a replacement for
gethostbyname and doesn't do anything more fancy DNS-wise than
gethostbyname does other than support AAAA records.  It still doesn't do
an MX lookup and you still have to do that separately, usually using a
more sophisticated DNS API that allows you to look for arbitrary record
types.

> Or should I go ahead and make it passive, and we will still not have
> problems if the customer has an OS with no IPv6 stacks installed?

AI_PASSIVE is only for servers and is unrelated to this problem.

I think the flag that you're looking for is AI_ADDRCONFIG, which tells
getaddrinfo to not return addresses using protocols for which there is no
configured local interface.  (So if you don't have an IPv4 interface, you
won't get IPv4 addresses, and if you don't have an IPv6 interface, you
won't get IPv6 addresses.)

> PS: if you prefer to go offlist, I wouldn't mind that. :-)

We probably should for further discussion, as I think we're moving farther
afield from the purpose of the list.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Wed, 09 Apr 2008 00:35:30 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Russ Allbery <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Russ Allbery wrote:

> I think you're missing the point.  In order to implement your proposal, I
> have to insert IPv6 knowledge into code that otherwise does not need any
> to work on both IPv4 and IPv6 systems.  If I don't have to care about IPv6
> when it comes to processing the presence or absence of MX records, SMTP
> clients honoring MX records can be written to be agnostic about the
> networking stack that they're using.  Indeed, they can be written and
> tested by people with only IPv4 access and work on IPv6 without
> modification, since all the portabliity work is done by the system
> library.
> 
> This is exactly the sort of abstraction and generalization accomplished
> via a good layering design, and layering violations are bad precisely
> because they don't allow this sort of clean separation of duties.  A lot
> of work went into designing IPv6-friendly APIs so that clients using the
> modern networking API and some additional bits of glue such as
> sockaddr_storage can use the same code with both IPv4 and IPv6 without
> ugly #ifdef hacks or following different code paths based on the protocol.
> Let's not undo that.

Russ, you seem to have a good handle of IPv6 with practical experience 
and using the various RFCs specifically 3484.

I'm catching up now with the various RFCd and I would like get a 
confirmation of what I am seeing as far the the intention and/or 
methodology.

It appears to me that Microsoft wishes virtualize IPv6 (and IPv4) from 
an application viewpoint. i.e, separate the communication layer.

When its all said and done, an SMTP client would never need to know 
about MX, A or AAAA records or any other record current or future for 
that matter.

If you want to send mail or even just check for SMTP hosting, all you 
need is two variables possible three, and the getaddrinfo() function call.

    - host name
    - service port
    - flags for IPv4 only, IPv6 or both (passive mode).

If done correctly, ideally the SMTP client will never need to worry 
explicit MX or implicit MX records.

Am I on track?

If so, my next question has to do with what are the requirements to make 
it work.

More specifically, right now our smtp code is using level 1 socket 
commands.  We have our own DNS resolver.

Would a first step be to port over to level 2, and removing or rather 
replace our GetDNSRecord() function with getaddrinfo() but use a IPv4 
only flag?

The goal would be to get the code switch over but still make it work for 
customers under IPv4 with no lost or extra IPv6 stack requirements.

Or should I go ahead and make it passive, and we will still not have 
problems if the customer has an OS with no IPv6 stacks installed?

 From some of my readings, this could be problematic when there is no 
IPv6 stacks.

Thanks

PS: if you prefer to go offlist, I wouldn't mind that. :-)

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Tue, 8 Apr 2008 14:29:30 -0500
To: Hector Santos <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: What is the history of 2821 and implict MX?
Cc: [email-masked], John C Klensin <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>, Dave Crocker <[email-masked]>
Sender: [email-masked]

On 4/7/08 at 6:54 PM -0400, Hector Santos wrote:

>So by virtue of the fact that 974 was not specific, in hindsight you 
>are suggesting it left it open-ended for any future record type 
>associated with the domain?

Yes, though not on purpose. I'm actually coming at this from the 
opposite end of things than I believe you are:

>When was 974 written? 1986?
>When was IPv6 invented?  1991?
>When was AAAA invented? 1995?

And let's remember to add that 2821 was added in 2001.

Lots of things had to change when IPv6 was introduced. A new AAAA 
record was needed to represent addresses in the DNS; a new EPRT 
command was needed in FTP. But there were lots of things that didn't 
change. We didn't need a new UDP header. We didn't need a new MAIL 
FROM command in SMTP. We didn't need new Telnet options negotiation. 
And what I'm claiming is that (prior to 2001), we didn't need a new 
MX record handling algorithm, as per the one in 974. The one in 974 
was perfectly applicable to IPv6: If you get back an empty MX list, 
you make the 0 preference one as described and look up the address. 
Yes, that address lookup is different than it was in IPv4, but (as 
the examples above show) that doesn't mean that anything else in the 
protocol needs to change. And in fact, a well-designed protocol 
shouldn't change at every layer just because a single layer has 
changed.

The MX rule of 974 is perfectly reasonable to apply to IPv4 and IPv6. 
I think that's what we should have 2821bis do.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Cc: SMTP Interest Group <[email-masked]>
From: Douglas Otis <[email-masked]>
To: Hector Santos <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Date: Tue, 8 Apr 2008 14:13:54 -0700
Sender: [email-masked]

On Apr 8, 2008, at 9:37 AM, Hector Santos wrote:
> Douglas Otis wrote:
>> Standardizing on AAAA fallback when MX resource record do not exist  
>> will require those using IPv6-only hostnames to publish bogus MX  
>> resource records as a means to avoid undesired traffic SMTP now  
>> generates. Standardization on AAAA fallback is likely to attract  
>> this undesired traffic and further abuse of SMTP.  The undesired  
>> traffic can be substantial, depending upon the nature of the  
>> spoofed email, where creating bogus MX resource records in response  
>> should not be seen as beneficial.  This effort will increase the  
>> DNS zone sizes.  Instances of IPv6 only SMTP lacking MX records and  
>> receiving public SMTP traffic is sure to represent a small minority  
>> of the number of hostnames in IPv6 address space.
>
> Given a MX mandate for security purposes, I have the following  
> questions:
>
> (1) WHERE is the MX mandate best apply?

Use of MX records would not change.  MX or A records would be used  
whenever an outbound SMTP client is attempting to discover the public  
SMTP server for a specific domain.  By purposely prohibiting MX fall- 
back to AAAA records, hostnames only having IPv6 addresses will not  
automatically assumed to be a possible SMTP server.  The assumption of  
AAAA records representing possible inbound SMTP servers for the domain  
represented by the hostname enables source domain exploits already  
common for IPv4.

Outbound SMTP clients discovering SMTP servers for an email address  
should quit when MX or A resource records are not published for the  
email address domain.  Inbound SMTP servers might rely upon the  
necessity of MX or A resource records to confirm validity of MailFrom  
email addresses, hopefully before message data has been accepted.   
Prohibition of AAAA MX fall-back would inhibit undesired traffic  
created by bad-actors spoofing source domains by exploiting existing  
hostname records.

To ensure uniform configurations between IPv4 and IPv6 clients, A  
record fall-back should also be deprecated, but this would need to be  
done in a separate draft.  RFC 2821bis would be would be making an  
unsafe architectural choice by standardizing AAAA fall-back when MX  
resource records are not found.  A luxury of not needing MX records is  
becoming expensive due to rampant SMTP abuse.

Hostnames seen on the Internet within IPv4 address space often  
represent substantial systems, although a small number of these hosts  
act as inbound SMTP servers.  IPv6 is likely to expose a wider range  
of devices to the Internet with an even smaller percentage acting as  
inbound SMTP servers.  In addition, many of these servers may be  
embedded with less resources compared to systems currently found  
within IPv4 address space.  Abuse currently endemic for A resource  
records may prove devastating for embedded servers directly connected  
to the Internet as promised by IPv6.

> 2) WHEN is the MX best utilized?
>
> (A) Before the PAYLOAD is transmitted?
> (B) After the PAYLOAD is transmitted but not accepted yet. (DATA)
> (C) After the PAYLOAD is accepted with a 250 response
> (D) Only when NECESSARY
>
> Of course, if your answer to 1.A, then it best utilized at 2.A.
>
> But I am afraid you and others are going to have a vastly different  
> views about where MX is used and when it is applied. Regardless of  
> WHERE, most will have no real choice when it can be applied. For  
> many, 2.C is their only option.  In fact, I think we might find many  
> here say 2.D is the really the only choice since MX is only  
> important come response time.
>
> What this means is that MANY of the concerns regarding IMPLICIT MX  
> and bounce attacks can be resolved or drastically minimized by  
> mandating a 2.A or 2.B SMTP level design.

This approach would help address the general concern of source domain  
spoofing.  This would also minimize the number of domain nodes that  
might need to publish SMTP related policy as well.

> Of course, that is not practical.

What is not practical?  Checking the reverse DNS zone is becoming less  
and less practical.  IPv6 seems sure to defeat this strategy.

Acceptance of a draft that details steps for a transition to MX only  
SMTP discovery would help bring about a smoother introduction of  
IPv6.  Changes will need to be adopted as a means to minimize  
disruptions an MX only discovery paradigm change might cause.  Some  
may adopt rote publishing of MX and address records.  Others may not  
default MailFroms to the local-host domain.

-Doug

Date: Tue, 08 Apr 2008 13:34:11 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: IPV6: Where are we? (SMTP)
Sender: [email-masked]

--On Monday, 07 April, 2008 22:51 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

> 
> At 23:51 +0200 on 04/07/2008, Frank Ellermann wrote about Re:
> IPV6: Where are we? (SMTP):
> 
>> Hector argues that it's the job of IPv6 domains to be
>> reachable, for that they must either also offer A, or use an
>> explicit MX with an IPv4 SMTP at a third party in addition to
>> their AAAA. Assuming that 2821bis will be as long a standard
>> as STD 10 (about 30 years) adding this pragmatical idea could
>> backfire when IPv4 is remote history.
> 
> You are assuming that IPv6 domains will not initially be Dual
> Stack. So long as they are dual stack (or have someone who is
> dual stack act as a secondary MX to forward to the IPv6-Only
> MTA) it will work.  You start with:
> 
> FQDN MX 10 IPv4
>       MX 20 IPv6
> 
> with both the IPv4 and IPv6 MTAs being able to save to the
> IMAP/POP mailboxes or both set to hand off to an internal MTA
> for final delivery.
> 
> As IPv6 becomes more widespread make the IPv4 MX a 30 not a 10
> and the IPv6 will become the preferred MTA.
> 
> Eventually you can remove the IPv4 (if there is a flag-day for
> depreciation of IPv4) or keep running the IPv4 or farm it out
> to a dual stack who will hand off to the IPv6 (as above).

This is certainly a model.  However, if I'm a potential SMTP
receiver, I'm dual-stack, I have exactly one MTA serving both
protocols, and my IPv4 and IPv6 connectivity is equally good, I
may not have a preference.  Instead, I'd prefer that the sender
figure out the best path to me using whatever mechanisms it uses
to deal with multihomed hosts, find routes, etc.  For that case,
using your notation, I want

   FQDN MX 10 IPv4-IPv6
   IPv4-IPv6 A address...
             AAAA address....

> Once you use a IPv4/IPv6 MX, the only use of the A will be by
> a antiquated resolver/MTA that does not understand MX or has
> its MX support turned off for some reason. All others will
> locate and talk to the IPv4 MTA via the MX.

Now, I think most of your argument still applies for the above
case, except, under either the language of 2821bis or the
language of 974, the MX record is optional and does not change
anything.

    john

Date: Tue, 08 Apr 2008 12:37:35 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Douglas Otis <[email-masked]>
CC:  [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Douglas Otis wrote:
> 
> Standardizing on AAAA fallback when MX resource record do not exist will 
> require those using IPv6-only hostnames to publish bogus MX resource 
> records as a means to avoid undesired traffic SMTP now generates. 
> Standardization on AAAA fallback is likely to attract this undesired 
> traffic and further abuse of SMTP.  The undesired traffic can be 
> substantial, depending upon the nature of the spoofed email, where 
> creating bogus MX resource records in response should not be seen as 
> beneficial.  This effort will increase the DNS zone sizes.  Instances of 
> IPv6 only SMTP lacking MX records and receiving public SMTP traffic is 
> sure to represent a small minority of the number of hostnames in IPv6 
> address space.

Hi Doug,

Question.

Given a MX mandate for security purposes, I have the following questions:

(1) WHERE is the MX mandate best apply?

  (A) 2821 Return Path
  (B) 2822 Reply-To:
  (C) 2822 From:
  (D) 2822 Sender:
  (E) Other

2) WHEN is the MX best utilized?

  (A) Before the PAYLOAD is transmitted?
  (B) After the PAYLOAD is transmitted but not accepted yet. (DATA)
  (C) After the PAYLOAD is accepted with a 250 response
  (D) Only when NECESSARY

Of course, if your answer to 1.A, then it best utilized at 2.A.

But I am afraid you and others are going to have a vastly different 
views about where MX is used and when it is applied. Regardless of 
WHERE, most will have no real choice when it can be applied. For many, 
2.C is their only option.  In fact, I think we might find many here say 
2.D is the really the only choice since MX is only important come 
response time.

What this means is that MANY of the concerns regarding IMPLICIT MX and 
bounce attacks can be resolved or drastically minimized by mandating a 
2.A or 2.B SMTP level design.

Of course, that is not practical.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Tue, 08 Apr 2008 10:54:59 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Michael Storz <[email-masked]>
CC: "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

Michael,

This is my 2 pennies:

I agree overall with your passion and experience. As a commercial vendor 
since the 80s in multiple mail networks, even some that predated SMTP, 
my customers are wide in needs. When it comes to a particular "issue" 
whether its a feature, built-in and/or optional, some will want us to 
solve it for them, others will prefer to deal with it themselves. When 
there is no major majority, you make it optional.

There are many view points, valid as well. I will say that there is no 
real justice in trying to express all of the issues, all the view points 
in such a short period, leaving it to a SWAG - scientific wide-ass guess.

As I said, there is no way to cover all the issues. It really does need 
to be further researched, documented and consolidated for peer review.

To me, there is a more general philosophical question to get out of the 
way because it has a direct and indirect relationship to everything we 
have been doing, including IPv6 ideas:

   In a chaotic world of connectivity, what is the society impact
   to have a low level full duplex, two way communications between
   end points?

   Asked another way, are we going to allow unauthorized
   anonymous senders to continue to prosper?  Does the
   sender require some form of "registration" or contact
   address?

I don't know if you realize this there is a long time strategies to 
connect every peer and server.  Many such have Apple, Google, Yahoo, 
Microsoft with its "Live" strategy are real long term goals where IPv6 
will play a major role in creating.  Even Apollo and Adobe want a piece 
of the connectivity action.

Up to this point, the SMTP system has relied on the basic principle that 
local mail does not require authorization. Only relays.

In the words of Monk, this has been both a blessing and a curse.

A blessing in that it allowed for the spread of connectivity and 
communications.  Without it, I sincerely doubt internet email would be 
what it is today.

Its a curse in that it open the door for exploitation and abuse.

I think we know that this was not something that just fell through the 
cracks.  As far as 80s,  there was many published concerns in the trade 
of foreseeing abuse with the sender or author domains.   In fact, prior 
to the internet, the public market of dialup online systems did not 
offer anonymous communications.  It required logins, etc.

But yet, even with the new openness, there was also optimistic 
expectations that this situation came be addressed.

Unfortunately, it never was adequately done, and in my view, it took the 
an infamous 2001/2002 SORBIG email virus with its unique dual phrase 
blitz attack on the mail network to finally make the world take notice 
of the weak provisions in the SMTP mail system and how it has been 
exploited.  Only then did the industry begin in earnest the DOMAIN::IP 
association and mapping strategies.  SPF and SENDERID is a result of 
that effort.

However, as we all know, these strategies has an inherent flaw with a 
design presumption that the sender MACHINE is always mapped to the 
sender DOMAIN in some authorized or permission based manner.

This is directly related the the general question about chaotic 
connectivity I raised above.

It is also directly related to the idea of identification via A/AAAA 
records or via a group list we call the MX mail host names list.

Either way, it is still some form of identification.

Also keep in mind there two different philosophies when it comes to 
implementation of SMTP mail reception and rejection:

   - You have growing SMTP level system that will do SMTP level
     security checking, even now at the DATA state.  These systems
     do 2821 level instant rejections.

   - You have the current majority of SMTP systems with a ACCEPT
     first, check later implementation.  These systems do post SMTP
     accept/bounce rejections - a very troubling part of the Email
     Security problem that continues to threatens delivery
     reliability.

Anyway, there are many intertwining issues to consider including a whole 
new can of worms with the virtualization methodologies that IPv6 is 
introducing which to me may even make MX/A/AAAA concepts transparent and 
obsolete at the application level and may even re-introduce mail hosting 
routing ideas.

A flat out "MX mandate" or no IMPLICIT MX while it sounds like a good 
idea as a whole, is it really?

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Michael Storz wrote:
> On Mon, 7 Apr 2008, Robert A. Rosenberg wrote:
> 
>> At 09:40 +0200 on 04/07/2008, Michael Storz wrote about deprecate
>> implicit MX even for IPv4:
>>
>>> The longer I follow this discussion and think about it, I am feeling that
>>> the cleanest solution would be to deprecate implicit MX even for IPv4. In
>>> the meantime I am convinced the implizit MX is a defect of RFC 2821. It
>>> was introduced more than 20 years ago as a workaround to get the routing
>>> via explizit MX RRs running.
>> While I agree with you that the time has come to depreciate implicate
>> MX for IPv4, I do not think addressing this issue/need should be
>> commingled with a ban on implicate MX for IPv6. IOW: Ban the
>> Implicate IPv6 MX as one effort and ban the Implicate IPv4 MX as a
>> separate effort or a failure of the IPv4 ban may prevent the IPv6 ban
>> from being effective. I see the 2 bans as SEPARATE issues and thus
>> should be addresses separately or we will have the IPv4 issue affect
>> the IPv6 issue. I see the IPv6 issue as something that needs to be
>> addressed NOW while the IPv4 issue can be fought another day if
>> needed. We have lived with this problem for 20 years and can live
>> with it, if needed, for a few more years. The IPv6 issue can NOT be
>> ignored or we will just end up in the same situation with AAAA record
>> usage as we have with A record usage. The time to act on AAAA usage
>> is NOW while the A usage can be addressed later/eventually.
>>
>>
> 
> As far as I can see, the discussion is going into the direction of
> respecting again the seperation of the different protocol layers as far as
> possible (a principle which I do support). And that couples the two
> protocols IPv4 and IPv6 closely together. And that means, if you want to
> depreciate implicit synthesized MX RRs, you have to depreciate them for
> IPv4 at the same time.
> 
> Depreciating impicit synthesized MX RRs makes only sense, if you think
> that using this feature nowadays with IPv4 or in the future with IPv6 is a
> problem. Unfortunately (from my point of view), several people on this
> list have expressed that this is not a problem for them.
> 
> However, my experience from being responsible (together with my team) for
> running email for a large scientific network for more than 20 years, is
> different.  For us it is a problem. It would be much better, to have a
> clear and clean statement that routing for SMTP is done by MX RRs and
> nothing else, basta! and everything else is a configuration error.
> 
> But this has never been a design goal. There are several areas in RFC
> 821/2821 and RFC 822/2822 where such stements are missing (I do not name
> them, because I do not want to direct discussion to these points again).
> 
> The general design principle has been
> 
> - you SHOULD not generate wrong things, but
> - you MUST accept them instead of rejecting such messages.
> 
> I understand that this attitude was necessary at the beginning to get SMTP
> running and having the maximum reachability. But I am absolutely convinced
> that this necessity does not exist anymore since a long time.
> 
> The result is that more and more ISPs are ignoring the standard. Some of
> them have at least the respectability to document this, like Frank just
> showed us with the link to the dokumentation of the suppression of DSNs by
> Dyndns.
> 
> Just my 2 cents from the operational world.
> Michael Storz

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Tue, 8 Apr 2008 09:37:41 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

On Mon, 7 Apr 2008, Robert A. Rosenberg wrote:

>
> At 09:40 +0200 on 04/07/2008, Michael Storz wrote about deprecate
> implicit MX even for IPv4:
>
> >The longer I follow this discussion and think about it, I am feeling that
> >the cleanest solution would be to deprecate implicit MX even for IPv4. In
> >the meantime I am convinced the implizit MX is a defect of RFC 2821. It
> >was introduced more than 20 years ago as a workaround to get the routing
> >via explizit MX RRs running.
>
> While I agree with you that the time has come to depreciate implicate
> MX for IPv4, I do not think addressing this issue/need should be
> commingled with a ban on implicate MX for IPv6. IOW: Ban the
> Implicate IPv6 MX as one effort and ban the Implicate IPv4 MX as a
> separate effort or a failure of the IPv4 ban may prevent the IPv6 ban
> from being effective. I see the 2 bans as SEPARATE issues and thus
> should be addresses separately or we will have the IPv4 issue affect
> the IPv6 issue. I see the IPv6 issue as something that needs to be
> addressed NOW while the IPv4 issue can be fought another day if
> needed. We have lived with this problem for 20 years and can live
> with it, if needed, for a few more years. The IPv6 issue can NOT be
> ignored or we will just end up in the same situation with AAAA record
> usage as we have with A record usage. The time to act on AAAA usage
> is NOW while the A usage can be addressed later/eventually.
>
>

As far as I can see, the discussion is going into the direction of
respecting again the seperation of the different protocol layers as far as
possible (a principle which I do support). And that couples the two
protocols IPv4 and IPv6 closely together. And that means, if you want to
depreciate implicit synthesized MX RRs, you have to depreciate them for
IPv4 at the same time.

Depreciating impicit synthesized MX RRs makes only sense, if you think
that using this feature nowadays with IPv4 or in the future with IPv6 is a
problem. Unfortunately (from my point of view), several people on this
list have expressed that this is not a problem for them.

However, my experience from being responsible (together with my team) for
running email for a large scientific network for more than 20 years, is
different.  For us it is a problem. It would be much better, to have a
clear and clean statement that routing for SMTP is done by MX RRs and
nothing else, basta! and everything else is a configuration error.

But this has never been a design goal. There are several areas in RFC
821/2821 and RFC 822/2822 where such stements are missing (I do not name
them, because I do not want to direct discussion to these points again).

The general design principle has been

- you SHOULD not generate wrong things, but
- you MUST accept them instead of rejecting such messages.

I understand that this attitude was necessary at the beginning to get SMTP
running and having the maximum reachability. But I am absolutely convinced
that this necessity does not exist anymore since a long time.

The result is that more and more ISPs are ignoring the standard. Some of
them have at least the respectability to document this, like Frank just
showed us with the link to the dokumentation of the suppression of DSNs by
Dyndns.

Just my 2 cents from the operational world.
Michael Storz

To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 07 Apr 2008 20:27:19 -0700
Sender: [email-masked]

"Robert A. Rosenberg" <[email-masked]> writes:
> Russ Allbery wrote about Re: current usage of AAAA implicit MX?:

>> It's not that it's technically difficult so much as that it's dubious
>> from a layering perspective, at least from where I sit.  It requires I
>> introduce IPv6-specific code (and hence ifdefs for systems without IPv6
>> constants and so forth) into an application that otherwise would not
>> need any and would be entirely stack-agnostic.

> OOPS. I was not considering the case where the code was being tailored
> at assembly time. Looking at my flow I see only 1 (2 if you want to
> ALWAYS set the flag in step 2) place where conditional code needs to be
> inserted. This is in step 3 where the Test Flag and IPN code would only
> get inserted IF IPv6 support is being generated.

I think you're missing the point.  In order to implement your proposal, I
have to insert IPv6 knowledge into code that otherwise does not need any
to work on both IPv4 and IPv6 systems.  If I don't have to care about IPv6
when it comes to processing the presence or absence of MX records, SMTP
clients honoring MX records can be written to be agnostic about the
networking stack that they're using.  Indeed, they can be written and
tested by people with only IPv4 access and work on IPv6 without
modification, since all the portabliity work is done by the system
library.

This is exactly the sort of abstraction and generalization accomplished
via a good layering design, and layering violations are bad precisely
because they don't allow this sort of clean separation of duties.  A lot
of work went into designing IPv6-friendly APIs so that clients using the
modern networking API and some additional bits of glue such as
sockaddr_storage can use the same code with both IPv4 and IPv6 without
ugly #ifdef hacks or following different code paths based on the protocol.
Let's not undo that.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Mon, 7 Apr 2008 22:51:06 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: IPV6: Where are we? (SMTP)
Sender: [email-masked]

At 23:51 +0200 on 04/07/2008, Frank Ellermann wrote about Re: IPV6: 
Where are we? (SMTP):

>Hector argues that it's the job of IPv6 domains to be reachable,
>for that they must either also offer A, or use an explicit MX
>with an IPv4 SMTP at a third party in addition to their AAAA.
>Assuming that 2821bis will be as long a standard as STD 10
>(about 30 years) adding this pragmatical idea could backfire
>when IPv4 is remote history.

You are assuming that IPv6 domains will not initially be Dual Stack. 
So long as they are dual stack (or have someone who is dual stack act 
as a secondary MX to forward to the IPv6-Only MTA) it will work.  You 
start with:

FQDN MX 10 IPv4
      MX 20 IPv6

with both the IPv4 and IPv6 MTAs being able to save to the IMAP/POP 
mailboxes or both set to hand off to an internal MTA for final 
delivery.

As IPv6 becomes more widespread make the IPv4 MX a 30 not a 10 and 
the IPv6 will become the preferred MTA.

Eventually you can remove the IPv4 (if there is a flag-day for 
depreciation of IPv4) or keep running the IPv4 or farm it out to a 
dual stack who will hand off to the IPv6 (as above).

Once you use a IPv4/IPv6 MX, the only use of the A will be by a 
antiquated resolver/MTA that does not understand MX or has its MX 
support turned off for some reason. All others will locate and talk 
to the IPv4 MTA via the MX.

Cc: SMTP Interest Group <[email-masked]>
From: Douglas Otis <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Date: Mon, 7 Apr 2008 19:36:39 -0700
Sender: [email-masked]

On Apr 7, 2008, at 9:54 AM, Dave Crocker wrote:
> John C Klensin wrote:
>> --On Sunday, 06 April, 2008 22:44 -0400 "Robert A. Rosenberg"
>> <[email-masked]> wrote:
>>> Remember that the A-Fallback behavior is ONLY due to the needs  
>>> (back in the 1980s)
> ...
>> Someone would need to check with Craig Partridge, but I believe  
>> that "only" (or "ONLY") in the above is not strictly correct. It  
>> may have been the primary reason, but, no matter how often "only"  
>> is repeated a desire to permit minimal configurations did, I am  
>> quite sure, figure in to the equation.
>
> A side discussion about history might be interesting, but I'll  
> suggest that it should not really be a factor for the current  
> discussion.  The reasons are:
>
> 1. It has a substantial installed base of use now.

SMTP without MX and only AAAA resource records is not widely deployed  
for public interchange.

> 2. There is a benefit in the feature, by virtue of reducing the  
> effort to create and email receiving service, and in some  
> environment the reduction is quite significant.

Standardizing on AAAA fallback when MX resource record do not exist  
will require those using IPv6-only hostnames to publish bogus MX  
resource records as a means to avoid undesired traffic SMTP now  
generates. Standardization on AAAA fallback is likely to attract this  
undesired traffic and further abuse of SMTP.  The undesired traffic  
can be substantial, depending upon the nature of the spoofed email,  
where creating bogus MX resource records in response should not be  
seen as beneficial.  This effort will increase the DNS zone sizes.   
Instances of IPv6 only SMTP lacking MX records and receiving public  
SMTP traffic is sure to represent a small minority of the number of  
hostnames in IPv6 address space.

A standardized default behaviour of AAAA fallback would also increase  
the overhead for those transmitting or receiving SMTP messages.  This  
new fallback mode would necessitate an additional DNS transaction and  
greatly increase the pool of hostnames used for spoofing an  
originating domain. In addition, when the hostname with AAAA only  
records do not accept messages, it may take days and many transactions  
before this problem is reported.  When a host is intended to act as a  
public SMTP server, publishing an MX record can be seen as offering an  
Opt-In strategy.  As everyone knows, Opt-Out and email does not work.

> 3. It is not generally recognized as causing any problems now.

Spoofing of originating domain is extremely common.  This strategy is  
already creating undesired traffic on servers not running SMTP.  This  
traffic might be generated when spoofed messages are being returned as  
NDNs, or when receiving SMTP servers attempt to validate the domain of  
the message in question.  When an MX is not found, a test might be  
performed by confirming a connection to port 25 is possible.  When  
these IPv6 hostnames represent simple devices reporting the status of  
vending machines, hot water heaters, etc, the undesired traffic  
created by the standardization of AAAA fallback may be enough to make  
these devices inoperable.  SMTP needs to play well with other protocols.

> What we need to do with this thread is end it.

End the denial that standardizing AAAA fallback for SMTP is not a  
substantial architectural change.  Depending upon the AAAA fallback  
mode of operation is also less likely to provide inter-operation, the  
goal of standardization.

-Doug

Date: Tue, 8 Apr 2008 12:10:00 +1200
To: [email-masked]
From: Glenn Anderson <[email-masked]>
Subject: Re: What is the history of 2821 and implict MX?
Sender: [email-masked]

At 4:55 pm -0400 7/4/2008, John C Klensin wrote:
>I believe, that I shifted away from (i) at the behest of one of
>the folks on the DNS side of the issue to make sure that the
>second lookup was not required if there were no DNS records at
>all for the name first looked up.

RFC 974 is quite clear about this, under "Issuing a Query":

    Certain responses to the query are considered errors:
...
Getting a response in which the response code is non-zero.

    Mailers are expected to do something reasonable in the face of an
    error.  The behaviour for each type of error is not specified here,
    but implementors should note that different types of errors should
    probably be treated differently.  For example, a response code of
    "non-existent domain" should probably cause the message to be
    returned to the sender as invalid, while a response code of "server
    failure" should probably cause the message to be retried later.

RFC 2821 (and 2821bis) on the other hand do not appear to clearly 
state that a "non-existent domain" error should cause a message to be 
returned to the sender as invalid.

For the case where the domain name does exist, but an empty list of 
MX records is returned, it is always going to require additional DNS 
lookups to ascertain that there are address records, so there is no 
gain in specifying that a check for address records is done before 
proceeding with an implicit MX.

I think the "No MX records found/present" wording for the choice to 
use an implicit MX is rather ambiguous, I think it would be better to 
use the "empty list" wording of RFC 974.

I propose something like this for the second half of the first 
paragraph of section 5.1:

The lookup first attempts to locate an MX record associated with the 
name. If a CNAME record is found, the resulting name is processed as 
if it were the initial name. If a non-existent domain error is 
returned, this situation MUST be reported as an error. If a temporary 
error is returned, the message MUST be queued and retried later 
(refer to sending strategy section?). If an empty list of MXs is 
returned, the address is treated as if it was associated with an 
implicit MX RR, with a preference of 0, pointing to that host. If MX 
records are present, but none of them are usable, or the implicit MX 
is unusable, this situation MUST be reported as an error.

Glenn.

Date: Mon, 07 Apr 2008 19:09:17 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC:  [email-masked]
Subject: Re: IPV6: Where are we? (SMTP)
Sender: [email-masked]

Frank Ellermann wrote:
> Robert A. Rosenberg wrote:
> 
> Hector argues that it's the job of IPv6 domains to be reachable,
> for that they must either also offer A, or use an explicit MX
> with an IPv4 SMTP at a third party in addition to their AAAA.
> Assuming that 2821bis will be as long a standard as STD 10 
> (about 30 years) adding this pragmatical idea could backfire
> when IPv4 is remote history.

30 years?  I'll take it. :-)

Hey, I would to be first to sign up for a brand new spec that addresses 
the future RIGHT now.  You don't have to nudge me on that. :-)

But that is not what Tony and John and Lisa want for 2821bis. At least I 
don't think so. It has been rammed down our throats that we are not 
attempting to cause CHANGE in our software.  Look at all the proposals 
which were shot down for that reason.

Well understood. I believe in that.  But its taken so darn LONG! :-)

No Frank. I'm all for maintaining compatibility with a pragmatic 
evolution.  I believe this is Crocker's philosophy and I 100% agree with 
an incremental approach.

I personally think we can put a stop to 2821bis now. Let this guys get 
this doc finished and rubber stamped. There are a lot of questionable 
stuff in there already that we intentional pushed to the side.  You can 
add only so much IPv6 to it now without it becoming a brand new spec.

And then, I hope, start a new SMTPv6 Draft proposal totally specific to 
SMTP operations for the IPv6 era and IPv4 playing 2nd fiddle this time 
around. I don't see much other than RFC 3974 that touches base with SMTP 
and IPv6 related issues.

We need more than whats in there.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 07 Apr 2008 18:54:25 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Pete Resnick <[email-masked]>
CC:  [email-masked], John C Klensin <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>, Dave Crocker <[email-masked]>
Subject: Re: What is the history of 2821 and implict MX?
Sender: [email-masked]

Pete Resnick wrote:
> 
 > In 974, "normal processing" involves
> finding the "address" associated with the domain. It does not mention A 
> records at all. So, for an IPv6 client, following the 974 algorithm 
> pretty clearly involves looking up AAAA records.

Ok, I will try to keep it short and non-argumentative but to just hope 
to supply some advocating reason here.

So by virtue of the fact that 974 was not specific, in hindsight you are 
suggesting it left it open-ended for any future record type associated 
with the domain?

When was 974 written? 1986?

When was IPv6 invented?  1991?

When was AAAA invented? 1995?

Come on Pete.  Clearly the mindset of the era was based on MX names of 
the time - A records, possibly CNAME records too.

If there was the intent to keep it open ended, which I see no semantics 
for such ideas, I don't think we can blame anyone for how things work now.

The fact is, given any point in the the timeline of software 
development, the software was trained to only use what was known at up 
to the point in time.  Clearly, specifically for a AAAA, it would of 
meant a technology that that would not exist for 10 more years for a 
entirely new set of communications invented 5 years earlier.

Guess what? it is still being fined tuned 17 years later!

Even then, I think it is still open-ended today - when the SOFTWARE is 
made to be aware of it.

I can see your point about 974 if we were talking about different names 
under same communication layers.  So if some new RR was invented and it 
was plug and play with the SAME software, then that would of been 
incredible.

That is not what we have here with IPv6.

This all reminds me of the old Fidonet day with mailers which were 
strictly RS232 at first.  The nodelist akin to the DNS today had 
telephone numbers.  IP nodes was even a consideration at first, but 
people were exploring  with IP and hostnames using spawned FTP and SMTP 
jobs event driven IP connections

When TCP/IP became a new growing feasible consideration, i.e, more nodes 
were able to afford PPP connections, new handshaking methods (IEMSI) 
file/data exchange protocol methods were invented specially designed for 
the internet.  The nodelist was enhanced to better define IP addresses 
and nodes in place of telephone numbers.

However, only a few FTN mailers were enhanced to support it i.e, 
BinkleyTerm.  Well, obviously old mailers had no way to communicate with 
IP nodes.

If there was any irony here, the developer vs admin debates to RELAX the 
standards to allow for new protocols was a major philosophical conflict 
that did not help Fidonet and IMV helped in it demise.

Of course that isn't going to happen here, but it certainly doesn't help 
with rate of progress we lack here.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: [email-masked]
Cc: John C Klensin <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>
From: Mark Andrews <[email-masked]>
Subject: Re: current usage of AAAA implicit MX? 
Date: Tue, 08 Apr 2008 08:32:54 +1000
Sender: [email-masked]

> 
> 
> 
> John C Klensin wrote:
> > --On Sunday, 06 April, 2008 22:44 -0400 "Robert A. Rosenberg"
> > <[email-masked]> wrote:
> >> Remember that the A-Fallback behavior is ONLY due to the
> >> needs (back in the 1980s) 
> ...
> > Someone would need to check with Craig Partridge, but I believe
> > that "only" (or "ONLY") in the above is not strictly correct.
> > It may have been the primary reason, but, no matter how often
> > "only" is repeated a desire to permit minimal configurations
> > did, I am quite sure, figure in to the equation.
> 
> 
> A side discussion about history might be interesting, but I'll suggest that i
> t 
> should not really be a factor for the current discussion.  The reasons are:
> 
> 1. It has a substantial installed base of use now.

	yes.
 
> 2. There is a benefit in the feature, by virtue of reducing the effort to cre
> ate 
> and email receiving service, and in some environment the reduction is quite 
> significant.
> 
> 3. It is not generally recognized as causing any problems now.

	It has unwanted consequences.   With the drop of WKS email went
	from "all machines that wanted email" to "all machines".  All
	this is trying to do is restore that distinction.
 
> What we need to do with this thread is end it.
> 
> d/
> > 
> 
> -- 
> 
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: IPV6: Where are we? (SMTP)
Date:  Mon, 7 Apr 2008 23:51:37 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 40
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Robert A. Rosenberg wrote:

> IMO there is no VALID excuse for allowing AAAA-Fallback except for
> the "We Allow A-Fallback so we should allow AAAA-Fallback" claim.
> I see the existence of A-Fallback support as an invalid issue to
> avoid justifying the need to not require the use of MX.

Sorry for adding a second message to this thread after writing...
| So that's it then, 2821bis-09 as is modulo some pending nits.
...almost a week ago.  But meanwhile I think 2821bis-09 could do
a better job explaining the issue.  

For a domain with A and AAAA the proposed rules based on RFC 974
make no difference.  An explicit MX means that the client can try
A or AAAA (or both after one failed).  An implicit MX has exactly
the same effect, so arguaby the explicit MX is redundant, or even
a deployment barrier.

If the domain.example has A and AAAA, but accepts SMTP only over
IPvX, it needs more than a simple explicit MX for its own name,
it needs an explicit MX pointing to say smtp.domain.example, and
smtp.domain.example gets either A or AAAA corresponding to IPvX.

Maybe 2821bis could mention this as example.  Pete's back to the
roots (RFC 974) proposal means, that a domain with only AAAA has
the same implicit MX like any other domain.  For an IPv4 sender
it is not reachable.  

Likewise a domain with only A has the same implicit MX like any
other domain, for an IPv6 sender it is not reachable.  In both
cases simply adding an explicit MX does not change the picture.

Hector argues that it's the job of IPv6 domains to be reachable,
for that they must either also offer A, or use an explicit MX
with an IPv4 SMTP at a third party in addition to their AAAA.
Assuming that 2821bis will be as long a standard as STD 10 
(about 30 years) adding this pragmatical idea could backfire
when IPv4 is remote history.

 Frank

Date: Mon, 7 Apr 2008 14:29:13 -0700
To: Hector Santos <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: What is the history of 2821 and implict MX?
Cc: [email-masked], John C Klensin <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>, Dave Crocker <[email-masked]>
Sender: [email-masked]

On 4/7/08 at 3:27 PM -0400, Hector Santos wrote:

>Pete Resnick wrote:
>
>>1. 974 did *not* have an "A fallback" rule at all. 974 is quite 
>>clear that the rule is, "If you can't find an MX, you should treat 
>>that as if you *did* find an MX where the preference was 0 and the 
>>name in the response was identical to the name queried. (That is, 
>>if you get back no MXs for a.example.org, then it should be 
>>equivalent to getting back a single MX of "a.example.org IN MX 0 
>>a.example.org".) If this rule were in effect today, you *would* 
>>connect to a mail host's IPv6 address even if it had no MX records.
>
>You lost me Pete. While the actual usage of the term "implicit MX" 
>is not used in 974, [...] the description in 974 which you repeated 
>above is effectively the same result that 2821 described as the 
>implicit MX record.

No, you are incorrect. In the 974 algorithm, if the list of MX 
records is empty, you add an MX (with a preference of 0 and the 
result name being identical to the initial MX query name*) to the 
list, and then do normal processing on the MX list. In 974, "normal 
processing" involves finding the "address" associated with the 
domain. It does not mention A records at all. So, for an IPv6 client, 
following the 974 algorithm pretty clearly involves looking up AAAA 
records.

In the 2821 algorithm, if the list of MX is empty, you first do an A 
record lookup on the name. Only if that succeeds do you add an MX 
record (with a preference of 0 and the result name being identical to 
the *A record query name*) to the list, and then do normal processing 
on the MX list. 2821 does not talk about looking up "addresses"; it 
specifically says that processing on the MX record is looking up "A 
records". An IPv6 client trying to follow the 2821 algorithm is out 
of luck.

Under the 974 algorithm, a host with only a AAAA record and no MX or 
A records will still be found. Under the 2821 algorithm, it won't.

>But I don't see how your last statement applies because you are 
>assuming the the IPv4 client is aware of AAAA record and more 
>specifically IPv6 level 2 TCP protocol layers.

Nope. I make no such assumption. Please carefully re-read the above.

>Regardless of 974 or 2821 NO MX records behavior (which to me is the 
>same), AAAA results would be meaningless to a IPv4 only client.

True, but irrelevant. Again, see above.

>>2. 2821 changed the rule and made explicit claims about looking for 
>>fallback A records.
>
>Semantics.

No. 2821 provides for A records. 974 does not.

>This is exactly what 2821 provides with the implicit MX concept. I 
>fail to see the difference.

Then you really need to re-read the above more carefully.

>In fact, I think 2821BIS should reintroduce the last "The idea here 
>is" sentence. Its perfect and will give people a better 
>understanding as to why it exist.

On this, we agree.

>>The question is, was that intentional? Did DRUMS intend to change 
>>the 974 rule in this regard, or was it trying to explain what the 
>>974 rule entailed by using examples? So far, I can find nothing in 
>>the DRUMS archive to support the position that 2821 intentionally 
>>changed the 974 rules.
>
>Probably because there are basically the same?

They are not.

>>My current feeling is that 2821bis should clarify that it intended 
>>the 974 rule. Yes, that gets us implicit MXs that point to AAAA 
>>hosts. Such is life.
>
>+1.  Adding that "The idea here is" line would be wonderful. :-)

Well, so long as we agree on the result. :-)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Mon, 07 Apr 2008 17:18:57 -0400
From: John C Klensin <[email-masked]>
To: Hector Santos <[email-masked]>
cc: [email-masked]
Subject: Re: Implicit MX decisions
Sender: [email-masked]

--On Monday, 07 April, 2008 16:00 -0400 Hector Santos
<[email-masked]> wrote:

> John C Klensin wrote:
>...
> I think the chart, summary I provided shows that the question
> we have attempts to address how a IPv6 system should behavior.
> Not a IPv4 system.
> 
> It is the IPv6 system that needs to decide where it should
> look up A or AAAA records. Not IPv4 systems.
> 
> Unless you don't think so, I don't think 2821bis is in any
> position to begin describing how IPv6 should behave as far as
> what records and/or order of lookups it should do.  A first,
> AAAA second or vice versa, information that both RFC 3484 and
> also 4083 attempt to address for IPv6 systems or hybrids.  Not
> pure IPV4 systems and this is clearly described in both
> documents.  IPv4 only systems will behave only one way.  This
> is independent of a Dual Stack Node. Not Dual Stack SMTP
> Application
> 
> In short, IMV, 2821bis is still about IPv4 and I think the
> only thing that we can even mention is to codify the fact that
> an incoming IPv6 still needs to be compatible with a 2821 IPv4
> SMTP system.

Hector, I read all the way to your last paragraph and was
preparing to write an "I agree" note.  Than I read that
paragraph and realized I had misinterpreted everything that you
had written earlier.

2821bis is intended to apply to both IPv4 and IPv6.  We really
have no practical model for specifying an application,
especially an application that runs over TCP, that runs
exclusively over (TCP over) IPv4.  It is not an accident that
2821 specifies a syntax for IPv6 address literals... and, unlike
the change in wording about MX records from 974, that change was
quite explicitly discussed during the DRUMS work.  It is very
clear that the fate and handling of AAAA records is irrelevant
to an IPv4-only implementation and almost equally so to a
dual-stack implementation running in an environment with no IPv6
connectivity.  But that doesn't make 2821bis "about IPv4" or
imply that there will be an SMTPv6 somewhere down the line.

    john

Date: Mon, 07 Apr 2008 16:55:39 -0400
From: John C Klensin <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
cc: "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>, Dave Crocker <[email-masked]>
Subject: Re: What is the history of 2821 and implict MX?
Sender: [email-masked]

--On Monday, 07 April, 2008 11:39 -0700 Pete Resnick
<[email-masked]> wrote:

> 
> On 4/7/08 at 9:54 AM -0700, Dave Crocker wrote:
> 
>> John C Klensin wrote:
>> 
>>> Someone would need to check with Craig Partridge...
>> 
>> A side discussion about history might be interesting, but
>> I'll  suggest that it should not really be a factor for the
>> current  discussion.
> 
> So, I want to disagree with Dave and wish to consider some
> history, though Dave may have only been referring to the
> history leading up to 974. I think the history leading up to
> 2821 might be important:
> 
> 1. 974 did *not* have an "A fallback" rule at all. 974 is
> quite clear that the rule is, "If you can't find an MX, you
> should treat that as if you *did* find an MX where the
> preference was 0 and the name in the response was identical to
> the name queried. (That is, if you get back no MXs for
> a.example.org, then it should be equivalent to getting back a
> single MX of "a.example.org IN MX 0 a.example.org".) If this
> rule were in effect today, you *would* connect to a mail
> host's IPv6 address even if it had no MX records.

Since this, and the statement in 974, has already confused at
least one person, let me repeat what Pete says above before
commenting.  The rule in 974 is that a mail client makes a query
for an MX record.  If it doesn't find it, it synthesizes one and
pretends.  That synthesis is _not_ dependent on finding an A RR
or anything else.   If, having found or invented the MX, its
data field contains a name that doesn't resolve to anything
useful, the failure occurs at that point, not in generating the
MX (or not).

It is perhaps also worth noting in this context that RFC 1123
talks exclusively about "address records" and not about "A
records" in the context of MX.    It does not discuss what we
are now calling the implicit MX rule at all.

> 2. 2821 changed the rule and made explicit claims about
> looking for fallback A records. The question is, was that
> intentional? Did DRUMS intend to change the 974 rule in this
> regard, or was it trying to explain what the 974 rule entailed
> by using examples? So far, I can find nothing in the DRUMS
> archive to support the position that 2821 intentionally
> changed the 974 rules.

I can find nothing in my personal notes either, which suggests
that the explanation in 2821 --which did attempt to merge the
974 and 1123 rules and explain them in less space-- was chosen
because it seemed more clear.  Note that 2821 could have picked
three options, all consistent with the understanding of 974 at
the time:

	(i) Reproduce exactly the operation of 974, i.e., if a
	lookup with Type=MX fails, generate an implicit MX
	regardless of the presence or absence of any other
	records.  Note that, if taken literally, this requires a
	second lookup if the Type=MX fails, even if the failure
	is NXDOMAIN.
	
	(ii) Use the model of 2821, which requires synthesis of
	an MX only if an A RR is found.
	
	(iii)  Use the model of 2821, but using the "address
	record" language of 1123.  That, of course, produces
	exactly what is in the 2821bis-09 draft.

I believe, that I shifted away from (i) at the behest of one of
the folks on the DNS side of the issue to make sure that the
second lookup was not required if there were no DNS records at
all for the name first looked up.   While I can't prove that
from my notes, I do have a note (quite cryptic in retrospect)
about a DNS issue that reinforces my vague memory.  I imagine
that the choice of "A RR" over "address record" was chosen with
almost no thought and no on-list discussion.

> If 2821 had preserved the 974 MX rule, we would not be having
> this discussion at all. The rule would be clear that the lack
> of the MX got you an implicit MX, and then you'd look up A and
> AAAA records as normal.

And a review of 1123 just now makes it clear to me that, if a
name had exactly two RRs, one A and the other AAAA, with an MX
pointing to it (implicit or explicit), an argument that one
should look at one of those records and not the other is
untenable except as a significant change to established
standards.

> This entire argument reduces (for me) to answering this
> question: Did 2821 intend to preserve the 974 rule? If DRUMS
> did *not* intend to change the 974 rule, then 2821's current
> text is an errant interpretation of 974 and should be fixed
> back to the 974 rule. If DRUMS *did* intend to change the rule
> to make it clear that 974 was all about
> backwards-compatibility for hosts that didn't have MX records,
> then there is a reasonable argument to be made for not doing
> so for AAAA.

I can find no record of a DRUMS decision to change the 974 rule.
If there was any explicit decision at all, it was made just to
clarify that the second DNS lookup was not required if there was
no address information present.   I assume that the lack of any
mention in my note of the choice between "A RR" and "address
record" terminology in 2821 means that the decision was made
with no thought of discussion.  Blame the stupid editor for
getting it wrong.

> My current feeling is that 2821bis should clarify that it
> intended the 974 rule. Yes, that gets us implicit MXs that
> point to AAAA hosts. Such is life.

Reserving further comment at this time.    But that
clarification can occur either as option (i) or option (iii)
above, possibly plus some explanatory text.   Or one could do
option (i) and put in a sentence or two indicating that the
second lookup can be omitted if the SMTP client knows that there
are no address records present.

     john

Date: Mon, 7 Apr 2008 16:26:02 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

At 04:57 -0400 on 04/07/2008, Hector Santos wrote about Re: deprecate 
implicit MX even for IPv4:

>Hector Santos wrote:
>
>>I say leave well enough alone and if you want to invent NEW 
>>expectations, then you MUST raise the bar from what is normally 
>>done and you can only do this with NEW indicators and state values.
>>
>>is IPv6 it?  From a legal standpoint, I say yes.
>>
>>Is DKIM it?  From a legal standpoint, I say yes.
>>
>>Is Port 587 it?  From a legal standpoint, I saw yes.
>>
>>But not a legacy system like IPv4 with no indicators, I say no.
>
>Michael,
>
>I will add to this a SMTP session with a HELO/EHLO domain literal 
>that is in the IPv6 format.
>
>This would provide legal ground to do something that is NEW and 
>acceptable with new provisions in the new standards.  Since the SMTP 
>client raised the bar (open the door) by showing something new, it 
>provides the opportunity for a new level of actions a receiver can 
>take.
>
>So to me, if you want to propose if a SMTP client is showing a IPv6 
>domain literal for the EHLO/HELO, then the idea of not doing 
>IMPLICIT MX  is 100% acceptable to me.

One question - What does the client using a EHLO/HELO with an IPN 
literal (or a FQDN) have to do with the MAIL-FROM FQDN of the Email 
Address? Just because the client called itself Domain1 does not mean 
that the email with MAIL-FROMs of Domain2 is going to have its 
replies (or status messages) sent to a MTA at Domain1 (Domain2 
incoming mail might be serviced by a different ISP or Domain). As a 
perfect example, my client is identifying itself via my OptOnline.Net 
Connectivity Provider FQDN/IPN yet the email is going to Panix.Com 
MTA and replies will get sent to Panix not OptOnline.

>
>The same applies in a POST SMTP logic where the 822 headers have 
>DKIM headers.  This raises the bar the CLIENT has put in himself 
>into and can not claim anything against new standards that with with 
>the new information provided by the client.
>
>--
>Sincerely
>
>Hector Santos, CTO
>http://www.santronics.com
>http://santronics.blogspot.com

Date: Mon, 7 Apr 2008 16:11:54 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

At 04:40 -0400 on 04/07/2008, Hector Santos wrote about Re: deprecate 
implicit MX even for IPv4:

>Michael Storz wrote:
>
>>The longer I follow this discussion and think about it, I am feeling that
>>the cleanest solution would be to deprecate implicit MX even for IPv4. In
>>the meantime I am convinced the implizit MX is a defect of RFC 2821. It
>>was introduced more than 20 years ago as a workaround to get the routing
>>via explizit MX RRs running.
>>
>  > snip
>>
>>Therefore from an operational and liability standpoint it is time to
>>deprecate the implizit MX RR. You had the guts to the deprecation the
>>source routes some years back. Now have the guts to deprecate the implizit
>>MX RR.
>
>Well, from a liability standpoint, in my view, eliminating the 
>IMPLICIT MX can certainly be viewed as the WRONG direction.

How does replacing the use of the A record with a MX pointing at the 
A record signify a wrong direction? My MTA will still be locatable 
via the MX record and able to locate the other MTA by its MX record 
so the messages will still get delivered. If, for some reason, one of 
the MTAs is running some antiquated code that does not recognize the 
use of the MX record to locate what MTA to send to, it will still (in 
violation of the implicate MX elimination) have a A record to use 
(unless when the MX record gets defined the A record for the FQDN 
gets deleted and the MX is pointed to something other than its FQDN 
name). If the MTA goes IPv6-Only or Dual Stack (with the MX not 
pointing at an A record with the FQDN name) this antiquated MTA would 
fail anyway.

Date: Mon, 7 Apr 2008 15:55:25 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

At 09:40 +0200 on 04/07/2008, Michael Storz wrote about deprecate 
implicit MX even for IPv4:

>The longer I follow this discussion and think about it, I am feeling that
>the cleanest solution would be to deprecate implicit MX even for IPv4. In
>the meantime I am convinced the implizit MX is a defect of RFC 2821. It
>was introduced more than 20 years ago as a workaround to get the routing
>via explizit MX RRs running.

While I agree with you that the time has come to depreciate implicate 
MX for IPv4, I do not think addressing this issue/need should be 
commingled with a ban on implicate MX for IPv6. IOW: Ban the 
Implicate IPv6 MX as one effort and ban the Implicate IPv4 MX as a 
separate effort or a failure of the IPv4 ban may prevent the IPv6 ban 
from being effective. I see the 2 bans as SEPARATE issues and thus 
should be addresses separately or we will have the IPv4 issue affect 
the IPv6 issue. I see the IPv6 issue as something that needs to be 
addressed NOW while the IPv4 issue can be fought another day if 
needed. We have lived with this problem for 20 years and can live 
with it, if needed, for a few more years. The IPv6 issue can NOT be 
ignored or we will just end up in the same situation with AAAA record 
usage as we have with A record usage. The time to act on AAAA usage 
is NOW while the A usage can be addressed later/eventually.

Date: Mon, 7 Apr 2008 15:37:41 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

--======_-1004522247=_mr======
Content-Type: multipart/alternative; boundary="======_-1004522247=_ma======"

--======_-1004522247=_ma======
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 02:25 -0400 on 04/07/2008, Hector Santos wrote about Re: How does 
SMTP IPv4 and IPv6 work together:

>Robert A. Rosenberg wrote:
>>
>>At 02:51 -0400 on 04/06/2008, Hector Santos wrote about Re: How 
>>does SMTP IPv4 and IPv6 work together:
>>
>>>So this is why I believe that the only text that is necessary at this
>>>point for 2821bis is:
>>>
>>>       IPv6 senders connecting to IPv4 systems MUST be aware that IPv4
>>>       systems are ignorant of IPv6 technology and therefore SHOULD
>>>       make it possible to comply with IPv4 SMTP expectations to allow
>>>       for responses.  This implies that IPv6 senders sending mail to
>>>       IPv6 SHOULD|MUST have explicit MX records or implicit MX A
>>>       record at a minimum.
>>
>>I have removed all of the rest of your message and left only the 
>>above. Make that SHOULD|MUST just SHOULD (and add "pointing at A 
>>and and optionally AAAA records" after the "explicit MX records" 
>>clause) and the issue is solved since only these combinations are 
>>valid:
>>
>>Should that "sending mail to IPv6" not read "sending mail to IPv4"?
>
>Yes, it was a typo, corrected with your suggested changes:
>
>      IPv6 senders connecting to IPv4 systems MUST be aware that IPv4
>      systems are ignorant of IPv6 technology and therefore SHOULD
>      make it possible to comply with IPv4 SMTP expectations to allow
>      for responses.  This implies that IPv6 senders sending mail to
>      IPv4 SHOULD have explicit MX records pointing at A and
>      optionally AAAA records.
>
>I am not sure I like the last sentence since the AAAA record is 
>meaningless to IPv4 only aware SMTP nodes.
>
>How about:
>
>      .... This implies that IPv6 senders sending mail to
>      IPv4 SHOULD have A records resulting from explicit MX
>      queries.

How about "... pointing at A and optionally AAAA records (to allow 
the IPv6 MTA to talk to IPv6-Only MTAs)"? This preserves and explains 
the MX->AAAA section. Thus IPv4 would/could be preferred for Dual 
Stack Receivers while still supporting both IPv4-Only and IPv6-Only 
receivers.

>
>--
>Sincerely
>
>Hector Santos, CTO
>http://www.santronics.com
>http://santronics.blogspot.com

--======_-1004522247=_ma======
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: How does SMTP IPv4 and IPv6 work
together</title></head><body>
<div>At 02:25 -0400 on 04/07/2008, Hector Santos wrote about Re: How
does SMTP IPv4 and IPv6 work together:</div>
<div><br></div>
<blockquote type="cite" cite>Robert A. Rosenberg wrote:
<blockquote type="cite" cite><br>
At 02:51 -0400 on 04/06/2008, Hector Santos wrote about Re: How does
SMTP IPv4 and IPv6 work together:<br>
<blockquote type="cite" cite>So this is why I believe that the only
text that is necessary at this<br>
point for 2821bis is:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv6 senders connecting to IPv4 systems
MUST be aware that IPv4<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; systems are ignorant of IPv6 technology
and therefore SHOULD<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; make it possible to comply with IPv4
SMTP expectations to allow<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for responses.&nbsp; This implies that
IPv6 senders sending mail to<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPv6 SHOULD|MUST have explicit MX
records or implicit MX A<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; record at a minimum.</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
I have removed all of the rest of your message and left only the
above. Make that SHOULD|MUST just SHOULD (and add &quot;pointing at A
and and optionally AAAA records&quot; after the &quot;explicit MX
records&quot; clause) and the issue is solved since only these
combinations are valid:<br>
<br>
Should that &quot;sending mail to IPv6&quot; not read &quot;sending
mail to IPv4&quot;?</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
Yes, it was a typo, corrected with your suggested changes:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; IPv6 senders connecting to IPv4 systems MUST
be aware that IPv4<br>
&nbsp;&nbsp;&nbsp;&nbsp; systems are ignorant of IPv6 technology and
therefore SHOULD<br>
&nbsp;&nbsp;&nbsp;&nbsp; make it possible to comply with IPv4 SMTP
expectations to allow<br>
&nbsp;&nbsp;&nbsp;&nbsp; for responses.&nbsp; This implies that IPv6
senders sending mail to</blockquote>
<blockquote type="cite" cite>&nbsp;&nbsp;&nbsp;&nbsp; IPv4 SHOULD have
explicit MX records pointing at A and</blockquote>
<blockquote type="cite" cite>&nbsp;&nbsp;&nbsp;&nbsp; optionally AAAA
records.<br>
<br>
I am not sure I like the last sentence since the AAAA record is
meaningless to IPv4 only aware SMTP nodes.<img
src="cid:p06240802c4202707c1b8@[192.168.1.11].1.0"><br>
<br>
How about:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; .... This implies that IPv6 senders sending
mail to<br>
&nbsp;&nbsp;&nbsp;&nbsp; IPv4 SHOULD have A records resulting from
explicit MX<br>
&nbsp;&nbsp;&nbsp;&nbsp; queries.</blockquote>
<div><br></div>
<div>How about &quot;... pointing at A and optionally AAAA records (to
allow the IPv6 MTA to talk to IPv6-Only MTAs)&quot;? This preserves
and explains the MX-&gt;AAAA section. Thus IPv4 would/could be
preferred for Dual Stack Receivers while still supporting both
IPv4-Only and IPv6-Only receivers.</div>
<div><br></div>
<blockquote type="cite" cite><br>
--<br>
Sincerely<br>
<br>
Hector Santos, CTO<br>
http://www.santronics.com<br>
http://santronics.blogspot.com</blockquote>
<div><br></div>
</body>
</html>
--======_-1004522247=_ma======--
--======_-1004522247=_mr======
Content-Id: <p06240802c4202707c1b8@[192.168.1.11].1.0>
Content-Type: image/gif; name="!3a-) Happy.gif"
 ; x-mac-type="47494666"
 ; x-mac-creator="474B4F4E"
Content-Disposition: attachment; filename="!3a-) Happy.gif"
Content-Transfer-Encoding: base64

--======_-1004522247=_mr======--

Date: Mon, 7 Apr 2008 15:29:28 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

At 02:13 -0400 on 04/07/2008, Hector Santos wrote about Re: How does 
SMTP IPv4 and IPv6 work together:

>Robert A. Rosenberg wrote:
>
>>My error in not stating my real question but assuming the caveat by 
>>implication. To reword my query (*CAPS* are the omitted caveat):
>>
>>What justification do you offer to allow an IPv6 MTA to run *VIA 
>>IPv6* without an EXPLICATE MX record? IOW: If it is dual stack and 
>>willing to use IPv4 then just allow the A-Fallback but why allow 
>>AAAA-Fallback to allow it to talk via IPv6? Note: I was assuming 
>>that an EXPLICATE MX would point not only to all the needed AAAA 
>>records but also the A records that would be used by a IPv4-Only 
>>Stack in Fallback mode (ie: Since the existence of the MX precludes 
>>A-Fallback , the A records MUST be referenced by the MX).
>  >
>>I guess I will need to be more explicate in the future and avoid 
>>unstated assumptions <g>.
>
>Side question: Are you using term EXPLICATE intentional?  because I 
>think everyone is on sync using "Explicit" vs "Implicit". Implicit 
>MX is the term used in 2821.

I am using the term explicate to mean "A MX was found in the DNS in 
response to a MX request" to distinguish it from the 2821 "implicate" 
case of pretending that the MX request returned a "FQDN MX 0 FQDN" 
since there was no MX there to be returned.

>That said, we have a IPv4 SMTP working model for the last 20+ years. 
>By extension, IMV, any reasonable engineer would model IPv6 in the 
>same way.  Another way to say that is if you are attempting to fit 
>IPv6 into the IPv4 world, then it would be common sense that IPv6 
>will behave with all the expectations of a IPv4 model.  In other 
>words, IPv6 should not alter IPv4  behavior.

This model ignores the reason why IPv4 works this way NOW. IOW: To 
allow pre-MX-era defined MTAs that used the A record to continue to 
work without requiring a MX to be defined and the failure in the 20 
years since to depreciate the use of no longer needed (since a MX 
will work) A records as well as not cracking down on admins who to 
this day define new IPv4 MTAs via A not MX records. If all the 
missing MX records were suddenly/magically be defined, IPv4 support 
would still work as it currently does (ie: The IPv4 MTAs would still 
get located). Thus REQUIRING that a MX (pointing at both the new IPv6 
MTA and the legacy IPv4 MX-Less MTA) be defined once you have a IPv6 
MTA is does not break the current model (ie: MX is optional for 
IPv4-Only MTAs but CAN be defined).

>
>That would be my justification from an engineering standpoint why an 
>IPv6 client "may" be able to do a AAAA lookup, simply because an 
>IPv4 client can do a A lookup.  So this means, the IPv6 MTA does not 
>have to have a MX record.

But why should it NEED to be able look at AAAA records when a MX 
record can and will point at both the IPv4 and IPv6 MTA's IPNs? Enter 
the 21st century and just define the MX record when you create your 
IPv6 MTA.

>
>--
>Sincerely
>
>Hector Santos, CTO
>http://www.santronics.com
>http://santronics.blogspot.com

Date: Mon, 7 Apr 2008 14:50:05 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 07:44 -0400 on 04/07/2008, John C Klensin wrote about Re: current 
usage of AAAA implicit MX?:

>--On Sunday, 06 April, 2008 22:44 -0400 "Robert A. Rosenberg"
><[email-masked]> wrote:
>
>>...
>>  Remember that the A-Fallback behavior is ONLY due to the
>>  needs (back in the 1980s) of MTAs that were following the
>>  pre-MX rule that you found an MTA by looking at the FQDN
>>  A-Record group.
>
>Robert, 
>
>Someone would need to check with Craig Partridge, but I believe
>that "only" (or "ONLY") in the above is not strictly correct.
>It may have been the primary reason, but, no matter how often
>"only" is repeated a desire to permit minimal configurations
>did, I am quite sure, figure in to the equation.

Why, since MX has been in existence for 20 years and most (if not 
all) currently deployed DNS and Resolver software support it, do you 
suggest the need to allow the use of A records in the absence of a MX 
to be allowed as opposed to being treated as a definition error? I am 
asking why NEW definitions of an IPv4 MTA should not use a MX record 
not why we should allow grandfather'ed definitions to not need to be 
upgraded via the addition of the MX.

BTW: You are quoting me out of context. The above quote of mine was 
NOT justifying any suggestion to deprecate A-Fallback support but 
only to justify initially banning AAAA-Fallback (until we can address 
the issue of allowing AAAA-Fallback) since the use of MX records to 
point at IPv6 MTAs can work since there is no pre-MX set of IPv6 MTAs 
to be supported (unlike the A-Only MTAs 20 years ago). I regard ANY 
MX-Less IPv6 MTAs as a definition error since the MX could (and 
SHOULD) have been defined (along with the legacy A-ONLY IPv4 MTAs 
being added to the MX when it is defined). Once you initially define 
a IPv6 MTA it is not any extra effort to add the requisite MX when 
you define the AAAA.

Date: Mon, 7 Apr 2008 14:28:31 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: IPV6: Where are we? (SMTP)
Sender: [email-masked]

At 22:17 -0400 on 04/06/2008, Hector Santos wrote about IPV6: Where 
are we? (SMTP):

>Why has this not been discussed as an alternative to AAAA?  It would 
>seem to me that A6 which has type value of 38 is a reasonable item 
>to be discussed  if we also going to discussed lookups for AAAA 
>records.

I seem to have the impression that the A6 version was depreciated in 
favor of the AAAA method due to AAAA being straight forward (it is 
just the IPv6 version of the A) while A6 was VERY complex to define 
(as DNS records) and implement (in code and resolvers). They were two 
different ways of defining IPv6 addresses and in the head-to-head 
competition AAAA won.

As to the Implicate MX question, I think we should take the 
conservative stance that direct AAAA references should be banned 
RIGHT NOW with this a possible relaxation of this restriction to be 
addressed at a later date via an RFC on this issue.

IOW:

IPv4-Only MTA FQDNs as at present - Optional (but suggested) MX with 
A-Fallback in the absence of the MX.

IPv6 MTA FQDNs ONLY via MX (with a recommendation that there be IPv4 
MTAs which MUST be listed in the MX [since the existence of the MX 
precludes A-Fallback]).

By INITIALLY saying "No AAAA-Fallback" we can address the issue later 
while allowing it NOW will prevent us from banning/depreciating it in 
the future (as we can see with trying to depreciate A-Fallback). IMO 
there is no VALID excuse for allowing AAAA-Fallback except for the 
"We Allow A-Fallback so we should allow AAAA-Fallback" claim. I see 
the existence of A-Fallback support as an invalid issue to avoid 
justifying the need to not require the use of MX.

Date: Mon, 07 Apr 2008 16:00:16 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC:  [email-masked]
Subject: Re: Implicit MX decisions
Sender: [email-masked]

John C Klensin wrote:

> Hector has tried to summarize the various positions, but his
> note seems to comment on connectivity choices.  I don't think
> those choices are at issue.   I don't believe they _can_ be an
> issue in 2821bis because making special rules about connection
> types would require updating RFC 3484.

John,  it cross my mind that this should be my last statement on this.

I hope my over simplification does not lose its basic meaning.

I think the chart, summary I provided shows that the question we have 
attempts to address how a IPv6 system should behavior.  Not a IPv4 system.

It is the IPv6 system that needs to decide where it should look up A or 
AAAA records. Not IPv4 systems.

Unless you don't think so, I don't think 2821bis is in any position to 
begin describing how IPv6 should behave as far as what records and/or 
order of lookups it should do.  A first, AAAA second or vice versa, 
information that both RFC 3484 and also 4083 attempt to address for IPv6 
systems or hybrids.  Not pure IPV4 systems and this is clearly described 
in both documents.  IPv4 only systems will behave only one way.  This is 
independent of a Dual Stack Node. Not Dual Stack SMTP Application

In short, IMV, 2821bis is still about IPv4 and I think the only thing 
that we can even mention is to codify the fact that an incoming IPv6 
still needs to be compatible with a 2821 IPv4 SMTP system.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 07 Apr 2008 15:27:45 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Pete Resnick <[email-masked]>
CC:  [email-masked], John C Klensin <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>, Dave Crocker <[email-masked]>
Subject: Re: What is the history of 2821 and implict MX?
Sender: [email-masked]

Pete Resnick wrote:
> 
> On 4/7/08 at 9:54 AM -0700, Dave Crocker wrote:
> 
>> John C Klensin wrote:
>>
>>> Someone would need to check with Craig Partridge...
>>
>> A side discussion about history might be interesting, but I'll suggest 
>> that it should not really be a factor for the current discussion.
> 
> So, I want to disagree with Dave and wish to consider some history, 
> though Dave may have only been referring to the history leading up to 
> 974. I think the history leading up to 2821 might be important:
> 
> 1. 974 did *not* have an "A fallback" rule at all. 974 is quite clear 
> that the rule is, "If you can't find an MX, you should treat that as if 
> you *did* find an MX where the preference was 0 and the name in the 
> response was identical to the name queried. (That is, if you get back no 
> MXs for a.example.org, then it should be equivalent to getting back a 
> single MX of "a.example.org IN MX 0 a.example.org".) If this rule were 
> in effect today, you *would* connect to a mail host's IPv6 address even 
> if it had no MX records.

You lost me Pete. While the actual usage of the term "implicit MX" is 
not used in 974, and personally, I think it is a BAD term,  the 
description in 974 which you repeated above is effectively the same 
result that 2821 described as the implicit MX record.

But I don't see how your last statement applies because you are assuming 
the the IPv4 client is aware of AAAA record and more specifically IPv6 
level 2 TCP protocol layers.

Regardless of 974 or 2821 NO MX records behavior (which to me is the 
same), AAAA results would be meaningless to a IPv4 only client.

I just don't see the different here and in my opinion, it really does 
not matter what 974 said differently because I doubly very highly ANYONE 
would be operating using its recommendations - even though I think its 
the same 2821 inherited and simply provided an official term for it.

> 2. 2821 changed the rule and made explicit claims about looking for 
> fallback A records. 

Semantics.  That is basically what 974 is describing when it says:

    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.

This is exactly what 2821 provides with the implicit MX concept. I fail 
to see the difference.

In fact, I think 2821BIS should reintroduce the last "The idea here is" 
sentence. Its perfect and will give people a better understanding as to 
why it exist.

> The question is, was that intentional? Did DRUMS 
> intend to change the 974 rule in this regard, or was it trying to 
> explain what the 974 rule entailed by using examples? So far, I can find 
> nothing in the DRUMS archive to support the position that 2821 
> intentionally changed the 974 rules.

Probably because there are basically the same?

> My current feeling is that 2821bis should clarify that it intended the 
> 974 rule. Yes, that gets us implicit MXs that point to AAAA hosts. Such 
> is life.

+1.  Adding that "The idea here is" line would be wonderful. :-)

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 07 Apr 2008 15:03:26 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: John C Klensin <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Dave Crocker wrote:
> 
> A side discussion about history might be interesting, but I'll suggest 
> that it should not really be a factor for the current discussion.  The 
> reasons are:
> 
> 1. It has a substantial installed base of use now.
> 
> 2. There is a benefit in the feature, by virtue of reducing the effort 
> to create and email receiving service, and in some environment the 
> reduction is quite significant.
> 
> 3. It is not generally recognized as causing any problems now.
> 
> What we need to do with this thread is end it.
> 

If you are suggesting to drop the proposal, then +1.

This is definitely way too much (and important too) to throw into 
2821bis at the last minute. I vote to nix it and if anything, the text I 
provided or similar regarding a "reminder" that IPv6 need to maintain 
SMTP compatible with IPv4 at all levels as we know it today, especially 
in the area of IPv4 based responses.

    IPv6 senders connecting to IPv4 systems MUST be aware that IPv4
    systems are ignorant of IPv6 technology and therefore SHOULD
    make it possible to comply with IPv4 SMTP protocol
    expectations to allow for responses.  This implies that
    IPv6 senders sending mail to IPv4 SHOULD have A records
    resulting from explicit MX queries or a A record resulting
    from a implicit MX.

You, John and Tony would be a better judge, but I think a simple 
statement like above is reasonable because it keeps with the 
compatibility requirements of current SMTP IPv4 systems.

If IPv6 systems or Hybrid are hitting our MTA/MSA software, the last 
thing I want to see happen is we rejected it because the client is not 
reachable come BOUNCE or come a user response back to the client domain.

I sincerely hope this is acceptable, if not, I am eager to learn why you 
don't think so.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Lost DSNs (was: current usage of AAAA implicit MX?)
Date:  Mon, 7 Apr 2008 21:02:06 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 9
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> I concede that most people don't think lost DSNs are
> a significant problem.

Unfortunately, I like good DSNs.  Yesterday I stumbled 
over <http://www.dyndns.com/news/newsletters/08.html>

 Frank

From: [email-masked]
Cc: [email-masked], John C Klensin <[email-masked]>, Robert A Rosenberg <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Date: Mon, 07 Apr 2008 11:33:19 -0700 (PDT)
Subject: Re: current usage of AAAA implicit MX?
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> Dave Crocker writes:
> > A side discussion about history might be interesting, but I'll suggest
> > that it should not really be a factor for the current discussion.
> > The reasons are:
> >
> > 1. It has a substantial installed base of use now.

> Reason enough for me.

> > 3. It is not generally recognized as causing any problems now.

> I concede that most people don't think lost DSNs are a significant problem.

Let's be careful with generalizations here. Depending on what you mean by 
"lost", I think there are significant problems and moreover ones we should
be trying to address.

However, I see no-MX fallback policies as having little if any impact in this
area. In fact I'll go further and say that if the goal is to improve the
reliability of email error reporting (and there is no doubt it is in trouble)
various things being proposed here would be in fact be actively
counterproductive in this regard.

				Ned

Date: Mon, 7 Apr 2008 11:39:01 -0700
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: What is the history of 2821 and implict MX?
Cc: John C Klensin <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>, Dave Crocker <[email-masked]>
Sender: [email-masked]

On 4/7/08 at 9:54 AM -0700, Dave Crocker wrote:

>John C Klensin wrote:
>
>>Someone would need to check with Craig Partridge...
>
>A side discussion about history might be interesting, but I'll 
>suggest that it should not really be a factor for the current 
>discussion.

So, I want to disagree with Dave and wish to consider some history, 
though Dave may have only been referring to the history leading up to 
974. I think the history leading up to 2821 might be important:

1. 974 did *not* have an "A fallback" rule at all. 974 is quite clear 
that the rule is, "If you can't find an MX, you should treat that as 
if you *did* find an MX where the preference was 0 and the name in 
the response was identical to the name queried. (That is, if you get 
back no MXs for a.example.org, then it should be equivalent to 
getting back a single MX of "a.example.org IN MX 0 a.example.org".) 
If this rule were in effect today, you *would* connect to a mail 
host's IPv6 address even if it had no MX records.

2. 2821 changed the rule and made explicit claims about looking for 
fallback A records. The question is, was that intentional? Did DRUMS 
intend to change the 974 rule in this regard, or was it trying to 
explain what the 974 rule entailed by using examples? So far, I can 
find nothing in the DRUMS archive to support the position that 2821 
intentionally changed the 974 rules.

If 2821 had preserved the 974 MX rule, we would not be having this 
discussion at all. The rule would be clear that the lack of the MX 
got you an implicit MX, and then you'd look up A and AAAA records as 
normal.

This entire argument reduces (for me) to answering this question: Did 
2821 intend to preserve the 974 rule? If DRUMS did *not* intend to 
change the 974 rule, then 2821's current text is an errant 
interpretation of 974 and should be fixed back to the 974 rule. If 
DRUMS *did* intend to change the rule to make it clear that 974 was 
all about backwards-compatibility for hosts that didn't have MX 
records, then there is a reasonable argument to be made for not doing 
so for AAAA.

My current feeling is that 2821bis should clarify that it intended 
the 974 rule. Yes, that gets us implicit MXs that point to AAAA 
hosts. Such is life.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Mon, 7 Apr 2008 19:53:33 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Cc: John C Klensin <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

Dave Crocker writes:
> A side discussion about history might be interesting, but I'll suggest 
> that it should not really be a factor for the current discussion.  
> The reasons are:
>
> 1. It has a substantial installed base of use now.

Reason enough for me.

> 3. It is not generally recognized as causing any problems now.

I concede that most people don't think lost DSNs are a significant problem.

Arnt

Date: Mon, 07 Apr 2008 09:54:17 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John C Klensin <[email-masked]>
CC: "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

John C Klensin wrote:
> --On Sunday, 06 April, 2008 22:44 -0400 "Robert A. Rosenberg"
> <[email-masked]> wrote:
>> Remember that the A-Fallback behavior is ONLY due to the
>> needs (back in the 1980s) 
...
> Someone would need to check with Craig Partridge, but I believe
> that "only" (or "ONLY") in the above is not strictly correct.
> It may have been the primary reason, but, no matter how often
> "only" is repeated a desire to permit minimal configurations
> did, I am quite sure, figure in to the equation.

A side discussion about history might be interesting, but I'll suggest that it 
should not really be a factor for the current discussion.  The reasons are:

1. It has a substantial installed base of use now.

2. There is a benefit in the feature, by virtue of reducing the effort to create 
and email receiving service, and in some environment the reduction is quite 
significant.

3. It is not generally recognized as causing any problems now.

What we need to do with this thread is end it.

d/
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 07 Apr 2008 09:38:45 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Michael Storz <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

Michael Storz wrote:
> my suggestion is in the same category as the try to sneak in semantics for
> the new protocol IPv6. If this is part of the goal of the current work,
> than I am allowed to make such a suggestion. As long as nobody tried to do
> that, I did not post anything.

The fact that someone makes a proposal that might be out of scope doesn't 
automatically make it ok for others to make proposals that might be out of scope.

Changing the installed base is not in scope, nevermind changing an installed 
base that has been solid and stable for 20 years and nevermind that it involves 
a change for which there is no demonstrated problem.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 07 Apr 2008 07:44:05 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

--On Sunday, 06 April, 2008 22:44 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

>...
> Remember that the A-Fallback behavior is ONLY due to the
> needs (back in the 1980s) of MTAs that were following the
> pre-MX rule that you found an MTA by looking at the FQDN
> A-Record group. 

Robert,  

Someone would need to check with Craig Partridge, but I believe
that "only" (or "ONLY") in the above is not strictly correct.
It may have been the primary reason, but, no matter how often
"only" is repeated a desire to permit minimal configurations
did, I am quite sure, figure in to the equation.

     john

Date: Mon, 7 Apr 2008 12:01:41 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IPV6: Where are we? (SMTP)
Cc: Hector Santos <[email-masked]>
Sender: [email-masked]

(More quoting than usual for me. Oh well.)

Hector Santos writes:
> I hope I can get an honest discussion here about IPv6 and hears IETF 
> and mail system overall thoughts on the subject.  I know it is all 
> subjective and will probably get different feelings here and among 
> other groups, but unless I am off base,  I think it might be healthy 
> to discuss it here if only to serve as an increasing awareness and to 
> help in the adoption process.
>
> Frankly, I did more in the last 3-4 days learning about the status of 
> IPv6 and from I am seeing, it seems to be the epitome or height of 
> IPv6 was around 2005

?

> and most of the work and implementation in outside the US.

Indeed.

> I have seen a few presentations that suggest or summarizes the 
> following highlights or key points:
> ...

(All true AFAICT.)

In my impression, the key status of IPv6 is that it's now viewed as 
unavoidable and not yet a profit opportunity.

A few years ago there were still lots of people who thought NAT would 
make IPv6 unnecessary, but I don't see that any more. Instead the news 
is a slow drip of little events like 
http://www.icann.org/announcements/announcement-04feb08.htm

Profitability hasn't arrived. There will be a day when people will pay 
extra for a software upgrade to get IPv6, or replace their little 
Linksys boxes with D-Link boxes that supports IPv6, but that day isn't 
yet. (Substitute other vendor names.)

> Other items I have learned that I have not seen discussed here or missed:
>
>   -  RFC 2874 or the A6 resource record.
>
>      "DNS Extensions to Support IPv6 Address Aggregation and
>       Renumbering"
>
> Why has this not been discussed as an alternative to AAAA?  It would 
> seem to me that A6 which has type value of 38 is a reasonable item to 
> be discussed  if we also going to discussed lookups for AAAA records.

A6 is dead. It was proposed, the proposal didn't carry through. (IMHO A6 
was a stupid misoptimisation.)

> Overall, I think IPv6 is an overwhelming concept which have not yet 
> put in enough time to consider for 2821bis, even if its just about 
> one part regarding IMPLICIT MX.

SMTP and IPv6 is in not common use, but it's old already. I got IPv6 in 
early 2003 and the software I used wasn't new then.

> Are we going to make the right decision?
>
> We know one thing - SMTP IPv4 operational behavior with a score of 
> years of time tested engineering behind it.
>
> I vote to NIX the whole IMPLICIT MX consideration for IPv6 for 2821bis 
> and I hope the IETF cogs and a champion among us can take us into the 
> next era with a new IETF chartered WG effort to see how to move SMTP 
> into the IPv6 era,  or even the feasibility of this effort.  Maybe 
> that was already done, I don't know.

It was.

> But it sure sounds to me, this is big mountain to climb for many.
>
> Of course, this is one person's opinion only.

And this answer is just my two cents.

Arnt

Date: Mon, 07 Apr 2008 11:49:48 +0200
From: Alessandro Vesely <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

Michael Storz wrote:
> [...] I definitely distinguish between internet and intranet
> issues. I use different methods and policies to accept and deliver email
> in our intranet than with the internet. But the standard should be about
> the internet.

There won't be great opportunities to find good tested software that 
works according to some obscure non-standard intranet messaging 
protocol, though.

Date: Mon, 07 Apr 2008 04:57:01 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Michael Storz <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

Hector Santos wrote:

> I say leave well enough alone and if you want to invent NEW expectations, 
> then you MUST raise the bar from what is normally done and you can only 
> do this with NEW indicators and state values.
> 
> is IPv6 it?  From a legal standpoint, I say yes.
> 
> Is DKIM it?  From a legal standpoint, I say yes.
> 
> Is Port 587 it?  From a legal standpoint, I saw yes.
> 
> But not a legacy system like IPv4 with no indicators, I say no.

Michael,

I will add to this a SMTP session with a HELO/EHLO domain literal that 
is in the IPv6 format.

This would provide legal ground to do something that is NEW and 
acceptable with new provisions in the new standards.  Since the SMTP 
client raised the bar (open the door) by showing something new, it 
provides the opportunity for a new level of actions a receiver can take.

So to me, if you want to propose if a SMTP client is showing a IPv6 
domain literal for the EHLO/HELO, then the idea of not doing IMPLICIT MX 
  is 100% acceptable to me.

The same applies in a POST SMTP logic where the 822 headers have DKIM 
headers.  This raises the bar the CLIENT has put in himself into and can 
not claim anything against new standards that with with the new 
information provided by the client.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 07 Apr 2008 04:40:31 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Michael Storz <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

Michael Storz wrote:

> The longer I follow this discussion and think about it, I am feeling that
> the cleanest solution would be to deprecate implicit MX even for IPv4. In
> the meantime I am convinced the implizit MX is a defect of RFC 2821. It
> was introduced more than 20 years ago as a workaround to get the routing
> via explizit MX RRs running.
> 
>
 > snip
> 
> Therefore from an operational and liability standpoint it is time to
> deprecate the implizit MX RR. You had the guts to the deprecation the
> source routes some years back. Now have the guts to deprecate the implizit
> MX RR.

Well, from a liability standpoint, in my view, eliminating the IMPLICIT 
MX can certainly be viewed as the WRONG direction.

Since 1986, when push came to shove, the US ECPA provided the court 
precedence argument for legal claims of Censorship, Malpractice and 
Tortious Interference (interrupting your business) where USER 
EXPECTATIONS where not met and that included the expected posting or 
delivery of mail and it can't be done, a notification was required.  The 
2821 level reject satisfies this notification requirement and so does 
the problematic accept-bounce post smtp action. In the US, this has been 
relaxed in 2000 to satisfy the Mommy (child porn) Market and to also 
encourage the development of AVS systems without legal ramifications. 
However, there is still an expectation of delivery of mail and a system 
can be held accountable for unwarranted intentional lost.   This comes 
under the "Good Samaritan" provisions of the 2000 law.  Of course, no 
one normally hear of this thus the "Myth of no liability" because there 
is generally usually no money in it and you must prove harm was done.

So where does mal-practice comes?  Doing something that goes against 
the standard and expected practice, norm and what experts of the 
industry would not normally do - hence the definition of MalPractice.

I say leave well enough alone if you want to invent NEW expectations, 
then you MUST raise the bar from what is normally done and you can only 
do this with NEW indicators and state values.

is IPv6 it?  From a legal standpoint, I say yes.

Is DKIM it?  From a legal standpoint, I say yes.

Is Port 587 it?  From a legal standpoint, I saw yes.

But not a legacy system like IPv4 with no indicators, I say no.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 7 Apr 2008 10:35:01 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: [email-masked]
cc: SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

On Mon, 7 Apr 2008, Dave Crocker wrote:

>
>
>
> Michael Storz wrote:
> > The longer I follow this discussion and think about it, I am feeling that
> > the cleanest solution would be to deprecate implicit MX even for IPv4.
>
>
> It's difficult to imagine a posting that could better demonstrate the disconnect
> some participants have from the goal of the current work.
>
> d/
>

Dave,

my suggestion is in the same category as the try to sneak in semantics for
the new protocol IPv6. If this is part of the goal of the current work,
than I am allowed to make such a suggestion. As long as nobody tried to do
that, I did not post anything.

Regards,
Michael Storz

Date: Mon, 7 Apr 2008 10:27:12 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: Rudy Nedved <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

On Mon, 7 Apr 2008, Rudy Nedved wrote:

> Michael,
>
> I agree with your assessment in the context of a mail entity which is
> worried about delivering mail to potentially 100,000 or more domains.
>
> These high value e-mail servers should have less to worry about and
> less to agree to. It seems like implicit MX records should be dropped.
>
> Alas, I don't agree that these rules should be applied to a mail entity
> which worries about delivery mail to one domain, inside of a company,
> protected and/or isolated (air gap networks) from the internet.
>
> We need a 2 tier model with 2 sets of requirements and expectations.
>
> -Rudy

Rudy,

tha's fine with me. I definitely distinguish between internet and intranet
issues. I use different methods and policies to accept and deliver email
in our intranet than with the internet. But the standard should be about
the internet.

Michael Storz

Date: Mon, 07 Apr 2008 00:53:54 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Michael Storz <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: deprecate implicit MX even for IPv4
Sender: [email-masked]

Michael Storz wrote:
> The longer I follow this discussion and think about it, I am feeling that
> the cleanest solution would be to deprecate implicit MX even for IPv4.

It's difficult to imagine a posting that could better demonstrate the disconnect 
some participants have from the goal of the current work.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 7 Apr 2008 09:40:45 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: deprecate implicit MX even for IPv4
Sender: [email-masked]

The longer I follow this discussion and think about it, I am feeling that
the cleanest solution would be to deprecate implicit MX even for IPv4. In
the meantime I am convinced the implizit MX is a defect of RFC 2821. It
was introduced more than 20 years ago as a workaround to get the routing
via explizit MX RRs running.

At the time source routes were deprecated the use of implizit MX should
have been deprecated too, because at that time the model about routing was
the usage of MX RRs and not A RRs and source routes.

Today email is a mission critical application. More and more legal
implications about handling of emails are coming up. For example it is
clear that the administrator is responsible and liable for an email after
it has been accepted by the MTA he is manageing at least by german law.
>From thi it follows , that there will be a time in the future were you
have to process double bounces.

Just imagine a hypothetical case, where a machine is not working properly,
heating up till it burns. Imagine futher, this machine sent a warning
email to the admin of the maschine. But beause the email was sent to an
unknown user, the DSN now sits in your queue and waits until it times out,
because there is now MX-Record.

Now, what will the court do? Will you as the admin of the email server get
some part of the assigement of obligation for the bunrt maschine (and
maybe for the burnt house)? I do not know.

But what position will you have, if implizit MX is not allowed anymore.
Your MTA would reject the email immediately because now it is required to
specify a MX RR for the delivery of the DSN. Not doing this is the sole
error of the admin of the machine. From a legal standpoint, I think you
will have a much better position.

Over the weekend I run a script to process all the domains of the 'mail
from' addresses, my dual-stack MTAs got via IPv4 (the other statitic about
received email I sent already was about IPv6).

There were 155583 different domains, 6311 had no MX RR, but only an A RR
(4 had in addition an AAAA RR). This means 4 % of the domains were
reachable by implizit MX only. If you compare this with my statistic about
were we really send emails to, this was 1 %. My interpretation of this
discrepancy is, that a big part of the this A-only RRs are misconfigured
systems. I tested some of these domains, and a lot did not run an email
server.

Therefore from an operational and liability standpoint it is time to
deprecate the implizit MX RR. You had the guts to the deprecation the
source routes some years back. Now have the guts to deprecate the implizit
MX RR.

Michael Storz

Date: Mon, 07 Apr 2008 02:57:17 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC:  [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
> I agree with your statements. For historical reasons we MUST allow use 
> of the A records in the FQDN IN group (since no-one has had the guts to 
> ramrod an RFC that says "Enough is Enough. MX has been in existence for 
> 20 years and that is enough time to have gotten off your rumps and added 
> MX records pointing at the A records that define your IPv4 MTAs. Thus as 
> of this Flag-Day date the ability to access an IPv4 MTA via its A record 
> instead of having a MX record point at that A record is forbidden and is 
> no longer supported").

Well, for me, practically speaking, it would have to be done as a 
deprecated option.  Still make it optional and allow the admin to decide 
when to turn it off.  So I guess specs will will eventually say "MAY?"

I would be interested in hearing how other MTA deal with implicit MX 
logic. For our MTA, it has a "1 Shot Attempt" only and that has worked 
for us.  I wonder if others have similar logic.

> The fact we allow MX-less MTAs to be accessed via an A record is NOT a 
> valid excuse to allow AAAA records to be used in this case. While that 
> WAS an excuse to allow the A record to be used (ignoring the question of 
> if this excuse is still valid), the existence of the MX record (and 
> [all-most?] 100% support for the MX record in DNS code and 100% support 
> for the MX record in the code with IPv6 support) that predates the 
> existence of IPv6, means that it should be required to exist and point 
> at the AAAA records that belong to IPv6 IPN monitoring MTAs. The use of 
> AAAA records to locate an IPv6 MTA does NOT predate the existence of the 
> MX and thus should be forbidden.

In principal I agree with your Robert, I just not convinced if its best 
decision.

Remember, I think it is safe to say that regardless of the client type, 
IPv4 or IPv6, it still needs to follow the requirement for a valid 
x821.Mail From return path.

Up to now, although there are CBV systems which attempt to verify the 
validity of the return path, whether its fake or not,  there haven't 
been, that I am aware of, any solid means of reliably and efficiently 
verifying the return path.

We been using SPF and SENDERID and that works up to a point, but 
overall, my main point is that is that the return path still needs to be 
valid.

So to me, the question really translates to how much "Humph" do we want 
to put into the return path validity idea.

Some people here think, that the return path validity is only important 
when you need it - i.e. come bounce time and not before that.

> Thus the resolution logic is as follows.
> 
> 1) Look for a MX. If found go to step 3. If not found set a NO-MX flag.
> 2) Pull the FQDN IN Group by acting as if a FQDN MX 0 FQDN was found in 
> step 1.
> 3) Process the IN A/AAAA records in order (within MX Priority order).
> 4) For each A/AAAA selected in step 3, check for the NO-MX flag and if 
> found ignore the record if it is an AAAA and immediately go to step 7.
> 5) Since NO-MX is not on, we found a real MX so process the A/AAAA as at 
> present. ie: If an A, check if we have IPv4 Stack support, if an AAAA 
> check for IPv6 Stack support. Lack of support goes to step 7.
> 6) Attempt to connect to the A/AAAA designated IPN. If we get a 
> connection then process based on whatever return code we get (which may 
> mean going to the next IPN in the list [step 3] or giving up).
> 7) The current A/AAAA record is no good, If this is not the end of the 
> A/AAAA list, go back to step 3 and process the next IPN in the list. 
> Otherwise go into the "No Usable IPNs" error state and deal with it 
> appropriately.
> 
> NOTE: This method keeps the status quo for the case where ALL the MTAs 
> for the FQDN are IPv4 MTAs (with or without a FQDN MX). It only says 
> that MX-less FQDNs are serviced by those A records in the FQDN IN group 
> and that any AAAA records found there are to be ignored.

I have to re-read the above more, but I think it sounds ok to me.

Overall, to me it is this:

I'm going to use MAX to represent a A or AAAA record.

     MAXLIST = GET_MX(domain)

     if MAXLIST has records then
         for each MAX in MAXLIST
            attempt to send mail to MAX
     else
         MAX = GET_MAX(domain)
         if MAX is OK then
            attempt to send mail to MAX
     endif

I think what you are arguing for or against is this:

     if MXList has records then
         for each MAX in MXList
             attempt to send mail to MAX
     else
         //--------- NEW LOGIC -----------
         if I am IPv6 only then
            MAX = GET_AAAA(domain)
         otherwise
            MAX = GET_A(domain)
         //--------- ROBERT LOGIC -----------

         if MAX is OK then
              attempt to send mail to MAX
     endif

Would this make sense?

Robert, maybe I am off based but I am getting the impressive that we 
really don't know what all the issues.  I say that because a lot will 
define on how IPv6 is installed on the machine.

For example, the machine IPv6 layer software might be tunneling and/or 
working with a translator unbeknowst to the SMTP client and may return 
the A record or AAAA record for you based on what is available.

If this is true, and based on my readings, there are implementations 
like this, then this would important in how SMTP with IPv6 semantics 
need to be written.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 07 Apr 2008 02:25:38 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC:  [email-masked]
Subject: Re: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
> At 02:51 -0400 on 04/06/2008, Hector Santos wrote about Re: How does 
> SMTP IPv4 and IPv6 work together:
> 
>> So this is why I believe that the only text that is necessary at this
>> point for 2821bis is:
>>
>>       IPv6 senders connecting to IPv4 systems MUST be aware that IPv4
>>       systems are ignorant of IPv6 technology and therefore SHOULD
>>       make it possible to comply with IPv4 SMTP expectations to allow
>>       for responses.  This implies that IPv6 senders sending mail to
>>       IPv6 SHOULD|MUST have explicit MX records or implicit MX A
>>       record at a minimum.
> 
> I have removed all of the rest of your message and left only the above. 
> Make that SHOULD|MUST just SHOULD (and add "pointing at A and and 
> optionally AAAA records" after the "explicit MX records" clause) and the 
> issue is solved since only these combinations are valid:
> 
> Should that "sending mail to IPv6" not read "sending mail to IPv4"?

Yes, it was a typo, corrected with your suggested changes:

      IPv6 senders connecting to IPv4 systems MUST be aware that IPv4
      systems are ignorant of IPv6 technology and therefore SHOULD
      make it possible to comply with IPv4 SMTP expectations to allow
      for responses.  This implies that IPv6 senders sending mail to
      IPv4 SHOULD have explicit MX records pointing at A and
      optionally AAAA records.

I am not sure I like the last sentence since the AAAA record is 
meaningless to IPv4 only aware SMTP nodes. :-)

How about:

      .... This implies that IPv6 senders sending mail to
      IPv4 SHOULD have A records resulting from explicit MX
      queries.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 07 Apr 2008 02:13:58 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC:  [email-masked]
Subject: Re: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

Robert A. Rosenberg wrote:

> My error in not stating my real question but assuming the caveat by 
> implication. To reword my query (*CAPS* are the omitted caveat):
> 
> What justification do you offer to allow an IPv6 MTA to run *VIA IPv6* 
> without an EXPLICATE MX record? IOW: If it is dual stack and willing to 
> use IPv4 then just allow the A-Fallback but why allow AAAA-Fallback to 
> allow it to talk via IPv6? Note: I was assuming that an EXPLICATE MX 
> would point not only to all the needed AAAA records but also the A 
> records that would be used by a IPv4-Only Stack in Fallback mode (ie: 
> Since the existence of the MX precludes A-Fallback , the A records MUST 
> be referenced by the MX).
 >
> I guess I will need to be more explicate in the future and avoid 
> unstated assumptions <g>.

Side question: Are you using term EXPLICATE intentional?  because I 
think everyone is on sync using "Explicit" vs "Implicit". Implicit MX is 
the term used in 2821.

Anyway, 99% of the time I don't judge by POLICY.  I used persistent 
protocol logic first, then use POLICY if there is particular reason whey 
one design over another may be deemed problematic. It could be an 
ethical engineering issue as well. i.e., I will never open an "Pandora 
Box" design. I wouldn't be able to sleep if I did.

That said, we have a IPv4 SMTP working model for the last 20+ years.  By 
extension, IMV, any reasonable engineer would model IPv6 in the same 
way.  Another way to say that is if you are attempting to fit IPv6 into 
the IPv4 world, then it would be common sense that IPv6 will behave with 
all the expectations of a IPv4 model.  In other words, IPv6 should not 
alter IPv4  behavior.

That would be my justification from an engineering standpoint why an 
IPv6 client "may" be able to do a AAAA lookup, simply because an IPv4 
client can do a A lookup.  So this means, the IPv6 MTA does not have to 
have a MX record.

Now, is there a new policy reason or a new technical reason why we 
should extend the IPv4 "implicit MX" design to IPv6?

Maybe, maybe not.  What would be the policy or technical reasons to not 
extend the same protocol logic we have not for IPv4 to IPv6?

Well, I did see some IPv6 field testing presentations that suggest that 
doing AAAA lookups are "Bad".  Its not efficient and there are DNS 
servers that are yielding erroneous results.

Is that reason enough?  Its interesting but I can't see that is reason 
enough. Not without more proof and confirmation.  Maybe there are other 
factors involved here.

I did sense the feeling from several postings that some would not want 
AAAA lookups because of the predicted world of millions of small IPv6 
devices on consumer machines, ones that are predicted to be sending out 
Email Reports or do mucho Call Home functionality.   To me, thats fine, 
as long as the Return Path is valid - SMTP 2821 is not violated.

Is there a policy reason based on Security?

Well, I think the Crockers and Levines think so.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 06 Apr 2008 22:42:36 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: Implicit MX decisions
Sender: [email-masked]

John C Klensin wrote:
> Could I ask that anyone who has expressed a position clearly, or
> even fairly clearly, just stop.  I think you can be assured that
> you have been heard.  

John, thanks for posting this.  It's good to see how well your request is being 
heeded.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 7 Apr 2008 00:48:17 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

At 02:51 -0400 on 04/06/2008, Hector Santos wrote about Re: How does 
SMTP IPv4 and IPv6 work together:

>  > What justification do you offer to allow an IPv6 MTA to run without an
>  > EXPLICATE MX record?
>
>I have started in my proposed in multiple messages and I repeated it
>above what I believe is the practical solution here and minimal text for
>2821bis without going overboard in trying something we are not sure
>about yet - for new systems using new technology that WANT to continue
>to operate and communicate in a IPv4, the MUST|SHOULD use a MX and/or
>implicit MX A record in order to be compatible with current expectations.

My error in not stating my real question but assuming the caveat by 
implication. To reword my query (*CAPS* are the omitted caveat):

What justification do you offer to allow an IPv6 MTA to run *VIA 
IPv6* without an EXPLICATE MX record? IOW: If it is dual stack and 
willing to use IPv4 then just allow the A-Fallback but why allow 
AAAA-Fallback to allow it to talk via IPv6? Note: I was assuming that 
an EXPLICATE MX would point not only to all the needed AAAA records 
but also the A records that would be used by a IPv4-Only Stack in 
Fallback mode (ie: Since the existence of the MX precludes A-Fallback 
, the A records MUST be referenced by the MX).

I guess I will need to be more explicate in the future and avoid 
unstated assumptions <g>.

Date: Mon, 7 Apr 2008 00:55:45 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 23:55 -0700 on 04/05/2008, Russ Allbery wrote about Re: current 
usage of AAAA implicit MX?:

>It's not that it's technically difficult so much as that it's dubious from
>a layering perspective, at least from where I sit.  It requires I
>introduce IPv6-specific code (and hence ifdefs for systems without IPv6
>constants and so forth) into an application that otherwise would not need
>any and would be entirely stack-agnostic.

OOPS. I was not considering the case where the code was being 
tailored at assembly time. Looking at my flow I see only 1 (2 if you 
want to ALWAYS set the flag in step 2) place where conditional code 
needs to be inserted. This is in step 3 where the Test Flag and IPN 
code would only get inserted IF IPv6 support is being generated.

Date: Mon, 7 Apr 2008 00:35:11 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

At 02:51 -0400 on 04/06/2008, Hector Santos wrote about Re: How does 
SMTP IPv4 and IPv6 work together:

>So this is why I believe that the only text that is necessary at this
>point for 2821bis is:
>
>       IPv6 senders connecting to IPv4 systems MUST be aware that IPv4
>       systems are ignorant of IPv6 technology and therefore SHOULD
>       make it possible to comply with IPv4 SMTP expectations to allow
>       for responses.  This implies that IPv6 senders sending mail to
>       IPv6 SHOULD|MUST have explicit MX records or implicit MX A
>       record at a minimum.

I have removed all of the rest of your message and left only the 
above. Make that SHOULD|MUST just SHOULD (and add "pointing at A and 
and optionally AAAA records" after the "explicit MX records" clause) 
and the issue is solved since only these combinations are valid:

  1) MX with a IPv4 and IPv6 FQDN listed on the RHS (ie: After 
resolving the IN records there should be at least one A record and 
one AAAA record). This allows use of IPv4 to send to IPv4 MTAs and 
use of either IPv4 or IPv6 to send to a IPv6 MTA (IPv4 only when Dual 
Stack).
  2) MX with a IPv4 FQDN listed on the RHS (forces all incoming 
traffic to be IPv4).
  3) No MX but at least one A for the FQDN.

Should that "sending mail to IPv6" not read "sending mail to IPv4"?

Date: Mon, 7 Apr 2008 00:14:10 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

At 20:54 -0400 on 04/06/2008, Hector Santos wrote about Re: Minor is. 
It's not a pardigm change:

>  >> John C Klensin asked:
>  >>
>>>  So what are you suggesting?
>
>Robert A. Rosenberg wrote:
>
>>  1) Require that any IPv6 MTA MUST be pointed to by an EXPLICATE MX record.
>
>Translation:
>
>EXPLICIT MX - it must have a MX record which exposes mail host A records.

I agree with your translation if by this you mean that IF there is a 
IPv6 MTA that is supposed to be supporting that FQDN, this support 
must be signified by listing the AAAA and A records of all the IPv6 
and IPv4 MTAs for that FQDN. Listing means pointing via the MX RHS to 
FQDNs of IN groups that contain the relevant A and AAAA records.

>
>>  2) Require that any IMPLICATE MX record that is built due to the absence
>>  of an EXPLICATE MX record follow the EXPLICATE MX RFC 3484 rules for an
>>  IPv4-ONLY stack (ie: Ignore all AAAA records found for foo.example.com
>>  IN A/AAAA).
>
>This is not consistent with #1 - mandating a successful MX record.

WHAT? If a MX is found, this meets my rule as quoted above. If there 
is no MX, then the FQDN MX 0 FQDN that you pretend to have found 
should, by my rules, cause the FQDN IN that gets referenced to be 
treated as if it is composed ONLY of A records (ie: Any AAAA records 
that are found should have their existence ignored just like an 
IPv4-only Stack would ignore them AS DOCUMENTED for this condition in 
RFC 3484).

>  > This simple set of rules allows A-Fallback to continue to work by simply
>>  requiring that an IMPLICATE MX that is created is treated the Stack as
>>  if it were an IPv4-Only Stack even when it is actually a Dual Stack or
>>  an IPv6-Only stack.
>
>OK, it sounds to me that what you are advocating is that RESOLVERS learn
>how to do an inherent "Implicit MX" default logic for all MX queries.
>
>Is that a correct statement?

No. The MTA asks for the MX. It gets told that there is no MX so it 
asks for the FQDN IN group and gets a mixture of A and AAAA (or if 
you need to ask separately for A and AAAA records, just ask for A 
records). Any AAAA records that get returned are ignored and only the 
A records are used. It is my understanding that it is the job of the 
MTA to request the A records in the absence of a MX not the job of 
the resolver to return A and AAAA records to a MX request in the 
absence of an MX. Even if the resolver DOES take it upon itself to 
return A/AAAA records in the absence of an MX record, it is not that 
hard for the MTA to ignore any returned AAAA records that get 
returned in response to a MX request.

Date: Sun, 6 Apr 2008 23:36:44 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

--======_-1004578032=_mr======
Content-Type: multipart/alternative; boundary="======_-1004578032=_ma======"

--======_-1004578032=_ma======
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 21:09 -0400 on 04/06/2008, Hector Santos wrote about Re: Minor is. 
It's not a pardigm change:

>Hector Santos wrote:
>>
>>The different here from what I am reading is that there seems to be 
>>this notion that the DNS resolver is always independent from the 
>>SMTP and its results drive the SMTP client - i.e, the SMTP client 
>>is not in the picture.  I don't believe that concept can be 
>>presumed to be always true.
>
>Clarification because DNS results always drives an SMTP client
>
>What I meant is that a MX query returning NO RECORDS is what drives 
>the SMTP to consider using a Implicit MX concept.
>
>If the resolver always return a MX query result, then the SMTP 
>client will never have any control here.  I don't think using the 
>zero preference is a reliable indicator to represent a raw A record 
>for the domain.

I agree with your statements. For historical reasons we MUST allow 
use of the A records in the FQDN IN group (since no-one has had the 
guts to ramrod an RFC that says "Enough is Enough. MX has been in 
existence for 20 years and that is enough time to have gotten off 
your rumps and added MX records pointing at the A records that define 
your IPv4 MTAs. Thus as of this Flag-Day date the ability to access 
an IPv4 MTA via its A record instead of having a MX record point at 
that A record is forbidden and is no longer supported").

The fact we allow MX-less MTAs to be accessed via an A record is NOT 
a valid excuse to allow AAAA records to be used in this case. While 
that WAS an excuse to allow the A record to be used (ignoring the 
question of if this excuse is still valid), the existence of the MX 
record (and [all-most?] 100% support for the MX record in DNS code 
and 100% support for the MX record in the code with IPv6 support) 
that predates the existence of IPv6, means that it should be required 
to exist and point at the AAAA records that belong to IPv6 IPN 
monitoring MTAs. The use of AAAA records to locate an IPv6 MTA does 
NOT predate the existence of the MX and thus should be forbidden.

As to support of a IPv6 MTA (either via an IPv6-Only or Dual 
IPv4/IPv6 stack), we mandate that the IPv6 MTAs (and any IPv4 MTAs 
that share the IPv6 MTA's FQDN) be pointed to by a MX.

Thus the resolution logic is as follows.

1) Look for a MX. If found go to step 3. If not found set a NO-MX flag.
2) Pull the FQDN IN Group by acting as if a FQDN MX 0 FQDN was found in step 1.
3) Process the IN A/AAAA records in order (within MX Priority order).
4) For each A/AAAA selected in step 3, check for the NO-MX flag and 
if found ignore the record if it is an AAAA and immediately go to 
step 7.
5) Since NO-MX is not on, we found a real MX so process the A/AAAA as 
at present. ie: If an A, check if we have IPv4 Stack support, if an 
AAAA check for IPv6 Stack support. Lack of support goes to step 7.
6) Attempt to connect to the A/AAAA designated IPN. If we get a 
connection then process based on whatever return code we get (which 
may mean going to the next IPN in the list [step 3] or giving up).
7) The current A/AAAA record is no good, If this is not the end of 
the A/AAAA list, go back to step 3 and process the next IPN in the 
list. Otherwise go into the "No Usable IPNs" error state and deal 
with it appropriately.

NOTE: This method keeps the status quo for the case where ALL the 
MTAs for the FQDN are IPv4 MTAs (with or without a FQDN MX). It only 
says that MX-less FQDNs are serviced by those A records in the FQDN 
IN group and that any AAAA records found there are to be ignored.
--======_-1004578032=_ma======
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: Minor is. It's not a pardigm
change</title></head><body>
<div>At 21:09 -0400 on 04/06/2008, Hector Santos wrote about Re: Minor
is. It's not a pardigm change:</div>
<div><br></div>
<blockquote type="cite" cite>Hector Santos wrote:
<blockquote type="cite" cite><br>
The different here from what I am reading is that there seems to be
this notion that the DNS resolver is always independent from the SMTP
and its results drive the SMTP client - i.e, the SMTP client is not in
the picture.&nbsp; I don't believe that concept can be presumed to be
always true.</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
Clarification because DNS results always drives an SMTP client<img
src="cid:p06240806c41f3c5b8907@[192.168.1.11].1.0"><br>
<br>
What I meant is that a MX query returning NO RECORDS is what drives
the SMTP to consider using a Implicit MX concept.<br>
</blockquote>
<blockquote type="cite" cite>If the resolver always return a MX query
result, then the SMTP client will never have any control here.&nbsp; I
don't think using the zero preference is a reliable indicator to
represent a raw A record for the domain.</blockquote>
<div><br></div>
<div>I agree with your statements. For historical reasons we MUST
allow use of the A records in the FQDN IN group (since no-one has had
the guts to ramrod an RFC that says &quot;Enough is Enough. MX has
been in existence for 20 years and that is enough time to have gotten
off your rumps and added MX records pointing at the A records that
define your IPv4 MTAs. Thus as of this Flag-Day date the ability to
access an IPv4 MTA via its A record instead of having a MX record
point at that A record is forbidden and is no longer
supported&quot;).</div>
<div><br></div>
<div>The fact we allow MX-less MTAs to be accessed via an A record is
NOT a valid excuse to allow AAAA records to be used in this case.
While that WAS an excuse to allow the A record to be used (ignoring
the question of if this excuse is still valid), the existence of the
MX record (and [all-most?] 100% support for the MX record in DNS code
and 100% support for the MX record in the code with IPv6 support) that
predates the existence of IPv6, means that it should be required to
exist and point at the AAAA records that belong to IPv6 IPN monitoring
MTAs. The use of AAAA records to locate an IPv6 MTA does NOT predate
the existence of the MX and thus should be forbidden.</div>
<div><br></div>
<div>As to support of a IPv6 MTA (either via an IPv6-Only or Dual
IPv4/IPv6 stack), we mandate that the IPv6 MTAs (and any IPv4 MTAs
that share the IPv6 MTA's FQDN) be pointed to by a MX.</div>
<div><br></div>
<div>Thus the resolution logic is as follows.</div>
<div><br></div>
<div>1) Look for a MX. If found go to step 3. If not found set a NO-MX
flag.</div>
<div>2) Pull the FQDN IN Group by acting as if a FQDN MX 0 FQDN was
found in step 1.</div>
<div>3) Process the IN A/AAAA records in order (within MX Priority
order).</div>
<div>4) For each A/AAAA selected in step 3, check for the NO-MX flag
and if found ignore the record if it is an AAAA and immediately go to
step 7.</div>
<div>5) Since NO-MX is not on, we found a real MX so process the
A/AAAA as at present. ie: If an A, check if we have IPv4 Stack
support, if an AAAA check for IPv6 Stack support. Lack of support goes
to step 7.</div>
<div>6) Attempt to connect to the A/AAAA designated IPN. If we get a
connection then process based on whatever return code we get (which
may mean going to the next IPN in the list [step 3] or giving
up).</div>
<div>7) The current A/AAAA record is no good, If this is not the end
of the A/AAAA list, go back to step 3 and process the next IPN in the
list. Otherwise go into the &quot;No Usable IPNs&quot; error state and
deal with it appropriately.</div>
<div><br></div>
<div>NOTE: This method keeps the status quo for the case where ALL the
MTAs for the FQDN are IPv4 MTAs (with or without a FQDN MX). It only
says that MX-less FQDNs are serviced by those A records in the FQDN IN
group and that any AAAA records found there are to be ignored.</div>
</body>
</html>
--======_-1004578032=_ma======--
--======_-1004578032=_mr======
Content-Id: <p06240806c41f3c5b8907@[192.168.1.11].1.0>
Content-Type: image/gif; name="!3a-) Happy.gif"
 ; x-mac-type="47494666"
 ; x-mac-creator="474B4F4E"
Content-Disposition: attachment; filename="!3a-) Happy.gif"
Content-Transfer-Encoding: base64

--======_-1004578032=_mr======--

Date: Sun, 6 Apr 2008 22:44:55 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 20:44 -0400 on 04/05/2008, Hector Santos wrote about Re: current 
usage of AAAA implicit MX?:

>Consider a world where there is only IPv6 and everyone is talking IPv6
>only.  I believe we will have the same issues with missing MX record and
>a implicit MX AAAA lookup behavior for the domain.

Only if we do NOT mandate NOW that a MX record is REQUIRED to 
locate/access an IPv6 MTA. Remember that the A-Fallback behavior is 
ONLY due to the needs (back in the 1980s) of MTAs that were following 
the pre-MX rule that you found an MTA by looking at the FQDN A-Record 
group. Once the use of MX records become the standard method of 
locating/accessing MTAs the direct use of A Records was (or rather 
should have been) depreciated.
>
>The only way that AAAA fallback can be eliminated, is if we use the
>opportunity for an IPv6 only system to mandate proper MX record.

Since the MX record exists NOW (and predates IPv6) there is NO NEED 
to EVER use an AAAA record to directly find an MTA and we should make 
the requirement to have a MX for IPv6-Only and Mixed IPv4/IPv6 MTAs a 
MUST. If we put this off, we will just get into the same "can not 
disallow fall-back" mess as we have now with MX-less A records.

Note that this keeps the current status quo in that we are NOT 
requiring an MX for IPv4-Only MTAs although a SHOULD (or MAY?) clause 
could be included to discourage this practice and advice admins to 
start to add any missing MXs since if/when they add an IPv6 MTA for 
the FQDN (going to dual stack) they are going to have to add the MX 
at that time (so get ready now).

Date: Sun, 06 Apr 2008 22:17:11 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: IPV6: Where are we? (SMTP)
Sender: [email-masked]

I hope I can get an honest discussion here about IPv6 and hears IETF and 
mail system overall thoughts on the subject.  I know it is all 
subjective and will probably get different feelings here and among other 
groups, but unless I am off base,  I think it might be healthy to 
discuss it here if only to serve as an increasing awareness and to help 
in the adoption process.

Frankly, I did more in the last 3-4 days learning about the status of 
IPv6 and from I am seeing, it seems to be the epitome or height of IPv6 
was around 2005 and most of the work and implementation in outside the US.

I have seen a few presentations that suggest or summarizes the following 
highlights or key points:

   - the growth rate of IPv6 address assigned is higher in the US,

   - but the usage of it is very low in the US.

   - most of the work is in academia, startups or vendor R&D labs,

   - while many of the big brand name vendors have IPv6 web sites,
     they are not marketing it or effectively put it on the back
     burner.  Points were made that the clients and infrastructure
     is simply not ready and other points where made that there
     is a higher overhead with an IPv6/AAAA framework.

   - However, other points were made that ISP are also adopting
     it to help with addressing and bandwidth issues and they
     feel comfortable that this is acceptable with their market
     of customers.  A point was made that since IPv6 is backward
     compatible, this has worked very well for ISPs.  I think they
     meant that they have IPv6 to IPv4 tunneling software that is
     high quality and works very well for them.

   - Only a few SMTP servers support IPv6.  Some of the current
     name brands require a recompile to support IPv6 sockets.

   - I saw a point that doing a A first, then AAAA lookup for
     SMTP clients was discovered to be more OPTIMAL because
     there is a high failure rate of AAAA records.  Some of
     this failure was pointed at buggy DNS server which may
     report erroneous SERVFAIL errors when a AAAA query
     is done first, but not when a A record is done first.

   - I saw a related point which suggest that the socket level
     2 function getaddrinfo() be "hacked" or changed to avoid
     doing AAAA requests.  Overall, the recommendation was
     to avoid doing AAAA requests as much as you can.  I was
     not sure if this was for VISTA only or a general
     recommendation.

   - Another related point is how doing a AAAA or A lookup
     will be masked by the getaddrinfo() request. So that
     might alter some logic in what is expected or not
     expected in SMTP.

Other items I have learned that I have not seen discussed here or missed:

   -  RFC 2874 or the A6 resource record.

      "DNS Extensions to Support IPv6 Address Aggregation and
       Renumbering"

Why has this not been discussed as an alternative to AAAA?  It would 
seem to me that A6 which has type value of 38 is a reasonable item to be 
discussed  if we also going to discussed lookups for AAAA records.

Overall, I think IPv6 is an overwhelming concept which have not yet put 
in enough time to consider for 2821bis, even if its just about one part 
regarding IMPLICIT MX.  Are we going to make the right decision?

We know one thing - SMTP IPv4 operational behavior with a score of years 
of time tested engineering behind it.

I vote to NIX the whole IMPLICIT MX consideration for IPv6 for 2821bis 
and I hope the IETF cogs and a champion among us can take us into the 
next era with a new IETF chartered WG effort to see how to move SMTP 
into the IPv6 era,  or even the feasibility of this effort.  Maybe that 
was already done, I don't know.  But it sure sounds to me, this is big 
mountain to climb for many.

Of course, this is one person's opinion only.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 06 Apr 2008 21:09:45 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC:  [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

Hector Santos wrote:
> 
> The different here from what I am reading is that there seems to be this 
> notion that the DNS resolver is always independent from the SMTP and its 
> results drive the SMTP client - i.e, the SMTP client is not in the 
> picture.  I don't believe that concept can be presumed to be always true.

Clarification because DNS results always drives an SMTP client :-)

What I meant is that a MX query returning NO RECORDS is what drives the 
SMTP to consider using a Implicit MX concept.

If the resolver always return a MX query result, then the SMTP client 
will never have any control here.  I don't think using the zero 
preference is a reliable indicator to represent a raw A record for the 
domain.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 06 Apr 2008 20:54:06 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC:  [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

>> John C Klensin asked:
 >>
>> So what are you suggesting?

Robert A. Rosenberg wrote:

> 1) Require that any IPv6 MTA MUST be pointed to by an EXPLICATE MX record.

Translation:

EXPLICIT MX - it must have a MX record which exposes mail host A records.

> 2) Require that any IMPLICATE MX record that is built due to the absence 
> of an EXPLICATE MX record follow the EXPLICATE MX RFC 3484 rules for an 
> IPv4-ONLY stack (ie: Ignore all AAAA records found for foo.example.com 
> IN A/AAAA).

This is not consistent with #1 - mandating a successful MX record.

First, the term used in 2821 is implicit MX.

I always thought it was a convoluted description which walks, smells and 
talks as if there is a presumption the SMTP client has its own DNS 
resolver or a API/OS DNS resolver that will perform this "IMPLICIT MX" 
concept for the SMTP client.

if so. NOPE.

In lieu of a specific and/or special DNS RESOLVER that will inherently 
(automatically) add an A record to the result of a MX query,  the 
"IMPLICIT MX" is generally a manual step of the requesting software - 
SMTP client - where it sees NO records are returned and it will now 
check the A record of the email address domain part.  Whether it done in 
the DNS resolver or in the SMTP client this process is called the 
Implicit MX.

Otherwise, the response of a MX request is always successful which is 
not always true in MX queries and this may be important in the logic 
used for SMTP client retries.

To prove the point, use a DNS client like NSLOOKUP and it will not 
return  the domain A record if a MX query has no records.

> This simple set of rules allows A-Fallback to continue to work by simply 
> requiring that an IMPLICATE MX that is created is treated the Stack as 
> if it were an IPv4-Only Stack even when it is actually a Dual Stack or 
> an IPv6-Only stack.

OK, it sounds to me that what you are advocating is that RESOLVERS learn 
how to do an inherent "Implicit MX" default logic for all MX queries.

Is that a correct statement?

If so, this is not realistic and I personally will not want a backend 
DNS resolver to do making "assumptions" or making up records that may 
not exist.

Keep in mind that the doing a MX query is only the 1st step in the TOTAL 
MX EXPANSION process.

A MX query returns A records which need to be then expanded into IP 
addresses by  looking up all the A records to get the IP addresses.

So if we have an DNS resolver automatically and inherently adding a fake 
zero preference A record representing the domain,  you don't even now 
yet if the A record actually exist unless it went out and actually 
checked for the A record.

This is NOT always desirable for two key reasons:

   1) The binary result of a MX whether is MXDOMAIN, SERVFAIL or SOA
      may be important in how a mail client does its retries.

   2) There are strategies where you do not want the A record
      expansion to take place immediately because the IP
      addresses attempted may by limited by the mail client.

      Note: If the DNS client is hitting a cache server, it may
      return the IP addresses as part the total result.

A good example is a large inbound farm network where there are a lot of 
   MX A records. For example, YAHOO.COM which will spit out a random set 
of  A records.   Using our own DNS resolver against my home ISP server 
(via my NAT):

V:\wc7beta\>wcdns yahoo.com -qt=mx -dbg

- MX Expand Multi-Home: No
- MX Delay Lookup     : No

-- [yahoo.com] --
DNS> Total DNS Servers: 1
DNS> DNS Servers #1 192.168.1.3
DNS> ********** GetDNSRecordsPrim() ***********
DNS> address  : yahoo.com
DNS> dnsdomain: 192.168.1.3
DNS> rtype    : MX (15)
DNS> socket   : UDP
DNS> timeout  : 10
DNS> records  : 7 aa: 0 an: 7  ns: 0  ar: 0  qd: 1  qr: 1 rcode: 0
DNS> query host: [yahoo.com]
DNS> RR MX   ttlB51   pre=1   | yahoo.com | d.mx.mail.yahoo.com
DNS> RR MX   ttlB51   pre=1   | yahoo.com | e.mx.mail.yahoo.com
DNS> RR MX   ttlB51   pre=1   | yahoo.com | f.mx.mail.yahoo.com
DNS> RR MX   ttlB51   pre=1   | yahoo.com | g.mx.mail.yahoo.com
DNS> RR MX   ttlB51   pre=1   | yahoo.com | a.mx.mail.yahoo.com
DNS> RR MX   ttlB51   pre=1   | yahoo.com | b.mx.mail.yahoo.com
DNS> RR MX   ttlB51   pre=1   | yahoo.com | c.mx.mail.yahoo.com
DNS> host: d.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: e.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: f.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: g.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: a.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: b.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> host: c.mx.mail.yahoo.com iplist: 0.0.0.0
DNS> total mx: 7 tagged: 7
count : 7
MX    *0  | 4251 | 1  | 0.0.0.0          | c.mx.mail.yahoo.com |
MX    *1  | 4251 | 1  | 0.0.0.0          | b.mx.mail.yahoo.com |
MX    *2  | 4251 | 1  | 0.0.0.0          | a.mx.mail.yahoo.com |
MX    *3  | 4251 | 1  | 0.0.0.0          | g.mx.mail.yahoo.com |
MX    *4  | 4251 | 1  | 0.0.0.0          | f.mx.mail.yahoo.com |
MX    *5  | 4251 | 1  | 0.0.0.0          | e.mx.mail.yahoo.com |
MX    *6  | 4251 | 1  | 0.0.0.0          | d.mx.mail.yahoo.com |

If I do this against our company DNS primary server at 208.247.131.10 
which also has an uplink cache server, I will get the IP records:

V:\wc7beta\wcdns yahoo.com -qt=mx -dbg -dns 8.247.131.10

- MX Expand Multi-Home: No
- MX Delay Lookup     : No

-- [yahoo.com] --
DNS> ********** GetDNSRecordsPrim() ***********
DNS> address  : yahoo.com
DNS> dnsdomain: 208.247.131.10
DNS> rtype    : MX (15)
DNS> socket   : UDP
DNS> timeout  : 10
DNS> records  : 17 aa: 0 an: 7  ns: 0  ar: 10  qd: 1  qr: 1 rcode: 0
DNS> query host: [yahoo.com]
DNS> RR MX   ttlR11   pre=1   | yahoo.com | d.mx.mail.yahoo.com
DNS> RR MX   ttlR11   pre=1   | yahoo.com | e.mx.mail.yahoo.com
DNS> RR MX   ttlR11   pre=1   | yahoo.com | f.mx.mail.yahoo.com
DNS> RR MX   ttlR11   pre=1   | yahoo.com | g.mx.mail.yahoo.com
DNS> RR MX   ttlR11   pre=1   | yahoo.com | a.mx.mail.yahoo.com
DNS> RR MX   ttlR11   pre=1   | yahoo.com | b.mx.mail.yahoo.com
DNS> RR MX   ttlR11   pre=1   | yahoo.com | c.mx.mail.yahoo.com
DNS> RR A    ttl22   | 216.39.53.1      | e.mx.mail.yahoo.com
DNS> RR A    ttl31   | 209.191.88.247   | f.mx.mail.yahoo.com
DNS> RR A    ttl31   | 68.142.202.247   | f.mx.mail.yahoo.com
DNS> RR A    ttl31   | 209.191.88.239   | g.mx.mail.yahoo.com
DNS> RR A    ttl31   | 206.190.53.191   | g.mx.mail.yahoo.com
DNS> RR A    ttl31   | 209.191.118.103  | a.mx.mail.yahoo.com
DNS> RR A    ttl02   | 66.196.97.250    | b.mx.mail.yahoo.com
DNS> RR A    ttl31   | 216.39.53.2      | c.mx.mail.yahoo.com
DNS> RR A    ttl31   | 216.39.53.3      | c.mx.mail.yahoo.com
DNS> RR A    ttl31   | 66.196.82.7      | d.mx.mail.yahoo.com
DNS> total mx: 10 tagged: 0
count : 10
MX     0  | 5211 | 1  | 66.196.82.7      | d.mx.mail.yahoo.com |
MX     1  | 5211 | 1  | 216.39.53.1      | e.mx.mail.yahoo.com |
MX     2  | 5211 | 1  | 209.191.88.247   | f.mx.mail.yahoo.com |
MX     3  | 5211 | 1  | 68.142.202.247   | f.mx.mail.yahoo.com |
MX     4  | 5211 | 1  | 209.191.88.239   | g.mx.mail.yahoo.com |
MX     5  | 5211 | 1  | 206.190.53.191   | g.mx.mail.yahoo.com |
MX     6  | 5211 | 1  | 209.191.118.103  | a.mx.mail.yahoo.com |
MX     7  | 5211 | 1  | 66.196.97.250    | b.mx.mail.yahoo.com |
MX     8  | 5211 | 1  | 216.39.53.2      | c.mx.mail.yahoo.com |
MX     9  | 5211 | 1  | 216.39.53.3      | c.mx.mail.yahoo.com |

There is no HARD CORE rule that suggest that a mail client MUST use all 
the expanded IP addresses in its total retry strategy.  It might choose 
to use just 5 IPs or 10 ips or whatever.  But what is important that the 
IP addresses may or may not be part of the result.

So some clients, like ours, will only expand the A to X number IPs for 
retries.

Is this correct or am I missing something here?

I always assumed it was well understood that an MX query and the 
implicit MX idea was essentially a two step concept whether its done by 
the resolver or smtp client, but the end result is the same.

The different here from what I am reading is that there seems to be this 
notion that the DNS resolver is always independent from the SMTP and its 
results drive the SMTP client - i.e, the SMTP client is not in the 
picture.  I don't believe that concept can be presumed to be always true.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 6 Apr 2008 21:35:24 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Cc: "Peter J. Holzer" <[email-masked]>
Sender: [email-masked]

I think I didn't explain myself very well... I didn't mean to say that 
these three address verifiers are quality software, correct, or 
anything like that.

The original message asked for current usage of AAAA implicit MX. The 
answer is "top three search results don't" for one type of email 
address processing software. What that type is important or not is a 
value judgment.

Arnt

Date: Sun, 6 Apr 2008 10:39:28 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: History of fallback to A
Cc: Russ Allbery <[email-masked]>
Sender: [email-masked]

Russ Allbery writes:
> For example, here at Stanford, there are a ton of departmental servers 
> that accept mail for some reason, and almost none of them have MX 
> records. People only add MX records when they need to direct mail 
> addressed to one system to a different one instead.

There are three cases:

1. The operators of such a server never add an AAAA. Nothing changes. MX 
lookups still fall back to A.

2. The operators of such a server add an AAAA at some point. IMO, adding 
MX at the same time is sound practice, but it's not strictly necessary, 
because there is an A and MX lookups still fall back to it.

3. The operators of such a server adds an AAAA and removes the A, or 
cannot get an A. In this case, an MX really has to be added.

Is this onerous?

Arnt

Date: Sun, 6 Apr 2008 10:46:41 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

On Sun, 6 Apr 2008, Robert A. Rosenberg wrote:

>
> At 11:38 +0200 on 04/05/2008, Michael Storz wrote about Re: current
> usage of AAAA implicit MX?:
>
> >  > - Number of your IPv6 MTAs which must be located via AAAA (ie: Which
> >>  belong to a FQDN with no IPv6 MX).
> >
> >None. And this is also true for IPv4. All of the hundreds of local MTAs in
> >the Munich Scientific Network (MWN) are routed via MX RRs to our MTAs or
> >to the MTAs of their departemental email servers. Port 25 is blocked from
> >the Internet to the MWN since 10 years.
> >
> >Does this answer your question?
>
> Yes. In your case, there is (as there should be) no reason to support
> AAAA-Fallback in the absence of an MX record (since there are no
> missing MX records).
>
> Since you were talking about domains SENDING to you (and your MTAs
> are dual stack), an interesting question is what is the MX status of
> those who send to you via IPv6 - IOW: How many of the MAIL-FROM FQDNs
> have no MX or A records but only AAAA? I am NOT asking you to provide
> this info but only say that it is a useful metric for the
> AAAA-Fallback issue.
>
>

There where none. As I said in that message:

"160 domains have a path back over IPv6, 155 via MX RRs and 5 via A/AAAA
RRs only:"

The 5 hosts without MX RRs were dual-stack.

Michael Storz

Date: Sun, 6 Apr 2008 10:32:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Cc: Russ Allbery <[email-masked]>
Sender: [email-masked]

Russ Allbery writes:
> Hector Santos <[email-masked]> writes:
>>  IPv4 and IPv6 are very different and software NEEDS to change in 
>>  order to even BEGIN to thinking about supporting it.
>
> I have to pick this nit. The difficulty of supporting IPv6 in 
> userspace programs tends to be exaggerated. At least on UNIX 
> varients, programs that use the new getaddrinfo and getnameinfo 
> interfaces can frequently be written to be entirely agnostic about 
> which IP stacks they're using.

+1

We don't use those and still it was easy. The biggest chunks of code are 
the ones to parse IPv6 addresses (e.g. in the config files) and to 
print IPv6 addresses (e.g. for logging).

Arnt

Date: Sun, 06 Apr 2008 03:47:04 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: IPV6 Implementations Reports
Sender: [email-masked]

I found a few IPv6 implementation presentations which might be of 
interest to others.

This one was particular interesting:

http://www.ap-ipv6tf.org/meetings/summit2007/file/4/(3)%20Kohki%20Ohhira%20-%20ohhira-presentation.pdf

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 06 Apr 2008 03:23:03 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Russ Allbery <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Russ Allbery wrote:
> "Robert A. Rosenberg" <[email-masked]> writes:
> 
> It's not that it's technically difficult so much as that it's dubious from
> a layering perspective, at least from where I sit.  It requires I
> introduce IPv6-specific code (and hence ifdefs for systems without IPv6
> constants and so forth) into an application that otherwise would not need
> any and would be entirely stack-agnostic.
> 
> I guess I'm questioning the cost/benefit analysis being applied here.  Are
> we really fixing a significant enough problem by not having implicit MX
> fallback for IPv6-only nodes to warrant introducing IPv6-specific logic
> into mail routing applications that otherwise could use stack-agnostic
> logic, and warrant the corresponding increase in complexity of
> specification and reasoning about mail systems?  It's setting off
> aesthetic red flags.  This is the sort of design decision whose
> consequences are fuzzy, and hence tend to have an underestimated impact.

+1 Well stated.

This is my main concern with this last minute change request which 
sounds to me is making to attempt to give IPv4 systems "a little" 
knowledge about IPv6 if only at the query level possibly only for some 
spam detection purpose.   There is no other benefit short of making the 
IPv4 system IPv6 aware at the SMTP TCP transport level and 2821bis is 
clearly not ready for full blown IPv6 support.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 05 Apr 2008 23:55:09 -0700
Sender: [email-masked]

"Robert A. Rosenberg" <[email-masked]> writes:

> Your implementation problem is simple to fix.
>
> 1) Look for MX.
> 2) If no MX found set NO-MX flag and do getaddrinfo.
> 3) If NO-MX and IPN=IPv6 Address skip address otherwise try address.
> 4) If Step 3 skipped address or address failed redo step 3 with next
> address until you run out of addresses.
>
> What is so hard about looking at the IPN format before trying it WHEN
> you used getaddrinfo due to the lack of an MX?

It's not that it's technically difficult so much as that it's dubious from
a layering perspective, at least from where I sit.  It requires I
introduce IPv6-specific code (and hence ifdefs for systems without IPv6
constants and so forth) into an application that otherwise would not need
any and would be entirely stack-agnostic.

I guess I'm questioning the cost/benefit analysis being applied here.  Are
we really fixing a significant enough problem by not having implicit MX
fallback for IPv6-only nodes to warrant introducing IPv6-specific logic
into mail routing applications that otherwise could use stack-agnostic
logic, and warrant the corresponding increase in complexity of
specification and reasoning about mail systems?  It's setting off
aesthetic red flags.  This is the sort of design decision whose
consequences are fuzzy, and hence tend to have an underestimated impact.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sun, 06 Apr 2008 02:51:33 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Robert A. Rosenberg" <[email-masked]>
CC:  [email-masked]
Subject: Re: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

Robert A. Rosenberg wrote:
> 
> At 10:25 -0400 on 04/05/2008, Hector Santos wrote about How does SMTP 
> IPv4 and IPv6 work together:
> 
>> To me, this all makes common sense.  I think the text in 2821bis should
>> simply lay down the possibilities as done above.  But I do think the
>> above can be folded to make it into smaller text.
> 
> While I agree 100% with your CONNECTIVITY charts/etc. You are ignoring 
> the question of WHEN/IF AAAA records should/can be used in the absence 
> of EXPLICATE MX that points at the AAAA via its RHS. 

No.  I did not ignore implicit nor explicit MX considerations.

First:

It is not a connectivity chart per se.  It illustrates the RECORD TYPE 
that *must* be available in order to be able to communicate via one of 
two TCP Protocols - IPv4 or IPv6.

There is a DIRECT relationship with the record type (A or AAAA) and 
these tells the software of what is available for data communications.

      A    --> Implies IPv4 TCP protocol stack and vice versa
      AAAA --> Implies IPv6 TCP protocol stack and vice versa

Second:

In successful explicit MX results,  there was an explicit exposure of A 
or AAAA records or BOTH for dual stacks.

The looking at the CHART, it will take you that which records will be 
useful for the client.

If the requester was a IPv4 client, it doesn't matter if the explicit MX 
result returns AAAA records among A records because IPv4 client is 
oblivious (doesn't know about) about AAAA records.  It doesn't need it 
and can't use it, but more importantly he can't probably isn't looking 
for this records to perform the final MX IP expansion (to get the IP 
address from the A records).

Third:

The CHART tells you what actions can be taken for when a MX fails and 
now the client will look for the "implicit MX" result A.K.A he will look 
up the IP address of the email address domain part.

So the question is, how doe he get this raw IP address of the email 
address domain part?

Well, look at the chart.

If the CLIENT is a IPv4 only system, he only knows how to look up one 
way - the A record.

IMPORTANT - what I am against is any semantics in 2821bis that attempts 
to CHANGE the behavior of an IPv4 only system by looking up an AAAA 
record for which he has NO USE for unless he was IPv6 TCP socket capable.

So the BURDEN is on the IPv6 client on what he should look for first or 
second?

    A    --> IPv6 client is assuming the target domain is IPv4 ready
             The ODDS are very high that will be IPv4 ready. So he might
             select to try this FIRST.

    AAAA --> IPv6 client is assuming the WORLD is IPv6 ready and will
             take its changes of doing an AAAA record first.  If it
             fails, then he might fall back to A record lookup.

The key point is that it the IPv6 system that will have to make the 
decision.  The practical short term solution is mostly A lookup first
because the odds are good most systems will be IPv4 ready even its a 
dual stack host.

So this is why I believe that the only text that is necessary at this 
point for 2821bis is:

      IPv6 senders connecting to IPv4 systems MUST be aware that IPv4
      systems are ignorant of IPv6 technology and therefore SHOULD
      make it possible to comply with IPv4 SMTP expectations to allow
      for responses.  This implies that IPv6 senders sending mail to
      IPv6 SHOULD|MUST have explicit MX records or implicit MX A
      record at a minimum.

Unless we are opening up 2821bis and extending it to do a full vetting 
to include all there about implement a 100% supported IPv6 client/server 
operations, they we need to discuss many aspects, including, but not 
exclusive, the following concepts:

   - Operational research on vendors experiences,

   - Understand any new augmented technology explored
     (translators, proxies),

   - Understand all the implementation requirements; at the OS
     level, socket level, and at the routers levels which from
     what I have researched is a real possible problem when a
     hop is not IPv6 ready.

   - Get a handle on the software change requirements at the
     socket level,  this looks pretty straight forward, but
     nonetheless it is still a change requirement.

   - Research all the field testing, nationally and world wide,
     reports, presentations, etc.

   - Collect reported security/threat issues such as the
     known HELO/EHLO IPv6 domain literal buffer overflow threats.

   - Offer some synergism by acknowledging the new issues and
     desires related to proposed MX mandates such as the
     standard track proposal by the DKIM/ASP folks.

     Side Note: We can only do a MX mandate for IPv6 and
     for systems that implement DKIM. This offers maximum
     backward compatibility.

   - Collect world wide industry consensus on whether a implicit
     MX is required or not from a SPAM/Security perspective,
     including getting the best current practice for how systems
     do an implicit MX, e.g., we only do 1 SHOT ATTEMPT at
     delivering mail to an implicit MX address.  If that single
     attempt fails, the transaction is bounced or rejected (admin
     option).

In summary:

The burden is on IPv6 system to decide what record type to use for 
failed explicit MX lookups thus falling back to an implicit MX A or AAAA 
lookup.

If we want to decide this for the IP6 system in 2821bis, I think we 
risking getting it wrong because there are a few strategies here

    - A first, AAAA second  - the short term practical approach
    - AAAA first, A second  - the long term ideal apprach

and also, maybe using ANOTHER discovery technology that centralizes all 
these god darn it Domain Lookups, MX, A, AAAA, SPF, DKIM, ASP or FRODO 
or whatever!

I hope I covered everything.

> What justification do you offer to allow an IPv6 MTA to run without an 
> EXPLICATE MX record? 

I have started in my proposed in multiple messages and I repeated it 
above what I believe is the practical solution here and minimal text for 
2821bis without going overboard in trying something we are not sure 
about yet - for new systems using new technology that WANT to continue 
to operate and communicate in a IPv4, the MUST|SHOULD use a MX and/or 
implicit MX A record in order to be compatible with current expectations.

What I am not sure off if we should make that a MUST across the board 
and use IPv6 (and possibly DKIM/ASP) as a spring board to mandating MX 
records for both IPv4 and IPv6.

I think I am open to slow deprecating on the implicit MX lookup as I 
originally posted in my input into this discussion.  But thats 
implementator ultimate decision.

> The fact that we allow IPv4 MTAs to run with only 
> an A record is NOT a valid excuse since that was/is permitted due to 
> A-Usage predating the existence of the MX record and thus allowed 
> (although that allowance should have been rescinded years ago).

Agree.  But it is what it is and if we force an MX, they might be a big 
impact.   All I know here is that recently the implicit MX played a role 
in helping my brother setup his mail server.  He already had a A record 
fo this simple single machine domain.  But the MX record was yet to be 
available when I set it up.   The mail testing was successful via 
implicit MX A record lookup and we know the MX record would catch up. 
It probably did within 1 hour or so.

So is this still a needed concept?  I am the fence on that.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sun, 6 Apr 2008 00:49:24 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Cc: "Peter J. Holzer" <[email-masked]>
Sender: [email-masked]

At 22:03 +0200 on 04/05/2008, Arnt Gulbrandsen wrote about Re: 
current usage of AAAA implicit MX?:

>Peter J. Holzer writes:
>>On 2008-04-04 17:30:29 -0400, Robert A. Rosenberg wrote:
>>>RFC 3974
>>>[...]
>>>It, BTW, REQUIRES an MX if there are any IPv6 MTAs  and only 
>>>supports A-Fallback in the absence of an MX
>>
>>No.
>
>"For the transition period, all mail domains should have MX records 
>such that MX targets with IPv4 and IPv6 addresses exist"?

I will point out the existence of an MX for the FQDN makes the 
question of AAAA-Fallback (or the existence of AAAA records for FQDN 
when you simulate the existence of a FQDN MX 0 FQDN record) a moot 
point since there is no AAAA record to fall-back on since it is 
LISTED in the actual MX as a valid MTA. Also the quote above says 
"SUPPLY MX RECORDS for your MTAs".

>
>>>  It also states that in the presence of an MX containing IPv6 address
>>>  references, an IPv4-Only stack should ignore the IPv6 addresses
>>
>>Yes, of course. It cannot reach them anyway. Just as IPv6-only 
>>hosts can ignore A records since they cannot reach them either.
>
>An IPv6-only host must use the presence/absence of A records to 
>generate the DSN. The DSN status code is 5.1.2 if there's no A and 
>5.4.x if there is an A but no way to reach it (ie. no configured 
>relay).
>
>Arnt

k

Date: Sun, 6 Apr 2008 01:03:21 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 14:02 -0700 on 04/05/2008, Russ Allbery wrote about Re: current 
usage of AAAA implicit MX?:

>In fact, from that perspective, it would be a bit annoying to write a
>fallback to A without also writing a fallback to AAAA for hosts without an
>MX record.  The obvious (at least with thirty seconds of thought, and I
>may be missing gotchas) way of implementing resolution of a mail server is
>to do an MX record lookup and, if that fails, call getaddrinfo on the RHS
>and connect to the resulting addresses until one of them works.  This
>would treat AAAA identically to A.

Your implementation problem is simple to fix.

1) Look for MX.
2) If no MX found set NO-MX flag and do getaddrinfo.
3) If NO-MX and IPN=IPv6 Address skip address otherwise try address.
4) If Step 3 skipped address or address failed redo step 3 with next 
address until you run out of addresses.

What is so hard about looking at the IPN format before trying it WHEN 
you used getaddrinfo due to the lack of an MX?

Date: Sun, 6 Apr 2008 00:37:42 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 21:21 +0200 on 04/05/2008, Peter J. Holzer wrote about Re: current 
usage of AAAA implicit MX?:

>On 2008-04-04 17:30:29 -0400, Robert A. Rosenberg wrote:
>>  At 12:56 -0400 on 04/04/2008, Tony Hansen wrote about Re: current
>>  usage of AAAA implicit MX?:
>>
>>  >These questions are intended to find out what current IPv6 deployments
>>  >do in these situations. When an MX is not found, are they already
>>  >looking for both A and AAAA records, or are they only looking for A
>>  >records. Are they following RFC 3974 or not? What's the installed base
>>  >already doing?
>>
>>  RFC 3974 talks about Dual Stack set-ups and what an IPv4-Only Server
>>  should do when presented with a Mixed MX or an MX that only points at
>>  IPv6 AAAA records. It, BTW, REQUIRES an MX if there are any IPv6 MTAs
>>  and only supports A-Fallback in the absence of an MX
>
>No.
>
>>  (ie: It does NOT define any attempt to look for AAAA records in the
>>  absence of an MX after/before checking for A records).
>
>Yes, it does:
>
>|   (1)  Lookup the MX record for the destination domain.
>[...]
>|        If NODATA (i.e., empty answer with NOERROR(0) RCODE) is
>|        returned, there is no MX record but the name is valid.  Assume
>|        that there is a record like "name.  IN MX 0 name." (implicit MX)
>|        and go to step (3). 
>[...]
>|   (3)  If the sending MTA has IPv4 capability, lookup the A records.
>|        Keep the resulting addresses until step (5).
>|
>|   (4)  If the sending MTA has IPv6 capability, lookup the AAAA records.
>
>Both A and AAAA records are looked up for the implicit MX.
>
>
>>  It also states that in the presence of an MX containing IPv6 address
>>  references, an IPv4-Only stack should ignore the IPv6 addresses
>
>Yes, of course. It cannot reach them anyway. Just as IPv6-only hosts can
>ignore A records since they cannot reach them either.
>
>>  and only use the IPv4 addresses (and in a IPv6-Only MX to NOT do
>>  IPv4-A-Record fallback).
>
>Where do you read that?

My error. I did not notice the weasel wording at the end of step 1 
that lacked a "bypassing step 4" after the "go to step (3)" which 
would have applied step 4 ONLY to real (as opposed to 
generated/simulated) MX records. Most of RFC 3974 talks about what to 
do when you encounter a REAL MX (a case where step 4 is a valid step 
since the REAL MX says to reference the AAA records even in the FQDN 
MX x FQDN case).

Date: Sun, 6 Apr 2008 00:14:53 -0400
To:  [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

At 03:39 -0400 on 04/05/2008, John C Klensin wrote about Re: Minor 
is. It's not a pardigm change:

>--On Wednesday, 02 April, 2008 00:17 -0400 "Robert A. Rosenberg"
><[email-masked]> wrote:
>
>>
>>  At 23:00 -0400 on 03/31/2008, John C Klensin wrote about Re:
>>  Minor is. It's not a pardigm change:
>>
>>>  Once that implicit MX record exists, there are fairly clear
>>>  rules  about which address to use for foo.example.com.   To
>>>  be a little  more precise, while the rules are clear, they
>>>  pretty much leave it  up to the sending host and there is no
>>>  real difference between the  traditional choice between the
>>>  two IPv4 addresses and the newer  choice between the IPv4
>>>  addresses and the IPv6 one.   The Standard  also gives the
>>>  sender implementation some flexibility about how many  of
>>>  those addresses it is obligated to try.
>>
>>  I disagree with your methodology. If the rule is that incoming
>>  MTAs (ie: Those MTAs that are supposed to be located via MXs)
>>  which listen at an IPv6 IPN are REQUIRED to be designed by an
>>  MX (ie: You are not treated as an incoming IPv6 MTA UNLESS you
>>  are pointed to by an MX), any implicate MX that is built in
>>  the absence of an EXPLICATE MX should contain ONLY the A
>>  records for that FQDN. Any AAAA records for the FQDN are
>>  ignored in building the implicate MX.
>
>This is interesting, but I have no idea what you are talking
>about.  MX records contain names, not address records in the
>DATA.  That has been clear since the beginning and 2821
>reinforces it.  Certainly it is possible to assign one DNS name
>to the set of IPv4 interfaces on a host and another name to the
>set of IPv6 interfaces, but, as soon as one does that, there
>are, as far as the DNS is concerned, two separate hosts.
>
>If I correctly understand what you are suggesting, it is that,
>if I have
>
>    foo.example.com.  IN A #.#....
>                      IN AAAA #:#:...
>
>My SMTP client should somehow generate, not the implicit MX
>called for by 2821bis (and 2821), which is
>
>    foo.example.com.  IN MX 0 foo.example.com.
>
>but some sort of MX arrangement that points to the A RR only and
>not to the AAAA RR.   There is just no way to do that, at least
>without putting completely new language in 2821bis that
>distinguishes between the interpretation rules for implicit and
>explicit MX records (and getting hopelessly entangled with and
>overriding RFC 3484).
>
>So what are you suggesting?

1) Require that any IPv6 MTA MUST be pointed to by an EXPLICATE MX record.
2) Require that any IMPLICATE MX record that is built due to the 
absence of an EXPLICATE MX record follow the EXPLICATE MX RFC 3484 
rules for an IPv4-ONLY stack (ie: Ignore all AAAA records found for 
foo.example.com IN A/AAAA).

This simple set of rules allows A-Fallback to continue to work by 
simply requiring that an IMPLICATE MX that is created is treated the 
Stack as if it were an IPv4-Only Stack even when it is actually a 
Dual Stack or an IPv6-Only stack.

Date: Sun, 6 Apr 2008 00:25:49 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 11:38 +0200 on 04/05/2008, Michael Storz wrote about Re: current 
usage of AAAA implicit MX?:

>  > - Number of your IPv6 MTAs which must be located via AAAA (ie: Which
>>  belong to a FQDN with no IPv6 MX).
>
>None. And this is also true for IPv4. All of the hundreds of local MTAs in
>the Munich Scientific Network (MWN) are routed via MX RRs to our MTAs or
>to the MTAs of their departemental email servers. Port 25 is blocked from
>the Internet to the MWN since 10 years.
>
>Does this answer your question?

Yes. In your case, there is (as there should be) no reason to support 
AAAA-Fallback in the absence of an MX record (since there are no 
missing MX records).

Since you were talking about domains SENDING to you (and your MTAs 
are dual stack), an interesting question is what is the MX status of 
those who send to you via IPv6 - IOW: How many of the MAIL-FROM FQDNs 
have no MX or A records but only AAAA? I am NOT asking you to provide 
this info but only say that it is a useful metric for the 
AAAA-Fallback issue.

Date: Sat, 5 Apr 2008 23:57:59 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

At 10:25 -0400 on 04/05/2008, Hector Santos wrote about How does SMTP 
IPv4 and IPv6 work together:

>To me, this all makes common sense.  I think the text in 2821bis should
>simply lay down the possibilities as done above.  But I do think the
>above can be folded to make it into smaller text.

While I agree 100% with your CONNECTIVITY charts/etc. You are 
ignoring the question of WHEN/IF AAAA records should/can be used in 
the absence of EXPLICATE MX that points at the AAAA via its RHS. We 
have to support IMPLICATE MX creation pointing at A records for the 
FQDN RHS of the email address due to a refusal to enforce the "Mail 
Servers are pointed to by EXPLICATE MX records" requirement that 
should have gone into effect at least 10-15 years ago once use of A 
records to find Mail Servers was superceded by the definition of MX 
records. While we still support IMPLICATE MX records pointing at A 
records, it is just to support lazy administrators who not bother to 
define MX records or who run MTA software without MX support or with 
crippled MX support. I am NOT saying to drop IMPLICATE A-Record MX 
generation but only to not go down the "AAAA without MX is supported" 
route. This is NOT the 1980s where we need to support MX-less FQDNs 
with A records but 2008 when there is NO VALID REASON to run an IPv6 
MTA that is not pointed to by an EXPLICATE MX. IMO: Any IPv6 MTA that 
expects to receive email is misconfigured if it is not pointed to by 
an EXPLICATE MX.

What justification do you offer to allow an IPv6 MTA to run without 
an EXPLICATE MX record? The fact that we allow IPv4 MTAs to run with 
only an A record is NOT a valid excuse since that was/is permitted 
due to A-Usage predating the existence of the MX record and thus 
allowed (although that allowance should have been rescinded years 
ago).

Date: Sat, 05 Apr 2008 20:44:41 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Russ Allbery <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Russ Allbery wrote:
> Hector Santos <[email-masked]> writes:
> 
>> IPv4 and IPv6 are very different and software NEEDS to change in order
>> to even BEGIN to thinking about supporting it.
> 
> I have to pick this nit.  The difficulty of supporting IPv6 in userspace
> programs tends to be exaggerated.  At least on UNIX varients, programs
> that use the new getaddrinfo and getnameinfo interfaces can frequently be
> written to be entirely agnostic about which IP stacks they're using.

Hi Russ,

You raised a good point. For simple query applications, sure,  level 2 
socket commands can help in the migration. Changes are minimal, if any.

However, and I'm sure you know all this, so I just speaking in general, 
this is just one small part of the possibly necessary total change 
requirements.

1) Existing simple query programs may need to be updated to define which 
  class results the want to get.  For example, getaddrinfo() needs to be 
passed the AI_PASSIVE flag if you want to see either IPv4 or IPv6 
addresses.  (note, I'm not a unix wienie any more so I can't tell you if 
this a portable behavior on Unix).

2) For some OSes, I recall seeing in Windows 2008 beta (which is 
basically VISTA without the Vista graphics) a OS global ON and OFF 
command switch to enable or disable IPv6 results. This is because before 
existing applicatons may not be expecting IPv6 requests or operations.

3) This also assumes applications are using the socket level 2 
getxxxxx()functions as oppose to using an in-house direct DNS client API 
library and/or the OS DNS API/library for queries. These API may not 
have been designed for IPv6 readiness or queries for desired IPv6 results.

But yes, developer to developer, I agree the design changes requirement 
complexity is over exaggerated. But for most, IMO, the design change 
requirements is part of a larger picture than just simple queries.

> I've written code that works fine with IPv6 without even testing on an
> IPv6-enabled system.  The code from my perspective as a programmer is
> identical either way.

Ok, then you coded and designed it to operate in a passive mode where 
getaddrinfo() return either the IP address portion of the socket address 
structure prepared for IPv4 or IPv6 operations.

If you have not done that and/or a developer was specifically aware of 
this and only asked for IPv4 results, is not ready for IPv6.

> In fact, from that perspective, it would be a bit annoying to write a
> fallback to A without also writing a fallback to AAAA for hosts without an
> MX record.  The obvious (at least with thirty seconds of thought, and I
> may be missing gotchas) way of implementing resolution of a mail server is
> to do an MX record lookup and, if that fails, call getaddrinfo on the RHS
> and connect to the resulting addresses until one of them works.  This
> would treat AAAA identically to A.

If you have a moment, please see my "How doe SMTP IPv4 and IPv6 work 
together" message post to the list earlier today.

The goal here is to highlight what I think is the obvious for maximize 
compatibility or minimum depending on your perspective.

2821bis should not, or rather I don't think it needs to add text that 
can change or implied a need for change for the existing IPv4 only 
expected behavior.

Consider a world where there is only IPv6 and everyone is talking IPv6 
only.  I believe we will have the same issues with missing MX record and 
a implicit MX AAAA lookup behavior for the domain.

The only way that AAAA fallback can be eliminated, is if we use the 
opportunity for an IPv6 only system to mandate proper MX record.

But I don't think we can mandate an MX for a pure IPv4 system simply 
because it was never required before in the IPv4 only whelm.

I just don't think we are ready to make any mandated MX claim yet for 
this 2821bis for either IPv4/6 protocal.  We need more vetting about this.

I think the best what we can do for 2821bis at this point is to make 
sure there is text requiring what IPv6 systems to need to do if they 
wish to contact a IPv4 only domain and expects responses from this IPv4 
system.  The only way this is possibke if when the IPv6 offers dual 
stacks allowed the IPv4 only system to use the MX/A records or implicit 
MX domain A record.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: [email-masked]
From: Mark Andrews <[email-masked]>
Mail-Followup-To: [email-masked] 
Subject: Re: Why implicit MX is a bad idea for IPv6 
Date: Sun, 06 Apr 2008 08:36:51 +1000
Sender: [email-masked]

> 
> On Sat, Apr 05, 2008 at 08:07:25PM +0200, Peter J. Holzer wrote:
> 
> > > IMPORTANT: a domain with no MX _and_ no A record, is not a maildomain.
> > > 
> > > This means an AAAA record is not an implicit MX record.
> > 
> > No, that doesn't follow at all. If all the MX records for a domain
> > contain hostnames with only AAAA records, the domain is just as
> > unreachable for an IPv4-only host as if it contained only an AAAA
> > record. And for a IPv6-only host it is just the other way around. 
> 
> It is the IPv6 host which is incompatible with existing standards and
> it is the IPv6 host which will have to work around that.
> 
> And your believe is probably based on what you write next:
> 
> > Many people arguing for the "only A records are implicit MX records"
> > side seem to ignore the fact that an MX record doesn't contain an
> > address on the right side. It contains a host name, which still needs to
> > be resolved to an address (via an A or AAAA lookup). The implicit MX
> > record isn't "synthesized from an A record", it is synthesized from the
> > domain name. There is no difference between the A lookup on the
> > hostnames in the real MX records and the one in the implicit MX records,
> > and neither should there be a difference in the AAAA lookups on those
> > hostnames, unless you want to follow the principle of most surprise.
> 
> 2821 section 5:
> "
>    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.
> "
> 
> which contradicts your statement and supports mine.
> 
> 
> > > If that set is empty, this is an error condition.
> > > 
> > > IMPORTANT: a domain with no A record in its MX set, is in error.
> > 
> > No. It is merely unreachable from IPv4. This is *probably* an error, but
> > may be intentional.
> 
> Most definately, not probably.
> 
> 2821 section 5:
> 
> "
>    If MX records
>    are present, but none of them are usable, this situation MUST be
>    reported as an error.
> "
> 
> And this is exactly what will happen when one or more MX records exist,
> but none of them have A records.
> 
> Intentionally creating confusion just seems wrong.  I think correctly
> programmed software will cope with "MX present but no A", but I wouldn't
> be surprised if there's software out there which has difficulties with
> such a case.
> 
> And don't forget the users.  The IPv4 host may just report "cannot deliver",
> but it could equally well report "bad configuration". And some hosts could
> keep retrying (which would be an error in itself, dunno).
> 
> Again: IPv6-only host setups will have to deal with the problems they
> create.  That means setting up gateways and A records.

	Today this is a reasonable expectation.  Essentially IPv6
	only networks can still get some IPv4 addresses to operate
	their dual stack boxes with.

	NAT64 still requires a real IPv4 address.

	In the end it will be the operators of the IPv4 only legacy
	systems which will need to provide the support as there
	won't be any IPv4 addresses available to the IPv6 only nets
	to map through.

		e.g. NAT46 gateways.

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

Date: Sat, 05 Apr 2008 18:26:52 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: Implicit MX decisions
Sender: [email-masked]

Hi.

Fortunately (for me) Tony and Lisa get to determine consensus on
this subject.  Even as editor, I'm just an occasional
participant in the discussion and sometime just a lurker.

However, I've just read through the last 24 hours of comments on
the subject.  It seems very clear to me that no one is saying
anything new.  We are getting the same arguments repeated over
and over again, with very slight variations in content, although
with significant variations in passion.

Tony and Lisa may be better at this than I am (or less exhausted
by 2821bis) but, if I were making the decision. the message
volume itself would be acting as an impediment to forming a
complete picture and making some sort of consensus.  Put more
strongly, this small number of arguments, repeated over and over
again with great passion are becoming a DoS attack on getting
2821bis finished and published.  I hope and assume that is no
one's intent.

Could I ask that anyone who has expressed a position clearly, or
even fairly clearly, just stop.  I think you can be assured that
you have been heard.  I think it is clear that no one has
actually changed his or her mind in the last week (probably much
longer), and that repeating things again is unlikely to change
that.

Hector has tried to summarize the various positions, but his
note seems to comment on connectivity choices.  I don't think
those choices are at issue.   I don't believe they _can_ be an
issue in 2821bis because making special rules about connection
types would require updating RFC 3484.

I would welcome a clear and balanced discussion of the options
(and might try to write one if no one else does).   But, other
than that, unless someone has something really new to say, I
think we are finished.

Just my opinion obviously... and as an individual: the editor
has no opinion and is just going to sit on 2821bis-10 until Tony
tells me what to say.

    john

Date: Sat, 5 Apr 2008 23:15:52 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: Why implicit MX is a bad idea for IPv6
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Apr 05, 2008 at 08:07:25PM +0200, Peter J. Holzer wrote:

> > IMPORTANT: a domain with no MX _and_ no A record, is not a maildomain.
> > 
> > This means an AAAA record is not an implicit MX record.
> 
> No, that doesn't follow at all. If all the MX records for a domain
> contain hostnames with only AAAA records, the domain is just as
> unreachable for an IPv4-only host as if it contained only an AAAA
> record. And for a IPv6-only host it is just the other way around. 

It is the IPv6 host which is incompatible with existing standards and
it is the IPv6 host which will have to work around that.

And your believe is probably based on what you write next:

> Many people arguing for the "only A records are implicit MX records"
> side seem to ignore the fact that an MX record doesn't contain an
> address on the right side. It contains a host name, which still needs to
> be resolved to an address (via an A or AAAA lookup). The implicit MX
> record isn't "synthesized from an A record", it is synthesized from the
> domain name. There is no difference between the A lookup on the
> hostnames in the real MX records and the one in the implicit MX records,
> and neither should there be a difference in the AAAA lookups on those
> hostnames, unless you want to follow the principle of most surprise.

2821 section 5:
"
   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.
"

which contradicts your statement and supports mine.

> > If that set is empty, this is an error condition.
> > 
> > IMPORTANT: a domain with no A record in its MX set, is in error.
> 
> No. It is merely unreachable from IPv4. This is *probably* an error, but
> may be intentional.

Most definately, not probably.

2821 section 5:

"
   If MX records
   are present, but none of them are usable, this situation MUST be
   reported as an error.
"

And this is exactly what will happen when one or more MX records exist,
but none of them have A records.

Intentionally creating confusion just seems wrong.  I think correctly
programmed software will cope with "MX present but no A", but I wouldn't
be surprised if there's software out there which has difficulties with
such a case.

And don't forget the users.  The IPv4 host may just report "cannot deliver",
but it could equally well report "bad configuration". And some hosts could
keep retrying (which would be an error in itself, dunno).

Again: IPv6-only host setups will have to deal with the problems they
create.  That means setting up gateways and A records.

To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 05 Apr 2008 14:02:40 -0700
Sender: [email-masked]

Hector Santos <[email-masked]> writes:

> IPv4 and IPv6 are very different and software NEEDS to change in order
> to even BEGIN to thinking about supporting it.

I have to pick this nit.  The difficulty of supporting IPv6 in userspace
programs tends to be exaggerated.  At least on UNIX varients, programs
that use the new getaddrinfo and getnameinfo interfaces can frequently be
written to be entirely agnostic about which IP stacks they're using.

I agree that changes are required for older software written against the
gethostbyname and related interfaces and for many things that one wants to
do in servers, not to mention weird network programs like ping or
traceroute require more work.  But for many common typical client
networking patterns, nothing other than writing to the new generic name
and address resolution interfaces is required.

I've written code that works fine with IPv6 without even testing on an
IPv6-enabled system.  The code from my perspective as a programmer is
identical either way.

In fact, from that perspective, it would be a bit annoying to write a
fallback to A without also writing a fallback to AAAA for hosts without an
MX record.  The obvious (at least with thirty seconds of thought, and I
may be missing gotchas) way of implementing resolution of a mail server is
to do an MX record lookup and, if that fails, call getaddrinfo on the RHS
and connect to the resulting addresses until one of them works.  This
would treat AAAA identically to A.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 5 Apr 2008 22:26:38 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--rwbb4r/vLufKlfJs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-05 22:03:17 +0200, Arnt Gulbrandsen wrote:
> Peter J. Holzer writes:
> >On 2008-04-04 17:30:29 -0400, Robert A. Rosenberg wrote:
> >>RFC 3974
> >>[...]
> >>It, BTW, REQUIRES an MX if there are any IPv6 MTAs  and only supports 
> >>A-Fallback in the absence of an MX
> >
> >No.
> 
> "For the transition period, all mail domains should have MX records such 
> that MX targets with IPv4 and IPv6 addresses exist"?

That doesn't say anything specifically the fallback. The fallback is
clearly specified in section 3 and includes fallback to an AAAA record.
So it is false that RFC 3974 "only supports A-Fallback in the absence of
an MX".

> >> It also states that in the presence of an MX containing IPv6 address
> >> references, an IPv4-Only stack should ignore the IPv6 addresses
> >
> >Yes, of course. It cannot reach them anyway. Just as IPv6-only hosts 
> >can ignore A records since they cannot reach them either.
> 
> An IPv6-only host must use the presence/absence of A records to generate 
> the DSN. The DSN status code is 5.1.2 if there's no A and 5.4.x if 
> there is an A but no way to reach it (ie. no configured relay).

Hmm. That would (after substituting AAAA for A) also apply to an IPv4
host, but it is unreasonable to expect that. I'd file that under
"quality of implementation".

In any case that's not in RFC 3974.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--rwbb4r/vLufKlfJs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--rwbb4r/vLufKlfJs--

Date: Sat, 05 Apr 2008 16:23:00 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Peter J. Holzer wrote:

> On 2008-04-04 17:30:29 -0400, Robert A. Rosenberg wrote:
> 
>> It also states that in the presence of an MX containing IPv6 address 
>> references, an IPv4-Only stack should ignore the IPv6 addresses
> 
> Yes, of course. It cannot reach them anyway. Just as IPv6-only hosts can
> ignore A records since they cannot reach them either.

+1

I'm getting the impression Pete that some here don't realize that IPv6 
is an entirely different TCP socket layer.

For folks who didn't know yet about IPv6, IPv6 is not just about given 
the world an astronomical number of addresses allowing for every device 
in the world to have its own IP address (and for PCs even 2 addresses),
we are talking about a new set of communication SOCKET methods.

IPv4 and IPv6 are very different and software NEEDS to change in order 
to even BEGIN to thinking about supporting it.

Keep in mind that IPv4 allows for a 32 bit number or 4 bytes.  IPv6 is 
32 bytes!   That means many software IP storage structures and records 
will have to be altered from what is otherwise a natural word size 
storage to one that is now NOT natural and will require extra 
programming and engineering.

So if you are wondering why IPv6 is slow to be adopted, it is because 
there are many unfeasible barriers to overcome for many still at this time.

For the majority of systems, it is not a plug and play solution.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sat, 5 Apr 2008 22:03:17 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Cc: "Peter J. Holzer" <[email-masked]>
Sender: [email-masked]

Peter J. Holzer writes:
> On 2008-04-04 17:30:29 -0400, Robert A. Rosenberg wrote:
>> RFC 3974
>> [...]
>> It, BTW, REQUIRES an MX if there are any IPv6 MTAs  and only supports 
>> A-Fallback in the absence of an MX
>
> No.

"For the transition period, all mail domains should have MX records such 
that MX targets with IPv4 and IPv6 addresses exist"?

>>  It also states that in the presence of an MX containing IPv6 address
>>  references, an IPv4-Only stack should ignore the IPv6 addresses
>
> Yes, of course. It cannot reach them anyway. Just as IPv6-only hosts 
> can ignore A records since they cannot reach them either.

An IPv6-only host must use the presence/absence of A records to generate 
the DSN. The DSN status code is 5.1.2 if there's no A and 5.4.x if 
there is an A but no way to reach it (ie. no configured relay).

Arnt

Date: Sat, 5 Apr 2008 21:51:44 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--72k7VsmfIboquFwl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-04 22:46:17 +0200, Arnt Gulbrandsen wrote:
> 
> Since data entry software matters and noone else has mentioned that 
> area, I searched CPAN and found three modules to help verify email 
> addresses in web forms etc., namely Mail::Verify, Net::validMX and 
> Email::Valid. All three do MX/A lookups, none do AAAA lookups.

The first two are IPv4 only. They also check if there are A records for
the RHS of the MX records and return an error if they can't find any.
So they will also flag 

      example.org.            IN MX   1  mx1.example.org.
                              IN MX   10 mx10.example.org.
      mx1.example.org.        IN AAAA 2001:db8:ffff::1
      mx10.example.org.       IN AAAA 2001:db8:ffff::2

as invalid. 

The third just checks if there is an MX record, but doesn't check the
contents in any way. So

    example.org.        IN MX   1 no-such-host.invalid.

will be reported as valid.

Neither behaviour really reflects the validity of a domain if there is
IPv6 connectivity (although the first makes some sense as a generic
test: Any domain reachable only via IPv6 can be considered unreachable
in practice now and at least for the next few years).

        hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--72k7VsmfIboquFwl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--72k7VsmfIboquFwl--

Date: Sat, 5 Apr 2008 21:33:42 +0200
From: "Peter J. Holzer" <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: Minor is. It's not a pardigm change
Mail-Followup-To: SMTP Discussion <[email-masked]>
Sender: [email-masked]

--hABqaeELJqnDDeDE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-05 11:32:10 -0700, Bill McQuillan wrote:
> On Sat, 2008-04-05, John C Klensin wrote:
> 
> > If I correctly understand what you are suggesting, it is that,
> > if I have
> 
> >    foo.example.com.  IN A #.#....
> >                      IN AAAA #:#:...
> 
> > My SMTP client should somehow generate, not the implicit MX
> > called for by 2821bis (and 2821), which is
> 
> >    foo.example.com.  IN MX 0 foo.example.com.
> 
> > but some sort of MX arrangement that points to the A RR only and
> > not to the AAAA RR.   There is just no way to do that, at least
> > without putting completely new language in 2821bis that
> > distinguishes between the interpretation rules for implicit and
> > explicit MX records (and getting hopelessly entangled with and
> > overriding RFC 3484).
> 
> It seems to me that the above concept of "implicit MX" requires an extra
> step that is not dictated by RFC 2821.

No, it's RFC 2821 which requires an extra step which wasn't there in RFC
974 (and isn't there in RFC 3974, either, and isn't performed by at
least one widely deployed MTA (postfix)). This step is 

"look up an A record to decide whether an MX record should be
synthesized". 

> In this concept the implicit MX is automatically synthesized when no
> explicit MX was found. Then "address records" would be looked up under
> that name (foo.example.com. above).
> 
> Extracting the important sentence from 2821, section 5:
> 
>    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.
> 
> My reading of this is: when an MX RR is not found then look for a an A RR
> with the same name. If the A RR is found, *treat it as* though it was the
> result of previously having found an MX pointing to that host name. Thus
> there is no need for a subsequent lookup of both A and AAAA RRs.

More importantly there is no need to do an A lookup at that time. Just
synthesize the MX and be done with it. The A lookup may fail later, but
that can also happen for any hostname contained in an MX record. For an
IPv6-only host there is no reason to do an A lookup at all.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--hABqaeELJqnDDeDE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--hABqaeELJqnDDeDE--

Date: Sat, 5 Apr 2008 21:21:59 +0200
From: "Peter J. Holzer" <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Mail-Followup-To: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

--2oox5VnwalALFvA7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-04 17:30:29 -0400, Robert A. Rosenberg wrote:
> At 12:56 -0400 on 04/04/2008, Tony Hansen wrote about Re: current 
> usage of AAAA implicit MX?:
> 
> >These questions are intended to find out what current IPv6 deployments
> >do in these situations. When an MX is not found, are they already
> >looking for both A and AAAA records, or are they only looking for A
> >records. Are they following RFC 3974 or not? What's the installed base
> >already doing?
> 
> RFC 3974 talks about Dual Stack set-ups and what an IPv4-Only Server 
> should do when presented with a Mixed MX or an MX that only points at 
> IPv6 AAAA records. It, BTW, REQUIRES an MX if there are any IPv6 MTAs 
> and only supports A-Fallback in the absence of an MX

No.

> (ie: It does NOT define any attempt to look for AAAA records in the
> absence of an MX after/before checking for A records).

Yes, it does:

|   (1)  Lookup the MX record for the destination domain.
[...]
|        If NODATA (i.e., empty answer with NOERROR(0) RCODE) is
|        returned, there is no MX record but the name is valid.  Assume
|        that there is a record like "name.  IN MX 0 name." (implicit MX)
|        and go to step (3).  
[...]
|   (3)  If the sending MTA has IPv4 capability, lookup the A records.
|        Keep the resulting addresses until step (5).
|
|   (4)  If the sending MTA has IPv6 capability, lookup the AAAA records.

Both A and AAAA records are looked up for the implicit MX.

> It also states that in the presence of an MX containing IPv6 address 
> references, an IPv4-Only stack should ignore the IPv6 addresses

Yes, of course. It cannot reach them anyway. Just as IPv6-only hosts can
ignore A records since they cannot reach them either.

> and only use the IPv4 addresses (and in a IPv6-Only MX to NOT do
> IPv4-A-Record fallback).

Where do you read that? 

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--2oox5VnwalALFvA7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--2oox5VnwalALFvA7--

Date: Sat, 5 Apr 2008 20:55:41 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--0qt3EE9wi45a2ZFX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-05 01:30:19 -0000, John Levine wrote:
> >ps.  While surveys are always useful, I'll repeat the observation
> >that changing the query model for SMTP is out of scope.
> 
> Dave, you're assuming your conclusion.
> 
> What we're trying to settle here is whether the existing query model
> is synthesize from A or synthesize from any address record.

Or synthesize from neither. That's the original algorithm in RFC 974: If
the list of MX records is empty, an MX record containing the domain on
the right side is synthesized. Whether an A or AAAA (or other) record is
present, is irrelevant at this stage. Address lookup only happens later
and will fail in the absence of an A or AAAA record regardless of
whether the hostname came from a real MX record or not.

(Yes, I know that RFC 974 is historical. But the language in RFC 2821
doesn't make a difference in an IPv4-only world, and I think it
needlessly complicates the algorithm).

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--0qt3EE9wi45a2ZFX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--0qt3EE9wi45a2ZFX--

Date: Sat, 5 Apr 2008 11:32:10 -0700
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

On Sat, 2008-04-05, John C Klensin wrote:

> If I correctly understand what you are suggesting, it is that,
> if I have

>    foo.example.com.  IN A #.#....
>                      IN AAAA #:#:...

> My SMTP client should somehow generate, not the implicit MX
> called for by 2821bis (and 2821), which is

>    foo.example.com.  IN MX 0 foo.example.com.

> but some sort of MX arrangement that points to the A RR only and
> not to the AAAA RR.   There is just no way to do that, at least
> without putting completely new language in 2821bis that
> distinguishes between the interpretation rules for implicit and
> explicit MX records (and getting hopelessly entangled with and
> overriding RFC 3484).

It seems to me that the above concept of "implicit MX" requires an extra
step that is not dictated by RFC 2821. In this concept the implicit MX is
automatically synthesized when no explicit MX was found. Then "address
records" would be looked up under that name (foo.example.com. above).

Extracting the important sentence from 2821, section 5:

   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.

My reading of this is: when an MX RR is not found then look for a an A RR
with the same name. If the A RR is found, *treat it as* though it was the
result of previously having found an MX pointing to that host name. Thus
there is no need for a subsequent lookup of both A and AAAA RRs.

What this says to me is that if we only look up A RRs in this step, there
will be only A RRs on hand to be returned as the resolution. If instead, we
look up both A RRs and AAAA RRs in order to determine if an implicit MX
should be used, there will be both types of address on hand to be returned.

I conclude that it *is* meaningful to allow only A RRs to be treated as
fallback MXs since the extra step of looking up address records at the
implicit MX target name is not actually required.

-- 
Bill McQuillan <[email-masked]>

Date: Sat, 5 Apr 2008 20:07:25 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: Why implicit MX is a bad idea for IPv6
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--C+ts3FVlLX8+P6JN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-05 14:26:50 +0200, Alex van den Bogaerdt wrote:
> 
> Here's why implicit MX for IPv6 is a bad idea.
> 
> Summary:
> a domain with no MX _and_ no A record, is not a maildomain.
> a domain with no A record in its MX set, is in error.
> 
> 
> 
> Interoperability in combination with the least surprise principle
> dictates that IPv6 AAAA RR cannot function as implicit MX.

To me following the  least surprise principle means that an AAAA record
must be treated exactly like an A record. Treating it differently is
highly surprising to me.

> (only MX, A and AAAA RR are relevant to this discussion)
> 
> Consider a sender $sender which is IPv4 only, has no clue about IPv6:
> 
> When asking for an MX RR, it gets zero answers. It will then ask for
> an A record and still get zero answers. It ends here.
> 
> 1) no MX record, no A, no AAAA
> or
> 2) no MX record, no A, only AAAA
> 
> According to $sender, these scenario's are the same. $sender will
> ignore AAAA records:
> 1) no MX record, no A
> 2) no MX record, no A
> 
> Apparently this domain is not a maildomain. It doesn't matter if the
> AAAA record is present or not.
> 
> IMPORTANT: a domain with no MX _and_ no A record, is not a maildomain.
> 
> This means an AAAA record is not an implicit MX record.

No, that doesn't follow at all. If all the MX records for a domain
contain hostnames with only AAAA records, the domain is just as
unreachable for an IPv4-only host as if it contained only an AAAA
record. And for a IPv6-only host it is just the other way around. 

Many people arguing for the "only A records are implicit MX records"
side seem to ignore the fact that an MX record doesn't contain an
address on the right side. It contains a host name, which still needs to
be resolved to an address (via an A or AAAA lookup). The implicit MX
record isn't "synthesized from an A record", it is synthesized from the
domain name. There is no difference between the A lookup on the
hostnames in the real MX records and the one in the implicit MX records,
and neither should there be a difference in the AAAA lookups on those
hostnames, unless you want to follow the principle of most surprise.

> Similar reasoning but now with MX records:
> 
> One or more MX records are found, thus a list of hostnames are built
> from it/them.  All AAAA records will be ignored, leaving only a set
> of A records and priorities.
> 
> If that set is empty, this is an error condition.
> 
> IMPORTANT: a domain with no A record in its MX set, is in error.

No. It is merely unreachable from IPv4. This is *probably* an error, but
may be intentional.

> This means the only valid setup for IPv6 hosts which want to receive
> mail is to have one or more MX records, with at least one A record in
> them.  That A record will point to a gateway.
> Any different setup will destroy email reliability.

Yes. Any IPv6-only host currently has very limited
internet-connectivity, and will need to use relays, proxies, or NAT to
use many services. But that's no different from many IPv4 hosts which
are behind firewalls, in RFC1918 networks, etc.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--C+ts3FVlLX8+P6JN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--C+ts3FVlLX8+P6JN--

Date: Sat, 5 Apr 2008 15:53:07 +0100
From: Tony Finch <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Michael Storz <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all know
Sender: [email-masked]

On Fri, 4 Apr 2008, Arnt Gulbrandsen wrote:
>
> You could say that the problem is that the host can be on the RHS of an email
> address anyway, and when it is, it kind of works but quite often it doesn't
> really work (because DSNs would be lost and other fringe problems). Earlier
> this week I found that about half of the MX-but-no-A domains in a sample of
> 30,000 recent nonspam messages weren't deliverable.

This is particularly common for email triggered by web forms.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOLE: NORTHEAST 5 TO 7. MODERATE BECOMING ROUGH. SHOWERS. MAINLY GOOD.

Date: Sat, 05 Apr 2008 10:25:05 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked], Tony Hansen <[email-masked]>, John C Klensin <[email-masked]>
Subject: How does SMTP IPv4 and IPv6 work together
Sender: [email-masked]

Since John thinks we are confused, I felt I owe it to myself if I 
summarized and outline what I thought was the technical compatibility 
issues to see if I understood it and was not confused.

As far as I concern, there ought not be any confusion but common sense 
modeling here when considering IPv6 in 2821bis.

We have three (3) possible models for a SMTP system:

      - Current IPv4 only system
      - Dual Stack IPv4/v6 system
      - A pure Ipv6 only system

When combined in client/server transactions, the following chart shows 
the possibilities in terms of minimum requirement for an implicit MX 
and/or A or AAAA records to perform a connection (communication) between 
two similar or hybrid systems:

  +-------------------------------------------+
  |          |            SENDER              |
  |          |--------------------------------|
  |RECEIVER  |  IPv4  |   IPv4/6    |  IPv6   |
  +----------+--------+-------------+---------|
  |          |        |             |         |
  |  IPv4    |   A    |     A       |  ****   |
  |          |        |             |         |
  |----------+--------+-------------+---------|
  |          |        |             |         |
  |  IPv4/6  |   A    |  A or AAAA  |  AAAA   |
  |          |        |             |         |
  |----------+--------+-------------+---------|
  |          |        |             |         |
  |  IPv6    |  ****  |    AAAA     |  AAAA   |
  |          |        |             |         |
  +-------------------------------------------+

The **** means that it the client/server can not communicate simply 
because each are not compatible in terms of TCP protocol.

The basic principle above is that new technology work with each other in 
the same way old technology work with each other, and in a hybrid 
situations, the common denominator method is used.

I believe 2821BIS need not go into details but to illustrate the key 
points of maintaining maximum compatibility.

Scenarios:

IPv4 to IPv4

   Status Quo - what we have today using the current IPv4 TCP layer.

IPv6 to IPv6

   Status Quo - what we have possible today and more tomorrow using
   a new pure IPv6 TCP layer.

IPv4 to IPv4/6

   Obviously the IPv4 system knows nothign about AAAA records or
   IPv6 TCP socket connections.  The A record can only be obtained
   via explicit MX or implicit MX.

IPv4 to IPv6
IPv6 to IPv4

   It is not possible for the IPv4 only system to talk to the IPv6
   system because each are using different TCP socket technology.

IPv4/6 to IPv4

   In this case, the IPv4/6 dual stack system performing a
   discovery on a IPv4 only system will find only A records.  With
   the IPv4/6 dual system having A records, it will allow the IPv4
   to return responses.

IPv4/6 to IPv4/6

   I presume these systems will use the maximum method (IPv6)
   available. What might be interesting here is a fall back to
   IPv4 if the IPv6 method fails due to some middle router
   compliancy issue or something else.

IPv4/6 to IPv6

   In the case, the sender will only see AAAA records and can only
   make a IPv6 socket connection.

IPv6 to IPv4/6

   In the case, the sender will only EXPECT AAAA records and can
   only make a IPv6 socket connection.

To me, this all makes common sense.  I think the text in 2821bis should 
simply lay down the possibilities as done above.  But I do think the 
above can be folded to make it into smaller text.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Sat, 5 Apr 2008 14:26:50 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Why implicit MX is a bad idea for IPv6
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Here's why implicit MX for IPv6 is a bad idea.

Summary:
a domain with no MX _and_ no A record, is not a maildomain.
a domain with no A record in its MX set, is in error.

Interoperability in combination with the least surprise principle
dictates that IPv6 AAAA RR cannot function as implicit MX.

(only MX, A and AAAA RR are relevant to this discussion)

Consider a sender $sender which is IPv4 only, has no clue about IPv6:

When asking for an MX RR, it gets zero answers. It will then ask for
an A record and still get zero answers. It ends here.

1) no MX record, no A, no AAAA
or
2) no MX record, no A, only AAAA

According to $sender, these scenario's are the same. $sender will
ignore AAAA records:
1) no MX record, no A
2) no MX record, no A

Apparently this domain is not a maildomain. It doesn't matter if the
AAAA record is present or not.

IMPORTANT: a domain with no MX _and_ no A record, is not a maildomain.

This means an AAAA record is not an implicit MX record.

Similar reasoning but now with MX records:

One or more MX records are found, thus a list of hostnames are built
from it/them.  All AAAA records will be ignored, leaving only a set
of A records and priorities.

If that set is empty, this is an error condition.

IMPORTANT: a domain with no A record in its MX set, is in error.

This means the only valid setup for IPv6 hosts which want to receive
mail is to have one or more MX records, with at least one A record in
them.  That A record will point to a gateway.
Any different setup will destroy email reliability.

The other way around, an IPv6-only sender trying to send mail to an
IPv4-only maildomain, is a problem which the IPv6 host must resolve
by using the gateway again.  IPv4-only receivers should not be bothered
with this.

Date: Sat, 5 Apr 2008 11:38:46 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

On Fri, 4 Apr 2008, Robert A. Rosenberg wrote:

>
> At 13:46 +0200 on 04/04/2008, Michael Storz wrote about Re: current
> usage of AAAA implicit MX?:
>
> >On Thu, 3 Apr 2008, Tony Hansen wrote:
> >
> >>  I'm looking for help answering these questions:
> >>
> >>     *	How are existing IPv6-enabled mail sites actually dealing with
> >>	missing MX records?
> >>
> >>     *	Are the IPv6-enabled email sites mostly following the
> >>	recommendations found in RFC 3974?
> >>
> >>     *	How widespread is the use of implicit MX with AAAA records? That
> >>	is, how prevalent are email sites that do not have MX records
> >>	but do have AAAA records?
> >>
> >>     *	How big is the existing IPv6-enabled email world?
> >>
> >>     *	What problems, if any, has been experienced by following RFC
> >>	3974?
> >
> >From my standpoint of view, the existing IPv6-enabled email world is
> >really small.
> >
> >At the moment we are in the transition to dual-stack MTAs. Therefore I
> >have only data about some of our domains which are reachable by IPv6 from
> >the Internet. We do not send emails via IPv6 to the Internet.
> >
> >- number of MTAs from which we accepted emails over IPv6: 255
> >- number of MTAs in addition to above, from which we rejected emails: 303
> >   (mainly backscatter DSNs to unknown recipients)
> >- number of MTAs from which we accepted emails over IPv4: 44793
> >
> >The MTAs, from which the data comes, are responsible for a major part of
> >the Munich Scientific Network with 4 universities and several colleges and
> >scientific institutions.
> >
> >[snip]
> >I hope this helps and is not to much data.
> >
> >Michael Storz
>
> Your numbers are interesting but are missing the most important statistics:
>

I am not sure if I understand you correctly, but I'll try to answer your
questions.

> - Number of IPv6 MTA Servers you are running (ie: Those that are
> receiving email from those 255 IPv6 MTAs and rejecting from those 303
> IPv6 MTAs) and how many different FQDNs these MTAs are servicing.

This was just one MTA postrelay1.lrz-muenchen.de. I did not use the data
from the second MTA postrelay2. They servce about 25 domains with about
60.000 addresses. As I said before, we are in a transition to dual-stack.
All the other hundreds of domains are routed via the single-stack MTAs
mailrelay1 and mailrelay2.

> - Number of your IPv6 MTAs which are located via MX records.

2 MTAs: postrelay1 and postrelay2

> - Number of your IPv6 MTAs which must be located via AAAA (ie: Which
> belong to a FQDN with no IPv6 MX).

None. And this is also true for IPv4. All of the hundreds of local MTAs in
the Munich Scientific Network (MWN) are routed via MX RRs to our MTAs or
to the MTAs of their departemental email servers. Port 25 is blocked from
the Internet to the MWN since 10 years.

Does this answer your question?

>
> The only REALLY important numbers are the IPv6 MTAs whose FQDN maps
> to an MX vs those who only get mapped via an AAAA record.
>
> Having 500 or 50,000 FQDNs mapped to incoming IPv6 servers is only
> important if you know how many must be reached/located via AAAA
> records due to the lack of a MX record set for the FQDN.
>
> This same measure for IPv4 reachable FQDNs would be interesting but
> only to show how many of these FQDNs still lack a MX 15-20 years
> after the need for A Lookup was made unneeded by the introduction of
> the MX record (except for those MTAs that are still running using a
> MTA package that does not support MX lookup or has this ability
> disabled).
>
>

Michael Storz

Date: Sat, 05 Apr 2008 03:39:46 -0400
From: John C Klensin <[email-masked]>
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

--On Wednesday, 02 April, 2008 00:17 -0400 "Robert A. Rosenberg"
<[email-masked]> wrote:

> 
> At 23:00 -0400 on 03/31/2008, John C Klensin wrote about Re:
> Minor is. It's not a pardigm change:
> 
>> Once that implicit MX record exists, there are fairly clear
>> rules  about which address to use for foo.example.com.   To
>> be a little  more precise, while the rules are clear, they
>> pretty much leave it  up to the sending host and there is no
>> real difference between the  traditional choice between the
>> two IPv4 addresses and the newer  choice between the IPv4
>> addresses and the IPv6 one.   The Standard  also gives the
>> sender implementation some flexibility about how many  of
>> those addresses it is obligated to try.
> 
> I disagree with your methodology. If the rule is that incoming
> MTAs (ie: Those MTAs that are supposed to be located via MXs)
> which listen at an IPv6 IPN are REQUIRED to be designed by an
> MX (ie: You are not treated as an incoming IPv6 MTA UNLESS you
> are pointed to by an MX), any implicate MX that is built in
> the absence of an EXPLICATE MX should contain ONLY the A
> records for that FQDN. Any AAAA records for the FQDN are
> ignored in building the implicate MX.

This is interesting, but I have no idea what you are talking
about.  MX records contain names, not address records in the
DATA.  That has been clear since the beginning and 2821
reinforces it.  Certainly it is possible to assign one DNS name
to the set of IPv4 interfaces on a host and another name to the
set of IPv6 interfaces, but, as soon as one does that, there
are, as far as the DNS is concerned, two separate hosts.

If I correctly understand what you are suggesting, it is that,
if I have

   foo.example.com.  IN A #.#....
                     IN AAAA #:#:...

My SMTP client should somehow generate, not the implicit MX
called for by 2821bis (and 2821), which is

   foo.example.com.  IN MX 0 foo.example.com.

but some sort of MX arrangement that points to the A RR only and
not to the AAAA RR.   There is just no way to do that, at least
without putting completely new language in 2821bis that
distinguishes between the interpretation rules for implicit and
explicit MX records (and getting hopelessly entangled with and
overriding RFC 3484).

So what are you suggesting?

    john

Date: Sat, 05 Apr 2008 03:22:37 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Implicit MXs - asking the question more clearly (was: Re: Scope Creep)
Sender: [email-masked]

I'm going to make another attempt at getting clearly focus on
the question here...

--On Wednesday, 02 April, 2008 12:38 -0700 Dave Crocker
<[email-masked]> wrote:
 
> John C Klensin wrote:
>  > --On Wednesday, April 02, 2008 11:25 AM -0700 Lisa
> Dusseault wrote:
>  >> WWTHD (What Would Ted Hardie Do): be blunt.   "After much
>  >> discussion on the topic, this specification does not extend
>  >> the A rule to AAAA records, but neither does it preclude a
>  >> parallel treatment."
> 
>> That leaves an ambiguity about behavior from which neither
>> SMTP clients  nor domain administrators can figure out what
>> to do. To me, that  ambiguity is the one case that is a
>> showstopper. It also, IMO, creates a  "known technical
>> defect" and that would exclude even publishing  something as
>> Proposed, much less Draft.
>> 
>> I see no way to avoid making a choice.
>> 
>> I think I and several others have said this before, but I can
>> live with  anything that (i) does not create an ambiguity and
>> (ii) does not  deprecate the existing (back to 974) behavior.
 
> I'm sorry to say that I see a way to deal with v6, without
> dealing with it.
> 
> Unfortunately, I see Lisa's language as too specific as well
> as too varied. "does not extend...to...but neither does it
> precludes" is, I believe, semantically equivalent to saying
> "is out of scope".  That's language that is more typical in
> IETF specifications.
> 
> So I think the choice is between
> 
> 1. The current draft language, which treats "direct" addresses
> as a list and names two entries, A and AAAA, explicilty, versus
> 
> 2. Language which cites A but declares all other details out
> of scope, using language like:
> 
>      "In the absence of indirect addressing, via a DNS MX
> record, this specification provides for use of direct
> addressing via IPv4 DNS A records.  Use of other direct
> addresses is out of scope."
> 
> 
> FWIW, I vote for 1.  v6 is too real to ignore.
> 
> I also suspect a diligent IESG would enforce including it as a
> requirement.

Dave,

While I agree with your vote for (1) -- somewhat more strongly
now than before reading and following the various threads in
this overheated and confused conversation --  I don't see (2) as
plausible.  If I'm going to configure DNS records for a host
that is IPv6-only, and that host might receive mail (or even
send it and receive bounce messages), I have to know whether, if
I simply put in an AAAA record, a mail client will find the
host.   There really are no "maybe" cases, whether stated as
MAY, as optional behavior,  or as outside the scope of the
standard, because, in practice, they are all equivalent to "no
implicit MX when AAAA is present without A; if you want mail and
want that to be predictable, the MX record MUST be there".

Although some variations in wording are possible, there is only
one way to say "one can reliably find and send mail to an
IPv6-only host without an explicit MX record" and that text is
in 2821bis-09 today.  All of the other statements amount to
"explicit MX required for IPv6-only hosts".

The sources of confusion in these discussions are issues that
may shed light on how the decision should be made about
IPv6-only hosts, but they are, themselves, out of scope for the
2821bis discussion, at least IMO.  Those discussions include the
question of whether it is time to deprecate implicit MXs
entirely, how to use the DNS to indicate that a host does not
want to receive mail, and what can be done in the absence of MX
records (and even DNS address records) if the sender has
preconfigured out of band information.

It is clear, at least to me, that none of the discussion applies
to dual-stack hosts that are shown in the DNS as dual-stack,
i.e., with both A and AAAA records associated with the same DNS
node.  If  there is no MX record at that node, the implicit MX
record will be generated because the A RR is there; the AAAA
record is irrelevant to its generation.  And if the MX record,
explicit or implicit, points to a node that has multiple address
records (A alone, AAAA alone, or mixed) the selection rules are
well-define elsewhere are well understood... even if they are
understood to permit more client choices and variations than
some people might like.

     john

Date: 5 Apr 2008 01:30:19 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>ps.  While surveys are always useful, I'll repeat the observation
>that changing the query model for SMTP is out of scope.

Dave, you're assuming your conclusion.

What we're trying to settle here is whether the existing query model
is synthesize from A or synthesize from any address record.  I don't
see overwhelming support in the existing holy writ for either
position.

R's,
John

To: Paul Hoffman <[email-masked]>
Cc: Michael Storz <[email-masked]>, SMTP Interest Group <[email-masked]>
From: Mark Andrews <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all know 
Date: Sat, 05 Apr 2008 10:54:03 +1100
Sender: [email-masked]

> 
> At 6:58 PM +0200 4/4/08, Michael Storz wrote:
> >Now, we can speculate
> >
> >- Is the missing MX RR by intention?
> 
> Yes. Is there an email address at mail.imc.org that you wanted to send mail t
> o.
> 
> >- Is the administrator clueless?
> 
> Sometimes.
> 
> >- Is he lazy?
> 
> Often times.
> 
> >- Is it just a configuration error (mail.imc.org instead of imc.org)?
> 
> No. imc.org has an MX record, and has for over a decae.
> 
> >or we could just ask Paul Hoffman :-)
> 
> Or, you can be more specific. What is the problem of a host that is 
> never expected to be on the RHS of an email address expected to have 
> an MX record? That's an honest question, given that it has been over 
> 12 years with the current setup.

	mail.imc.org leaks.

	Return-Path: [email-masked]

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

Date: Fri, 4 Apr 2008 17:30:29 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 12:56 -0400 on 04/04/2008, Tony Hansen wrote about Re: current 
usage of AAAA implicit MX?:

>These questions are intended to find out what current IPv6 deployments
>do in these situations. When an MX is not found, are they already
>looking for both A and AAAA records, or are they only looking for A
>records. Are they following RFC 3974 or not? What's the installed base
>already doing?

RFC 3974 talks about Dual Stack set-ups and what an IPv4-Only Server 
should do when presented with a Mixed MX or an MX that only points at 
IPv6 AAAA records. It, BTW, REQUIRES an MX if there are any IPv6 MTAs 
and only supports A-Fallback in the absence of an MX (ie: It does NOT 
define any attempt to look for AAAA records in the absence of an MX 
after/before checking for A records).

It also states that in the presence of an MX containing IPv6 address 
references, an IPv4-Only stack should ignore the IPv6 addresses and 
only use the IPv4 addresses (and in a IPv6-Only MX to NOT do 
IPv4-A-Record fallback).

Date: Fri, 4 Apr 2008 17:15:35 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 13:46 +0200 on 04/04/2008, Michael Storz wrote about Re: current 
usage of AAAA implicit MX?:

>On Thu, 3 Apr 2008, Tony Hansen wrote:
>
>>  I'm looking for help answering these questions:
>>
>>     *	How are existing IPv6-enabled mail sites actually dealing with
>>	missing MX records?
>>
>>     *	Are the IPv6-enabled email sites mostly following the
>>	recommendations found in RFC 3974?
>>
>>     *	How widespread is the use of implicit MX with AAAA records? That
>>	is, how prevalent are email sites that do not have MX records
>>	but do have AAAA records?
>>
>>     *	How big is the existing IPv6-enabled email world?
>>
>>     *	What problems, if any, has been experienced by following RFC
>>	3974?
>
>From my standpoint of view, the existing IPv6-enabled email world is
>really small.
>
>At the moment we are in the transition to dual-stack MTAs. Therefore I
>have only data about some of our domains which are reachable by IPv6 from
>the Internet. We do not send emails via IPv6 to the Internet.
>
>- number of MTAs from which we accepted emails over IPv6: 255
>- number of MTAs in addition to above, from which we rejected emails: 303
>   (mainly backscatter DSNs to unknown recipients)
>- number of MTAs from which we accepted emails over IPv4: 44793
>
>The MTAs, from which the data comes, are responsible for a major part of
>the Munich Scientific Network with 4 universities and several colleges and
>scientific institutions.
>
>[snip]
>I hope this helps and is not to much data.
>
>Michael Storz

Your numbers are interesting but are missing the most important statistics:

- Number of IPv6 MTA Servers you are running (ie: Those that are 
receiving email from those 255 IPv6 MTAs and rejecting from those 303 
IPv6 MTAs) and how many different FQDNs these MTAs are servicing.
- Number of your IPv6 MTAs which are located via MX records.
- Number of your IPv6 MTAs which must be located via AAAA (ie: Which 
belong to a FQDN with no IPv6 MX).

The only REALLY important numbers are the IPv6 MTAs whose FQDN maps 
to an MX vs those who only get mapped via an AAAA record.

Having 500 or 50,000 FQDNs mapped to incoming IPv6 servers is only 
important if you know how many must be reached/located via AAAA 
records due to the lack of a MX record set for the FQDN.

This same measure for IPv4 reachable FQDNs would be interesting but 
only to show how many of these FQDNs still lack a MX 15-20 years 
after the need for A Lookup was made unneeded by the introduction of 
the MX record (except for those MTAs that are still running using a 
MTA package that does not support MX lookup or has this ability 
disabled).

Date: Fri, 4 Apr 2008 17:50:12 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all know
Sender: [email-masked]

At 21:09 +0200 on 04/04/2008, Arnt Gulbrandsen wrote about Re: There 
is at least one email server without MX RR but AA:

>You could say that the problem is that the host can be on the RHS of an
>email address anyway, and when it is, it kind of works but quite often
>it doesn't really work (because DSNs would be lost and other fringe
>problems). Earlier this week I found that about half of the MX-but-no-A
>domains in a sample of 30,000 recent nonspam messages weren't
>deliverable.
>
>Arnt

That is a configuration error in that the MX does not point at a MTA 
that is willing to accept the message.

Going FQDN MX does NOT require FQDN on the RHS (or a FQDN A record) 
but only one or more FQDNXs on the RHS who are willing to accept the 
email (and have A and/or AAAA records).

Date: Fri, 4 Apr 2008 17:40:57 -0400
To: SMTP Interest Group <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

At 10:27 -0700 on 04/04/2008, Dave Crocker wrote about Re: current 
usage of AAAA implicit MX?:

>ps.  While surveys are always useful, I'll repeat the observation 
>that changing the query model for SMTP is out of scope. The current 
>model is 1) look for MX, 2) look for address record (A and/or AAAA). 
>Anything that removes step 2 is a model change.

What is being talked about is NOT removing Step 2 but restricting it 
to looking at A records. Looking at AAAA records in Step 2 should not 
be allowed since due to the ability to use an MX record to point at 
an IPv6 MTA, there is NO NEED (unlike the IPv4 case due to historical 
support for locating an IPv4 MTS directly by its A record) to EVER 
expect that an IPv6 MTA should/can be DIRECTLY locatable via its AAAA 
record.

Even RFC 3974 talks ONLY about the use of MX records to locate IPv6 MTAs.

Date: Fri, 4 Apr 2008 22:46:17 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: current usage of AAAA implicit MX?
Cc: Tony Hansen <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Since data entry software matters and noone else has mentioned that 
area, I searched CPAN and found three modules to help verify email 
addresses in web forms etc., namely Mail::Verify, Net::validMX and 
Email::Valid. All three do MX/A lookups, none do AAAA lookups.

Arnt

Date: Fri, 4 Apr 2008 22:27:30 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Tony Hansen <[email-masked]>, Lisa Dusseault <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

On Fri, 4 Apr 2008, Arnt Gulbrandsen wrote:

> Michael Storz writes:
> > - number of MTAs from which we accepted emails over IPv6: 255
>
> Perhaps you could take the email addresses sent to you by those MTAs and
> see how many have MX records, how many only A and how many only AAAA?
>
> Arnt
>

Ok, I've done that. It took some time and I don't know if it is helpful.

>From the 255 MTAs, I got emails with 504 different domains in 'mail from'
(I excluded the outgoing servers of the german ISP freenet.de, because it
would distort the statistik).

160 domains have a path back over IPv6, 155 via MX RRs and 5 via A/AAAA
RRs only:

ok: art.wga.hu -A->    148.6.0.90 -PTR-> art.wga.hu
no:                               -PTR-> www.hung-art.hu -A-> 148.6.0.90
ok:            -AAAA-> 2001:738:5001:0:0:0:0:90 -PTR-> art.wga.hu
no:                                             -PTR-> www.hung-art.hu -AAAA-> 2001:738:5001:0:0:0:0:90

no: mail.imc.org -A->    192.245.12.227 -PTR-> Balder-227.Proper.COM -A-> 192.245.12.227
no:              -AAAA-> 2001:470:1F04:392:0:0:0:2 -PTR-> properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net -AAAA-> NXDOMAIN

ok: mail.utef.cvut.cz -A->    147.32.68.12 -PTR-> mail.utef.cvut.cz
ok:                   -AAAA-> 2001:718:2:2600:0:0:0:3 -PTR-> mail.utef.cvut.cz

no: mailman.teg-ev.de -A->    193.99.159.73 -PTR-> teg.v-pe.de -A-> 193.99.159.73
no:                   -AAAA-> 2001:600:1003:1:0:0:0:73 -PTR-> teg.v-pe.de -AAAA-> 2001:600:1003:1:0:0:0:73

ok: s5.stud.ku.dk -A->    130.225.126.137 -PTR-> s5.stud.ku.dk
ok:               -AAAA-> 2001:878:100:12:0:0:0:137 -PTR-> s5.stud.ku.dk

3 of them are the email servers of their domain without host subdomain:

% dig +short imc.org mx
5 mail.imc.org.
% dig +short utef.cvut.cz mx
10 regulus.utef.cvut.cz.
% dig +short regulus.utef.cvut.cz AAAA
mail.utef.cvut.cz.
2001:718:2:2600::3
% dig +short teg-ev.de mx
0 mail.teg-ev.de.
% dig +short mail.teg-ev.de AAAA
2001:600:1003:1::73

>From the 155 MX RRs

- 58 MX RRs, where all hosts have A + AAAA RRs
- 44 MX RRs, which point to one host which has A + AAAA RRs
- 43 MX RRs, where at least one of the backup MX has only A RRs, all
  others with A and AAAA RRs
- 5 MX RRs, where the primary has only A RRs, but backup has A and AAAA
  RRs
- 5 MX RRs with mixed hosts, same prio but some have only A RRs other both
- 0 MX where one of the hosts has only an AAAA RR, which means
  prioritizing a protocol is not used

and

- 3 of the MX point to themselves, which means the domains are hosts with
MX RRs.

Michael Storz

Date: Fri, 04 Apr 2008 16:21:38 -0400
From: John C Klensin <[email-masked]>
To: Tony Hansen <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

--On Friday, 04 April, 2008 13:06 -0400 Tony Hansen
<[email-masked]> wrote:

> I got the following message and received permission to repost
> it here.
> 
> 	Tony Hansen
> 	[email-masked]
> 
> From: "Steinar H. Gunderson" <[email-masked]>
> 
> Hi,
> 
> Harald sent this on to me, as I've set up and help administer
> the a real-world e-mail setup with IPv6 support. I'm not sure
> how much I can help you with the other points, but I can tell
> you that there is at least one site accepting e-mail with an
> AAAA record only -- my home machine. :-)
> 
> Apart from that, I don't think you can remove delivering
> e-mail directly to AAAA records; it's already supported in
> MTAs out there, and you can be pretty sure it's actually being
> used. Besides, if you sent mail to [email-masked], and
> example.org had both A and AAAA records (but no MX), should
> you really not try delivering on IPv6?

Tony,

While this is useful, it also illustrates that we still haven't
managed to make clear what problem we are talking about.  If you
sent mail to [email-masked], and "both A and AAAA records (but
no MX)" are present, then

(i) Under the scenario in which an implicit MX is generated only
for A RRs, 
     example.org.  IN MX 0 example.org.
would be implied.

(ii) Under the scenario in which an implicit MX is generated for
either A or AAAA RRs, 
     example.org.  IN MX 0 example.org.
would be implied -- exactly the same.

Once
     example.org.  IN MX 0 example.org.
exists, whether explicit or derived from the presence of the A
RR, it would be, IMO, a serious misunderstanding of the protocol
to claim that delivery to the AAAA interface is prohibited.  

I don't think that is at issue here.  I think the _only_ issue
is whether or not, if a given domain name has no MX record(s)
_and_ no A record(s), but has at least one AAAA record, whether
that implies that a mail client should synthesize the implied MX
and then consider it as a mail-delivery destination.

The confusion about what is actually the question is beginning
to concern me more than the question itself.  I know this isn't
your fault, but we need to figure out how to explain this better.

     john

> 
> /* Steinar */
> -- Software Engineer, Google Norway
> 

Date: Fri, 4 Apr 2008 21:44:53 +0200
From: "Peter J. Holzer" <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Mail-Followup-To: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

--eJnRUKwClWJh1Khz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-03 16:32:17 -0400, Tony Hansen wrote:
> Before we can put the issue of AAAA implicit MX to bed, we need to get 
> an answer to the question of how much AAAA implicit MX is already being 
> used in the real world.
> 
> It's been postulated that the current deployment of this and its use is 
> low. However, RFC 3974 (SMTP Operational Experience in Mixed IPv4/v6 
> Environments), was published three years ago, and it mandates AAAA 
> implicit MX (as much as an informational document can mandate anything).
> 
> So I'm looking for information from people who are currently working in 
> the IPv6-based email world.

I am not, but I just looked (briefly) at the source code of postfix 2.5.1.

As far as I can see, it treats the "implicit MX" exactly the same as any
"explicit MX". There is no "if this was an implicit MX then ignore AAAA
records" special case.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--eJnRUKwClWJh1Khz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--eJnRUKwClWJh1Khz--

Date: Fri, 04 Apr 2008 12:25:52 -0700
To: Paul Hoffman <[email-masked]>, Michael Storz <[email-masked]>, SMTP Interest Group <[email-masked]>
From: SM <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all  know
Sender: [email-masked]

At 11:21 04-04-2008, Paul Hoffman wrote:
>Yes. Is there an email address at mail.imc.org that you wanted to 
>send mail to.

If there is a delivery problem for mail coming from this mailing 
list, my mail server sends an email notification to 
[email-masked].

>Or, you can be more specific. What is the problem of a host that is 
>never expected to be on the RHS of an email address expected to have 
>an MX record? That's an honest question, given that it has been over 
>12 years with the current setup.

The host is on the RHS of an email address.  That's been the case for 
quite some time.

Regards,
-sm

Date: Fri, 4 Apr 2008 21:15:04 +0200
From: "Peter J. Holzer" <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all  know
Mail-Followup-To: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-04 11:21:46 -0700, Paul Hoffman wrote:
> 
> At 6:58 PM +0200 4/4/08, Michael Storz wrote:
> >Now, we can speculate
> >
> >- Is the missing MX RR by intention?
> 
> Yes. Is there an email address at mail.imc.org that you wanted to send mail 
> to.

Yes, there is. Or maybe I don't want to, but my MTA may want to:

<[email-masked]>

This address is accepted, but random addresses at mail.imc.org aren't:

250 2.1.5 <[email-masked]>... Recipient ok
550 5.1.1 <[email-masked]>... User unknown

> >or we could just ask Paul Hoffman :-)
> 
> Or, you can be more specific. What is the problem of a host that is 
> never expected to be on the RHS of an email address expected to have 
> an MX record?

It may not be expected to be there, but it is - just look at the return
path of any message of this list.

> That's an honest question, given that it has been over 
> 12 years with the current setup.

The current setup is RFC-2821 compliant (although one could quibble
whether mail.imc.org is really the "canonical" name of the host). It's
just an example where a domain name without an MX record is on the RHS
of email addresses. That doesn't seem to be intentional, judging from
your reaction.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--opJtzjQTFsWo+cga--

Date: Fri, 4 Apr 2008 21:09:44 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: There is at least one email server without MX RR but AAAA RR we all know
Cc: Michael Storz <[email-masked]>, Paul Hoffman <[email-masked]>
Sender: [email-masked]

Paul Hoffman writes:
> What is the problem of a host that is never expected to be on the RHS 
> of an email address expected to have an MX record? That's an honest 
> question, given that it has been over 12 years with the current 
> setup.

(mail.imc.org is on the RHS of 10 addresses in my mail archive, 
including [email-masked] and [email-masked].)

You could say that the problem is that the host can be on the RHS of an 
email address anyway, and when it is, it kind of works but quite often 
it doesn't really work (because DSNs would be lost and other fringe 
problems). Earlier this week I found that about half of the MX-but-no-A 
domains in a sample of 30,000 recent nonspam messages weren't 
deliverable.

Arnt

Date: Fri, 4 Apr 2008 20:59:59 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: Paul Hoffman <[email-masked]>
cc: SMTP Interest Group <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all  know
Sender: [email-masked]

On Fri, 4 Apr 2008, Paul Hoffman wrote:

>
> At 6:58 PM +0200 4/4/08, Michael Storz wrote:
> >Now, we can speculate
> >
> >- Is the missing MX RR by intention?
>
> Yes. Is there an email address at mail.imc.org that you wanted to send mail to.
>
> >- Is the administrator clueless?
>
> Sometimes.
>
> >- Is he lazy?
>
> Often times.
>
> >- Is it just a configuration error (mail.imc.org instead of imc.org)?
>
> No. imc.org has an MX record, and has for over a decae.
>
> >or we could just ask Paul Hoffman :-)
>
> Or, you can be more specific. What is the problem of a host that is
> never expected to be on the RHS of an email address expected to have
> an MX record? That's an honest question, given that it has been over
> 12 years with the current setup.
>
Sorry for not being specific enough, I thought it would be obvious after
looking into the header of the message. I am referring to the address
[email-masked]. In the meantime I am convinced that it is a
configuration error, because I looked into my archive:

>From [email-masked] Wed Oct 27 04:22 MET 1999
>From [email-masked] Wed Nov  3 00:37 MET 1999
>From [email-masked] Wed Nov  3 07:14 MET 1999
>From [email-masked] Fri Mar 10 23:22 MET 2000
>From [email-masked] Sat Mar 11 00:30 MET 2000

Regards,
Michael Storz
--
===========================
Leibniz-Rechenzentrum      |    <mailto:[email-masked]>
Boltzmannstr. 1            |    Fax: +49 89 35831-9700
85748 Garching / Germany   |    Tel: +49 89 35831-8840
===========================

Date: Fri, 4 Apr 2008 20:50:12 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all  know
Reply-To: [email-masked]
Mail-Followup-To: SMTP Interest Group <[email-masked]>
Sender: [email-masked]

On Fri, Apr 04, 2008 at 11:21:46AM -0700, Paul Hoffman wrote:

> Or, you can be more specific. What is the problem of a host that is 
> never expected to be on the RHS of an email address expected to have 
> an MX record? That's an honest question, given that it has been over 
> 12 years with the current setup.

This message came from [email-masked], which is such
an address.

We need to find the place to drop a return-to-sender:

Before 2821:  lookup an MX record for $RHS
If not found: lookup the address of $RHS and pretend it was an MX.

During 2821:  lookup an MX record for $RHS
If not found: lookup the A-record(s) for $RHS and pretend it was an MX.

After 2821:   lookup an MX record for $RHS
If not found: currently under debate.
  a) stay with looking up A-records (i.e. no AAAA fall back, only A)
  b) change back to looking up addresses (i.e. A and AAAA fall back)

Date: Fri, 4 Apr 2008 11:27:52 -0700
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all know
Sender: [email-masked]

On Fri, 2008-04-04, John Levine wrote:

>>There is no MX RR for mail.imc.org, but it has an A and an AAAA RR:

> Right.  Since there are no addresses [email-masked] and no mail is
> sent with a @xxx.imc.org address, that's how it should be. 

I agree, but then one wonders about:

Return-Path: [email-masked]
                             ^^^^             ;-)

-- 
Bill McQuillan <[email-masked]>

Date: Fri, 4 Apr 2008 11:21:46 -0700
To: Michael Storz <[email-masked]>, SMTP Interest Group <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all  know
Sender: [email-masked]

At 6:58 PM +0200 4/4/08, Michael Storz wrote:
>Now, we can speculate
>
>- Is the missing MX RR by intention?

Yes. Is there an email address at mail.imc.org that you wanted to send mail to.

>- Is the administrator clueless?

Sometimes.

>- Is he lazy?

Often times.

>- Is it just a configuration error (mail.imc.org instead of imc.org)?

No. imc.org has an MX record, and has for over a decae.

>or we could just ask Paul Hoffman :-)

Or, you can be more specific. What is the problem of a host that is 
never expected to be on the RHS of an email address expected to have 
an MX record? That's an honest question, given that it has been over 
12 years with the current setup.

Date: Fri, 04 Apr 2008 11:02:35 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Dave Crocker wrote:
>> By "AAAA implicit MX", I mean: What happens if there is no MX record? 
> 
> 
> ahh.  understand.
> 
> May I suggest that we call it what it is:  No-MX.

my bad.

i don't recall hearing the term 'implicit mx' used before, but it's been 
politely pointed out to me that it is in rfc2821.

we shall now all suffer a roseanna-dana moment:  never mind...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: 4 Apr 2008 17:54:30 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: There is at least one email server without MX RR but AAAA RR we all know
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>There is no MX RR for mail.imc.org, but it has an A and an AAAA RR:

Right.  Since there are no addresses [email-masked] and no mail is
sent with a @xxx.imc.org address, that's how it should be.  Depending
on how Paul has his server set up, mail to addresses like that might
be rejected quickly, might return a DSN, might time out after a week,
might accidentally be mapped to the corresponding [email-masked], or
might go into a black hole somewhere.

This is exactly the situation that works better without implicit MX.

R's,
John

Date: Fri, 04 Apr 2008 10:27:12 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Tony Hansen <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Tony Hansen wrote:
> 
> Thanks for the tweak to the nose Dave. ;-)
> 
> By "AAAA implicit MX", I mean: What happens if there is no MX record? 

ahh.  understand.

May I suggest that we call it what it is:  No-MX.

It's simple and -- small pun -- direct.  No overloading or bias. No chance of 
misunderstanding.

As for querying what people are already doing, that's always a good idea.  I 
just want to make sure everyone know what is being queried.

d/

ps.  While surveys are always useful, I'll repeat the observation that changing 
the query model for SMTP is out of scope. The current model is 1) look for MX, 
2) look for address record (A and/or AAAA).  Anything that removes step 2 is a 
model change.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 04 Apr 2008 11:18:02 -0600
From: Willie Gillespie <[email-masked]>
Organization: Engineering System Solutions
To: Michael Storz <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: There is at least one email server without MX RR but AAAA RR we all know
Sender: [email-masked]

Well, I send mail to [email-masked] to send to this list.  Therefore,
the domain is imc.org.

% dig +short MX imc.org
5 mail.imc.org.

So, since there is an MX record, I know that I should send my e-mail to
mail.imc.org, which happens to have A and AAAA records.

Willie

Michael Storz wrote:
> BTW, there is at least one email server without MX RR but AAAA RR we all
> know. Just look into the header of this message. Do you see the
> Return-Path? Yes? Well, you've found the host I mean.
> 
> There is no MX RR for mail.imc.org, but it has an A and an AAAA RR:
> 
> % dig +short mail.imc.org A
> 192.245.12.227
> % dig +short mail.imc.org AAAA
> 2001:470:1f04:392::2
> 
> Unfortunately, it does not have a corespondig/correct
> reverse-forward-mapping :-(
> 
> % display_fwrev_mapping mail.imc.org
> no: mail.imc.org -A->    192.245.12.227 -PTR-> Balder-227.Proper.COM -A-> 192.245.12.227
> no:              -AAAA-> 2001:470:1F04:392:0:0:0:2 -PTR-> properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net -AAAA-> NXDOMAIN
> 
> Now, we can speculate
> 
> - Is the missing MX RR by intention?
> - Is the administrator clueless?
> - Is he lazy?
> - Is it just a configuration error (mail.imc.org instead of imc.org)?
> 
> or we could just ask Paul Hoffman :-)
> 
> Regards,
> Michael Storz
> 

Date: Fri, 04 Apr 2008 13:06:49 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

I got the following message and received permission to repost it here.

	Tony Hansen
	[email-masked]

From: "Steinar H. Gunderson" <[email-masked]>

Hi,

Harald sent this on to me, as I've set up and help administer the a 
real-world e-mail setup with IPv6 support. I'm not sure how much I can 
help you with the other points, but I can tell you that there is at 
least one site accepting e-mail with an AAAA record only -- my home 
machine. :-)

Apart from that, I don't think you can remove delivering e-mail directly 
to AAAA records; it's already supported in MTAs out there, and you can 
be pretty sure it's actually being used. Besides, if you sent mail to 
[email-masked], and example.org had both A and AAAA records (but no 
MX), should you really not try delivering on IPv6?

/* Steinar */
-- Software Engineer, Google Norway

Date: Fri, 4 Apr 2008 18:58:17 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: SMTP Interest Group <[email-masked]>
cc: [email-masked]
Subject: There is at least one email server without MX RR but AAAA RR we all know
Sender: [email-masked]

BTW, there is at least one email server without MX RR but AAAA RR we all
know. Just look into the header of this message. Do you see the
Return-Path? Yes? Well, you've found the host I mean.

There is no MX RR for mail.imc.org, but it has an A and an AAAA RR:

% dig +short mail.imc.org A
192.245.12.227
% dig +short mail.imc.org AAAA
2001:470:1f04:392::2

Unfortunately, it does not have a corespondig/correct
reverse-forward-mapping :-(

% display_fwrev_mapping mail.imc.org
no: mail.imc.org -A->    192.245.12.227 -PTR-> Balder-227.Proper.COM -A-> 192.245.12.227
no:              -AAAA-> 2001:470:1F04:392:0:0:0:2 -PTR-> properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net -AAAA-> NXDOMAIN

Now, we can speculate

- Is the missing MX RR by intention?
- Is the administrator clueless?
- Is he lazy?
- Is it just a configuration error (mail.imc.org instead of imc.org)?

or we could just ask Paul Hoffman :-)

Regards,
Michael Storz

Date: Fri, 04 Apr 2008 12:56:15 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Thanks for the tweak to the nose Dave. ;-)

By "AAAA implicit MX", I mean: What happens if there is no MX record? 
Does SMTP we fall back to 1) looking for A records, or 2) looking for 
both A and AAAA records?

These questions are intended to find out what current IPv6 deployments 
do in these situations. When an MX is not found, are they already 
looking for both A and AAAA records, or are they only looking for A 
records. Are they following RFC 3974 or not? What's the installed base 
already doing?

	Tony

Dave Crocker wrote:
> 
> 
> 
> Tony Hansen wrote:
>> Before we can put the issue of AAAA implicit MX to bed, we need to get 
>> an answer to the question of how much AAAA implicit MX is already 
>> being used in the real world.
> 
> 
> 1. I apologize both for poor memory and for being so thoroughly dense, 
> but I don't know what "implicit MX" means and would appreciate a simple 
> definition that folks agree on.
> 
> 
> 2. Per the comments of more than one of us, isn't the question of 
> dropping MX for AAAA out of scope for this rfc2821bis effort?
> 
> d/
> 

Date: Fri, 04 Apr 2008 08:53:02 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Tony Hansen <[email-masked]>
CC: SMTP Interest Group <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Tony Hansen wrote:
> Before we can put the issue of AAAA implicit MX to bed, we need to get 
> an answer to the question of how much AAAA implicit MX is already being 
> used in the real world.

1. I apologize both for poor memory and for being so thoroughly dense, but I 
don't know what "implicit MX" means and would appreciate a simple definition 
that folks agree on.

2. Per the comments of more than one of us, isn't the question of dropping MX 
for AAAA out of scope for this rfc2821bis effort?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 04 Apr 2008 08:20:30 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Paul Smith <[email-masked]>
CC: Tony Hansen <[email-masked]>, SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Paul Smith wrote:
> 
> Tony Hansen wrote:
>>
>> Before we can put the issue of AAAA implicit MX to bed, we need to get 
>> an answer to the question of how much AAAA implicit MX is already 
>> being used in the real world.
>>
> I'm not sure that this is that significant anyway.
> 
> For a sending server, if it tries an implicit AAAA when it shouldn't, 
> then it's no biggy, it's just wasting its own resources
> For a receiving server, it shouldn't (assuming any level of sensible 
> internal authorisation procedures) take long to add an MX record if the 
> standard requires it.

+1 Paul.

I see text as simple as:

      SMTP systems implementing IPv6 connections who wish to
      send mail to a IPv4 only systems MUST offer a MX/A records or
      MUST offer a fallback to a A record for the MAIL FROM return
      path address [including any user response address in RFC 2822
      a MUA or automated MTA may use to create a new reply message].

This alone will make sure SMTP developers or open source keepers do not 
forget that they need to take this account the IPv4-only world that 
isn't going to go away for a very very long time.

Anyway way to state this:

     For hybrid SMTP client/server (IPv6/IPv4) sessions, the IPv6
     client MUST comply with 2821 SMTP protocol requirements. This
     means the return path or any user response address used in the
     transaction MUST be resolvable using MX/A records or A record
     fallback.

Reasoning:

Overall, I think the difficulty of IPv6 considerations for SMTP has been 
that was unfortunately designed as an alternative to IPv4, rather than 
extension.  Thus, it is difficult to make this a simple transparent 
transition without radical software changes at multiple OSI layers.

In order to begin to make any sense from an problem-solving engineering 
standpoint, I believe we must fundamentally first agree the burden is on 
IPv6 implementations to make sure they are backward compatible.  Not the 
other way around.

So the key issues I am more interesting in seeing addressed, whether its 
added to 2821bis or not, is what are key concepts for IPv6/IPv4 
interfacing for a IPv4 world oblivious to IPv6 systems.   This is the 
critical part I believe needs to be address in 2821bis because backward 
compatibility is important. Obviously.

I also think a major important concept to revisit is the current 
requirement and importance of a valid x821 return path and how it 
applies in an future IPv6 era.  If it still a standard 2821 requirement 
and expectation that the return path be a valid entity,  then this alone 
enforces the requirement for IPv6 mail senders as well.  If this is 
true, then this will help define some semantics for 2821bis.

I bring the return path because I was getting the impression (possibly 
incorrectly) that:

    a) It may be desirable to be more tolerant of send only
       clients, and

    b) also allow for support of the growth of consumer
       based hosting devices.

I believe many foresee an era where small device hosting is widespread 
in the consumer market place, whether by choice or by some installed 
IPv6 ready appliance or device the consumer is using on his computer and 
the vendor has implemented a borderline unethically practice to 
broadcast or call home reporting device via SMTP-IPv6.

I can imagine that if the required valid return path concept is not 
reinforced for the IPv6 era, then IPv6 can be a greater source for spam 
or malicious behavior against the IPv4 world.

For example, the IPv6 only client/server sessions will see the same 
security issues (i.e., Domain::IP associations) the IPv4 only 
client/server world sees now for the last few decades.

However, in a more plausible IPv6 -> IPv4 session growing world,  the 
IPv4 receiver may experience even more unknown return paths and the IPv6 
system runs a higher risk of getting blacklisted.

So this real more plausible IPv6 to IPv4 client/server scenario 
represents the current and greater critical issue that should be discussed.

In short, whatever is done in 2821bis, I believe it is important that we 
stress the IPv6 mail system if it wishes to contact a SMTP IPv4 system 
then it must continue to behave as expected by the SMTP x821 protocol 
and that basically means the sender must have a MX/A record resolution 
available either directly or via some proxy host.

Whatever is done for the SMTP x821 protocol as we know it today, the 
burden must not be placed on existing IPv4 systems. The burden must be 
placed on IPv6.

Finally, I personally not sure if we want to make sure a MX record is 
required across the board simply because it isn't today in the IPv4 world.

But we raise the bar above the practice of legacy operations, this 
provides the opportunity for developers to add new zero-false positive 
logic to handle the new level of possibilities.  That means that IPv6 
systems who want to contact a IPv4 system MUST have a MX/A record 
resolution simply because it is expected today.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Fri, 4 Apr 2008 13:46:49 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: Tony Hansen <[email-masked]>
cc: SMTP Interest Group <[email-masked]>, Lisa Dusseault <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

On Thu, 3 Apr 2008, Tony Hansen wrote:

> I'm looking for help answering these questions:
>
>    *	How are existing IPv6-enabled mail sites actually dealing with
> 	missing MX records?
>
>    *	Are the IPv6-enabled email sites mostly following the
> 	recommendations found in RFC 3974?
>
>    *	How widespread is the use of implicit MX with AAAA records? That
> 	is, how prevalent are email sites that do not have MX records
> 	but do have AAAA records?
>
>    *	How big is the existing IPv6-enabled email world?
>
>    *	What problems, if any, has been experienced by following RFC
> 	3974?

>From my standpoint of view, the existing IPv6-enabled email world is
really small.

At the moment we are in the transition to dual-stack MTAs. Therefore I
have only data about some of our domains which are reachable by IPv6 from
the Internet. We do not send emails via IPv6 to the Internet.

- number of MTAs from which we accepted emails over IPv6: 255
- number of MTAs in addition to above, from which we rejected emails: 303
  (mainly backscatter DSNs to unknown recipients)
- number of MTAs from which we accepted emails over IPv4: 44793

The MTAs, from which the data comes, are responsible for a major part of
the Munich Scientific Network with 4 universities and several colleges and
scientific institutions.

Statistics by top level domain of reverse mapping:

- accepted MTAs over IPv6 (25)

       2 arpa       2   at       5   ch       2  com       1   cz      42   de
       2  edu       1   es       1   fi      22   fr       3   gr       1   hr
       3   hu       1   id       1   ie      19  net       4   nl       4   no
       9  org       1   pl       2   pt       2   se       1   si       3   uk
     121  n/a

- additional rejected IPv6-MTAs (28)

       1 arpa       1   at       3   bg       4   ch       5  com       2   cz
      16   de       3   dk       1   eu       3   fi       8   fr       1   gr
       2   hu       1   id       4   it      15   jp       1   lt       2   my
      52  net       8   nl       2   no      11  org       1   pt       3   se
       1   to       1   tv       3   uk     103  n/a

- accepted MTAs over IPv4 (164)

      33   ac       6   ad      25   ae       2 aero      13   ag       2   al
       3   am     126   ar       2 arpa     696   at     254   au       1   aw
       1   az       5   ba     149   be      41   bg       2   bh      87  biz
       1   bm       2   bo     241   br       2   bt       1   bw       8   by
       3   bz     217   ca       3  cat      43   cc     516   ch      32   cl
      72   cn      29   co   14836  com       2 coop       4   cr       8   cu
       2   cx      11   cy     212   cz   11486   de     143   dk       3   do
       5   ec    1149  edu      19   ee       4   eg     224   es       1   et
     150   eu      82   fi       1   fj       2   fm     509   fr       5   ge
       1   gg       1   gh       2   gi       1   gl      92  gov     135   gr
       1   gs      35   hk       3   hm      29   hr     149   hu      13   id
      53   ie     102   il       1   im      48   in     597 info      19  int
       6   ir      11   is     819   it       4   jo     549   jp       8   ke
       2   kh      39   kr       1   kw       8   kz       6   lb      12   li
       6   lk      40   lt      21   lu      22   lv      12   ma       6   mc
       8   md       1   mg      12  mil       3   mk       1   mn       1   mo
       1 mobi       1   mr       5   ms       1   mt       1   mv      57   mx
      11   my       3   mz       3   na       4 name       2   nc    5929  net
     474   nl      69   no       4   np      14   nu      64   nz       1   om
     895  org       1   pa      14   pe       1   pg       8   ph      18   pk
     315   pl       2   ps     119   pt       4   py       2   qa      65   ro
       4   rs     458   ru       5   sa       1   sc     182   se      52   sg
       3   sh      25   si      59   sk       1   sm       2   sn       1   st
      11   su       1   sv       3   sy       1   sz       6   tc      32   th
       2   tk      10   tn       7   to      58   tr      23   tv     120   tw
       2   tz      71   ua       1   ug     619   uk     436  n/a      32   us
       9   uy       2   va       7   ve       6   vn       1   vu       8   ws
      21   yu      67   za

I hope this helps and is not to much data.

Michael Storz

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Registration model, 2821bis-06
Date:  Fri, 4 Apr 2008 12:57:42 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 19
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:
 
>> "whatever it needs to do ... given a domain name" and "an address
>> for the domain name" means to me "lookup both A and AAAA records"
>> in a mixed IPv4/IPv6 world.
 
> Okay, maybe 974 does say that.  But has been pointed out a couple
> of times, the world has changed a lot since then.

Interpreting RFC 974 published 1986 in a way as if it was meant to
cover the later invention IPv6 is shaky, after all its status is
"HISTORIC" for a reason.  We could also claim that RFC 974 wants
us to check WKS before doing something with addresses not limited
to AAAA.  

Extending "implicit MX" to AAAA while ignoring WKS is like keeping
forwarding after deprecating the reverse routes:  broken by design.

 Frank

Date: Fri, 04 Apr 2008 10:35:33 +0100
From: Paul Smith <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: SMTP Interest Group <[email-masked]>
Subject: Re: current usage of AAAA implicit MX?
Sender: [email-masked]

Tony Hansen wrote:
>
> Before we can put the issue of AAAA implicit MX to bed, we need to get 
> an answer to the question of how much AAAA implicit MX is already 
> being used in the real world.
>
I'm not sure that this is that significant anyway.

For a sending server, if it tries an implicit AAAA when it shouldn't, 
then it's no biggy, it's just wasting its own resources
For a receiving server, it shouldn't (assuming any level of sensible 
internal authorisation procedures) take long to add an MX record if the 
standard requires it.

Paul

Date: Thu, 03 Apr 2008 18:46:32 -0500
From: Keith Moore <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Peter J. Holzer wrote:

> 
>> the 974 fallback means that no MX 
>> records + an A record implies authorization to deliver mail to that IPv4 
>> address.  it doesn't imply any authorization to deliver mail to any IPv6 
>> address.
> 
> I think the 974 fallback does imply exactly that. It says so
> explicitely:
> 
> |  Where ever
> |  delivering a message is mentioned, all that is meant is that the
> |  mailer should do whatever it needs to do to transfer a message to a
> |  remote site, given a domain name for that site.  (For example, an
> |  SMTP mailer will try to get an address for the domain name, which
> |  involves another query to the domain system, and then, if it gets an
> |  address, connect to the SMTP TCP port).
> 
> "whatever it needs to do ... given a domain name" and "an address for
> the domain name" means to me "lookup both A and AAAA records" in a mixed
> IPv4/IPv6 world.

Okay, maybe 974 does say that.  But has been pointed out a couple of 
times, the world has changed a lot since then.  In this world of 90% 
spam, clogged mail queues, and most hosts not being configured to 
receive mail, I don't think it's appropriate anymore to assume that a 
receiving host really really wants to get mail so badly (in the absence 
of any explicit indication like an MX record) that the sending host 
needs to do "whatever it needs to do" to get it there.

and of course 974 was obsoleted by 2821.

> I understand the desire to get rid of the fallback. However, I don't
> think that the wording in RFC 2821 can be reasonably extended to
> "fallback for IPv4 only".

I think our job is to clearly specify what should work for the Internet 
today, and what seems likely to work well in the future.  I don't think 
we're constrained to say only what text in old documents can be 
"reasonably extended" to say.

   If the fallback goes for AAAA records, I would very much like
> to see it deprecated for A records, too (something like "clients MUST
> lookup an A record, but SMTP service operators SHOULD NOT rely on this
> behaviour and SHOULD add an explicit MX record").

I could see getting rid of support for fallback to A, but it would 
require a sort of flag day.  e.g. "sending MTAs SHOULD NOT fallback to A 
after Dec 31, 2011 23:59:59 UTC".  Though if we really wanted to do that 
I think we'd be safely in "new document" territory as opposed to "wrap 
up 2821bis" territory.

Keith

Date: Fri, 4 Apr 2008 01:03:43 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--MnLPg7ZWsaic7Fhd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2008-04-02 08:31:34 -0400, Keith Moore wrote:
> 
> 
> 
> Arnt Gulbrandsen wrote:
> 
> >How many people would be happy if 5.1 were to say this?
> >
> > - if there is no MX record, but there is an A, then the sending
> >   host MUST synthesise an MX
> > - if there is no MX record and no A, but there is an AAAA, then
> >   the sending host MAY synthesise an MX
> > - even if a client doesn't use AAAA records for synthesising MX
> >   records, it MAY use them for delivering mail once an MX has
> >   been synthesised.
> 
> first rule is fine - really I think that fallback to A should eventually 
> be deprecated (probably as of some flag day) but 2821bis clearly is not 
> the place to do this.
> 
> second rule - MAY should be SHOULD NOT, perhaps even MUST NOT.
> 
> third rule is a bad idea, IMHO.

I don't even understand what the third rule means. If an MX record isn't
synthesized in the first place how can it be used to look up an AAAA
record? Or does that mean that it is ok for a client to use an AAAA
record only if there is also an A record? If so, I agree that's a bad
idea.

> the 974 fallback means that no MX 
> records + an A record implies authorization to deliver mail to that IPv4 
> address.  it doesn't imply any authorization to deliver mail to any IPv6 
> address.

I think the 974 fallback does imply exactly that. It says so
explicitely:

|  Where ever
|  delivering a message is mentioned, all that is meant is that the
|  mailer should do whatever it needs to do to transfer a message to a
|  remote site, given a domain name for that site.  (For example, an
|  SMTP mailer will try to get an address for the domain name, which
|  involves another query to the domain system, and then, if it gets an
|  address, connect to the SMTP TCP port).

"whatever it needs to do ... given a domain name" and "an address for
the domain name" means to me "lookup both A and AAAA records" in a mixed
IPv4/IPv6 world.

It is also implicit in the order:

1) Do an MX lookup, which results in an ordered list of (priority,
   hostname) tuples..

2) If the list is empty, insert (0, REMOTE)

3) Remove unusable hostnames from the list.

4) "try to deliver" (as defined above) to the hosts in order.

Note that steps 1 to 3 do not involve any A records. Only step 4
involves lookup of an address record, because you need an IP address to
open a TCP connection.

So far this is IMO very clear and unambiguous.

RFC 2821 changed that, by changing step 2 above (which doesn't mention
or need an A record into:

|  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.

The requirement "but an A RR is found" is new here. I don't know why it
was added and whether the change was intentional: If there is only IPv4,
the change makes no difference at all - maybe it was only meant as a
clarification, not a change. But with IPv6 there is a change. Firstly,
the RFC restricts the use of generic "address records" to specific "A
records", so it forbids the use if IPv6 (this probably wasn't
intentional, since the use of IPv6 address literals is explicitely
allowed, which wouldn't make much sense in an IPv4-only protocol).
Secondly, it uses A records in two places: For address resolution and
for determining whether the implicit MX record should be synthesized at
all (in RFC 974 it was always synthesized, regardless of the presence or
absence of an address (or any other non-MX) record). So now we have two
places where we have to decide whether we extend "A record" to "any
address record". Clearly we need to lookup AAAA records to determine the
address of an IPv6 host, so that's beyond question. But we don't
necessarily need to lookup an AAAA reccord to synthesize an MX record.
However, looking up only an A record here leads to my nonsensical
interpretation of rule 3. 

I understand the desire to get rid of the fallback. However, I don't
think that the wording in RFC 2821 can be reasonably extended to
"fallback for IPv4 only". To get useful behaviour it would need to
changed significantly, and that would be a direct contradiction to RFC
974 which should be explicitely mentioned and explained. Just going back
to the simple rules of 974 (which draft-klensin-rfc2821bis-09
essentially does, although I find the description in RFC 974 clearer) is
IMHO the only way under the constraints of going from proposed to draft
standard. If the fallback goes for AAAA records, I would very much like
to see it deprecated for A records, too (something like "clients MUST
lookup an A record, but SMTP service operators SHOULD NOT rely on this
behaviour and SHOULD add an explicit MX record").

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

--MnLPg7ZWsaic7Fhd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--MnLPg7ZWsaic7Fhd--

To: Tony Hansen <[email-masked]>
Cc: SMTP Interest Group <[email-masked]>, Lisa Dusseault <[email-masked]>
From: Mark Andrews <[email-masked]>
Subject: Re: current usage of AAAA implicit MX? 
Date: Fri, 04 Apr 2008 09:14:21 +1100
Sender: [email-masked]

> 
> Before we can put the issue of AAAA implicit MX to bed, we need to get 
> an answer to the question of how much AAAA implicit MX is already being 
> used in the real world.
> 
> It's been postulated that the current deployment of this and its use is 
> low. However, RFC 3974 (SMTP Operational Experience in Mixed IPv4/v6 
> Environments), was published three years ago, and it mandates AAAA 
> implicit MX (as much as an informational document can mandate anything).
> 
> So I'm looking for information from people who are currently working in 
> the IPv6-based email world.
> 
> I'm assuming that a number of email sites over in Asia are already 
> IPv6-enabled, and there are probably other enclaves as well. So I'm 
> looking for information on actual email deployment and sites.
> 
> I'm looking for help answering these questions:
> 
>    *	How are existing IPv6-enabled mail sites actually dealing with
> 	missing MX records?
> 
>    *	Are the IPv6-enabled email sites mostly following the
> 	recommendations found in RFC 3974?
> 
>    *	How widespread is the use of implicit MX with AAAA records? That
> 	is, how prevalent are email sites that do not have MX records
> 	but do have AAAA records?

	With or without a A record?

	AAAA only is very different to A+AAAA where there definitely
	is a implict MX.
 
>    *	How big is the existing IPv6-enabled email world?
> 
>    *	What problems, if any, has been experienced by following RFC
> 	3974?
> 
> Also, who else could I send this message to in order to gain additional 
> insights?
> 
> Thank you!
> 
>      Tony Hansen
>      "shepherd for 2821bis"
>      [email-masked]
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Thu, 03 Apr 2008 16:32:17 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
CC: Lisa Dusseault <[email-masked]>
Subject: current usage of AAAA implicit MX?
Sender: [email-masked]

Before we can put the issue of AAAA implicit MX to bed, we need to get 
an answer to the question of how much AAAA implicit MX is already being 
used in the real world.

It's been postulated that the current deployment of this and its use is 
low. However, RFC 3974 (SMTP Operational Experience in Mixed IPv4/v6 
Environments), was published three years ago, and it mandates AAAA 
implicit MX (as much as an informational document can mandate anything).

So I'm looking for information from people who are currently working in 
the IPv6-based email world.

I'm assuming that a number of email sites over in Asia are already 
IPv6-enabled, and there are probably other enclaves as well. So I'm 
looking for information on actual email deployment and sites.

I'm looking for help answering these questions:

   *	How are existing IPv6-enabled mail sites actually dealing with
	missing MX records?

   *	Are the IPv6-enabled email sites mostly following the
	recommendations found in RFC 3974?

   *	How widespread is the use of implicit MX with AAAA records? That
	is, how prevalent are email sites that do not have MX records
	but do have AAAA records?

   *	How big is the existing IPv6-enabled email world?

   *	What problems, if any, has been experienced by following RFC
	3974?

Also, who else could I send this message to in order to gain additional 
insights?

Thank you!

     Tony Hansen
     "shepherd for 2821bis"
     [email-masked]

Date: Thu, 03 Apr 2008 12:55:23 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Michael Storz <[email-masked]>
CC:  [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Michael Storz wrote:
> On Wed, 2 Apr 2008, John C Klensin wrote:
> 
>>
>>
>> --On Wednesday, April 02, 2008 11:01 AM -0700
>> [email-masked] wrote:
>>
>>>> Connectivity to/from AAAA-only mail servers will suck
>>>> terribly for many decades to come, but no 2821bis
>>>> wordsmithing can avoid that. Only an arrangement with a
>>>> dual-stack relay can improve connectivity, and that
>>>> practically requires an MX RR or more.
>>> This is certainly true for the Internet email service. But not
>>> all use of
>>> standardized email protocols (including usage on the open
>>> Internet) is in
>>> futherance of this service. It is entirely possible that at
>>> some point
>>> an alternate service offering will emerge that's IPv6-only. I
>>> have no idea
>>> how likely this is but it is not beyond the realm of
>>> possibility.
>> And, in addition and FWIW, the claim that a dual stack setup
>> "practically requires" an MX setup is false, as has been pointed
>> out before.   The following setup, with no MX record, is all
>> that is necessary under the current 2821 standard:
>>
>>    destination.example.com. IN A ...
>>                             IN AAAA ....
> 
> The only reference in the current 2821 standard about IPv6 is for address
> literals. I cannot find a reference to an AAAA RR. Therefore I assume the
> above statement is wrong. 2821 only defines the semantics for IPv4,
> semantics about IPv6 are undefined. This is a subtle distinction, but
> nevertheless it is one. 2821bis just begins to define semantics for IPv6
> (beside the address literal).
> 
> At the moment, when an AAAA RR appears, the problem is resolved by "common
> sense", what mostly mean do the same thing as if it would be an A RR. This
> is a reasonable thing to do, if there are no explicit statements in the
> standard.
> 
> However, if you extend a standard, you have to carefully balance the pros
> and cons of the existing semantics when you try to carry them over.
> 
> At the moment I see two positions:
> 
> - use AAAA RRs in synthesizing MX RRs
> - do not use AAAA RRs in synthesizing MX RRs
> 
> Reasoning about first position:
> - it carries over the semantics of IPv4
> - it will maximize email connectivity
> 
> Reasoning about second position:
> - it will reduce server load and ressources, because emails with
>   * "recipient-AAAA-domains" without an MX RR will be immediately
>     rejected
>   * "originator-AAAA-domains" without an MX RR will not be accepted
> 
> In the end this means: has the majority of email servers to pay for
> the connectivity of a minority of email servers?
> 
> Is there any other reason I forgot? Otherwise we could just try to find
> consensus which position we prefer.
> 
> Michael Storz

Overall, we can't neglect the basic requirements for compatibility.

If anything will be added, I prefer text in 2821bis that will help 
prepare us for the future, possibly outlining the current issues, 
current methods, and more importantly what technologies or possible 
changes will be important or a consideration in a successful migration.
Information that will increase awareness.

Also, if the text is going to include terms such as "synthesize", this 
needs to be clearly defined as to what that means.  Who is doing the 
synthesis?   The DNA client?  The MTA?  The DNA Server?  A dual stack 
protocol logic?  I see this is a important design question because if a 
MTA is going to do a MX lookup, does the result include the synthesis of 
a fallback?  Of is the MTA still responsible to do the fallback itself?

Also, keep in mind the availability of new technology will act as 
helpers for the new generation receivers. Such as DKIM which will raise 
the bar (new non-legacy expectations) on senders.  IOW, new mail 
indicators will suggest senders *should* be up-to-par with expected DNS 
mail setup procedures.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Thu, 3 Apr 2008 09:48:24 -0700
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

On Thu, 2008-04-03, Michael Storz wrote:

> At the moment I see two positions:

> - use AAAA RRs in synthesizing MX RRs
> - do not use AAAA RRs in synthesizing MX RRs

> Reasoning about first position:
> - it carries over the semantics of IPv4
> - it will maximize email connectivity

> Reasoning about second position:
> - it will reduce server load and ressources, because emails with
>   * "recipient-AAAA-domains" without an MX RR will be immediately
>     rejected
>   * "originator-AAAA-domains" without an MX RR will not be accepted

> In the end this means: has the majority of email servers to pay for
> the connectivity of a minority of email servers?

> Is there any other reason I forgot? Otherwise we could just try to find
> consensus which position we prefer.

Looking at this from a slightly different angle.

We choose one of these alternatives and publish 2821bis. Then it is
concluded that the wrong choice has been made. Which of the following
corrections will be the easier RFC to write?

1 - "Now *stop* using AAAA RRs to synthesize MX RRs."

2 - "Now *start* using AAAA RRs to synthesize MX RRs."

-- 
Bill McQuillan <[email-masked]>

Date: Thu, 3 Apr 2008 10:19:56 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

On Wed, 2 Apr 2008, John C Klensin wrote:

>
>
>
> --On Wednesday, April 02, 2008 11:01 AM -0700
> [email-masked] wrote:
>
> >> Connectivity to/from AAAA-only mail servers will suck
> >> terribly for many decades to come, but no 2821bis
> >> wordsmithing can avoid that. Only an arrangement with a
> >> dual-stack relay can improve connectivity, and that
> >> practically requires an MX RR or more.
> >
> > This is certainly true for the Internet email service. But not
> > all use of
> > standardized email protocols (including usage on the open
> > Internet) is in
> > futherance of this service. It is entirely possible that at
> > some point
> > an alternate service offering will emerge that's IPv6-only. I
> > have no idea
> > how likely this is but it is not beyond the realm of
> > possibility.
>
> And, in addition and FWIW, the claim that a dual stack setup
> "practically requires" an MX setup is false, as has been pointed
> out before.   The following setup, with no MX record, is all
> that is necessary under the current 2821 standard:
>
>    destination.example.com. IN A ...
>                             IN AAAA ....

The only reference in the current 2821 standard about IPv6 is for address
literals. I cannot find a reference to an AAAA RR. Therefore I assume the
above statement is wrong. 2821 only defines the semantics for IPv4,
semantics about IPv6 are undefined. This is a subtle distinction, but
nevertheless it is one. 2821bis just begins to define semantics for IPv6
(beside the address literal).

At the moment, when an AAAA RR appears, the problem is resolved by "common
sense", what mostly mean do the same thing as if it would be an A RR. This
is a reasonable thing to do, if there are no explicit statements in the
standard.

However, if you extend a standard, you have to carefully balance the pros
and cons of the existing semantics when you try to carry them over.

At the moment I see two positions:

- use AAAA RRs in synthesizing MX RRs
- do not use AAAA RRs in synthesizing MX RRs

Reasoning about first position:
- it carries over the semantics of IPv4
- it will maximize email connectivity

Reasoning about second position:
- it will reduce server load and ressources, because emails with
  * "recipient-AAAA-domains" without an MX RR will be immediately
    rejected
  * "originator-AAAA-domains" without an MX RR will not be accepted

In the end this means: has the majority of email servers to pay for
the connectivity of a minority of email servers?

Is there any other reason I forgot? Otherwise we could just try to find
consensus which position we prefer.

Michael Storz

Date: Wed, 2 Apr 2008 16:36:09 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Scope Creep
Sender: [email-masked]

At 13:50 +0200 on 04/02/2008, Michael Storz wrote about Re: Scope Creep:

>That means in the case of no MX record, I suggest the following algorithm:
>
>- if a domain has only A records, synthesize a MX record
>- if a domain has A and AAAA records, synthesize a MX record only
>   for the A records, the AAAA records should be dropped.
>- if a domain has only AAAA records, do not synthesize a MX record
>
>For a MTA with ipv4 stack, this would mean no change. For a MTA with dual
>stack, only the ipv4 part would use synthesized MX records. A MTA with
>ipv6 stack only would never synthesize a MX record.

+1 (this algorithm is what I have been suggesting so of course I agree).

Date: Wed, 02 Apr 2008 18:46:36 -0400
From: Keith Moore <[email-masked]>
To: John C Klensin <[email-masked]>
CC: Alessandro Vesely <[email-masked]>, John Levine <[email-masked]>, [email-masked]
Subject: Re: History of fallback to A
Sender: [email-masked]

>> I think the above provides quite some insight into
>> specifications
>> regarding the MX record, so I took the liberty of copying it in
>> http://en.wikipedia.org/wiki/MX_record#History_of_fallback_to_A
> 
> be a little careful because, for several reasons of which only a few 
> were related to their being a bad idea, MD and MF were never really used 
> on large scale.   See Dave's note about the actual deployment realities 
> -- my recollection is that MX was used as an inter-network gateway 
> mechanism somewhat earlier than his not would indicate, but, for 
> on-Internet relay purposes, MXs were essentially useless (and hence 
> little used) until the DNS was widely deployed and  widely used.

in particular, several OS vendors were distributing versions of sendmail 
through the early 1990s at least that DID NOT implement MX lookup

Keith

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
To: John C Klensin <[email-masked]>
Subject: Re: Scope Creep
Date: Wed, 2 Apr 2008 13:17:22 -0700
Sender: [email-masked]

On Apr 2, 2008, at 11:51 AM, John C Klensin wrote:

>
>
> --On Wednesday, April 02, 2008 11:25 AM -0700 Lisa Dusseault <[email-masked] 
> > wrote:
>>
>> WWTHD (What Would Ted Hardie Do): be blunt.   "After much
>> discussion on the topic, this specification does not extend
>> the A rule to AAAA records, but neither does it preclude a
>> parallel treatment."
>
> Lisa,
>
> That leaves an ambiguity about behavior from which neither SMTP  
> clients nor domain administrators can figure out what to do. To me,  
> that ambiguity is the one case that is a showstopper. It also, IMO,  
> creates a "known technical defect" and that would exclude even  
> publishing something as Proposed, much less Draft.

Yup, I certainly prefer removing ambiguity, but I do see it as a  
realistic fallback to at least document the known ambiguity and lack  
of consensus, even for a Draft Standard.  I was of course partially in  
jest about WWTHD and answering Arnt's direct question about how to  
word something, not whether that was the best option.

thanks,
Lisa

Date: Wed, 02 Apr 2008 12:38:50 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

John C Klensin wrote:
 > --On Wednesday, April 02, 2008 11:25 AM -0700 Lisa Dusseault wrote:
 >> WWTHD (What Would Ted Hardie Do): be blunt.   "After much
 >> discussion on the topic, this specification does not extend
 >> the A rule to AAAA records, but neither does it preclude a
 >> parallel treatment."

> That leaves an ambiguity about behavior from which neither SMTP clients 
> nor domain administrators can figure out what to do. To me, that 
> ambiguity is the one case that is a showstopper. It also, IMO, creates a 
> "known technical defect" and that would exclude even publishing 
> something as Proposed, much less Draft.
> 
> I see no way to avoid making a choice.
> 
> I think I and several others have said this before, but I can live with 
> anything that (i) does not create an ambiguity and (ii) does not 
> deprecate the existing (back to 974) behavior.

I'm sorry to say that I see a way to deal with v6, without dealing with it.

Unfortunately, I see Lisa's language as too specific as well as too varied. 
"does not extend...to...but neither does it precludes" is, I believe, 
semantically equivalent to saying "is out of scope".  That's language that is 
more typical in IETF specifications.

So I think the choice is between

1. The current draft language, which treats "direct" addresses as a list and 
names two entries, A and AAAA, explicilty, versus

2. Language which cites A but declares all other details out of scope, using 
language like:

     "In the absence of indirect addressing, via a DNS MX record, this 
specification provides for use of direct addressing via IPv4 DNS A records.  Use 
of other direct addresses is out of scope."

FWIW, I vote for 1.  v6 is too real to ignore.

I also suspect a diligent IESG would enforce including it as a requirement.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 2 Apr 2008 21:35:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Cc: [email-masked]
Sender: [email-masked]

[email-masked] writes:
> You may have noticed that draft-09 carefully sidesteps the IPv6 
> question by mentioning an obviousness test from an operational 
> viewpoint.

Indeed. The mirror I use must have stopped working. Thanks. I'll get it 
from elsewhere tomorrow. No more mail from me tonight, then.

Arnt

Date: Wed, 2 Apr 2008 21:31:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Cc: John C Klensin <[email-masked]>, [email-masked]
Sender: [email-masked]

John C Klensin writes:
> And, in addition and FWIW, the claim that a dual stack setup 
> "practically requires" an MX setup is false, as has been pointed out 
> before.

If that refers to me, then I think that wasn't what I claimed. I claimed 
(or meant to claim) that using an dual-stack _relay_ practically 
requires MX records. One way to do it:

example.com IN A 2006:0608:...
example.com IN MX 10 example.com.
             IN MX 20 relay.example-isp.net.

There are other ways to do it. People who don't mind pointing 
http://example.com at the relay can use an extra A record instead of 
the MX record(s).

Arnt

Date: Wed, 02 Apr 2008 12:11:26 -0700
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Hi Arnt,
At 04:11 02-04-2008, Arnt Gulbrandsen wrote:
>How many people would be happy if 5.1 were to say this?
>
>  - if there is no MX record, but there is an A, then the sending
>    host MUST synthesise an MX
>  - if there is no MX record and no A, but there is an AAAA, then
>    the sending host MAY synthesise an MX
>  - even if a client doesn't use AAAA records for synthesising MX
>    records, it MAY use them for delivering mail once an MX has
>    been synthesised.

You may have noticed that draft-09 carefully sidesteps the IPv6 
question by mentioning an obviousness test from an operational 
viewpoint.  The above sounds more like a decision to be made during 
implementation.  The MAY makes it more difficult, from the server 
end, to determine why a message isn't being delivered as we have to 
know whether the client is designed to synthesize the AAAA RR as an 
MX in addition to the usual failure points.

>Connectivity to/from AAAA-only mail servers will suck terribly for 
>many decades to come, but no 2821bis wordsmithing can avoid that. 
>Only an arrangement with a dual-stack relay can improve 
>connectivity, and that practically requires an MX RR or more.

That's a reason for having the MX RR.

This discussion has covered both sides of the (implicit MX) argument 
from historical, email architecture, implementation and operational 
viewpoints.  Whichever option is accepted will be viewed as a change 
from RFC 2821.  I would be happy if the issue could be resolved one 
way or another.

Regards,
-sm 

Date: Wed, 02 Apr 2008 15:03:44 -0400
From: John C Klensin <[email-masked]>
To: Alessandro Vesely <[email-masked]>, John Levine <[email-masked]>
cc: [email-masked]
Subject: Re: History of fallback to A
Sender: [email-masked]

--On Wednesday, April 02, 2008 11:21 AM +0200 Alessandro Vesely 
<[email-masked]> wrote:

>
> John Levine wrote:
>> RFC 821 came out in 1982.  It makes only passing references
>> to DNS, because at the time the transition from HOSTS.TXT to
>> the DNS had not yet started.  RFC 883, the first description
>> of the DNS came out over a year later in late 1983.  It
>> described the now abandoned MD and MF records.  According to
>> RFCs 897 and 921, the transition to DNS started in 1983, but
>> HOSTS.TXT didn't go away until the end of 1985.
>>
>> In January 1986, RFC 973 and 974 deprecated MD and MF records,
>> replaced them with MX, and defined the MX lookup with
>> fallback to A. While rereading 974, I note that it also
>> recommends that clients do a WKS lookup on each MX host to
>> see if it actually supports SMTP and discard the MX entry if
>> it doesn't, but as far as I can tell, nobody ever did that.
>> Too bad.
>>
>> So this means that SMTP had been in use for at least a year
>> using HOSTS.TXT, and then another couple of years using A,
>> MD, and MF, before MX came along, and I get the impression
>> that MD and MF were clunky enough that a most people just
>> used the A record.  Under the circumstances, MX without
>> fallback to A wouldn't have worked because of the substantial
>> installed base of mail servers using A records.
>
> I think the above provides quite some insight into
> specifications
> regarding the MX record, so I took the liberty of copying it in
> http://en.wikipedia.org/wiki/MX_record#History_of_fallback_to_A

be a little careful because, for several reasons of which only a 
few were related to their being a bad idea, MD and MF were never 
really used on large scale.   See Dave's note about the actual 
deployment realities -- my recollection is that MX was used as 
an inter-network gateway mechanism somewhat earlier than his not 
would indicate, but, for on-Internet relay purposes, MXs were 
essentially useless (and hence little used) until the DNS was 
widely deployed and  widely used.

    john

Date: Wed, 02 Apr 2008 14:59:16 -0400
From: John C Klensin <[email-masked]>
To: [email-masked], Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

--On Wednesday, April 02, 2008 11:01 AM -0700 
[email-masked] wrote:

>> Connectivity to/from AAAA-only mail servers will suck
>> terribly for many decades to come, but no 2821bis
>> wordsmithing can avoid that. Only an arrangement with a
>> dual-stack relay can improve connectivity, and that
>> practically requires an MX RR or more.
>
> This is certainly true for the Internet email service. But not
> all use of
> standardized email protocols (including usage on the open
> Internet) is in
> futherance of this service. It is entirely possible that at
> some point
> an alternate service offering will emerge that's IPv6-only. I
> have no idea
> how likely this is but it is not beyond the realm of
> possibility.

And, in addition and FWIW, the claim that a dual stack setup 
"practically requires" an MX setup is false, as has been pointed 
out before.   The following setup, with no MX record, is all 
that is necessary under the current 2821 standard:

   destination.example.com. IN A ...
                            IN AAAA ....

That would cause, regardless of how this argument about 
AAAA-based synthesis comes out, an implicit MX record equivalent 
to
   destination.example.com. IN MX 0 destination.example.com.
to be generated and then address selection algorithms specified 
elsewhere to be used.

If one had stronger preferences about which interface type was 
preferred, one could use MX records to specify that.  But that 
has been the case for a long time and none of these proposals or 
options changes that.

One can sensibly argue that the flexibility about address 
(actually interface) selection is too broad and could be 
tightened.  But that, too, is a major new piece of work.

And, like Ned, I'm tiring of repeating myself about this.

    john

Date: Wed, 02 Apr 2008 14:51:45 -0400
From: John C Klensin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

--On Wednesday, April 02, 2008 11:25 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

>
>
> On Apr 2, 2008, at 2:27 AM, Arnt Gulbrandsen wrote:
>
>>>
>>> However, trying to squeeze that effort into the RFC2821bis
>>> process   is a good way to kill both.
>>
>> It would be good to have wording for 2821bis that neither
>> consciously extends the A rule nor consciously doesn't extend
>> it.   But I can't think of a way to do it.
>
> WWTHD (What Would Ted Hardie Do): be blunt.   "After much
> discussion on the topic, this specification does not extend
> the A rule to AAAA records, but neither does it preclude a
> parallel treatment."

Lisa,

That leaves an ambiguity about behavior from which neither SMTP 
clients nor domain administrators can figure out what to do. 
To me, that ambiguity is the one case that is a showstopper. 
It also, IMO, creates a "known technical defect" and that would 
exclude even publishing something as Proposed, much less Draft.

I see no way to avoid making a choice.

I think I and several others have said this before, but I can 
live with anything that (i) does not create an ambiguity and 
(ii) does not deprecate the existing (back to 974) behavior.

     john

From: [email-masked]
Cc: [email-masked]
Date: Wed, 02 Apr 2008 11:21:39 -0700 (PDT)
Subject: Re: Scope Creep
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> Dave Crocker writes:
> > John Leslie wrote:
> >>    I'm happy to call it "registration" too. I think this should tend
> >> to get us thinking about the right thing. How should the intent to
> >> receive email for a domain be signaled?
> >
> > The current model permits no email-specific registration, in order to
> > operate a mail-receiving service.  Anything that eliminates use of an
> > A/AAAA record changes this basic flexibility.
> >
> > So the requirement "How should the intent to
> > > receive email for a domain be signaled?" is, in fact, a very basic
> > change to the core Internet mail service model.

> If the ability to set up a mail server purely by setting up a host
> (without adding an MX record) is a significant feature of the internet
> mail system, then I would expect to see significant use of it. Right?

Absolutely and totally wrong, I'm afraid. The Internet is a huge place and gets
bigger all the time. There are a vast number of different communities out
there, some overlapping, others almost entirely isolated. Unless you're a major
multinational ISP there is effectively no chance that you can have any real
insight into all the variations in service and usage out there, and even then
your results can easily be oddly skewed in various different ways. All you know
is your own little corner of this world, and that's effectively shrinking all
the time.

But let's assume, for the sake of argument, that you were actually able to
reliably determine that this is indeed a rarely used feature. My response to
that is simple: So what? It may be little used, but this says _nothing_ about
why people use it. Given the history it very likely that without this feature
it would be much more difficult for some to operate a mail server.

Will this change with IPv6? It's entirely possible it will. It is also possible
it won't. And like it or not, our ability to influence this is pretty limited.

You know, after watching MIME finally deploy after previous efforts to extend
email past plain text failed, I thought we had succesfully internalized the
lesson the that extent to which the installed base and behavior associated with
it matters can be entirely disproportionate to its size. It may be that
a refresher course is in order.

				Ned

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Subject: Re: Scope Creep
Date: Wed, 2 Apr 2008 11:25:30 -0700
Sender: [email-masked]

On Apr 2, 2008, at 2:27 AM, Arnt Gulbrandsen wrote:

>>
>> However, trying to squeeze that effort into the RFC2821bis process  
>> is a good way to kill both.
>
> It would be good to have wording for 2821bis that neither  
> consciously extends the A rule nor consciously doesn't extend it.  
> But I can't think of a way to do it.

WWTHD (What Would Ted Hardie Do): be blunt.   "After much discussion  
on the topic, this specification does not extend the A rule to AAAA  
records, but neither does it preclude a parallel treatment."

Lisa

From: [email-masked]
Cc: [email-masked]
Date: Wed, 02 Apr 2008 11:01:10 -0700 (PDT)
Subject: Re: Registration model, 2821bis-06
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> Now that I think about it, 2821bis-06 does require something more than
> A/AAAA in order to operate a mail server: If a host only has an IPv6
> address, 2821bis-06 section 5.1 requires the operator of that host to
> form an arrangement with a dual-stack relay in order to send mail to
> IPv4-only targets.

> IMO, that's not an unreasonable requirement. I think it's perfectly
> reasonable and almost unavoidable. I'm pointing it out to show that the
> text already requires something more than getting an AAAA record and
> setting up some software on the host itself.

> How many people would be happy if 5.1 were to say this?

>   - if there is no MX record, but there is an A, then the sending
>     host MUST synthesise an MX

Has to be this way - any change to this is out of scope of this effort, not
to mention a very bad idea.

>   - if there is no MX record and no A, but there is an AAAA, then
>     the sending host MAY synthesise an MX

I have stated repeatedly that this is the one outcome that I view as completely
unacceptable, and since I have made this point multiple times I'm not going  to
bother to repeat it.

IMO our choices here are between MUST and SHOULD NOT. I'm in favor of MUST but
I will (reluctantly) settle for SHOULD NOT if that's the consensus.

>   - even if a client doesn't use AAAA records for synthesising MX
>     records, it MAY use them for delivering mail once an MX has
>     been synthesised.

I don't see how this warrants being a separate case to consider. You look up
MX, if you don't find you pretend you found one pointing at itself. You then
proceed to look up the A/AAAA records corresponding to the hosts on the MX
list. (If AAAA fallback is prohibited you also have to set a flag turning off
AAAA lookups, but this is no real hardship since you probably want to only do
AAAA lookups when IPv6 access is available.)

> This permits people to set up IPv6-only mail servers without any MX or
> relay, and it doesn't declare any deployed 2821-compliant code to be
> illegal, and it doesn't tell anyone to assume that IPv6-only devices
> are mail servers by default.

And in the process blocks our ability to move to draft without getting some
kind of exception. And I have to say I see no legitimate reason for the IESG to
grant such an excception.

> Connectivity to/from AAAA-only mail servers will suck terribly for many
> decades to come, but no 2821bis wordsmithing can avoid that. Only an
> arrangement with a dual-stack relay can improve connectivity, and that
> practically requires an MX RR or more.

This is certainly true for the Internet email service. But not all use of
standardized email protocols (including usage on the open Internet) is in
futherance of this service. It is entirely possible that at some point
an alternate service offering will emerge that's IPv6-only. I have no idea
how likely this is but it is not beyond the realm of possibility.

				Ned

Date: Wed, 2 Apr 2008 19:24:29 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Cc: [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

Dave Crocker writes:
> Since there have already been quite a few postings, by several 
> different people, that explained this, it looks like a review of the 
> archive is in order.

I have read all the postings. I suppose you tried to explain when you 
said that the A rule is a basic feature. But you didn't explain why 
extending this basic feature is beneficial, or why this basic feature 
is good. Could you do so?

Arnt

Date: Wed, 02 Apr 2008 10:14:40 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: History of fallback to A
Sender: [email-masked]

Alessandro Vesely wrote:
> 
> John Levine wrote:
>> RFC 821 came out in 1982.  It makes only passing references to DNS,
>> because at the time the transition from HOSTS.TXT to the DNS had not
>> yet started.  RFC 883, the first description of the DNS came out over
>> a year later in late 1983.  It described the now abandoned MD and MF
>> records.  According to RFCs 897 and 921, the transition to DNS started
>> in 1983, but HOSTS.TXT didn't go away until the end of 1985.
>>
>> In January 1986, RFC 973 and 974 deprecated MD and MF records,
>> replaced them with MX, and defined the MX lookup with fallback to A.
...
>> So this means that SMTP had been in use for at least a year using
>> HOSTS.TXT, and then another couple of years using A, MD, and MF,
>> before MX came along, 

Looking at things in very broad strokes:

1.  hosts.txt remained in use for much of the 80s

2.  The pre-MX specifications for A-record surrogates were experiments that 
culminated in the MX record.  Hence, they were not relevant to real-world operation.

3.  MX did not gain substantial deployment and use until the latter 80s.

So that is at least 5 years of hosts.txt or A record, for doing email "routing".

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 02 Apr 2008 10:10:11 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Dave Crocker writes:
>> Difficult to see how much more completely it can be explained that 
>> this is out of scope for the current effort.
> 
> A supporting argument would help. Try a sentence like "keeping the same 
> rules as in 2821 is out of scope because ..." or better "adding AAAA to 
> the rule about A is in scope and appropriate because ...".

Ahh, I see.  Since there have already been quite a few postings, by several 
different people, that explained this, it looks like a review of the archive is 
in order.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 02 Apr 2008 10:08:57 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Rudy Nedved <[email-masked]>
CC: [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

As I said, you get credit for even knowing about 733...

d/

Rudy Nedved wrote:
> Alas, I tended to blur things with pushing the use of SMTP and mail 
> format with networks such as DECnet, BITnet, etc. long time
> ago.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 2 Apr 2008 18:53:33 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Dave Crocker writes:
> Difficult to see how much more completely it can be explained that 
> this is out of scope for the current effort.

A supporting argument would help. Try a sentence like "keeping the same 
rules as in 2821 is out of scope because ..." or better "adding AAAA to 
the rule about A is in scope and appropriate because ...".

Arnt

Date: Wed, 02 Apr 2008 11:57:08 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Dave,

fixing bugs in the mail specifications is entirely in scope for the 
current effort.

Keith

Dave Crocker wrote:
> 
> 
> 
> Arnt Gulbrandsen wrote:
>> How many people would be happy if 5.1 were to say this?
>>
>>  - if there is no MX record, but there is an A, then the sending
>>    host MUST synthesise an MX
> 
> 
> -1
> 
> Difficult to see how much more completely it can be explained that this 
> is out of scope for the current effort.
> 
> d/
> 

Date: Wed, 02 Apr 2008 07:49:20 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> How many people would be happy if 5.1 were to say this?
> 
>  - if there is no MX record, but there is an A, then the sending
>    host MUST synthesise an MX

-1

Difficult to see how much more completely it can be explained that this is out 
of scope for the current effort.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 02 Apr 2008 07:49:20 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> How many people would be happy if 5.1 were to say this?
> 
>  - if there is no MX record, but there is an A, then the sending
>    host MUST synthesise an MX

-1

Difficult to see how much more completely it can be explained that this is out 
of scope for the current effort.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 2 Apr 2008 15:45:01 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

On Wed, 2 Apr 2008, Keith Moore wrote:

>
> > I checked my logs of the last 7 days. My mail servers have sent emails to
> > 29.401 different domains worldwide, 29.015 via MX records and only
> > 286 via A records, which is less than 1 %. For a statistik about how many
> > emails are sent via MX records compared to A records the result would
> > even be lower.
> >
> > The missing MX records for the 286 domains are the result of lazy or
> > clueless mail administrators.
>
> While I think that deprecating A fallback would be a good idea, I don't
> buy that admins currently using it are lazy or clueless.  What they're
> doing is explicitly permitted by the current standards.
>
> Keith
>

If you are using an exception of the algorithm instead of the normal case,
when it is easy for you to use the normal case, then this means you have
no clue or you are lazy.

>From the 286 domains mentioned above 128 are second level domains. 1 has
no www server, 3 have different ip addresses for the www server and for
the rest of the 124 domains the ip address for the domain is the same as
the ip address of the www server. Since the configuration is made by the
ISP which manages the DNS server responsible for the domain and therefore
need only minimal effort to insert the correct MX record, this is at least
a sign of lazyness in my eyes.

Michael Storz

Date: Wed, 2 Apr 2008 14:43:27 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

Keith Moore writes:
> Arnt Gulbrandsen wrote:
>> How many people would be happy if 5.1 were to say this?
>> ...
>>  - even if a client doesn't use AAAA records for synthesising MX
>>    records, it MAY use them for delivering mail once an MX has
>>    been synthesised.

> third rule is a bad idea, IMHO.

I don't mind dropping that. I put it in because I think it's a 
defensible reading of 2821. But IMO it's an extremely unimportant case, 
so I don't really care either way.

Arnt

Date: Wed, 2 Apr 2008 14:39:10 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Scope Creep
Cc: Keith Moore <[email-masked]>, Michael Storz <[email-masked]>
Sender: [email-masked]

Keith Moore writes:
>> The missing MX records for the 286 domains are the result of lazy or
>> clueless mail administrators.
>
> While I think that deprecating A fallback would be a good idea, I 
> don't buy that admins currently using it are lazy or clueless.  What 
> they're doing is explicitly permitted by the current standards.

Judging by the 38 domains I visually inspected, the usage is:

   50% cluelessness or error
   25% informed choice
   25% indeterminate

I've no reason to think that a larger sample would be very different, 
but I'm too lazy to collect one.

Arnt

Date: Wed, 02 Apr 2008 08:33:33 -0400
From: Keith Moore <[email-masked]>
To: Michael Storz <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

> I checked my logs of the last 7 days. My mail servers have sent emails to
> 29.401 different domains worldwide, 29.015 via MX records and only
> 286 via A records, which is less than 1 %. For a statistik about how many
> emails are sent via MX records compared to A records the result would
> even be lower.
> 
> The missing MX records for the 286 domains are the result of lazy or
> clueless mail administrators.

While I think that deprecating A fallback would be a good idea, I don't 
buy that admins currently using it are lazy or clueless.  What they're 
doing is explicitly permitted by the current standards.

Keith

Date: Wed, 02 Apr 2008 08:31:34 -0400
From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Registration model, 2821bis-06
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> How many people would be happy if 5.1 were to say this?
> 
>  - if there is no MX record, but there is an A, then the sending
>    host MUST synthesise an MX
>  - if there is no MX record and no A, but there is an AAAA, then
>    the sending host MAY synthesise an MX
>  - even if a client doesn't use AAAA records for synthesising MX
>    records, it MAY use them for delivering mail once an MX has
>    been synthesised.

first rule is fine - really I think that fallback to A should eventually 
be deprecated (probably as of some flag day) but 2821bis clearly is not 
the place to do this.

second rule - MAY should be SHOULD NOT, perhaps even MUST NOT.

third rule is a bad idea, IMHO.  the 974 fallback means that no MX 
records + an A record implies authorization to deliver mail to that IPv4 
address.  it doesn't imply any authorization to deliver mail to any IPv6 
address.

the principle of least surprise should dictate that AAAA use is 
consistent from one conforming sending MTA implementation to another. 
the presence or absence of an A record should not affect whether an AAAA 
record is used.

I envision an MTA administrator getting IPv6 support for his server and 
then testing to see if it works for receiving mail.  IPv6 should work 
for receiving mail if the DNS is configured correctly - i.e. an MX 
record is present - and not otherwise.

Date: Wed, 2 Apr 2008 13:55:13 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Registration model, 2821bis-06
Cc: "Derek J. Balling" <[email-masked]>
Sender: [email-masked]

Derek J. Balling writes:
> On Apr 2, 2008, at 7:11 AM, Arnt Gulbrandsen wrote:
>>  - if there is no MX record and no A, but there is an AAAA, then
>>    the sending host MAY synthesise an MX
>
> I think this verbiage is (IMHO) horrible. It makes an "AAAA-only" mail
> server completely unreliable, as you can never know for certain if a
> sending host will choose to talk to you or not.

You don't know that anyway. All the deployed MTAs that implement the 
algorithm from RFC 2821 page 60 won't talk to you.

In practice an IPv6-only mail server has to have incoming and outgoing 
dual-stack relays in order to talk to all the deployed IPv4-only MTAs.

> That ambiguity-of-behavior is a bad idea (again, IMHO).

You can't force deployed IPv4 MTAs to see the AAAAs, so this pain is 
unavoidable.

Arnt

Date: Wed, 2 Apr 2008 13:50:46 +0200 (MEST)
From: Michael Storz <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

On Wed, 2 Apr 2008, Arnt Gulbrandsen wrote:

> If the ability to set up a mail server purely by setting up a host
> (without adding an MX record) is a significant feature of the internet
> mail system, then I would expect to see significant use of it. Right?
>
> So I took 30,000 recent messages containing little spam. In those
> messages I found 954 unique domains in To, From, Cc and Reply-To
> fields. Among the 954 domains, practically all have MX records and most
> have A records. There are 38 domains that have an A record but no MX.
> All 38 are reachable, 33 answer on port 80, 21 answer on port 25, and
> some of the 21 seem to be incorrectly configured.
>
> So that leaves about 20 domains, 2% of the original.
>

I checked my logs of the last 7 days. My mail servers have sent emails to
29.401 different domains worldwide, 29.015 via MX records and only
286 via A records, which is less than 1 %. For a statistik about how many
emails are sent via MX records compared to A records the result would
even be lower.

The missing MX records for the 286 domains are the result of lazy or
clueless mail administrators.

The discussion here is about a standard, which means enforcing rules and
not helping people to stay lazy.

It makes no sense to transfer a feature which was needed 20 years ago but
not anymore in these days to a new protocol.

That means in the case of no MX record, I suggest the following algorithm:

- if a domain has only A records, synthesize a MX record
- if a domain has A and AAAA records, synthesize a MX record only
  for the A records, the AAAA records should be dropped.
- if a domain has only AAAA records, do not synthesize a MX record

For a MTA with ipv4 stack, this would mean no change. For a MTA with dual
stack, only the ipv4 part would use synthesized MX records. A MTA with
ipv6 stack only would never synthesize a MX record.

Michael Storz

Cc: [email-masked]
From: "Derek J. Balling" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Subject: Re: Registration model, 2821bis-06
Date: Wed, 2 Apr 2008 07:48:51 -0400
Sender: [email-masked]

--Apple-Mail-6--951018569
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Apr 2, 2008, at 7:11 AM, Arnt Gulbrandsen wrote:
> - if there is no MX record and no A, but there is an AAAA, then
>   the sending host MAY synthesise an MX

I think this verbiage is (IMHO) horrible. It makes an "AAAA-only" mail  
server completely unreliable, as you can never know for certain if a  
sending host will choose to talk to you or not.

That ambiguity-of-behavior is a bad idea (again, IMHO).

Cheers,
D

--Apple-Mail-6--951018569
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-6--951018569--

Date: Wed, 2 Apr 2008 13:11:19 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Registration model, 2821bis-06
Sender: [email-masked]

Now that I think about it, 2821bis-06 does require something more than 
A/AAAA in order to operate a mail server: If a host only has an IPv6 
address, 2821bis-06 section 5.1 requires the operator of that host to 
form an arrangement with a dual-stack relay in order to send mail to 
IPv4-only targets.

IMO, that's not an unreasonable requirement. I think it's perfectly 
reasonable and almost unavoidable. I'm pointing it out to show that the 
text already requires something more than getting an AAAA record and 
setting up some software on the host itself.

How many people would be happy if 5.1 were to say this?

  - if there is no MX record, but there is an A, then the sending
    host MUST synthesise an MX
  - if there is no MX record and no A, but there is an AAAA, then
    the sending host MAY synthesise an MX
  - even if a client doesn't use AAAA records for synthesising MX
    records, it MAY use them for delivering mail once an MX has
    been synthesised.

This permits people to set up IPv6-only mail servers without any MX or 
relay, and it doesn't declare any deployed 2821-compliant code to be 
illegal, and it doesn't tell anyone to assume that IPv6-only devices 
are mail servers by default.

Connectivity to/from AAAA-only mail servers will suck terribly for many 
decades to come, but no 2821bis wordsmithing can avoid that. Only an 
arrangement with a dual-stack relay can improve connectivity, and that 
practically requires an MX RR or more.

Arnt

Date: Wed, 02 Apr 2008 11:21:39 +0200
From: Alessandro Vesely <[email-masked]>
To: John Levine <[email-masked]>
CC: [email-masked]
Subject: Re: History of fallback to A
Sender: [email-masked]

John Levine wrote:
> RFC 821 came out in 1982.  It makes only passing references to DNS,
> because at the time the transition from HOSTS.TXT to the DNS had not
> yet started.  RFC 883, the first description of the DNS came out over
> a year later in late 1983.  It described the now abandoned MD and MF
> records.  According to RFCs 897 and 921, the transition to DNS started
> in 1983, but HOSTS.TXT didn't go away until the end of 1985.
> 
> In January 1986, RFC 973 and 974 deprecated MD and MF records,
> replaced them with MX, and defined the MX lookup with fallback to A.
> While rereading 974, I note that it also recommends that clients do a
> WKS lookup on each MX host to see if it actually supports SMTP and
> discard the MX entry if it doesn't, but as far as I can tell, nobody
> ever did that.  Too bad.
> 
> So this means that SMTP had been in use for at least a year using
> HOSTS.TXT, and then another couple of years using A, MD, and MF,
> before MX came along, and I get the impression that MD and MF were
> clunky enough that a most people just used the A record.  Under the
> circumstances, MX without fallback to A wouldn't have worked because
> of the substantial installed base of mail servers using A records.

I think the above provides quite some insight into specifications
regarding the MX record, so I took the liberty of copying it in
http://en.wikipedia.org/wiki/MX_record#History_of_fallback_to_A

Date: Wed, 2 Apr 2008 11:27:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

Dave Crocker writes:
> John Leslie wrote:
>>    I'm happy to call it "registration" too. I think this should tend
>> to get us thinking about the right thing. How should the intent to
>> receive email for a domain be signaled?
>
> The current model permits no email-specific registration, in order to 
> operate a mail-receiving service.  Anything that eliminates use of an 
> A/AAAA record changes this basic flexibility.
>
> So the requirement "How should the intent to
> > receive email for a domain be signaled?" is, in fact, a very basic 
> change to the core Internet mail service model.

If the ability to set up a mail server purely by setting up a host 
(without adding an MX record) is a significant feature of the internet 
mail system, then I would expect to see significant use of it. Right?

So I took 30,000 recent messages containing little spam. In those 
messages I found 954 unique domains in To, From, Cc and Reply-To 
fields. Among the 954 domains, practically all have MX records and most 
have A records. There are 38 domains that have an A record but no MX. 
All 38 are reachable, 33 answer on port 80, 21 answer on port 25, and 
some of the 21 seem to be incorrectly configured.

So that leaves about 20 domains, 2% of the original.

Yes, it's a basic feature, but it's a little-used one, and half the 
usage is due to mistakes. _Half_ the users won't get their DSNs. That's 
not a feature we ought to extend to IPv6.

> In a clean-slate exercise, there are good reasons to consider imposing 
> that requirement.  In a world with decades of momentum for 
> administering and operating email a certain way, changing the 
> registration model warrants separate, careful, and extended 
> consideration.
>
> It is a topic thoroughly worthy of that consideration.
>
> However, trying to squeeze that effort into the RFC2821bis process is 
> a good way to kill both.

It would be good to have wording for 2821bis that neither consciously 
extends the A rule nor consciously doesn't extend it. But I can't think 
of a way to do it.

Arnt

Date: Wed, 02 Apr 2008 01:20:13 -0400
From: Keith Moore <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: outdated thinking about domains and hosts
Sender: [email-masked]

Some of the arguments being put forth here about the use of AAAA records 
as fallback for missing MX records seem to be based on a very old and 
long-obsolete idea of the relationship between domain names and hosts.

Many years ago, it used to be the case that a domain name was the name 
of a host.  More precisely, a domain name was associated with a host's 
IP address, and the vast majority of hosts had exactly one network 
interface and one IP address.  In that world, it was easy to think of 
the host and domain and IP address as all being more-or-less pointers to 
the same thing.

Of course, in those days the vast majority of hosts were also multi-user 
timesharing computers.  Hosts were expensive and because of this it was 
generally expected that a host would serve a community of users rather 
than a single user.  So it was natural to think of a community of users 
as having a host that provided computing resources, and to associate 
that community with the host's domain name and an IP address.   Several 
of the early Internet services were built around the idea of being able 
to remotely access a user's resources or information on a host: finger, 
ftp, telnet, and of course email.

The first nail in the coffin of this idea was RFC 974.  The introduction 
of MX records broke the host=domaindress relationship because MX 
records allowed email to be sent to hosts that were not even connected 
to the Internet.  More generally, MX records made it possible to create 
domains for use in email addresses that didn't correspond to any actual 
host anywhere.  All that mattered was that the primary MX servers for a 
domain knew what to do with mail that was sent to a user at that domain.

Since then a number of things have further weakened the 
host=domaindress relationship:

- As the Internet grew, in order to make various services scale to 
handle the demand, it often became necessary to implement a service with 
  large numbers of host that shared a single domain name - or even 
sharing a single IP address using special-purpose load-sharing NATs.

- Eventually it was realized that it was very convenient to associate a 
service with a domain name (say for marketing purposes or ease-of-use) 
even when the service required only a small fraction of the resources 
available on a single host.  The result was what is known as "virtual 
hosting" where a single host provides services that are associated with 
a large number of domains, at much lower cost than would have been 
required to provide a separate host for each domain.  Extensions to HTTP 
  made it possible for a web server to handle requests for URLs in 
different domains even though they were associated with the same IP 
address.  Other workarounds have been found for other protocols (e.g. 
the common POP/IMAP/FTP convention of using usernames of the form 
"user@domain" during login).

For similar reasons, it is now common for a single host to be accessible 
via multiple IP addresses.

- SRV records further weakened the relationship between domains and 
hosts by allowing that relationship to be specified on a per-service 
basis, for application protocols defined to use SRV.

Today, the vast majority of references to a domain name, whether in 
email or in a URL or otherwise, DO NOT refer to a specific host. 
Domains are no longer equivalent or even nearly equivalent to host 
names, and haven't been for a long time.

----

How does this relate to AAAA fallbacks?  Simply this:

The argument that a host ought to be able to run email without 
registering an MX record for its domain is specious.  In general, a host 
does not have a designated domain name or even a designated address 
anymore.  Even a host as modest as a typical desktop PC can support an 
arbitrary number of services that are associated with an arbitrary 
number of domains.

Yes, there might be a domain associated with a host's IP address via DNS 
PTR lookup, but that's irrelevant because very few applications care 
what domain the PTR record points to.  Certainly email doesn't care, 
except for logging.  And quite often that domain is meaningless - just 
something provided by the ISP because certain stupid applications won't 
work unless there's a PTR record there.  (As if having a PTR record 
pointing to a meaningless domain name were an indicator of anything useful.)

One consequence of this is that the owner of a host isn't really 
prevented from running an email server on that host by his inability to 
write an MX record to any particular zone.  I see three cases:

1) The owner of the host also owns one or more domains that he can 
associate with the host, and he has write permission to the DNS zones 
for those domains.  He can create MX records for those domains.

2) Like case (1) but for some reason the interface to those DNS zones is 
dysfunctional and won't let him create MX records.  But since the owner 
of the host also owns those domain names, he can move them to other DNS 
hosting providers with less dysfunctional interfaces.  And DNS providers 
will get their act together when they realize they're losing business. 
problem solved.

3) The owner of the host doesn't own the domain name that someone has 
associated with that host.  In that case, the host owner simply doesn't 
have the right to create email addresses at that domain.  That right 
belongs to the domain owner.  The host owner can still run an email 
server on his host, he just can't insist that email addresses that are 
associated with someone else's domain should be handled by his host.

Keith

Date: Wed, 2 Apr 2008 00:35:13 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

At 16:36 +0100 on 04/01/2008, Sabahattin Gucukoglu wrote about Re: 
Minor is. It's not a pardigm change:

>In reality, for me at least, it's obvious what has to happen: you
>synthesise the MX record, then act on it according to your supported
>address families as you would with any other non-synthesised record -
>connect to whatever you can.

When you synthesize it ONLY include A records and go from there. When 
you create your synthesized MX as if it was FQDN MX 0 FQDN create it 
as if the FQDN A/AAAA referenced by the MX was

FQDN A IPv4A
      A IPv4B

even if the FQDN A/AAAA is really

FQDN A    IPv4A
      A    IPv4B
      AAAA IPv6A
      AAAA IPv6B

Date: Wed, 2 Apr 2008 00:17:39 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

At 23:00 -0400 on 03/31/2008, John C Klensin wrote about Re: Minor 
is. It's not a pardigm change:

>Once that implicit MX record exists, there are fairly clear rules 
>about which address to use for foo.example.com.   To be a little 
>more precise, while the rules are clear, they pretty much leave it 
>up to the sending host and there is no real difference between the 
>traditional choice between the two IPv4 addresses and the newer 
>choice between the IPv4 addresses and the IPv6 one.   The Standard 
>also gives the sender implementation some flexibility about how many 
>of those addresses it is obligated to try.

I disagree with your methodology. If the rule is that incoming MTAs 
(ie: Those MTAs that are supposed to be located via MXs) which listen 
at an IPv6 IPN are REQUIRED to be designed by an MX (ie: You are not 
treated as an incoming IPv6 MTA UNLESS you are pointed to by an MX), 
any implicate MX that is built in the absence of an EXPLICATE MX 
should contain ONLY the A records for that FQDN. Any AAAA records for 
the FQDN are ignored in building the implicate MX.

Date: Tue, 1 Apr 2008 20:44:36 -0400
From: John Leslie <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

   Frankly, I think Dave just enjoys arguing, but I see a point to clarify:

Dave Crocker <[email-masked]> wrote:
> John Leslie wrote:
> 
>> One could say, "Anything that eliminates the use of an A RR as a
>> substitute registration changes this flexibility."

   I fat-fingered this, thinking "substitute for registration, but not
typing it. I do not believe Implied-MX is a "registration".

> What this reformulation misses is that using an A* record means that
> there is no incremental registration requirement.

   ... another of Dave's leaps of faith...

> Since the A* record is there for other reasons, it means that being an
> email server only requires running the software.

   In fact, "being" an email server has never required anything beyond
running the software. Witness some extremely clue-challenged email
administrators we have all had the pleasure of dealing with...

> So, what you are calling "substitution" is, in fact, requiring an 
> email-specific registration step that is not now present.

   This is a difficult sentence to parse -- not made any easier, alas,
by my fat-fingered typing. But, as I read RFC2821, there clearly _is_
an email-specific registration step "present"; but there's also an
exception to it.

   Dave seems to believe that the existence of an exception not only
dussolves any "requirement", but also requires us to make additional
exceptions whenever a "similar" situation arises. You missed your
calling as a Philadelphia lawyer, Dave. ;^)

> In fact, it has already been documented over the last few days that
> registering MXs can be problematic.

   ... as well as a number of other instances of the clue-challenged
running the railroad...

   (Note, Dave is not saying these clue-challenged DNS administrators
would _actually_ prevent folks from exercising their right to squeeze
under the Implied-MX exception already in RFC2821.)

>>> So the requirement "How should the intent to receive email for a
>>> domain be signaled?" is, in fact, a very basic change to the core
>>> Internet mail service model.
>>
>> Funny, I thought it was a question.
> 
> There is currently no requirement to register intent.  So to ask the 
> question is to look for a change to the model.

   (Exasperation is creeping in...)

   I _was_ careful to avoid the "evil R-word" there. An intent _can_
be "signaled" without "registration".

> I'm fine with providing an ability to state intent. I'm not fine
> with requiring it.

   We're writing _standards_ here, Dave. Standards are _about_
requiring things. Making ever-more exceptions is something legisators
love to do, but it can never simplify the overall process.

   I have expressed elsewhere my doubts whether folks coding email
server software are even going to follow the instructions we put in
2821bis. (I've even expressed doubt whether it's _possible_ to follow
the convoluted revision of Section 5 currently in 2821bis-09.)

   Everybody here is nearing exhaustion. The "about a week" Tony
Hansen set for this discussion is drawing to a close. I don't envy
his task of calling consensus on this.

>> But while we're discussing the subject, I see nothing wrong with
>> raising the issue. Perhaps somebody might become convinced that
>> active registration is worth encouraging.
> 
> As long as the discussion is decoupled from the *bis round of
> discussion, that's dandy.

   I'd be happy to discuss it separately.

> It's easy to get distracted.

   Indeed!!!

--
John Leslie <[email-masked]>

Date: Tue, 1 Apr 2008 23:48:55 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: Scope Creep
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Apr 01, 2008 at 02:08:54PM -0700, Dave Crocker wrote:

> >   One could say, "Anything that eliminates the use of an A RR as a
> >substitute registration changes this flexibility."
> 
> What this reformulation misses is that using an A* record means that there 
> is no incremental registration requirement.  Since the A* record is there 
> for other reasons, it means that being an email server only requires 
> running the software.

That is how it was, decades ago.  And it made sense, in a time when
computers had to be moved by a large number of trucks.

Then MX records were invented, and this fall back came into existence.

That too made sense at the time. From that moment on, an *A* record
would also function as a default MX record.

But this does not imply an *AAAA* record needs to.  And even if it
did, things change.

One of the reasons for IPv6 was a large number of possible addresses,
so that each person could have their own range, and make it possible
to give your wrist watch an address.  It is unlikely that all of such
new devices will receive mail.

Compare:

Most devices on the net can receive mail
vs.
Most devices on the net cannot receive mail

> >>So the requirement "How should the intent to receive email for a
> >>domain be signaled?" is, in fact, a very basic change to the core
> >>Internet mail service model.
> >
> >   Funny, I thought it was a question.
> 
> There is currently no requirement to register intent.  So to ask the 
> question is to look for a change to the model.

If the intention was "no change", then IPv6 would have been exactly
like IPv4 but just with larger addresses.  It isn't.

The world has changed, and that includes SMTP. There is no reason to
implement an antique fall back mechanism into a brand new protocol.

From: [email-masked]
Cc: [email-masked]
Date: Tue, 01 Apr 2008 13:50:46 -0700 (PDT)
Subject: Re: nullmx
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> <[email-masked]> wrote:
 
> >> For pure clients I'd look into RFC 4409, 4954, and 5068.
> > 4409: Submission. Irrelevant
> [...]

> If you consider "direct-to-MX" as perfectly okay it is
> unlikely that we find a model where the MUST in 2821bis
> for <postmaster> makes sense from an MX-POV:

I'm not sure what you mean by "direct-to-MX", but regardless, I must say that I
view the <postmaster> convention as a fairly pointless anachronism at this
point. I don't know of a single widely used client that will let you send a
message to such an address. And most users aren't going to know how to do it
using telnet.

> If the "unknown stranger" connecting to an MX is a MUA
> or any MTA not accepting mail, then <postmaster> won't
> work.  As you said 2821bis doesn't require <postmaster>
> for anything that sends, it requires it for relays.

For about the fifth time, that's not what 2821bis says. You keep dropping the
vital qualification that the requirement only applies to systems, _including_
_relays_, that operate an SMTP receiver. There is no requirement that a system
with an SMTP client also have an SMTP server up and running.

> > We're not talking about MSAs or submission operations
> > here.

> When "direct-to-MX" doesn't work, as it's often the case
> today, users submit their mail, and after that what is
> left talking to an MX is a relay.  Either directly the
> used MSA, or some outbound relay behind the MSA.

I have no idea what you're talking about.

> >> for SMTP relays 2821bis 4.5.1 says "postmaster MUST
> >> work".
 
> > Actually, it says nothing of the sort. The text is very
> > clear: It says that SMTP *receivers* must have a
> > postmaster address.

> We are talking about the same three lines, you say that's
> very clear, why is it that we interpret this different ?

I'm very much afraid it's because your reading is quite simply wrong.

> | Any system that includes an SMTP server supporting mail
> | relaying or delivery MUST support the reserved mailbox
> | "postmaster" as a case-insensitive local name.

> Ignoring "direct-to-MX" cases, and the normal operations
> on the side of the receiver:  The last hop on the side of
> the originator talking as client to the first hop on the
> side of the receiver (MX or simple A-fallback server) is
> a relay.

> It's the outbound relay behind or identical with the MSA.
> And it's a relaying server, any MSA is a relaying server.

> And a separate outbound relay behind the MSA also acts as
> server when it gets outbound mail from the MSA.  When it
> has something in its send queue it connects - as client -
> to the MX (or A-fallback or AAAA-toaster), and that is
> where it might cause trouble.

> The admin of the MX trying to figure out whatever goes
> wrong has the connecting IP, maybe also a dubious EHLO,
> but the IP is good enough, and can send a mail to this
> relay, <postmaster@[IP]>, asking what's going on.

They can if there's an SMTP server on the host to send it to. But it is in no
way a standards violation if there isn't. Nor is there apparently any
requirement that a host actually accept mail sent using an address literal
specifying one of its IP addresses. (I could have sworn handling such addresses
was required but I just checked and it apparently isn't.) And regardless of
what's required, the fact is a lot of systems either won't accept address
literals or don't know their own address literal "names" when they see them,
and no amount of rulemaking is likely to change this.

> ...

> > even if, say, an outbound relay host also operates an
> > SMTP server, in many setups it will not accept incoming
> > connections from the Internet - it's instead reserved
> > for messages coming from "inside".

> Then it IMO missed a critical point of the <postmaster>
> rule for relays.

There is no such rule and repeated statements to the contrary isn't going to
bring such a rule into existance. Again, the statements in section 4.1.3 are
all qualified by clauses like "by all receivers" and "that includes an SMTP
server" and so on. You cannot simply ignore these qualifiers because you don't
like what they imply.

> If there is no way to report trouble
> with a misbehaving outbound relay the only alternative
> is to block it, firewall its IP or similar.  And for a
> setup with only one outbound relay it will be difficult
> to discuss the removal of this block after the trouble
> was fixed.

Yep. I do it all the time.

> > Assuming there's something who actually reads postmaster
> > mail (increasingly unlikely, more's the pity), sending
> > something directly to the postmaster address to the
> > server that is coresident with the misbehaving cliwnt
> > might be worth a try in such a situation.

> That is the idea, or maybe today only an ideal.  I don't
> insist that it works, but 2821bis says MUST for a reason.
> The only reason I can imagine is to report trouble.  With
> potentially dire consequences if it doesn't work.

Yes, well, there are lots of dire consequences lurking everywhere. That's life
in the food chain.

> > in most cases a better idea would be to send to the
> > postmaster address associated with the domain listed in
> > the MAIL FROM address.

> If the trouble we're talking about reaches the point where
> you have more than only the IP and maybe EHLO.  When you
> get MAIL FROM:<[email-masked]> an attempt to
> report problems to <[email-masked]> won't do
> what you want (at the moment disabled + over quota, but
> when it worked you'd talk with me - and in the case of a
> random de.clara.net user they won't be able to help you
> fix whatever is wrong).

Again, the present-day reality is that postmaster addresses, especially
host-specific ones, are often unmonitored and may even be routed straight to
the bitbucket. If all you have is the IP address of a problem system I suspect
a better approach is to figure out who the address belongs to, then find an
approprirate technical contact address to report the problem to. (And the odds
are pretty good it won't be "postmaster@anything".)

> As things are today the trouble you try to report might be
> even no de.clara.net problem, you better don't trust that
> MAIL FROM addresses mean anything at all (as it happens
> you'd have an SPF PASS or FAIL in this example, but I fear
> the majority of MAIL FROMs still is "unclear")

> >> Please don't tell me that this assumption is unjustified

> > I'm afraid I don't have a choice. The requirements you
> > appear to be advocating are unjustified and unworkable in
> > practice.

> I'm not exactly advocating it, I quoted 2821bis and think
> it makes sense.  Folks ignoring this rule will find out if
> they can get away with it.

There is no such rule and therefore the people are "ignoring" nothing.

> Whenever I need to report some
> trouble and find that postmaster@ doesn't work, I note the
> fact in the postmaster.rfc-ignorant.org zone.  It's nothing
> personal, just a public "don't waste your time" notebook.

You might want to review the rfc-ignorant.org criteria for such listings, which
is also quite clear:

  If the right-hand-side of an address doesn't have a postmaster address (e.g.,
  given an address of <[email-masked]>, if "[email-masked]" bounces as
  non-existent (on any of the valid MX servers for 'example.tld'), then
  example.tld would be listed.

In other words, this is all about postmaster addresses corresponding to the
domain used in some address not working. There is nothing in the criteria that
would support listing a domain because they don't have an SMTP server accesible
on every system that operates an SMTP client.

				Ned

Date: Tue, 01 Apr 2008 14:08:54 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John Leslie <[email-masked]>
CC: [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

John Leslie wrote:
>    This statement is exactly correct.
> 
>> Anything that eliminates use of an A/AAAA record changes this basic
>> flexibility.
> 
>    This statement is not.
> 
>    One could say, "Anything that eliminates the use of an A RR as a
> substitute registration changes this flexibility."

What this reformulation misses is that using an A* record means that there is no 
incremental registration requirement.  Since the A* record is there for other 
reasons, it means that being an email server only requires running the software.

So, what you are calling "substitution" is, in fact, requiring an email-specific 
registration step that is not now present.  In fact, it has already been 
documented over the last few days that registering MXs can be problematic.

>> So the requirement "How should the intent to receive email for a
>> domain be signaled?" is, in fact, a very basic change to the core
>> Internet mail service model.
> 
>    Funny, I thought it was a question.

There is currently no requirement to register intent.  So to ask the question is 
to look for a change to the model.

>    Dave is certainly entitled to an opinion that there shouldn't be
> any such way -- thought I don't think that's _quite_ what he's saying.

It wasn't.  I'm fine with providing an ability to state intent.  I'm not fine 
with requiring it.

> (I wish he'd be a little clearer.)

So does he, but he's not likely to get any better at clarity.

>    But while we're discussing the subject, I see nothing wrong with
> raising the issue. Perhaps somebody might become convinced that
> active registration is worth encouraging.

As long as the discussion is decoupled from the *bis round of discussion, that's 
dandy.

>> However, trying to squeeze that effort into the RFC2821bis process
>> is a good way to kill both.
> 
>    ... which makes me wonder why folks are so intent on squeezing an
> extension of Implied-MX into this (hopefully) Draft Standard...

Well, after all, as long as we have the hood up,...

It's easy to get distracted.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 1 Apr 2008 15:15:41 -0400
From: John Leslie <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

Dave Crocker <[email-masked]> wrote:
> John Leslie wrote:
> 
>> I'm happy to call it "registration" too. I think this should tend
>> to get us thinking about the right thing. How should the intent to
>> receive email for a domain be signaled?
> 
> The current model permits no email-specific registration, in order to 
> operate a mail-receiving service.

   This statement is exactly correct.

> Anything that eliminates use of an A/AAAA record changes this basic
> flexibility.

   This statement is not.

   One could say, "Anything that eliminates the use of an A RR as a
substitute registration changes this flexibility."

   And, I'll admit up-front that I'd like to do so. But that's not
the subject at hand.
> 
> So the requirement "How should the intent to receive email for a
> domain be signaled?" is, in fact, a very basic change to the core
> Internet mail service model.

   Funny, I thought it was a question.

   Dave is certainly entitled to an opinion that there shouldn't be
any such way -- thought I don't think that's _quite_ what he's saying.
(I wish he'd be a little clearer.)

> In a clean-slate exercise, there are good reasons to consider
> imposing that requirement. In a world with decades of momentum for
> administering and operating email a certain way, changing the
> registration model warrants separate, careful, and extended
> consideration.

   ... which is why I'm prepared to accept continuing the RFC2821
language.

   But while we're discussing the subject, I see nothing wrong with
raising the issue. Perhaps somebody might become convinced that
active registration is worth encouraging.

   (There are those of us that thought we were doing so when 2821
was written...)

> It is a topic thoroughly worthy of that consideration.

   Thank you.

> However, trying to squeeze that effort into the RFC2821bis process
> is a good way to kill both.

   ... which makes me wonder why folks are so intent on squeezing an
extension of Implied-MX into this (hopefully) Draft Standard...

--
John Leslie <[email-masked]>

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: nullmx
Date:  Tue, 1 Apr 2008 20:59:38 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 168
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<[email-masked]> wrote:
 
>> For pure clients I'd look into RFC 4409, 4954, and 5068.
> 4409: Submission. Irrelevant
[...]

If you consider "direct-to-MX" as perfectly okay it is
unlikely that we find a model where the MUST in 2821bis
for <postmaster> makes sense from an MX-POV:

If the "unknown stranger" connecting to an MX is a MUA
or any MTA not accepting mail, then <postmaster> won't
work.  As you said 2821bis doesn't require <postmaster>
for anything that sends, it requires it for relays.

> We're not talking about MSAs or submission operations
> here.

When "direct-to-MX" doesn't work, as it's often the case
today, users submit their mail, and after that what is
left talking to an MX is a relay.  Either directly the
used MSA, or some outbound relay behind the MSA.

>> for SMTP relays 2821bis 4.5.1 says "postmaster MUST
>> work".
 
> Actually, it says nothing of the sort. The text is very
> clear: It says that SMTP *receivers* must have a 
> postmaster address.

We are talking about the same three lines, you say that's
very clear, why is it that we interpret this different ?

| Any system that includes an SMTP server supporting mail
| relaying or delivery MUST support the reserved mailbox
| "postmaster" as a case-insensitive local name.

Ignoring "direct-to-MX" cases, and the normal operations
on the side of the receiver:  The last hop on the side of
the originator talking as client to the first hop on the
side of the receiver (MX or simple A-fallback server) is
a relay.

It's the outbound relay behind or identical with the MSA.
And it's a relaying server, any MSA is a relaying server.

And a separate outbound relay behind the MSA also acts as
server when it gets outbound mail from the MSA.  When it
has something in its send queue it connects - as client -
to the MX (or A-fallback or AAAA-toaster), and that is
where it might cause trouble.

The admin of the MX trying to figure out whatever goes
wrong has the connecting IP, maybe also a dubious EHLO,
but the IP is good enough, and can send a mail to this
relay, <postmaster@[IP]>, asking what's going on.

> Furthermore, it says that the bare local name 
> "postmaster" is what has to work.

Yes, I don't insist on the domain-literal, the important
point is that the IP of the client causing trouble is 
known, and minus "direct-to-MX" cases this client is a
relay.  

> It says *nothing* about postmaster@random-host-system-name
> having to work.

Right, I don't insist that the EHLO FQDN of the relay
makes sense, using <postmaster> at the known IP may be
better to discuss whatever goes wrong.  

> I think your problem here is you're conflating hosts
> with administrative domainss.

No, I don't think that's the misunderstanding.  I think
the model MUA -> MSA -> outbound relay -> MX covers all
potentially dangerous shortcuts, we don't need to make
it more complex.  

There can be separate administrative domains on the
side of the sender, but from an MX POV trying to report
trouble caused by the outbound relay that's irrelevant
and invisible, all it has is the IP and maybe a more or
less useful EHLO FQDN.

> specific hosts dedicated to specific tasks: Incoming
> relay from the Internet, outbound relay to the 
> Internet, submission from local users, spam filtering,
[...]

Yes, "do NOT assume that your MSA is the host talking
to MXs, there can be separate outbound relays" belongs
to the things folks learn when they ask for help on the
SPF HELP list.  Shortly before or after they mastered
"MX is not necessarily related to outbound mail".

Oversimplifications are dangerous, but we don't need to
make it more complex than necessary.  Unfortunately all
these important points at the "border" are not discussed
in email-arch.  The email-arch focus is on "there can be
more ADMDs involved than you think".  Which is true, but
not relevant for the "border" cases.

> even if, say, an outbound relay host also operates an
> SMTP server, in many setups it will not accept incoming
> connections from the Internet - it's instead reserved
> for messages coming from "inside".

Then it IMO missed a critical point of the <postmaster>
rule for relays.  If there is no way to report trouble 
with a misbehaving outbound relay the only alternative
is to block it, firewall its IP or similar.  And for a
setup with only one outbound relay it will be difficult
to discuss the removal of this block after the trouble
was fixed.

> once again it is quite clearly talking about a server's
> implementation of the RCPT TO command.

ACK, anything with <postmaster> is about RCPT TO, nobody
should try MAIL FROM:<postmaster>, for that 2821bis has
MAIL FROM:<>.

> Assuming there's something who actually reads postmaster
> mail (increasingly unlikely, more's the pity), sending
> something directly to the postmaster address to the
> server that is coresident with the misbehaving cliwnt
> might be worth a try in such a situation.

That is the idea, or maybe today only an ideal.  I don't
insist that it works, but 2821bis says MUST for a reason.
The only reason I can imagine is to report trouble.  With
potentially dire consequences if it doesn't work.

> in most cases a better idea would be to send to the 
> postmaster address associated with the domain listed in
> the MAIL FROM address.

If the trouble we're talking about reaches the point where
you have more than only the IP and maybe EHLO.  When you
get MAIL FROM:<[email-masked]> an attempt to
report problems to <[email-masked]> won't do
what you want (at the moment disabled + over quota, but
when it worked you'd talk with me - and in the case of a
random de.clara.net user they won't be able to help you
fix whatever is wrong). 

As things are today the trouble you try to report might be
even no de.clara.net problem, you better don't trust that
MAIL FROM addresses mean anything at all (as it happens
you'd have an SPF PASS or FAIL in this example, but I fear
the majority of MAIL FROMs still is "unclear")

>> Please don't tell me that this assumption is unjustified

> I'm afraid I don't have a choice. The requirements you
> appear to be advocating are unjustified and unworkable in
> practice.

I'm not exactly advocating it, I quoted 2821bis and think
it makes sense.  Folks ignoring this rule will find out if
they can get away with it.  Whenever I need to report some
trouble and find that postmaster@ doesn't work, I note the
fact in the postmaster.rfc-ignorant.org zone.  It's nothing
personal, just a public "don't waste your time" notebook.

 Frank

Date: Tue, 01 Apr 2008 11:50:48 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John Leslie <[email-masked]>
CC: [email-masked]
Subject: Re: Scope Creep
Sender: [email-masked]

John Leslie wrote:
>    I'm happy to call it "registration" too. I think this should tend
> to get us thinking about the right thing. How should the intent to
> receive email for a domain be signaled?

The current model permits no email-specific registration, in order to operate a 
mail-receiving service.  Anything that eliminates use of an A/AAAA record 
changes this basic flexibility.

So the requirement "How should the intent to
 > receive email for a domain be signaled?" is, in fact, a very basic change to 
the core Internet mail service model.

In a clean-slate exercise, there are good reasons to consider imposing that 
requirement.  In a world with decades of momentum for administering and 
operating email a certain way, changing the registration model warrants 
separate, careful, and extended consideration.

It is a topic thoroughly worthy of that consideration.

However, trying to squeeze that effort into the RFC2821bis process is a good way 
to kill both.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 1 Apr 2008 14:39:35 -0400
From: John Leslie <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Scope Creep
Sender: [email-masked]

Dave Crocker <[email-masked]> wrote:
> 
> 15 years ago, IPv6's -- and, yes, I mean what we now call IPv6 and yes,
> I mean 1.5 decades ago -- once-in-a-lifetime occurrence was touted as
> the reason for massively expanding the scope of the original problem
> that was being worked on (limited address space.)

   IPv6 has been a _very_ interesting study in scope-creep, and I hope
to get to read some professional historians' views on this subject.

> Please, oh please, let's not re-use that justification for scope-creep.

   Alas, the only way to avoid that is by _having_ other alternatives
for adding features some of us see as essential.

   Happily, SMTP has a feature for Extensions. :^)

   Thus, when somebody proposes a feature which could reasonably be
done by an SMTP Extension, we can send them off to design one.

   Alas, there are features which _can't_ be done using extensions.

   One which I particularly cared about was recording more trace
information. We had some flame-wars about that, and ended up with
rather less than I wanted, but an extension of Received trace headers
which can serve the needs I envisioned.

   Our current flame-war concerns what Dave likes to call "registration"
of email-receiving services for a domain. This is another thing we
_can't_ do via SMTP Extensions.

   I'm happy to call it "registration" too. I think this should tend
to get us thinking about the right thing. How should the intent to
receive email for a domain be signaled?

   In RFC2821, it's signaled by MX RRs (whether actual or implied).
The actual MX RR seems to fulfil an "adequate" registration. The
implied-MX, to be frank, doesn't. The presence of an A RR indicates
nothing about such an intent. We must go further to make implied-MX
even barely tolerable as "registration".

   Discussion here has centered on, "Well, try port 25: if it wants
email for that domain it'll be listening on port 25!"

   That's false, of course: there are any number of reasons it might
not be listening at any moment. So we write in language that requires
multiple tries. (Others have noted problems inherent in this.)

   And merely listening on port 25 isn't enough. It's actually common
for a host to listen on port 25 without the slightest intent of
accepting email to a domain identical to whatever domain's A RR may
have returned its IP address. Thus we have to endure things like
Verizon's Call-Back Verification... :^(

   I make no apologies for having proposed a step away from
implied-MX as "registration". It's a real issue. It can't be fixed
by any SMTP Extension. Is it "scope-creep"? Perhaps. But it's also
an interoperability problem which would ordinarily be considered
when moving to Draft Standard.

> It's more like "let's be judicious" and "let's not let spamming fears
> whip our requirements around trying to satisfy secondary goals."

   The problem which concern me are "related to" spam, yes; but they'd
still be issues if spam disappeared entirely.

   May I suggest, "Let's be judicious, and not let the mention of
spamming fears prevent us from considering issues which deserve our
attention regardless of spam."

--
John Leslie <[email-masked]>

Date: Tue, 01 Apr 2008 11:23:50 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John Leslie <[email-masked]>
CC: [email-masked]
Subject: Re: dual-stack IP transition
Sender: [email-masked]

John Leslie wrote:
>    Minimizing the change _does_ tend to ease implementation...
> 
>> and particularly should not make any changes to its registration model.
> 
>    That really doesn't follow.
> 
>    In particular, there are a number of possible gateway-like options
> for communication between an IPv4-only host and an IPv6-only host.
> It might be _very_ helpful to register preferences on which to use.

The registration model is not about v4 vs. v6.  It is about use of A (or AAAA) 
vs. MX in order to find an SMTP receiving host.

And the problems with requiring MX registration, in order to receive mail, have 
now been well documented over the last few days.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 01 Apr 2008 11:19:53 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

Paul Smith wrote:
> *Now* is the time to do this. If the IPv6 mail standard is finalised 
> allowing fallback to AAAA, then the cat is out of the bag, and there's 
> no going back. 

The above seems to nicely capture the problem we are having in this dialogue.

Some folks are treating IPv6 considerations in isolation and even as a 
clean-slate approach.  Others are attending to the larger, installed system and 
viewing v6 issues as an incremental change.

This is a pretty classic tradeoff between the pragmatic vs. the ideal.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 1 Apr 2008 13:56:11 -0400
From: John Leslie <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: dual-stack IP transition
Sender: [email-masked]

Dave Crocker <[email-masked]> wrote:
> 
> Basically, the current task is one of supporting a dual-stack
> networking environment.

   I would _like_ to talk about that.

> That's a challenge for all Internet use, not just email. 

   Agreed.

> Solutions for it need to be universal, not specific to email.

   Alas, the "universal" solutions I've seen don't seem to be adequate.

   (Off-topic opportunity: I'm observing some work intended to make
TCP itself address-agile, even to the extent of continuing a TCP
session started within IPv4 over IPv6, and vice-versa.)

> The SMTP specification should be modified in the smallest and most 
> localized fashion possible

   Minimizing the change _does_ tend to ease implementation...

> and particularly should not make any changes to its registration model.

   That really doesn't follow.

   In particular, there are a number of possible gateway-like options
for communication between an IPv4-only host and an IPv6-only host.
It might be _very_ helpful to register preferences on which to use.

   The current 2821bis discusses this issue in Section 5.1:
] 
] When a domain name associated with an MX RR is looked up and the
] associated data field obtained, the data field of that response MUST
] contain a domain-name.  That domain-name, when queried, MUST return
] at least one address record (e.g., A or AAAA RR) that gives the IP
] address of the SMTP server to which the message should be directed.
]...
] When the lookup succeeds, the mapping can result in a list of
] alternative delivery addresses rather than a single address, because
] of multiple MX records, multihoming, or both.  To provide reliable
] mail transmission, the SMTP client MUST be able to try (and retry)
] each of the relevant addresses in this list in order, until a
] delivery attempt succeeds.  However, there MAY also be a configurable
] limit on the number of alternate addresses that can be tried.  In any
] case, the SMTP client SHOULD try at least two addresses.

   I'm guessing that this indicates that an IPv4-only host may
"try" an IPv6 address by failing to open an IPv6 socket.

   I find it unfortunate that there's no mention of continuing the
search in hopes of finding an IPv4 address...

] Two types of information are used to rank the host addresses:
] multiple MX records, and multihomed hosts.
] 
] MX records contain a preference indication that MUST be used in
] sorting if more than one such record appears (see below).  Lower
] numbers are more preferred than higher ones.  If there are multiple
] destinations with the same preference and there is no clear reason to
] favor one (e.g., by recognition of an easily-reached address), then
] the sender-SMTP MUST randomize them to spread the load across
] multiple mail exchangers for a specific organization.

   This seems to _prohibit_ preferring the address family the host
prefers.

] The destination host (perhaps taken from the preferred MX record) may
] be multihomed, in which case the domain name resolver will return a
] list of alternative IP addresses.  It is the responsibility of the
] domain name resolver interface to have ordered this list by
] decreasing preference if necessary, and the SMTP sender MUST try them
] in the order presented.
] 
] Although the capability to try multiple alternative addresses is
] required, specific installations may want to limit or disable the use
] of alternative addresses.  The question of whether a sender should
] attempt retries using the different addresses of a multihomed host
] has been controversial.  The main argument for using the multiple
] addresses is that it maximizes the probability of timely delivery,
] and indeed sometimes the probability of any delivery; the counter-
] argument is that it may result in unnecessary resource use.  Note
] that resource use is also strongly determined by the sending strategy
] discussed in Section 4.5.4.1.

   If I move on to Section 5.2, however, there's contradictory
language:
] 
] In the contemporary Internet, SMTP clients and servers may be hosted
] on IPv4 systems, IPv6 systems, or dual-stack systems that are
] compatible with either version of the Internet Protocol.  The host
] domains to which MX records point may, consequently, contain "A RR"s
] (IPv4), "AAAA RR"s (IPv6), or any combination of them.  While RFC
] 3974 [11] discusses some operational experience in mixed
] environments, it was not comprehensive enough to justify
] standardization and some of its recommendations appear to be
] inconsistent with this specification.  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).

   (I would like to believe that such a major shift would have gotten
at least a "but see Section 5.2" note back in Section 5.1.)

   This text worries me! It would seem to permit IPv6 clients to make
no actual attempt to deliver email to IPv4-only domains, not even by
use of a gateway.

] 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.

   Does this text help? I can't tell... :^(

--
John Leslie <[email-masked]>

Date: Tue, 01 Apr 2008 18:36:28 +0100
From: Paul Smith <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Sabahattin Gucukoglu <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, John R Levine <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

>
> - mail queues get clogged up trying to send mail to hosts that don't 
> support SMTP.  because "connection refused" is a temporary error to 
> SMTP, any mail sent to a host that doesn't support SMTP will sit in a 
> queue for days before bouncing or being discarded. 
This one is the one which I find the most compelling. In my mind, at the 
moment the specification causes ambiguous behaviour because of the 
implicit fallback to A records. Does 'connection refused' mean 'there is 
no mail server here, so give up and don't come back' or 'the mail server 
is down for maintenance/crashed/etc, so please do come back'? With the 
implicit fallback to A, there's no way to tell, but with a required MX 
record there is.

Spam being received by people won't be reduced by not allowing fallback 
to AAAA, as the mail wouldn't get anywhere anyway, but it will be 
sitting in queues on servers taking up resources unnecessarily.

I can see the need for this ambiguity in IPv4 now for backwards 
compatibility reasons, and I can see why it was there originally for 
backwards compatibility at that time, but now there is the prospect of 
clearing things up and removing the ambiguity in the future, without 
breaking backwards compatibility more than it would be anyway (IPv4 only 
mail servers won't be able to talk to IPv6 only servers anyway).

*Now* is the time to do this. If the IPv6 mail standard is finalised 
allowing fallback to AAAA, then the cat is out of the bag, and there's 
no going back. So, unless there's a good technical reason (the only 
reasons I've seen so far have essentially been 'ease of use' or 
'political' reasons (the possibility of overly time consuming approval 
processes to get another MX record added in the rare case where an 
existing host without mail will need to have mail added)) I'm for not 
allowing fallback to AAAA as it removes the 'connection refused' ambiguity.

Date: Tue, 1 Apr 2008 13:22:51 -0400
From: John Leslie <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Subject: The Actual Difference
Sender: [email-masked]

John C Klensin <[email-masked]> wrote:
> 
> Suppose one has mail addressed to [email-masked].  Suppose 
> further that one has
>   foo.example.com.  IN A 10.0.0.1
>                     IN A 10.0.0.2
>                     IN AAAA ....
> and no MX record.
> 
> Now what 2821bis now says includes "address record" and the old 
> rule about making an implicit MX record with preference 0 and 
> then following the rules.  So we pretend that we had
>   foo.example.com.   MX 0 foo.example.com.
> to complement the above.

   Indeed: both 2821 ande 2821bis-09 require exactly that.

   The _difference_ is that 2821 _requires_ a DNS query for an
A RR, while 2821bis-09 _requires_ querying for
" 
" either an IPv4 A RR or an IPv6 AAAA RR, or their successors

   As I read this, it requires querying for _both_ A and AAAA
whether or not the host doing the querying knows about both
IPv4 and IPv6. (And it introduces that "or their successors"
language, which I find frankly impossible to implement.)

> Interestingly enough, in that case, even if the rule were 
> "implicit MX on A RRs only", exactly the same MX record would be 
> generated.  The only time the "address record" rule that is now 
> present in 2821bis is an issue is if there is no A RR.

   Exactly. (I have been hesitating to point this out, for fear of
interrupting a perfectly good flame war.)

> Once that implicit MX record exists, there are fairly clear 
> rules about which address to use for foo.example.com.

   Alas, they're not all that clear to me. :^(

> To be a little more precise, while the rules are clear, they
> pretty much leave it up to the sending host

   (That's what I mean by not so clear...)

   Please excuse me for snipping the rest of John K's wisdom on
this diversion. I'd be _very_ happy to discuss it under a different
Subject heading.

> If a receiving host wants to specify a priority for which of 
> IPv6 or IPv4 it prefers to receive traffic over, it must have 
> two names, one for its IPv4 interface(s) and one for its IPv6 
> one(s) and then put in an explicit set of MX records that bind 
> separate priorities to those two names.

   Or, it might have two MX RRs with the same priority...

> So again no issue with whether a host looks for an AAAA record
> if it cannot find an MX.

   In this particular case: yes, substituting the 2821bis language
has no effect on the outcome -- the only effect being requiring
more DNS traffic.

   There are, of course, other cases where the different language
_would_ lead to different results -- the most obvious being an
IPv6-only domain.

   This whole flame-war seems a lot like many other IPv6 flame-wars
I've observed: one side saying that differences between IPv4 and
IPv6 should be prohibited, with the other side saying differences
should be respected and used.

   Frankly, I have no use for the "differences prohibited" side
(so I don't usually reply). I'd much prefer to be talking about
_how_ to best respect the differences.

--
John Leslie <[email-masked]>

From: [email-masked]
Cc: [email-masked], Frank Ellermann <[email-masked]>, [email-masked]
Date: Tue, 01 Apr 2008 09:46:57 -0700 (PDT)
Subject: Re: nullmx
To: Hector Santos <[email-masked]>
Sender: [email-masked]

> [email-masked] wrote:

> > I'm afraid I don't have a choice. The requirements you appear to be advocating
> > are unjustified and unworkable in practice. If you're thinking about proposing
> > a language change saying that all systems engaged in SMTP client activities
> > MUST or even SHOULD also have an acessible server to accept problem reports,
> > that's simply not going to happen.
> >
> > 				Ned

> The point is well stated, but this doesn't jive with the requirement
> that MAIL FROM must be a valid acceptable address.

I don't see a conflict. We're talking about the host the SMTP client runs on,
whose "name" could be determined either from the EHLO/HELO argument, PTR lookup
of the IP address, synthesized as a daomin literal of the IP address, etc. This
is entirely separate from the MAIL FROM address, and nothing says that the MAIL
FROM address has to have anything to do with the host name of the SMTP client.
(Hopefully we've left all the "append your host as a source route onto the
return path stuff behind some time back.) Indeed, any SMTP client that
unconditionally stuffs its own host name in there is violating a different set
of requirements if the resulting address doesn't work.

> In others words, in an anonymous transaction (not authenticated, no info
> nor history on the domain), the receiver has no real substantiated clue
>   that the client has no INBOUND mail box for notifications or feedback.

Correct. But that feedback isn't supposed to be directed at the preceeding
host. It's supposed to go to the MAIL FROM address. Of course if the MAIL FROM
is broken or forged or whatever that presents a problem, but this is
independent of whether or not there's an SMTP server on the preceeding host you
can send postmaster mail to.

I think one of the things Frank is after is a way to report problems either
when it is clear it's an issue with the host the SMTP client is running on or
when the MAIL FROM doesn't work. The problem is that the SMTP architecture
doesn't provide a means for a client to say "report any issues you have with me
to this address". Of course it would be possible to add such a capability, but
even if it made sense to do so (I for one am not convinced) this is not the
time or place for it.

> It really has nothing to do with the scale of the system.  Small or
> large, they are all viewed the same to the outside world.

As well they should be. Quite a lot of effort usually goes into making this
view possible, in many cases including a lot of hackery at the network and DNS
levels.

> In my view, it would be really stupid for legitimate systems NOT to have
> a valid return path mail box handy and ready to accept feedback
> regardless if its read, not read and/or ignored, included always
> accepted, relayed or dropped.   The address was accepted is the key
> point because it s standard requirement the return path be valid.

Again, we're not talking about the MAIL FROM here.

> In lieu of this standard return path expectation, this type of behavior
> can and is used for automated black listing, e.g., failed bounces are
> automatically black listed.

I really don't want to get into the relative merits of MAIL FROM validation
right now - I'm pretty sure there are a bunch of differing but strongly held
opinions in this area.

				Ned

Date: Tue, 01 Apr 2008 12:35:04 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: nullmx
Sender: [email-masked]

[email-masked] wrote:

> I'm afraid I don't have a choice. The requirements you appear to be advocating
> are unjustified and unworkable in practice. If you're thinking about proposing
> a language change saying that all systems engaged in SMTP client activities
> MUST or even SHOULD also have an acessible server to accept problem reports,
> that's simply not going to happen.
> 
> 				Ned

The point is well stated, but this doesn't jive with the requirement 
that MAIL FROM must be a valid acceptable address.

In others words, in an anonymous transaction (not authenticated, no info 
nor history on the domain), the receiver has no real substantiated clue 
  that the client has no INBOUND mail box for notifications or feedback.

It really has nothing to do with the scale of the system.  Small or 
large, they are all viewed the same to the outside world.

In my view, it would be really stupid for legitimate systems NOT to have 
a valid return path mail box handy and ready to accept feedback 
regardless if its read, not read and/or ignored, included always 
accepted, relayed or dropped.   The address was accepted is the key 
point because it s standard requirement the return path be valid.

In lieu of this standard return path expectation, this type of behavior 
can and is used for automated black listing, e.g., failed bounces are 
automatically black listed.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Tue, 01 Apr 2008 12:21:29 -0400
From: Keith Moore <[email-masked]>
To: Sabahattin Gucukoglu <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, John R Levine <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

Sabahattin Gucukoglu wrote:
> Hi Arnt,
> 
> On 31 Mar 2008 at 11:32, Arnt Gulbrandsen <[email-masked]> said:
>> Adding IPv6 support to internet mail forces a question: If there isn't an
>> MX RR for a given domain, does the SMTP client fall back to looking up an A
>> RR, A or AAAA, or A and AAAA? We have to choose, and all of them represent
>> a change.
> 
> Why?  As John has pointed out, all 2821bis is saying you have to do as an 
> Internet mailer is to imagine that there's an MX record of preference 0 
> with the target of the recipient domain for that same recipient domain 
> when there isn't one already.  That's how it's always been, and all this 
> bother about whether or not it's appropriate to deny mail to recipients 
> without an MX record in the IPv6 case is apparently appealing only to 
> people who want it that way for purely anti-abuse motives 

false.  this isn't just about deterring abuse.

- the vast majority of hosts on the Internet today don't want to receive 
mail.  this will be even more true in an IPv6 world where every toaster, 
light switch, etc. can have an IP address.

at the time RFC 974 was published fallback to A records was needed for 
backward compatibility with existing practice.  we don't have that 
problem now with AAAA records today, because today, nobody can expect to 
reliably receive mail via IPv6 without setting up a MX that will accept 
incoming mail from IPv4 and relay it over IPv6.

- some of those hosts that don't want to receive mail actually have SMTP 
servers because they are configured that way by default by the OS 
vendor.  any mail sent to those servers just takes up disk space - 
nobody ever reads it.

- mail queues get clogged up trying to send mail to hosts that don't 
support SMTP.  because "connection refused" is a temporary error to 
SMTP, any mail sent to a host that doesn't support SMTP will sit in a 
queue for days before bouncing or being discarded.

(note that mail is fairly unique among applications in this respect. 
most applications don't persistently retry when they see "connection 
refused")

--

because most hosts don't want to receive mail, the "right thing" to do 
is to have the default behavior - i.e. the behavior when no MX record is 
present - be to not deliver mail to that host.  we still need to 
fallback to A records for backward compatibility with hosts that rely on 
that.  but we don't need to fallback to AAAA records.

Keith

From: "Sabahattin Gucukoglu" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 01 Apr 2008 16:36:49 +0100
Subject: Re: Minor is. It's not a pardigm change
CC: John R Levine <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>, [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Hi Arnt,

On 31 Mar 2008 at 11:32, Arnt Gulbrandsen <[email-masked]> said:
> Adding IPv6 support to internet mail forces a question: If there isn't an
> MX RR for a given domain, does the SMTP client fall back to looking up an A
> RR, A or AAAA, or A and AAAA? We have to choose, and all of them represent
> a change.

Why?  As John has pointed out, all 2821bis is saying you have to do as an 
Internet mailer is to imagine that there's an MX record of preference 0 
with the target of the recipient domain for that same recipient domain 
when there isn't one already.  That's how it's always been, and all this 
bother about whether or not it's appropriate to deny mail to recipients 
without an MX record in the IPv6 case is apparently appealing only to 
people who want it that way for purely anti-abuse motives (not, FWIW, that 
I'm saying they're inherently a bad idea - but they have no place on a 
draft-standard-to-be, for which they are entirely unmoving reasons for 
breaking this longstanding rule).  OTOH, the wording of the spec lends 
itself to this sort of non-semantic thinking, so perhaps a slight touch to 
emphasise the synthesis of the MX record more clearly rather than as a 
fallback to address records (but to be fair to John, he's made it as 
generic as he possibly can) might help.

In reality, for me at least, it's obvious what has to happen: you 
synthesise the MX record, then act on it according to your supported 
address families as you would with any other non-synthesised record - 
connect to whatever you can.  If you're feeling desperate, send the mail 
to someone else to relay it into the other network for you (this wasn't 
mentioned in the spec either, I find).

I can accept that, from an implementation point of view, there may well be 
subtle differences between uses of the synthesised MX record and the real 
thing.  For instance, you can't rely on Additional Section replies in DNS 
to include all relevant information when an MX query is made.  You have to 
make the queries for supported address types yourself.  I'm not sure you 
can rely on the Additional section anyway (DNS gurus, please advise).  
Also, there's the matter of how one actually processes the MX target; for 
standard resolver routines in system libraries that support IPv6, though, 
you'll end up with results to suit your stack(s), and most MTAs are doing 
that anyway.  For instance, gethostbyname(3) or getaddrinfo(3), which, 
with a little bit of coaxing, generally do the right thing or at least do 
it well enough.  This is clean, consistent with other protocols and 
sensible and, unless preference is given to a particular address family, I 
think giving multiple families of address for a single dual-stacked 
machine in the DNS for a single hostname is preferable to using individual 
MX records.  You can then depend on the right thing happening even when MX 
is absent, no matter with IPv4, IPv6 or both.

Someone please tell me I missed something so I can put the coffee machine 
back on and get back into my terrible habbit. :-)

Cheers,
Sabahattin

- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: [email-masked]
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/

From: [email-masked]
Cc: [email-masked]
Date: Mon, 31 Mar 2008 19:53:46 -0700 (PDT)
Subject: Re: nullmx
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> <[email-masked]> wrote:
 
> >> Mail to <postmaster> at this host is still supposed to work.
 
> > Say what? That's only the case if the host runs an SMTP server,
> > in which case it is entirely logical to require support of a
> > postmaster address. It is entirely possible for a host to have
> > an SMTP client and no server.

> For pure clients I'd look into RFC 4409, 4954, and 5068.

4409: Submission. Irrelevant in the context of the relay operations we're
      discussing.
4954: SMTP AUTH. Although defined for relay as well as submit, irrelevant in
      practice.
5068: Submission requirements. Also irrelevant.

> When the server in question is sure that it's not talking with one
> of its own users and acting as MSA, where clients might have
> funny names like "oemcomputer" or "xyzzy.invalid", an MX could
> assume that an unknown stranger talking to it is an SMTP relay.

We're not talking about MSAs or submission operations here.

> And for SMTP relays 2821bis 4.5.1 says "postmaster MUST work".

Actually, it says nothing of the sort. The text is very clear: It says that
SMTP *receivers* must have a postmaster address. It says *nothing* about SMTP
clients always having to operate a receiver or having to have postmaster
address. Furthermore, it says that the bare local name "postmaster" is what has
to work. It says *nothing* about postmaster@random-host-system-name having to
work.

I think your problem here is you're conflating hosts with administrative
domainss. For small setups all transport and storage services often run on a
single host so they may be effectively the same thing. But this isn't how
things work in larger setups. Architectures change once you start talking about
handling millions of users, transfer rates in the thousands of messages a
second, hundreds of thousands of simultaneous connections, and multiple network
connections with different performance and traffic shaping policies.

It is very common in large multihost deployments to have specific hosts
dedicated to specific tasks: Incoming relay from the Internet, outbound relay
to the Internet, submission from local users, spam filtering, virus detection,
message storage, download points, and so on. (One of the main reasons for this
is that the hardware requirements for an MTA tend to be quite different from
those for a store. MTAs are well-suited to rack-and-stack so a bunch of blades
are often used whereas stores are I/O-heavy and usually end up on a smaller set
of much bigger boxes with lots of disks.)

And in many cases messages travel internally using heavily extended or even
entirely nonstandard protocols and mechanisms. As a result it is entirely
possible for a given host in such a setup to engage in relay operations but
only support a client, a server, neither, or both. And even if, say, an
outbound relay host also operates an SMTP server, in many setups it will not
accept incoming connections from the Internet - it's instead reserved for
messages coming from "inside".

And all this still ignores issues like network performance, multihoming,
failover and clustering, and having multiple zones on a single physical box. We
have an entire deployment engineering team that does nothing but design such
setups. These folks are intimately familiar with the performance of the various
hardware boxes, filesystems, disks, interconnects, and heaven knows what else.
(I myself am woefully ignorant of almost all of these details, but I've seen
first hand the difference between a well-designed and poorly-designed large
scale setup.)

> 2821bis 4.1.1.3 does not help to decide if the other side is a
> client or relay.  In the <tm> real SMTP </tm> that might have
> been obvious in the reverse-path, more than one hop is a relay.

> > postmaster is only required for servers that perform delivery
> > or relay functions. I presume that's so a stub server that
> > always returns 5xy errors isn't required to accept postmaster
> > mail.

> That point is explicitly mentioned in 4.5.1, yes.  It is kind
> of obvious that MTAs always saying 554 instead of 220 cannot
> accept mail to <postmaster>, nevertheless 2821bis mentions it.

But once again it is quite clearly talking about a server's implementation
of the RCPT TO command.

> But for an MX tormented by a client out of control a mail to
> <postmaster> asking to fix whatever is broken can make sense,
> if just blocking this client doesn't help or is undesirable.

OK... Assuming there's something who actually reads postmaster mail
(increasingly unlikely, more's the pity), sending something directly to the
postmaster address to the server that is coresident with the misbehaving cliwnt
might be worth a try in such a situation. But there's no standards violation to
complain about if  it doesn't work. And in most cases a better idea would be to
send to  the postmaster address associated with the domain listed in the MAIL
FROM address.

> >> I couldn't tell without cheating (= looking into 2821bis)
> >> if that's MUSTard, SHOULD, or between the lines.

> Well, now you forced me to check it.

> > If you believe otherwise you'll need to cite the relevant
> > sections of 2821bis to support your point. I couldn't find
> > anything along the lines of what you appear to be claiming
> > in there.

> From the POV of an MX talking to a client that definitely is
> not "one of ours", i.e. an unknown stranger, and that does
> not use RFC 821 reverse-paths, assuming that "direct-to-MX"
> is bad, it can be only a relay, and for relays it's a MUST.

No it isn't. See above.

> Please don't tell me that this assumption is unjustified,

I'm afraid I don't have a choice. The requirements you appear to be advocating
are unjustified and unworkable in practice. If you're thinking about proposing
a language change saying that all systems engaged in SMTP client activities
MUST or even SHOULD also have an acessible server to accept problem reports,
that's simply not going to happen.

				Ned

Date: Tue, 1 Apr 2008 11:03:06 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

John C Klensin writes:
> One observation, having worked through this several times before 
> realizing that the answer is obvious and feeling a need to be sure 
> that we are in agreement about what we are discussing...

We agree about almost everything. Our only disagreement is about whether 
AAAA records should influence the decision whether to synthesise an MX 
record.

Consider a case where 2821 and 2821bis gives a different result: An 
IPv6-only network printer. Most of my printers can send mail, none 
listen on port 25, and when the IPv4 network becomes tight, the 
printers will be among the first devices to lose their A RRs, so this 
is a good example.

Code implementing the rules in 2821 will correctly decide that mail to 
the network printer's host name isn't deliverable, code implementing 
the rules in 2821bis-06 will infer an MX.

2821: An MTA being told to send mail to the printer rejects at once.
2821bis-06: The MTA tries for a few days, then gives up.

2821: A web form rejects [email-masked] as bad
2821bis-06: A web form accepts [email-masked] as a valid 
email address.

Similar for the other uses and devices I thought of: 2821 code makes the 
practically correct decision, 2821bis-06 the wrong one.

(I deleted the rest of what I quoted, because my responses were just yes 
yes yes.)

Arnt

Date: Tue, 1 Apr 2008 11:02:57 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: not delivering, and History of fallback to A
Sender: [email-masked]

(I dropped all the CCs - the list grew long.)

Dave Crocker writes:
> [email-masked] wrote:
>> Not exactly. The issue isn't what to do in general, it's what to do 
>> in this document. I have no problem with someone starting an MX . 
>> effort or a require
>>  MX effort and seeing if they can get consensus on it. (If the former 
>>  gets started I plan to support it, the latter I'll oppose.) It just 
>>  doesn't belong
>>  in 2821bis.
>
> +1

I would +1 if I thought 2821bis could ignore this, but unfortunately I 
think that 2821 has to choose: Consciously extend the A rule to cover 
AAAA, or consciously not extend it.

> As with Ned, I suspect we are going to be long-retired, and possibly 
> long-dead, before v4 use reduces sufficiently to be ignored.

I suspect none of us will be retired by the time IPv6-only hosts/devices 
appear.

Arnt