Subject: Re: Minor is. It's not a pardigm change
From: "Robert A. Rosenberg" <[email-masked]>
To: [email-masked]
Date: Tue, 1 Apr 2008 00:38:31 -0400
List-Id: <ietf-smtp.imc.org>

At 16:11 +0200 on 03/31/2008, Frank Ellermann wrote about Re: Minor 
is.  It's not a pardigm change:

>No matter what 2821bis will say, when IPv6 enters the picture
>they need to talk.  The mail guy in an IPvX network will want
>mail from non-IPvX networks.
>
>  Frank

So if you are a IPv6 SMTP MTA document this fact with a MX. If you 
are IPv6 but NOT an SMTP MTA document this fact either with an "MX ." 
or better with the absence of an MX for that FQDN.

IOW: If a FQDN has no MX, there should NOT be an attempt to find a 
MTA Server for that FQDN by doing an AAAA fallback (but doing a 
fall-back to an A is acceptable for historic reasons). Failure to 
find an MX or an A for a FQDN should act as it does at present (IOW: 
In the absence of an MX do NOT assume that an AAAA might represent a 
MTA). Saying NO AAAA Fall-Back is the only way to avoid the problems 
that A Fall-Back causes since there is no VALID need for AAAA 
fall-back in the absence of an MX unlike the situation prior to the 
creation of the MX record type that necessitated doing A Fall-Back 
(since prior to the MX, the A WAS the way to find a MTA).

Date: Mon, 31 Mar 2008 21:11:30 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Rudy Nedved <[email-masked]>
CC: [email-masked], John R Levine <[email-masked]>, [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

Rudy Nedved wrote:
> I understand. The assumption is that implementations that work in RFC 
> 733/821 world were upgraded to match RFC 2821.

You get credit for even knowing about 733, but please forgive my losing a small 
OCD battle:

    733 was for the Arpanet.  Transport was by FTP commands.

    822 was paired with 821 for the Internet.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: not delivering, and History of fallback to A
Date:  Tue, 1 Apr 2008 05:41:51 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 14
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> However, I am sympathetic to the argument that we can't keep revising=20
> 2821bis forever, and that we need to push it out the door even if we=20
> immediately start working on one or more fixes to 2821bis.  Maybe we=20
> should just accept that the "core" email specifications will never be=20
> entirely current, even at the time they are published.
=20
> I'd certainly support publication of a short RFC that deprecated AAAA=20
> fallback.

<sigh />  So that's it then, 2821bis-09 as is modulo some pending nits.

 Frank

Date: Mon, 31 Mar 2008 23:02:08 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: dual-stack IP transition is not specific to SMTP
Sender: [email-masked]

> Basically, the current task is one of supporting a dual-stack networking 
> environment.  That's a challenge for all Internet use, not just email. 
> Solutions for it need to be universal, not specific to email.

Doesn't follow.  Different applications use the network in different 
ways, and IPv6 doesn't impact all applications in the same way.  IPv6 is 
not a drop-in replacement for IPv4, and there is no one-size-fits-all 
solution to adapt applications to IPv6.

> The SMTP specification should be modified in the smallest and most 
> localized fashion possible and particularly should not make any changes 
> to its registration model.

Again, it doesn't follow.  Yes, small and localized changes are 
generally to be preferred over elaborate changes that don't add any 
functionality.  But eliminating AAAA fallback is a small and localized 
change - and it has the added benefit of making mail simpler and more 
robust.

Keith

Date: Mon, 31 Mar 2008 23:00:58 -0400
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Sender: [email-masked]

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

--On Monday, March 31, 2008 11:32 AM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> A rather simple and straightforward task that the current
>> draft  satisfies reasonably, modulo the usual
>> wordsmith-hacking.
>
> I read the -06 draft as permitting the last two alternatives
> ("A or AAAA", "A and AAAA"). 2821 itself says A.

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.

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.

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.

So, from the standpoint of the synthesized MX record (or an 
explicit MX record set up the same way), there is no difference 
between the "A and AAAA" and "A or AAAA" cases described above 
-- those are differences that have to do with selection of a 
target address once the MX record exists or is inferred.

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.  So again no issue with 
whether a host looks for an AAAA record if it cannot find an MX.

     john

Date: Mon, 31 Mar 2008 22:57:22 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
CC: Eric Allman <[email-masked]>, John R Levine <[email-masked]>, [email-masked]
Subject: Re: not delivering, and History of fallback to A
Sender: [email-masked]

[email-masked] wrote:

>> So let me postulate a world in which IPv4 is
>> gone, A records are gone, and IPv6 reins over the planet, and we have
>> switched to requiring MX for any inbound mail hosts.
> 
> That's somewhat uninteresting to me because I don't think it will happen 
> in any sort of time frame frame we're concerned with. What we might get to is a
> situation where it is feasible to run a server with only IPv6 and not 
> IPv4. But even that isn't going to happen any time soon.

I remember that during the MIME discussions many of us thought that 
BITNET and affiliated NJE-based academic networks would be with us for a 
very long time.  And indeed, BITNET kept growing for awhile, if slowly. 
  Then when it died, it happened almost overnight.  Similar observations 
could be made for uucp, and gopher.

Mail will be one of the last two global applications for which IPv4 is a 
practical necessity (http being the other).  Once mail and http no 
longer need IPv4, neither will anything else that runs globally. When 
enterprise networks no longer need IPv4 and the hair-pulling that comes 
with it, they'll pull the plugs quite rapidly.  ISPs will follow soon 
afterward.

> Again, this is about 2821bis, not about getting anyone's, let alone everyone's,
> favorite spam fighting mechanism onto the standards track. And I have yet to
> hear a convincing explanation for how AAAA fallback changes the situation for
> bad guys in any appreciable way.

I agree on that point, though I think the AAAA fallback fix is justified 
on other grounds.  And to me this kind of fix seems very much in line 
with why we started the DRUMS effort in the first place, and why we made 
other changes between 821/822 and 2821/2822.

However, I am sympathetic to the argument that we can't keep revising 
2821bis forever, and that we need to push it out the door even if we 
immediately start working on one or more fixes to 2821bis.  Maybe we 
should just accept that the "core" email specifications will never be 
entirely current, even at the time they are published.

I'd certainly support publication of a short RFC that deprecated AAAA 
fallback.

Keith

Date: Mon, 31 Mar 2008 19:46:05 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: Eric Allman <[email-masked]>, John R Levine <[email-masked]>, [email-masked]
Subject: Re: not delivering, and History of fallback to A
Sender: [email-masked]

[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

>> Some feel that the transition to IPv6 is a once-in-a-lifetime opportunity
>> to make some of these fundamental changes.
> 
> And some of us feel that coupling such changes is ill advised.

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

Please, oh please, let's not re-use that justification for scope-creep.

>> So let me postulate a world in which IPv4 is gone, A records are gone, and
>> IPv6 reins over the planet, and we have switched to requiring MX for any
>> inbound mail hosts.
> 
> That's somewhat uninteresting to me because I don't think it will happen in
> any sort of time frame frame we're concerned with. 

It can be useful to envision the end-point to a transition.  It can also be 
distracting.

As with Ned, I suspect we are going to be long-retired, and possibly long-dead, 
before v4 use reduces sufficiently to be ignored.

>> Ned seems to be thinking about the bad guys, saying "So what? Spammers are
>> going to try to send to hosts whether or not they have MX records, so
>> what's the point?"
> 
> Well, I'm thinking about the bad guys only to the extent that I don't want to
>  give them any more opportunities to cause harm than they already have. 

I can see how your "spammers are gonna do whatever they want", text might be 
taken as a "so what", but only if one ignores the paragraph you wrote after 
that, where you said:

      "The goal here is to try and come up with an operational policy which, when
implemented by legitimate operators, will result in the greatest amount of
interoperability in the medium to long term. And yes, a secondary goal should
be not to create situations that spammers can exploit."

That kind of language is difficult to interpret as "so what".

It's more like "let's be judicious" and "let's not let spamming fears whip our 
requirements around trying to satisfy secondary goals."

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: nullmx
Date:  Tue, 1 Apr 2008 04:19:19 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 60
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<[email-masked]> wrote:
=20
>> Mail to <postmaster> at this host is still supposed to work.
=20
> 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.  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.

And for SMTP relays 2821bis 4.5.1 says "postmaster MUST work".

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.=20

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

>> I couldn't tell without cheating (=3D 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.

Please don't tell me that this assumption is unjustified, I
know that some MXs still tolerate it when I try direct-to-MX
for reasons like "my provider won't let me report spam to SC"
or to check what RFC-I listable problems a domain might have,
after it somehow attracted my attention in a negative way.

If there is no way to decide what is a relay all MUSTard in
2821bis talking about relays would be a waste of time, so
how do you do this ? =20

 Frank

From: [email-masked]
Cc: [email-masked], John R Levine <[email-masked]>, [email-masked]
Date: Mon, 31 Mar 2008 16:23:44 -0700 (PDT)
Subject: Re: not delivering, and History of fallback to A
To: Eric Allman <[email-masked]>
Sender: [email-masked]

> I've been reading this exchange with an emotion that varies between
> amusement and bemusement, and I've come to the conclusion that Ned
> and John must be talking about different things.

> There are two ways of looking at this problem.  I'm pretty sure that
> both are saying that this only applies to AAAA records, since
> regardless of the merits it's just too hard to require MX for IPv4
> hosts given where we are today.

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.

> Some feel that the transition to
> IPv6 is a once-in-a-lifetime opportunity to make some of these
> fundamental changes.

And some of us feel that coupling such changes is ill advised.

> So let me postulate a world in which IPv4 is
> gone, A records are gone, and IPv6 reins over the planet, and we have
> switched to requiring MX for any inbound mail hosts.

That's somewhat uninteresting to me because I don't think it will happen in any
sort of time frame frame we're concerned with. What we might get to is a
situation where it is feasible to run a server with only IPv6 and not IPv4. But
even that isn't going to happen any time soon.

> Ned seems to be thinking about the bad guys, saying "So what?
> Spammers are going to try to send to hosts whether or not they have
> MX records, so what's the point?"

Well, I'm thinking about the bad guys only to the extent that I don't want to
give them any more opportunities to cause harm than they already have. Again,
this is about 2821bis, not about getting anyone's, let alone everyone's,
favorite spam fighting mechanism onto the standards track. And I have yet to
hear a convincing explanation for how AAAA fallback changes the situation for
bad guys in any appreciable way.

Of course spammers are highly unpredictable, often to the point of acting
against their own best interests, so it is impossible to say with assurance
that given we do this it cannot possibly lead to that. The best we can do is
guess, and my assessment is that it is best not to make an architectural shift
as part of adding IPv6 support.

> Clearly hosts that are not pointed
> to by any MX record will either have a rogue SMTP server (which more
> or less by definition will only receive spam) or it won't respond on
> port 25 (and so the client side will time out), but in either case it
> makes no difference to the legitimate mail flow which will never even
> try to connect to such hosts (remember, we're in a world that doesn't
> fall back to AAAA). I don't think John is in any sense saying that
> spammers will suddenly go to finishing school and stop their boorish
> behavior, and hence only disagrees with the "what's the point?" part.

Yes, I think so.

> John seems to be thinking about the good guys, saying "But consider
> the good guys who are being unwillingly drawn into this battle."  In
> particular, blowback is a horrid problem, which, if the purported
> sending return-path address actually gets to a live SMTP server, is a
> scourge upon the people, whether or not the local-part is legitimate.
> In this world, legitimate SMTP clients will note that they are trying
> to send a message to a mailer that does not accept mail and
> presumably drop that message on the floor rather than contribute to
> the problem.

> I confess that I agree with both of them on some level.  Such a move
> will decrease blowback from legitimate mailers.  But it isn't at all
> clear to me that such a move will be a significant improvement since
> the spammers can just choose return-paths with domains that accept
> mail.

It's interesting that you characterize this as being a possible future action.
>From where I sit it is already reality: Spammers are overwhelming already using
legitimate MAIL FROM addresses. (I suspect this is due to some very large ISPs
performing reverse address validity checks. And please, let's not get
sidetracked onto how such checks are a bad idea. I'm condoning nothing, merely
staring what I know for a fact has been done on a large scale.) Even worse,
I've seen some rather chilling indications that they are now attempting to pair
up the "right" MAIL FROM with each RCPT TO.

> It is clear to me that if identifying hosts that are
> legitimate mail receivers is a good thing, then the right thing to do
> is label the legitimate receivers rather than the non-receivers, as
> the latter outnumber the former by a huge (and growing) ratio.

Well, as it happens I have a printer that accepts jobs via SMTP... (It's
actually pretty funny - many of the responses are misspelled, it always
identifies itself as example.com, and so on.) Actually something of a pain
since I have to make sure to block traffic to it lest it start spewing
printouts of spam.

> Aesthetically I like the idea of such labeling, but I'm having
> trouble coming up with a good technical argument for it, based in
> part on Ned's discussion.  I just can't find justification for John's
> claim that "[i]t's going to change the way that MTAs are set up which
> will make it harder for spammers to abuse."

I like the idea of labelling services too - in theory. In practice we have a
huge installed base that's under continuous attack and a network that needs to
transition to a new infrastructure and which, as far as I can tell, is moving
very slowly if at all.

> Just for the record, sendmail has /never/ "report[ed] back every two
> hours to say that your message hasn't bounced yet".  It will report
> back exactly once per message saying that your message has been
> delayed (but indeed hasn't bounced), but will never do that more than
> once per message.  And sendmail respects DSN NOTIFY requests, so it's
> trivial for the message sender to turn it off entirely.

Our MTA is configurable in this regard and while the defaults are sensible a
surprising number of sites insist on getting multiple notices on a fairly short
time scale. And we also support DSN, but sadly not that many messages use it to
suppress unnecessary notifications.

				Ned

From: [email-masked]
Cc: [email-masked]
Date: Mon, 31 Mar 2008 15:09:13 -0700 (PDT)
Subject: Re: nullmx
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> Mark Andrews wrote:

> > It doesn't however mean you cannot send mail from that
> > machine however. You just have to set an appropriate mail
> > domain for outgoing mail.

> > Rather than [email-masked] the mail would come
> > from [email-masked] or something similar if you
> > were using "MX 0 .".

> JFTR, that is a nullmx for toaster.example.net, and the host
> toaster.example.net can send MAIL FROM [email-masked]
> (or from almost any address excluding @toaster.example.net).

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

In fact the language is even more restrictive - 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. 

> I couldn't tell without cheating (= looking into 2821bis) if
> that's MUSTard, SHOULD, or between the lines.

It isn't even between the lines as far as I can tell. 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.

				Ned

Date: Mon, 31 Mar 2008 23:32:50 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: Minor is.  It's not a pardigm change
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 31, 2008 at 11:56:51AM -0400, Hector Santos wrote:

> But I think overall, there are two discussions going on here.
> 
>   1) A vs AAAA fall backs, and

1a: "A" fallback for IPv4 and none for IPv6
1b: "A" fallback for IPv4 and "AAAA" fallback for IPv6
1c: "A" fallback for all
1d: "A" and "AAAA" fallback for all
1e: "A" or "AAAA" fallback for all

I think 1e would be insane. Choice is not good.
1c wouldn't work for IPv6-only hosts
1d wouldn't work for IPv4-only hosts, plus you do not want to
change existing installations.

Which leaves 1a and 1b.  And I do think that most of us argue
for either 1a or 1b.  I am not in favour of it, but I can see
why people would want 1b.

Getting rid of the fallback has nothing to do with:

>   2) Mandating MX for Email Security Policies

I think this one can stop; it is clear to most that this is not
the right time and place.

But there are other reasons why fallback should go.  IPv6 is
designed so that everybody can have all the addresses they want,
each one can have a name.

Back then, when computers were huge and expensive, it made sense
that every host would have a hostname which would also work as an
email domain name.

Now and in the near future, this is quite different. I do not want
my microwave oven, my thermometers, my light switches, my vacuum
cleaning robot, the fridge, and whatever other appliance with an
address, to be seen as mail domains.

You really do not want to publish something like "MX 0 ." for
each and every one of them, except for the one or two hosts that
do receive mail.

If the sending side does not find an MX record, should it really
continue to query for an AAAA record and/or an A record?

Yes, for IPv4, because this is the standard. Back then it was a
good thing to do, but nowadays it is no longer necessary (only
conveniant for some). Nevertheless: don't change it.

No, for IPv6, because right now is the correct time and place to
get rid of it.

I do appreciate that RFC 974 mentions hostname, not A record, and
thus implicitly also mentions AAAA records. But that RFC also
discusses WKS queries. Things change.

I think it would be a huge mistake to have "AAAA" fallback just
because it is similar to "A" fallback.

Date: Mon, 31 Mar 2008 16:40:32 -0400 (EDT)
From: John R Levine <[email-masked]>
To: Rudy Nedved <[email-masked]>
cc: [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Cleverness: None detected
Sender: [email-masked]

> It isn't clear how many implementations do more then translating a hostname 
> into an address record and using it. It is not clear that intranet or 
> behind-firewall clients use MX records.

Then they're not following the RFCs, which is perfectly fine so long as 
you don't expect them to interoperate directly with the outside world.

That won't change.  So could you clarify what you've been objecting to?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: nullmx
Date:  Mon, 31 Mar 2008 22:40:32 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 40
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Mark Andrews wrote:

> It doesn't however mean you cannot send mail from that
> machine however. You just have to set an appropriate mail
> domain for outgoing mail.

> Rather than [email-masked] the mail would come
> from [email-masked] or something similar if you
> were using "MX 0 .".

JFTR, that is a nullmx for toaster.example.net, and the host
toaster.example.net can send MAIL FROM [email-masked]
(or from almost any address excluding @toaster.example.net).

Mail to <postmaster> at this host is still supposed to work.
I couldn't tell without cheating (=3D looking into 2821bis) if
that's MUSTard, SHOULD, or between the lines.

> Non deliver reports don't have to go back to the originating
> machine.

I can sing "originator as indicated in the reverse-path", in
moments when JohnK would seriously wish that I don't try to=20
sing, at least not on this list.

BTW, your example also shows another reason why "v=3Dspf1 -all"
is not the same as nullmx.  The toaster.example.net MTA using
this FQDN in its EHLO needs "v=3Dspf1 a -all" (added "a") or=20
another way to indicate that it's permitted to use this name.

When it sends an NDR or any mail with an empty reverse-path
receivers checking SPF look for a policy associated with the
EHLO name, and that is generally recommended in RFC 4408 for
the purpose of rejecting abuse of EHLO names, not limited to
empty reverse-paths.

Clearly nobody is forced to protect EHLO names with SPF FAIL,
but if they do they better get this right.

 Frank

Date: Mon, 31 Mar 2008 12:58:51 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: dual-stack IP transition is not specific to SMTP
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 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.
...
> Look up either A or AAAA: A-only hosts would look up A, AAAA-only hosts 
> would look up AAAA, dual-protocol hosts would look up both, and an 
> address would be deliverable or not depending on who's sending.

Basically, the current task is one of supporting a dual-stack networking 
environment.  That's a challenge for all Internet use, not just email. 
Solutions for it need to be universal, not specific to email.

The SMTP specification should be modified in the smallest and most localized 
fashion possible and particularly should not make any changes to its 
registration model.

>> A rather simple and straightforward task that the current draft 
>> satisfies reasonably, modulo the usual wordsmith-hacking.
 >
> I read the -06 draft as permitting the last two alternatives ("A or 
> AAAA", "A and AAAA"). 2821 itself says A.

+1.

>> It appears that there has been a spontaneous desire for some spiffy 
>> new goals to be overloaded onto that one, long-standing *requirement*.
>>
>> This amounts to retro-active re-design on-the-fly.
> 
> We can't escape redesigning this. IPv6 forces us to.

v6 forces adding v6 address records.  It does not force changing the 
registration model.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: 31 Mar 2008 19:45:43 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: Minor is.  It's not a pardigm change
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>I agree that addresses with address literals are rare, but that doesn't 
>mean many hosts aren't ready to accept them ...

For the benefit of people who haven't read the draft, address literals
are still there, and now include IPv6 addresses.

The argument in progress is about whether to synthesize an MX record
from an AAAA record.

R's,
John

Date: Sun, 30 Mar 2008 18:24:57 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: History of fallback to A
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Mar 30, 2008 at 07:42:39AM -0700, [email-masked] wrote:

> > 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.
> 
> Yes, that's more or less the case.

Then: people didn't know MX records and thus didn't use them. Or maybe
they did already know about MX records but did not yet support them.
Some fallback mechanism was necessary to bridge the gap between pre-MX
and post-MX time, or else MX didn't stand a chance.

Now: people do know MX records and do use them, except for a couple
of spammers maybe. There is no need anymore to design a fallback.

> This also ignores the issue of what is the right thing to do in the
> transitional case where there's no MX record but a mixture of A and AAAA
> records. Only falling back to the A record subset seems, well, wrong.

Why?

You present a gut feeling, with no more and no less value than the
opposite gut feeling.

One could also argue that if such a mix is present, this indicates
mail delivery is not possible for that name.

Here's why: the fallback mechanism was designed for receivers not
yet aware of MX records. If receivers know about AAAA records, they
most certainly will also be aware of MX records.

> So I believe the correct course going forward is to have the same fallback
> rules for AAAA that we do for A. Having said all this, it certainly isn't a
> showstopper for me if this goes the other way, if for no other reason than the
> fact that we'll have plenty of time to fix this if whatever decision we make
> turns out to be wrong. The only outcome that is a showstopper for me is for
> this issue to remain unresolved.

I believe adding those fallback rules is wrong.  Apart from the two
arguments I presented above, I have more:

Adding a fallback mechanism for 2^32 minus a bit possible addresses,
in a time when the number of actually used addresses was very low, is
one thing.

Adding the same fallback now, for many more possible addresses, has
the potential of ruining the net.

Last but not least: not having a fallback for AAAA is not a change.
Having a fallback for AAAA is a change.

To: "Frank Ellermann" <[email-masked]>
Cc: [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: nullmx (was: Last Call: draft-klensin-rfc2821bis) 
Date: Tue, 01 Apr 2008 06:11:37 +1100
Sender: [email-masked]

> 
> Mark Andrews wrote:
> 
> >> First, it may have been obvious to you, but it wasn't obvious to=20
> >> many of us.   In the general case, it still isn't.  But you=20
> >> stated the situation exactly correctly.   "MX 0 ." means "I=20
> >> don't want email".   "SRV 0 0 ." doesn't really indicate "no=20
> >> service", it indicates "please do look for that service here".
> =20
> > "SRV 0 0 <hostname>" means look for that service here.
> > "." is not a valid hostname.
> 
> Possibly you miss a subtle point in the nullmx design, it does not
> only mean "I don't want email".  It also means "any mail claiming
> to be MAIL FROM me cannot be okay, because there is no route to
> report non-delivery" [etc. down to RFC 3834 auto-replies, but the
> REQUIRED capability is to report non-delivery].

	I'm well aware of that.

	It doesn't however mean you cannot send mail from that
	machine however. You just have to set an appropriate mail
	domain for outgoing mail.

	Rather than [email-masked] the mail would come
	from [email-masked] or something similar if you
	were using "MX 0 .".

	Non deliver reports don't have to go back to the originating
	machine.  There are 100's of millions of clients today that
	operate in exactly this manner.

	Mark
 
> On the DKIM list folks discussed to emulate "I send no mail" with
> a public statement "all my mails are signed", and then simply not
> sending signed mails.  That's possible, but rather indirect, and
> won't help receivers not interested in DKIM signing practises.
> 
> Even more subtle, DKIM is not about the 2821 MAIL FROM, so this
> approach is beside the point wrt SMTP.  Likewise a SenderID PRA
> "spf2.0/pra -all" policy won't help wrt SMTP.
> 
> The SPF solution "v=3Dspf1 -all" is acceptable, but this won't help
> receivers not interested in checking SPF.  It also might not work
> for receivers deciding to accept SPF FAIL, using it only as an
> ingredient in scoring.=20
> 
> Another now AFAIK long dead solution was a blacklist of domains
> never sending mails, again not working for receivers not checking
> this black list, or using it only as an ingredient in scoring.
> 
> nullmx tackles the problem directly within RFC 2821 and 2821bis
> MUSTard, because receivers MUST report non-delivery they have no
> business to accept an "impossible" reverse path bound to a nullmx.
> 
> Of course receivers intending to violate 2821(bis) could still
> accept the nullmx reverse path, but that is their problem, folks
> are free to be as stupid as they can get away with.
> 
> Disclaimer for those who have not read it on the general list:
> 
> I do NOT support to add nullmx post second Last Call to 2821bis,
> and I don't think that billions of IPv6 toasters and webcams not
> interested in mail should have a nullmx or publish "v=3Dspf1 -all"
> or whatever DKIM offers to say "all mail from me is discardable".
> 
>  Frank
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Mon, 31 Mar 2008 12:18:40 -0600
From: Willie Gillespie <[email-masked]>
Organization: Engineering System Solutions
To: SM <[email-masked]>
CC: [email-masked]
Subject: Re: Minor isn't.  It's a pardigm change
Sender: [email-masked]

SM wrote:
> 
> Hi Paul,
> At 02:39 31-03-2008, Paul Smith wrote:
>> Either:
>> - toaster.example.org is going to send a message with the return-path 
>> of [email-masked], in which case I'd EXPECT 
>> toaster.example.org to have an SMTP server running on it, hence an MX 
>> record would not be a bad thing, or
>> - toaster.example.org is going to send a message with a null return 
>> path, in which case what does it matter..
> 
> The discussion have been whether the receiver should explicitly specify 
> a MX RR to determine whether it accepts mail.  If we stretch the MX RR 
> requirement to a forward and reverse model, then the sender 
> (toaster.example.org) also has to have a MX RR.  This means that the 
> change affects both senders and receivers.  If we use a null 
> return-path, the sender won't know whether there was a delivery failure.
<snip>

I think that stretching the MX RR requirement to both a forward and 
reverse model is not something we should necessarily consider.  I 
believe that would change the architecture too fundamentally.

I do stand on the side that MX records should be required for IPv6 only 
hosts that wish to receive mail at a FQDN.

The reason this must be discussed now, is because if 2821bis is 
published allowing AAAA fall-back, then we can never* change it in the 
future.

- Willie

* Obviously by never, I mean that it wouldn't ever happen.  That that it 
  theoretically couldn't happen.

From: "Sabahattin Gucukoglu" <[email-masked]>
To: John R Levine <[email-masked]>
Date: Mon, 31 Mar 2008 19:13:47 +0100
Subject: Re: Minor is.  It's not a pardigm change
CC: [email-masked]
Content-description: Mail message body
Sender: [email-masked]

Hi John,

On 30 Mar 2008 at 20:38, John R Levine <[email-masked]> said:
> >   To run an email server, today, an existing host only needs to make the 
> > server software operational.  No other change is required.  For example,
> > no coordination with DNS administration is required.
> 
> I suppose that's still true in theory, but when's the last time you saw a
> non-spam message sent to someone@[12.34.56.78] or saw an MTA deliberately
> configured to accept mail to dotted quad addresses? Every useful mail
> server has at least an A record.

No, I find that it happens.  Dynamic DNS providers, for instance, provide 
memorable names for addresses, often free if those names are inside the 
providers' domains.  Most ISPs provide existing ready-mapped hostnames for 
their customers.  And even besides that, there's the simple question of 
how to make a host that didn't once receive mail start to receive it 
without touching the DNS configuration, as might happen at a dedicated 
webserver.  The fallback provides that mechanism and it's often more than 
sufficient.

I agree that addresses with address literals are rare, but that doesn't 
mean many hosts aren't ready to accept them (mine does because I'm on 
sendmail and sendmail scans the addresses bound for addition in literal 
form in the w class - known hostnames - and I'm aware of at least a couple 
of Windows servers whose instructions tell the end-user to set up address-
literal forms in a similar way).

When IPv6 becomes widespread and there are fewer obstacles to reaching 
IPv6 nodes, perhaps we'll go back to receiving our mail with SMTP because 
everyone will want a hostname of his/her very own.  In such a case, the MX 
record may well be a nuisance more than necessary, and operating system 
vendors may well be justified in including stub MTAs with a default of 
"Reject everything".

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: Mon, 31 Mar 2008 10:48:17 -0700
To: Paul Smith <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Minor isn't.  It's a pardigm change
Cc: [email-masked]
Sender: [email-masked]

Hi Paul,
At 02:39 31-03-2008, Paul Smith wrote:
>Either:
>- toaster.example.org is going to send a message with the 
>return-path of [email-masked], in which case I'd 
>EXPECT toaster.example.org to have an SMTP server running on it, 
>hence an MX record would not be a bad thing, or
>- toaster.example.org is going to send a message with a null return 
>path, in which case what does it matter..

The discussion have been whether the receiver should explicitly 
specify a MX RR to determine whether it accepts mail.  If we stretch 
the MX RR requirement to a forward and reverse model, then the sender 
(toaster.example.org) also has to have a MX RR.  This means that the 
change affects both senders and receivers.  If we use a null 
return-path, the sender won't know whether there was a delivery failure.

>Personally, I can see a strong point for requiring MX records for 
>any domain which can receive mail as it removes a big ambiguity. 
>Anyone who doesn't set one up will soon notice that things aren't 
>working and will fix it. If a mail administrator is on 'talking 
>terms' with the DNS administrator enough to have an AAAA record 
>assigned to them, surely they're on talking terms enough to have an 
>MX record set up as well, especially since the DNS administrator 
>should know enough to know that one is expected.

We then have to elect whether we want a mail service as we add the 
Address record.  If we want to run a mail service later, it can be an 
administrative burden to get the MX RR added.

Regards,
-sm 

Date: 31 Mar 2008 16:57:40 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Looking for good mail vs. looking for bad mail
Organization: 
Sender: [email-masked]

[ I'm explaining, not arguing. ]

The importance of question of what domains are valid for make became
apparent during the endless discussions about DKIM SSP.  (No, I'm not
saying that SSP in anything like its current form is a good idea.)

In case anyone hadn't noticed, filtering spam by looking for the
characteristics of bad messages is a losing battle.  So the current
work with DKIM et al is to make it easier to recognize messages from
known good senders, thereby reducing both number of messages that need
expensive filtering, and also allowing somewhat more aggressive
filtering on what's left.

One of the issues has to do with domains that have a lot of
subdomains, some of which send mail and most of which don't.  If, say,
ibm.com goes to the effort of persuading everyone that they are well
behaved, we can expect bad guys to try to piggyback onto their good
reputation.  A certain amount of mail comes from [email-masked], but
plenty comes from [email-masked], [email-masked], and a variety of
other subdomains.  We expect that IBM will start signing their mail,
so at some point receivers can assume that mail that purports to be
from ibm.com or us.ibm.com that doesn't have a signature is likely to
be bogus.  (This is what SSP tries to do.)

But what about mail from [email-masked] or [email-masked], or any
of a zillion other hosts that have A records and presumably someday
will have AAAA records?  It would be really nice if IBM could say
forget it, not from us, for all of their non-mail domains.  Even if we
get MX 0 . on standards track, it will be rather cumbersome, since it
would roughly double the size of every non-trivial DNS zone with an MX
0 . for nearly every A or AAAA record.  For reasons I presume all of
us know, DNS wildcards don't help, and the various tree climbing and
zone cut kludges aren't workable.

So if you agree that it is likely to be useful to identify mail from
real senders, by far the simplest way to do that would be to require
an MX for the real senders' domains.

R's,
John

Date: Mon, 31 Mar 2008 09:41:59 -0700
To: Arnt Gulbrandsen <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Defaulting to no mail for IPv6-only hosts
Cc: [email-masked]
Sender: [email-masked]

At 01:48 31-03-2008, Arnt Gulbrandsen wrote:

>I fine-tuned the subject field ;)

I fine-tuned the recipient list. :-)

>But the hostnames I see _are_ fully qualified. Don't you have 
>messages like this?
>
>     From: "Something R. Other" <[email-masked]>
>     Sender: [email-masked]
>
>I have tens of thousands of messages where the From field's domain 
>is a strict postfix of the Sender field's domain. I don't know how 
>to estimate how many of the Sender addresses are deliverable, but 
>it's few enough that I consider them all untrustworthy and don't use them.

To avoid any confusion, note that my comment relates to the Sender: 
address in this example being used in the RFC 2821 mail.from.

I've seen such messages.  One of the problems here is that the sender 
may not be aware that the DSN goes to [email-masked].  If 
there's an MX RR for foo.example.com, then there's a presumption that 
the administrator is aware that there should be a SMTP service 
there.  As the editor of RFC 2821bis pointed out, it forces people to think.

Regards,
-sm 

Date: Mon, 31 Mar 2008 11:56:51 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC:  [email-masked]
Subject: Re: Minor is.  It's not a pardigm change
Sender: [email-masked]

Frank Ellermann wrote:
> Carl S. Gutekunst wrote:
> 
>> I get leery any time the specs assume that the guy running the 
>> mail server and the guy running the DNS server are on speaking
>> terms.
> 
> No matter what 2821bis will say, when IPv6 enters the picture
> they need to talk.  The mail guy in an IPvX network will want
> mail from non-IPvX networks.

Frank, the school of thought for a successful migration to IP6 will 
largely depend, at least initially, on the availability of dual stacks 
which will help in the smooth migration.  From that standpoint and as 
well from having no real market pressures, I have felt no urgent need 
for radical changes or mad rush to implement direct support for IP6.  It 
might be "simple" to discuss this from an admin standpoint, but from a 
engineering standpoint, systems who are going to mix will need to change 
their DNS clients software implementations radically.  Those are the facts.

But I think overall, there are two discussions going on here.

   1) A vs AAAA fall backs, and
   2) Mandating MX for Email Security Policies

and as you know, the latter is part of the wishes of the ASP group.

I have long stop trying to figure things out here with the different 
motives people have.  People speak from both sides but the SSP/ASP group 
was told long ago they were going to have a problem trying to mandate a 
MX record tied to EMAIL security.  They ignored the warnings from SMTP 
developers in the SSP/ASP discussions and/or move the discussions to non 
WG rooms and now they are attempting to throw in their day late (and 
dollar short) last minutes wishes on 2821BIS in hope it will make their 
ASP proposal more viable.

-- 
Sincerely

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

From: [email-masked]
Cc: [email-masked]
Date: Mon, 31 Mar 2008 08:50:06 -0700 (PDT)
Subject: Re: Minor is.  It's not a pardigm change
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> Carl S. Gutekunst wrote:

> > I get leery any time the specs assume that the guy running the
> > mail server and the guy running the DNS server are on speaking
> > terms.

> No matter what 2821bis will say, when IPv6 enters the picture
> they need to talk.

They already need to talk in the worst way but they don't. (Too much desire for
fiefdoms, I suppose.) And I don't see IPv6 forcing the issue. It can easily see
being the recipient of a one-way "in addition to having IPv4 address foo for
domain bar, you now have IPv6 address foo6, enjoy" message.

> The mail guy in an IPvX network will want
> mail from non-IPvX networks.

And they'll arrange it by setting up a relay of some kind. Perhaps
the case we should be looking at is this:

MX           IN MX 10    IPV6
MX	     IN MX 20    IPV4

IPV6	     IN AAAA ...
IPV4	     IN A    ...

				Ned

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  nullmx (was: Last Call: draft-klensin-rfc2821bis)
Date:  Mon, 31 Mar 2008 17:01:46 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 51
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Mark Andrews wrote:

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

Possibly you miss a subtle point in the nullmx design, it does not
only mean "I don't want email".  It also means "any mail claiming
to be MAIL FROM me cannot be okay, because there is no route to
report non-delivery" [etc. down to RFC 3834 auto-replies, but the
REQUIRED capability is to report non-delivery].

On the DKIM list folks discussed to emulate "I send no mail" with
a public statement "all my mails are signed", and then simply not
sending signed mails.  That's possible, but rather indirect, and
won't help receivers not interested in DKIM signing practises.

Even more subtle, DKIM is not about the 2821 MAIL FROM, so this
approach is beside the point wrt SMTP.  Likewise a SenderID PRA
"spf2.0/pra -all" policy won't help wrt SMTP.

The SPF solution "v=3Dspf1 -all" is acceptable, but this won't help
receivers not interested in checking SPF.  It also might not work
for receivers deciding to accept SPF FAIL, using it only as an
ingredient in scoring.=20

Another now AFAIK long dead solution was a blacklist of domains
never sending mails, again not working for receivers not checking
this black list, or using it only as an ingredient in scoring.

nullmx tackles the problem directly within RFC 2821 and 2821bis
MUSTard, because receivers MUST report non-delivery they have no
business to accept an "impossible" reverse path bound to a nullmx.

Of course receivers intending to violate 2821(bis) could still
accept the nullmx reverse path, but that is their problem, folks
are free to be as stupid as they can get away with.

Disclaimer for those who have not read it on the general list:

I do NOT support to add nullmx post second Last Call to 2821bis,
and I don't think that billions of IPv6 toasters and webcams not
interested in mail should have a nullmx or publish "v=3Dspf1 -all"
or whatever DKIM offers to say "all mail from me is discardable".

 Frank

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Minor is. It's not a pardigm change
Date:  Mon, 31 Mar 2008 16:15:02 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 14
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Alex van den Bogaerdt wrote:

> Basically I see these points of view right now:
=20
> a) leave as is.  Only lookup A record where no MX record exists
> b) leave as is.  Like looking up A record, one should lookup AAAA
>    record if no MX record exists (details A or AAAA vs. A and AAAA
>    can be discussed separately once consensus on (b) is achieved)
> c) change the design
=20
> Notice how (a) and (b) disagree and both say 'no change'.
> IMHO (c) shouldn't happen.  For what it's worth: I'm for (a).

+1

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Minor is.  It's not a pardigm change
Date:  Mon, 31 Mar 2008 16:11:17 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 11
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Carl S. Gutekunst wrote:

> I get leery any time the specs assume that the guy running the=20
> mail server and the guy running the DNS server are on speaking
> terms.

No matter what 2821bis will say, when IPv6 enters the picture
they need to talk.  The mail guy in an IPvX network will want
mail from non-IPvX networks.

 Frank

Date: Mon, 31 Mar 2008 14:55:52 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 31, 2008 at 02:21:06PM +0200, Arnt Gulbrandsen wrote:

> >>>This amounts to retro-active re-design on-the-fly.
> >>
> >>We can't escape redesigning this. IPv6 forces us to.
> >I still don't understand why IPv6 forces a redesign. I don't consider 
> >an MX record in the DNS system strongly tied to a transport.
> 
> Indeed. But this isn't about the MX, it's about what to do when the 
> domain in question has no MX.

Correct.

> >...
> >
> >>I like falling back to A only. That imposes no new requirements on 
> >>existing code or IPv4-only hosts, and it doesn't make unrealistic 
> >>presumptions about what software runs on future IPv6-only devices.

Notice: lookup A only

> >In spirit I agree.
> >
> >If something is trying to deliver e-mail, they have a choice between 
> >looking up an A or AAAA record or looking up MX records.

Notice: lookup A and/or AAAA

That's no agreement at all.  It's what this discussion is about.

> RFC 2821 page 60 says quite clearly that if MX records exist, they must 
> be used, and that an A record is used only if there aren't any MXes. 
> 974/1123 say much the same (some details are different).

That's the current status.  What people are trying to do, is to do the
same with AAAA records.

Basically I see these points of view right now:

a) leave as is.  Only lookup A record where no MX record exists
b) leave as is.  Like looking up A record, one should lookup AAAA
   record if no MX record exists (details A or AAAA vs. A and AAAA
   can be discussed separately once consensus on (b) is achieved)
c) change the design

Notice how (a) and (b) disagree and both say 'no change'.
IMHO (c) shouldn't happen.

For what it's worth: I'm for (a).

Date: Mon, 31 Mar 2008 14:21:06 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Cc: Rudy Nedved <[email-masked]>, John R Levine <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

Rudy Nedved writes:
>>> It appears that there has been a spontaneous desire for some spiffy 
>>> new goals to be overloaded onto that one, long-standing 
>>> *requirement*.
>>>
>>> This amounts to retro-active re-design on-the-fly.
>>
>> We can't escape redesigning this. IPv6 forces us to.
> I still don't understand why IPv6 forces a redesign. I don't consider 
> an MX record in the DNS system strongly tied to a transport.

Indeed. But this isn't about the MX, it's about what to do when the 
domain in question has no MX.

> ...
>
>> I like falling back to A only. That imposes no new requirements on 
>> existing code or IPv4-only hosts, and it doesn't make unrealistic 
>> presumptions about what software runs on future IPv6-only devices.
> In spirit I agree.
>
> If something is trying to deliver e-mail, they have a choice between 
> looking up an A or AAAA record or looking up MX records.

RFC 2821 page 60 says quite clearly that if MX records exist, they must 
be used, and that an A record is used only if there aren't any MXes. 
974/1123 say much the same (some details are different).

> I wouldn't quite describe this as a "faling back".
>
> I hope you understand my perspective.

I'm afraid I don't really. Sorry.

Arnt

Date: Mon, 31 Mar 2008 10:39:16 +0100
From: Paul Smith <[email-masked]>
To: SM <[email-masked]>
CC: [email-masked]
Subject: Re: Minor isn't.  It's a pardigm change
Sender: [email-masked]

SM wrote:
> Without the implicit MX for AAAA RRs
>
> example.com.  IN MX 10 smtp.example.com.
>
> smtp.example.com.  IN A 2001:DB8::1
> a.example.com.     IN A 2001:DB8::2
>
> example.com.       IN A 2001:DB8::1
> example.net.       IN A 2001:DB8::1
>
> user.example.org.          IN A 2001:DB8::21
> toaster.example.org.       IN A 2001:DB8::22
>
> In this example, if the sending domain is toaster.example.com, we 
> would accept the mail for example.com as it fits our RFC 821 model.  
> Without the implicit MX, we would need
>
> toaster.example.org.       IN MX 10  toaster.example.org.
>
> for the message to be accepted.  There are valid reasons for 
> toaster.example.com to be able to send mail to a.example.com and for 
> toaster.example.org (running a SMTP service this time) to be able to 
> accept mail and DSNs without having to resort to a MX RR.  From an 
> operational point of view, let's assume that this is a short term fix 
> and we don't have the access to do a DNS change.
Excuse me for being thick, but I don't really see the problem here...

Either:
- toaster.example.org is going to send a message with the return-path of 
[email-masked], in which case I'd EXPECT 
toaster.example.org to have an SMTP server running on it, hence an MX 
record would not be a bad thing, or
- toaster.example.org is going to send a message with a null return 
path, in which case what does it matter..

Personally, I can see a strong point for requiring MX records for any 
domain which can receive mail as it removes a big ambiguity. Anyone who 
doesn't set one up will soon notice that things aren't working and will 
fix it. If a mail administrator is on 'talking terms' with the DNS 
administrator enough to have an AAAA record assigned to them, surely 
they're on talking terms enough to have an MX record set up as well, 
especially since the DNS administrator should know enough to know that 
one is expected.

Maybe some people would automatically set up an MX record for every AAAA 
record, to get the equivalent behaviour as for IPv4, and there's nothing 
wrong with that if they want to waste resources, but I'd expect most to 
be more sensible and just set them up as necessary.

A possible alternative could be to change the retry requirements for 
domains which don't have an MX record, so you do a '3 day' retry for 
domains with MX records, but a shorter retry for domains with only AAAA 
records - this would avoid the big problem of people sending mail to 
domains which are never going to accept mail, and thus the massive 
resource wastage due to all the failed retries which are doomed to 
failure. The bad side of this is that the 99% of people who don't read 
the standards will think things are working OK without the AAAA domain 
when they're only partially working - hence I'd think the mandatory MX 
record would be a better idea.

Date: Mon, 31 Mar 2008 11:32:31 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Minor is. It's not a pardigm change
Cc: John R Levine <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

Dave Crocker writes:
> John R Levine wrote:
>> Quite true.  If the goal is to maximize the total amount of mail 
>> delivered to mail servers, legit mail, spam, blowback, phishes, 
>> whatever, then fallback to AAAA is definitely the right thing to do. 
>>  But is that really what we're trying to accomplish?
>
> I thought the goal was to add v6 support to Internet mail.

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.

Look up only A: What John wants, and what I think is best, and what most 
IPv4-only hosts do today. IPv6-only hosts would have to look up A and 
forward mail to such destinations via a relay, and IPv6-only mail 
servers would need to have an MX record pointing at them.

This is a change because it means that IPv6-only hosts aren't presumed 
to run mail servers by default, which also implies that code cannot 
make an email address by concatenating some localpart with the host's 
FQDN.

This is not a change because old mail servers do exactly this.

Look up either A or AAAA: A-only hosts would look up A, AAAA-only hosts 
would look up AAAA, dual-protocol hosts would look up both, and an 
address would be deliverable or not depending on who's sending.

This is a change because for the first time, an address can be valid 
despite there being neither an MX or an A RR for the domain. (I think 
this would break the MUA I'm using, actually. It has a typo check on 
To/Cc which uses an MX+A lookup.)

This is not a change because old mail servers (IPv4-only) do exactly 
this (look up A only, not AAAA, and not X25 not ISDN either).

Look up both A and AAAA: All hosts would have to look up both address 
types, and if they cannot reach the presumed destination, forward the 
mail to a dual-protocol relay.

This is a change because vast numbers of IPv4-only hosts today do not 
look up AAAA records when an MX lookup fails.

This is not a change because at least some of the software written in 
the past five years does this.

> A rather simple and straightforward task that the current draft 
> satisfies reasonably, modulo the usual wordsmith-hacking.

I read the -06 draft as permitting the last two alternatives ("A or 
AAAA", "A and AAAA"). 2821 itself says A.

> It appears that there has been a spontaneous desire for some spiffy 
> new goals to be overloaded onto that one, long-standing 
> *requirement*.
>
> This amounts to retro-active re-design on-the-fly.

We can't escape redesigning this. IPv6 forces us to.

I like falling back to A only. That imposes no new requirements on 
existing code or IPv4-only hosts, and it doesn't make unrealistic 
presumptions about what software runs on future IPv6-only devices.

Arnt

Date: Mon, 31 Mar 2008 10:48:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Defaulting to no mail for IPv6-only hosts
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

I fine-tuned the subject field ;)

John C Klensin writes:
> Of course, the firm requirement in 2821 that all domains in email 
> addresses be fully-qualified, plus either a little knowledge or a 
> quick determination that "hostname" is not a TLD, is sufficient to 
> reject such messages as non-deliverable as soon as they touch the 
> mail system and possibly earlier.

Of course.

But the hostnames I see _are_ fully qualified. Don't you have messages 
like this?

     From: "Something R. Other" <[email-masked]>
     Sender: [email-masked]

I have tens of thousands of messages where the From field's domain is a 
strict postfix of the Sender field's domain. I don't know how to 
estimate how many of the Sender addresses are deliverable, but it's few 
enough that I consider them all untrustworthy and don't use them.

> The fact that those rejections do not occur often enough may be more 
> evidence about the futility of trying to fix these sorts of problems 
> by fine-tuning standards.

I sort of agree with the argument, except that IMO it doesn't apply in 
the common case.

Arnt

Date: Sun, 30 Mar 2008 23:53:06 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: Minor isn't.  It's a pardigm change
Sender: [email-masked]

At 18:57 30-03-2008, John C Klensin wrote:
>MXs that way is, IMO, inappropriate.  However, while the requirement 
>for relaying has become less as we have evolved toward a 
>fully-connected Internet, if MXs are relegated to "administrative 
>convenience", we would, IMO, need to restore the original RFC 821 
>model of forward and reverse paths.   Put differently, one either 
>has MX records or one has to have "came from" and "route through" 
>functions in the mail transport syntax and model.  Getting rid of 
>those functions turned MX from what might otherwise have been an 
>administrative convenience into a fundamental part of the architecture.

This is an interesting point.  We have been discussing about whether 
a MX should be a test of whether the domain elects to receive 
mail.  Nobody mentioned the forward and reverse paths model up to now 
although that's what tends to be enforced.

There are times when people or automated agents send a message as a 
notification.  It's a fire and forget approach as a reply to act on 
isn't expected.  There's also the case where a message is sent and we 
expect a reply or a DSN to determine whether the message has reached 
the receiver.  The reverse path is not important in the first 
case.  With a MX-only approach, we have a constraint where the first 
case would only work if the sending domain has a MX RR.

>But that modeling issue doesn't have anything to do with whether 
>getting rid of implicit MXs, or restricting them to IPv4, is a good 
>idea.  I do see a reason to do that in principle, but I don't think 
>it holds up in practice: to the extent that "transport over IPv6" is 
>a different service than "transport over IPv4", then one might 
>reasonably have SMTP-related reasons for preferring one of those 
>services over the other that were independent of the considerations 
>of RFC 3484.   That might suggest DNS setups like
>
>   foo.bar.baz.  IN MX 10 v4host.smtp.example.com.
>                 IN MX 5  v6host.smtp.example.com.
>   v4host.smtp.example.com IN A 10.0.0.6
>   v6host.smtp.example.com IN AAAA 2001:DB8::6
>   ; smtp.example.com  IN AAAA 2001:DB8::6
>   ;                   IN A 10.0.0.6
>
>and, all other things being equal, avoiding the MX default to help 
>force people to think about those issues.  But, as others have said 
>at more length, it appears to me that the horse is long out of the barn.

One of the arguments for the change is the above.  It may also help 
the transition to IPv6.  But then we don't usually do changes on a may alone.

Getting back to the existence test:

IPv4 example

example.com.  IN MX 10 smtp.example.com.

smtp.example.com.  IN A 192.0.2.1
example.com.       IN A 192.0.2.1
example.net.       IN A 192.0.2.1

user.example.org        IN A 192.0.2.21

IPv6 example

example.com.  IN MX 10 smtp.example.com.

smtp.example.com.  IN A 2001:DB8::1

example.com.       IN A 2001:DB8::1
example.net.       IN A 2001:DB8::1

user.example.org.       IN A 2001:DB8::21

example.net doesn't wish to receive mail.  However, it will see SMTP 
transaction attempts for domain because of the implicit 
fallback.  That can be an issue for some receivers which is why they 
use null-mx and other tricks.  The sending domain, user.example.org, 
has a reachable reverse path.

Without the implicit MX for AAAA RRs

example.com.  IN MX 10 smtp.example.com.

smtp.example.com.  IN A 2001:DB8::1
a.example.com.     IN A 2001:DB8::2

example.com.       IN A 2001:DB8::1
example.net.       IN A 2001:DB8::1

user.example.org.          IN A 2001:DB8::21
toaster.example.org.       IN A 2001:DB8::22

In this example, if the sending domain is toaster.example.com, we 
would accept the mail for example.com as it fits our RFC 821 
model.  Without the implicit MX, we would need

toaster.example.org.       IN MX 10  toaster.example.org.

for the message to be accepted.  There are valid reasons for 
toaster.example.com to be able to send mail to a.example.com and for 
toaster.example.org (running a SMTP service this time) to be able to 
accept mail and DSNs without having to resort to a MX RR.  From an 
operational point of view, let's assume that this is a short term fix 
and we don't have the access to do a DNS change.

IPv6 is yet to see extensive deployment.  To ensure coexistence 
between IPv4 and IPv6 networks, the "where" test is more important 
and it's better to have MX RRs for any message exchange.  That won't 
necessarily solve the transition problem.  And if we go down that 
path, we are putting restrictions in the current model.

Now, for a reality test, we all know that it has become more 
difficult to ensure mail delivery due to barriers at the receiving 
end.  At the end of the day, the receiver's policy dictates whether 
the sender can get the message through.  The receiver can always 
enforce a policy where the sender hostname requires a MX RR.  But 
then we cannot play the blame game where we refer to the SMTP 
standard to determine who is wrong.

The advantages of the change are:

  1. A domain can publish whether it wants to accept mail

  2. Operational problems due to misconfiguration may be detected more easily

  3. IPv6 transition may be easier

The disadvantages are:

  1. A domain has to publish whether it wants to send mail.

  2. People would expect the same behavior with IPv6.

  3. We are changing the model by making it more difficult to exchange mail.

Regards,
-sm  

To: [email-masked]
Subject: Re: not delivering, and History of fallback to A
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 30 Mar 2008 23:21:51 -0700
Sender: [email-masked]

[email-masked] writes:

>> No, of course not.  It's going to change the way that MTAs are set up
>> which will make it harder for spammers to abuse.

> I completely fail to see how the availability or nonavailability of DNS
> fallback behavior will lead to increased spam abuse. As I pointed out
> previously, if spammers percieve an advantage to sending directly to
> hosts named in A/AAA records they are going to do so no matter what. By
> the same token, if they don't perceive an advantage they won't do it.

Trying to explain this one point just for the sake of clarity, since I
think I see what Jon's getting at:

A huge amount of the spam that's out there involves spammers scraping the
Internet for anything that looks like an address and dumping it into an
MTA (generally by way of a compromised system).  That MTA then does its
normal thing with that mail.  The widespread use of other anti-spam
tactics is pushing more spammers into abusing the MTAs accessible
compromised systems instead of sending spam directly themselves.

If that address points to some host that doesn't actually receive mail
(message IDs cause this to happen all the time), that spam creates a bunch
of attempted deliveries, bounces back to the (forged) envelope sender,
etc.  Without the A record fallback, it could be immediately discarded.

Now, in my opinion, like every other antispam measure, such as the
greylisting that makes this MTA behavior now more common, this wouldn't
result in a net decrease of spam in the long run.  Most anti-spam measures
just make the mail system more complex and fragile for short-lived gains
that quickly disappear.  However, this one has the advantage of being,
from a certain perspective, also more formally correct in that it
represents the reality of hosts that don't accept e-mail more clearly and
allows quick discarding of lots of spam to addresses that will never
exist.  As anti-spam measures go, it's a fairly straightforward and
uncomplicated one.

Practical questions of deployment are another matter which I won't get
into.  I just wanted to try to take another shot at explaining the above
sentence, since it makes sense to me too.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: "Carl S. Gutekunst" <[email-masked]>
Cc: John C Klensin <[email-masked]>, [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: Minor is. It's not a pardigm change 
Date: Mon, 31 Mar 2008 15:50:13 +1000
Sender: [email-masked]

> 
> John C Klensin wrote:
> > If one were designing the architecture de novo today, in today's 
> > environment, there would be a strong case for "no MX default", but the 
> > sort of situation Carl mentions would also make a strong case for 
> > separate "MX-forward-path" and "MX-reverse-path" (bounces) records.
> 
> I dunno. I get leery any time the specs assume that the guy running the 
> mail server and the guy running the DNS server are on speaking terms. 
> I've seen too many cases (even in smallish companies) where the 
> corporate mail server and DNS were run by one department, but web and 
> E-mail aware applications were run by another. Typically, the latter 
> group would be pre-allocated a "pool" of hostnames, A records, and PTR 
> records. When they added a new server, they'd just grab the next name 
> and number from the pool. If they had to differentiate in advance which 
> machines sent mail, and throw MX records into the mix too, they'd never 
> ship.

	What they are being allocated today is a A record, PTR and
	MX implicit. 

	They can achieve exactly the same thing by requesting a
	pool of A, PTR and MX records.

	Or eventually when they add a new host they will just get
	the next KEY record from the pool and the host will add the
	AAAA, A, MX ("0 ." by default) and PTR records for itself
	using the KEY record and SIG(0) for the forward records and
	TCP based athentication for the reverse record.  6to4 reverse
	already uses TCP based authentication so the later is not
	a big stretch of the imagination.
 
	Mark

> <csg>
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Sun, 30 Mar 2008 22:13:43 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: Minor is.  It's not a pardigm change
Sender: [email-masked]

John C Klensin wrote:
> If one were designing the architecture de novo today, in today's 
> environment, there would be a strong case for "no MX default", but the 
> sort of situation Carl mentions would also make a strong case for 
> separate "MX-forward-path" and "MX-reverse-path" (bounces) records.

I dunno. I get leery any time the specs assume that the guy running the 
mail server and the guy running the DNS server are on speaking terms. 
I've seen too many cases (even in smallish companies) where the 
corporate mail server and DNS were run by one department, but web and 
E-mail aware applications were run by another. Typically, the latter 
group would be pre-allocated a "pool" of hostnames, A records, and PTR 
records. When they added a new server, they'd just grab the next name 
and number from the pool. If they had to differentiate in advance which 
machines sent mail, and throw MX records into the mix too, they'd never 
ship.

<csg>

Date: Sun, 30 Mar 2008 21:39:55 -0700
From: Jim Fenton <[email-masked]>
To: [email-masked]
CC: John Levine <[email-masked]>, [email-masked]
Subject: Re: Defaulting to no mail
Sender: [email-masked]

Dave Crocker wrote:
>
>
>
> John Levine wrote:
>> Under the current setup, any domain that has an A record is presumed
>> to be a mail domain, and if it's not, there's no good way to advertise
>> that fact.  
>
>
>> Getting rid of the AAAA fallback flips the default to be in line with
>> reality 
>
>
> Flipping any 20-year default for an global installed base should be 
> pursued with an assumption that it won't work, not that it will.  This 
> puts the burden of making the case on those lobbying for the change.  
> And it should make the barrier for adoption be pretty high.  In other 
> words, the case needs to be compelling, not merely appealing.

20-year default for AAAA fallback?

Actually, I have the opposite question:  Is _adding_ AAAA fallback in 
2821bis more likely to set it back in terms of progression on standards 
track?  2821 doesn't have a requirement for AAAA fallback, so it seems 
that adding that requirement might be just the type of "mission creep" 
you're trying to avoid.

But I'm definitely not an expert on what is and what isn't allowable in 
standards track progression...

-Jim

To: John C Klensin <[email-masked]>
Cc: [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis 
Date: Mon, 31 Mar 2008 14:31:37 +1000
Sender: [email-masked]

> I'm no longer going to comment on the mail aspects of this MX 
> debate on the IETF list -- see the ietf-smtp list.  But there is 
> an issue here with much broader implications...
> 
> --On Monday, March 31, 2008 9:36 AM +1000 Mark Andrews 
> <[email-masked]> wrote:
> 
> >...
> > 	It's a natural back port of the SRV rules to MX.
> >
> > 		"SRV 0 0 ." indicates "no service".
> 
> Well, strictly speaking, it doesn't mean that, regardless of 
> what the SRV specs say.   What is means is "this service is not 
> advertised for this domain". 

	The lack of a SRV RRset means that.  

> If a service is associated, as 
> part of its protocol, with an established (not necessarily 
> well-known) port, then the only way to determine that the 
> service isn't offered is by attempting to connect to that port. 

	"SRV 0 0 ." is a affirmative statement saying there is no
	service for this domain.  There may well still be something
	listening on the standard port processing transactions for
	another domain.

	You have similar today with MX records where host A can be
	handling all email directed to domain B and host B is
	handling all email directed to domain A.

	SRV support was NOT grandfathered in for existing protocols
	to avoid the well known port problem.

	The default was for NEW protocols that decided to use SRV
	records.  SRV lookup is not optional in these cases.

> If is isn't associated with a specific port, one may have a hard 
> time trying to find the service, but the only way to know that 
> is isn't being offered is scan ports looking for it its 
> symptoms.   For good reason or bad, there are also all sorts of 
> ways to communicate the location of a service and the port to 
> use that have nothing to do with the DNS and DNS changes, 
> restrictions, and records cannot affect them.  These are not 
> special properties of SMTP, with or without MX records; they are 
> properties of TCP.  If one wants to fix those problems, then TCP 
> has to be changed to affirmatively return a "no service" message 
> if an attempt is made to connect to a port on which no service 
> is specifically listening.
>
> > 	It was obvious 20+ years ago that MX processing was broken
> > 	as there was no way to say "I don't want email".
> 
> First, it may have been obvious to you, but it wasn't obvious to 
> many of us.   In the general case, it still isn't.  But you 
> stated the situation exactly correctly.   "MX 0 ." means "I 
> don't want email".   "SRV 0 0 ." doesn't really indicate "no 
> service", it indicates "please do look for that service here".

	"SRV 0 0 <hostname>" means look for that service here.
	"." is not a valid hostname.
 
> >   Looking
> > 	a the MX record, "MX 0 ." was the obvious solution.  The
> > 	only reason I can see that it never went ahead was FUD.
> 
> While it is better than interpreting the lack of a bit in a WKS 
> record as "no service", it is still nothing more than an attempt 
> to use the DNS to say "please don't try a mail connection to 
> this domain".  I think that is probably ok and would be happy to 
> see a proposal carefully considered to see if consensus could be 
> reached (as Frank points out, there was such a proposal but it 
> quietly disappeared, no FUD campaign needed).

	The was FUD about the roots being overwhelmed by A lookups.
	That FUD was raised again the moment this was resuggested.

>  But I note that 
> "please don't do X" is a solution to a different set of problems 
> than a solution that would prevent someone who is predisposed to 
> antisocial behavior from trying something.  Since bad guys can 
> deduce addresses by scanning --and will certainly do so if we 
> make it sufficiently hard for them to use the DNS-- this type of 
> DNS change, it seems to me, would have little effect on the 
> antisocial.   And, again, that isn't a statement about email 
> because it applies with equal force to any other application 
> service we have.

	I'm not really worried about anti-social behaviour.  I want
	good behaviour for real users that send email to hosts that
	don't have SMTP servers turned on.  1 week timeouts is not
	good behaviour.

> > 	It's so obvious that some MTA's already implement it.  Exim
> > 	is the example I've been told about.
> >
> > 	The existing MX processing rules assume that *every* host
> > 	wants to receive email.  The assumption has not been correct
> > 	for 20+ years.
> 
> The existing A processing rules assume that *every* host wants 
> to, or is at least able to, receive web connections, file 
> transfer connections, SIP connections, telnet connections, 
> Jabber connections, and, by the way, DNS connections.  Changing 
> the MX rules won't change the assumption that every host 
> supports email.  And most, it will make a statement of 
> preference that mail connections won't be accepted more clear. 
> And, viewed in that light, Exim's behavior represents a 
> willingness to honor a preference... a willingness that, 
> incidentally, can be bypassed by the simple expedient of giving 
> it an address in literal form rather than one that is processed 
> via the DNS.  Of course, Exim can, and often is, configured to 
> reject mailbox@[ip-literal] addresses, but that behavior is 
> outside the standard.
> 
>        john
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Mon, 31 Mar 2008 00:27:28 -0400
From: John Leslie <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Subject: Paradigm change?
Sender: [email-masked]

John C Klensin <[email-masked]> wrote:
> 
> Using the DNS to _discover_ where to find the preferred server 
> for a particular service for a particular domain is a different 
> matter from using the DNS to determine whether or not a 
> particular server supports a particular service.

   True, but all of us are talking about the first, not the second.
We aren't setting out to ask whether a _server_ supports SMTP --
we're asking what IP address a _domain_ advertises for receiving
SMTP connections.

   The RFC2821 text about implicit MX states a fallback, in the
absence of any MX RR, and it states it in terms of what the
implied MX record must be assumed to be.

> (1) I do not agree with Dave that MX records are simply an 
> administrative convenience (nor do I read his comment as 
> implying that the DNS more generally is just an administrative 
> convenience).  I think they are part of the architecture, an 
> architecture that clearly includes DNS use.

   Agreed.

> I do think there is a case to be made that using MXs to isolate
> the location of a mail server from the domain at which the
> mail address is located is an administrative convenience,

   I'm not sure I understand. I hope you mean that the domain-name
of the server need not be the same as the domain for which it
receives email, which I consider a rather important architectural
feature.

> even though it is, as others have pointed out, critical enough
> to important operational service models that identifying and
> dismissing MXs that way is, IMO, inappropriate.

   (I'm sure I _don't_ understand that statement.)

> However, while the requirement for relaying has become less as
> we have evolved toward a fully-connected Internet, if MXs are
> relegated to "administrative convenience", we would, IMO, need
> to restore the original RFC 821 model of forward and reverse
> paths.

   I can imagine other solutions, but I agree that MX RRs were
essential to depretating forward-path.

> But that modeling issue doesn't have anything to do with whether 
> getting rid of implicit MXs, or restricting them to IPv4, is a 
> good idea.

   Agreed, I think...

> I do see a reason to do that in principle, but I don't think it
> holds up in practice: to the extent that "transport over IPv6"
> is a different service than "transport over IPv4",

   (I'm not sure we've yet found a better paradigm than recognizing
them as different -- and assuming the existence of a gateway.)

> then one might reasonably have SMTP-related reasons for
> preferring one of those services over the other that were 
> independent of the considerations of RFC 3484.

   This looks interesting!

> That might suggest DNS setups like
> 
>   foo.bar.baz.  IN MX 10 v4host.smtp.example.com.
>                 IN MX 5  v6host.smtp.example.com.
>   v4host.smtp.example.com IN A 10.0.0.6
>   v6host.smtp.example.com IN AAAA 2001:DB8::6
>   ; smtp.example.com  IN AAAA 2001:DB8::6
>   ;                   IN A 10.0.0.6

   I may be confused...

   One certainly can use DNS to state a preference for IPv4 or IPv6
and a gateway for the other, but this doesn't look to be doing that.

> and, all other things being equal, avoiding the MX default to 
> help force people to think about those issues.  But, as others 
> have said at more length, it appears to me that the horse is 
> long out of the barn.

   The IPv4 horse is "long out of the barn", but not the IPv6 one.

> (2) One of the reasons I felt that we should have done "TCPng" 
> when we did IPv6 is that I believe, in retrospect, that 
> TCP/IP[v4] seriously erred in letting "timeout" or "connection 
> reset" be our only real ways to report "service not supported". 

   Agreed that those are not the right wayr: though "connection
reset may be "close enough", "timeout" certainly isn't.

> I believe that a server should be able (and required) to return 
> a definitive "no service on that port" message at the TCP level 
> and perhaps that there should be a definitive way to probe for 
> the presence of a service other than opening a TCP connection. 

   Either of those would be an improvement.

> I believe that having that type of functionality would be an 
> effective way to deal with many of the issues that we are now 
> trying to push onto the DNS even though it might raise some 
> complex issues about negative response caching and would make 
> operations like port scanning more efficient.

   But in our "real world," DNS appears to be our best tool.
And I believe SRV RRs will get us there, though we need to be
patient and might need to tweak their definition.

> But that horse is not only out of the barn, it has long since 
> disappeared over the horizon.

   "Bring me that horizon!"

--
John Leslie <[email-masked]>

Date: Sun, 30 Mar 2008 21:24:16 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John Leslie <[email-masked]>
CC: [email-masked]
Subject: Re: Defaulting to no mail
Sender: [email-masked]

John Leslie wrote:
>    That there are today some clue-challenged DNS administrators is
> unfortunate, but the requisite level of clue really isn't that great;
> and the deficiency is undobtedly correlated with the minuscule need to
> advertise MX records.

Basic philosophical difference of.

For an installed base with a long history, idealised design preferences are lost 
in the mist.

I do not presume that changing the dynamic range or average of admin, ops, or 
user behaviors is a productive path... At least not without very careful 
motivation, design, and deployment effort, of which the current proposal 
represents none.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 30 Mar 2008 23:41:33 -0400
From: John Leslie <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Defaulting to no mail
Sender: [email-masked]

Dave Crocker <[email-masked]> wrote:
> John Levine wrote:
> 
>> Under the current setup, any domain that has an A record is presumed
>> to be a mail domain, and if it's not, there's no good way to advertise
>> that fact.  
>> Getting rid of the AAAA fallback flips the default to be in line with
>> reality 
> 
> Your assertion about that the change would "flip[] the default to be in 
> line with reality" is a helpful example of seeking to satisfy that 
> requirement, since it highlights core assumptions and permits debating
> them.
> 
> For example, changing a default alters the strategic orientation of a 
> service. An example impact is that it can substantially alter the
> barrier to entry.  So, for example, the proposed change would require
> a very different degree of broad-based DNS administrative capability
> than is often available, as Ned observed.

   That's overstating the case, Dave.

   That there are today some clue-challenged DNS administrators is
unfortunate, but the requisite level of clue really isn't that great;
and the deficiency is undobtedly correlated with the minuscule need to
advertise MX records.

   The larger ISPs already have web-based programs to maintain DNS
records, and the programming to accept a check-box to generate a
MX record for "running an email server" is certainly no more than an
hour's work. I doubt you'll find _any_ registrar two years from now
that doesn't offer that.

>> As other people have pointed out, a no-mail default is far more robust
>> than the current default, since a fair number of non-mail hosts turn
>> out to be running some sort of default SMTP server which will swallow
>> and lose mail. 
> 
> Here, again, is a helpful assertion, since it is concrete and pragmatic.  
> But is it correct?
> 
> Is this a real and serious problem that needs correcting?

   That's a different question, Dave.

> I had not heard about this as a pressing operational problem, but I
> also don't claim to be deeply connected into the SMTP operations
> community.  Others on this list are.

   Indeed.

   We do quite a bit of user support for email at JLC.net. The short of
it is, we try to find evidence in our email logs. That tells us where
it went, or if it's still pending.

   Users, indeed, do mostly hit the "reply" button, but typos are _not_
rare.

   I won't call it a "pressing operational problem" today; but if spam
volume keeps doubling, I make no promises I won't call it "pressing"
within five years.

>> Or even if they aren't running an SMTP server, it can
>> take a week for the message to time out and bounce.  It'd be much
>> better for such messages to fail immediately so the sender will notice
>> and can do something about it.
> 
> This is an entirely different change to the service model, and one with 
> some potentially very large impact, such as dramatically increasing the 
> rate of delivery failure.

   Again, you overstate the case. The increased _rate_ is unlikely to
be "dramatic", and the ease of debugging would be _significantly_
greater without a long delay between hitting the "send" button and
getting an error message.

   The fact is, the substanital majority of email sent by our users
is to domains that will act on it in a few seconds.

> In effect, it could move email more towards 
> instant messaging, in being a model of instantaneous success/failure, 
> rather than being the infrastructure-persistence model we now have.

   Sounds like something the users would like...

> One question is to impose this change on the entire email community,
> rather than add it as a option.

   No doubt that would bother you, though I'm not sure why. A substantial
majority of the users I know would prefer it, and don't like being faced
with too many options.

====

   Let me ask, seriously, doesn't this sound like a better design?

--
John Leslie <[email-masked]>

Date: Sun, 30 Mar 2008 23:36:16 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
Subject: Re: not delivering, and History of fallback to A
Sender: [email-masked]

John R Levine wrote:
> 
>> I completely fail to see how the availability or nonavailability of DNS
>> fallback behavior will lead to increased spam abuse. As I pointed out
>> previously, if spammers percieve an advantage to sending directly to
>> hosts named in A/AAA records they are going to do so no matter what. By
>> the same token, if they don't perceive an advantage they won't do it.
> 
> I see that I have been completely unable to explain myself.  I give up.

Thanks. I appreciate that.  New mandates based on "economy of scale" is
not feasible on old and widely embedded system like SMTP. If you had in 
the back of your mind making a tie-in to some other Email Security 
proposal(s), including one that is attempting to mandate a MX records to 
make it work "right," I could see some useful reason to point that out.

-- 
Sincerely

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

Date: Sun, 30 Mar 2008 23:28:04 -0400
From: John C Klensin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Defaulting to no mail
Sender: [email-masked]

--On Sunday, March 30, 2008 4:10 PM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

> There is another argument: A fair amount of software
> constructs email addresses, most notably
>
>      Sender: something@hostname
>
> and
>
>     MAIL FROM:<something@hostname>
>
> The best I can say for these addresses is that they're
> syntactically valid. It would be a great joy to me if all the
> muckware would stop assuming that blah@hostname is a
> deliverable email address.

Of course, the firm requirement in 2821 that all domains in 
email addresses be fully-qualified, plus either a little 
knowledge or a quick determination that "hostname" is not a TLD, 
is sufficient to reject such messages as non-deliverable as soon 
as they touch the mail system and possibly earlier.   The fact 
that those rejections do not occur often enough may be more 
evidence about the futility of trying to fix these sorts of 
problems by fine-tuning standards.

    john

Date: Sun, 30 Mar 2008 23:13:03 -0400
From: John Leslie <[email-masked]>
To: John Levine <[email-masked]>
Cc: [email-masked]
Subject: Re: Defaulting to no mail
Sender: [email-masked]

John Levine <[email-masked]> wrote:
> 
> Under the current setup, any domain that has an A record is presumed
> to be a mail domain,

   Let us pause for a moment, and consider that statement.

   It is correct in that it talks of "domains". DNS queries are for
Resource Records for a "domain". And email (excepting the @[IP] case)
is intended to go to a "domain."

   It's slightly less correct to say "is presumed..." The domain
might also have an MX RR -- in which case the presumption is denied.
The "presumption" means that any SMTP server asked to send to that
domain must try to open a port 25 connection, and continue to
"presume" until that attempt times out.

> and if it's not, there's no good way to advertise that fact.

   Clearly, waiting for a timeout is not "a good way".

> (Current crocks include running a stub server that rejects everything,
> and the MX 0 . proposal.)

   It would seem that neither of these are likely to be done by admins
that now can't be bothered to publish a MX RR because "it's working
just fine as it stands."

> In a world where the fraction of mail that is spam is 95% and growing,

   Has anybody else noticed that we were saying "80% spam" just a year
ago?

   One can argue whether the spam volume is doubling every six months
or whether it takes a year... Let's assume it takes a year: in the
ten-year expected lifetime of 2821bis, that would project to 99.995%
spam...

> the load due to unwanted mail to non-mail domains is significant.

   ... meaning that today's 20:1 would become 20,000:1. :^(

> As Keith recently pointed out, since it is no longer 1983, the vast
> majority of names with A records are not mail servers nor are they
> domains that occur in valid mail addresses.

   I suspect we'll see Zipf's law at work (frequency of occurance is
roughly inversely proportional to the rank position), with roughly
100 domains accounting for at least half the email, and nobody bothering
to set up email beyond the 100,000th domain. ISC.org estimated roughly
500 million hosts on the Internet at the start of 2008. Thus, we seem
to be very roughly at one in 5,000 right now.

> As other people have pointed out, a no-mail default is far more robust
> than the current default, since a fair number of non-mail hosts turn
> out to be running some sort of default SMTP server which will swallow
> and lose mail.

   I can't estimate this effect. Sorry...

> Or even if they aren't running an SMTP server, it can take a week for
> the message to time out and bounce.

   I can testify to that.

> It'd be much better for such messages to fail immediately so the
> sender will notice and can do something about it.

   This does seem more user-friendly to me.

   I continue to gaze in amazement at the postings I see which deny
that we can or shuold do anything about these facts.

   :^(

--
John Leslie <[email-masked]>

Date: Sun, 30 Mar 2008 23:05:54 -0400
From: John C Klensin <[email-masked]>
To: "Carl S. Gutekunst" <[email-masked]>, John R Levine <[email-masked]>
cc: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Minor is.  It's not a pardigm change
Sender: [email-masked]

--On Sunday, March 30, 2008 7:05 PM -0700 "Carl S. Gutekunst" 
<[email-masked]> wrote:

> Requiring an MX record for every mail host certainly would be
> a paradigm shift. The historical use of the MX record is to
> identify which hosts are responsible for the incoming E-mail
> for a domain, not identifying the specific hosts that are able
> to accept E-mail. There are many situations where a sending
> MTA coerces the RHS of the bounce address to its own hostname
> to ensure that bounces are returned specifically to the
> sending host. This might be done for list management, capacity
> management, internal corporate organization, security, or a
> number of other reasons. If MX records were required, then
> they'd have to be added for every one one of these sending
> hosts. I know of many organizations for which this would be a
> significant administrative burden.

Hmm.   This example, which I agree with but hadn't though to 
introduce into this discussion, is probably another example of 
why we don't want to try to tamper with things now by simply 
changing the defaults (or by distinguishing IPv6 from IPv4).  If 
one were designing the architecture de novo today, in today's 
environment, there would be a strong case for "no MX default", 
but the sort of situation Carl mentions would also make a strong 
case for separate "MX-forward-path" and "MX-reverse-path" 
(bounces) records.

That issue is similar to Frank Ellermann's oft-repeated 
complaint that (paraphrasing) we weakened the architecture 
vis-a-vis today's needs when reverse-paths stopped looking like 
<@nearest-relay: user@presumed-origin> rather than depending on 
MX records to determine the mail routing for rejection/bounce 
messages and thereby treating them the same way forward-path 
messages are treated.

But those sorts of considerations are important if and when we 
decide to go design a replacement email system.  In the 
environment we have, it is yet another reason why the notion of 
an address-based MX default has to apply to address records of 
all types.

    john

Date: Sun, 30 Mar 2008 19:05:57 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: John R Levine <[email-masked]>
CC: Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Minor is.  It's not a pardigm change
Sender: [email-masked]

John R Levine wrote:
>>   To run an email server, today, an existing host only needs to make 
>> the server software operational.  No other change is required.  For 
>> example, no coordination with DNS administration is required.
>
> I suppose that's still true in theory, but when's the last time you 
> saw a non-spam message sent to someone@[12.34.56.78] or saw an MTA 
> deliberately configured to accept mail to dotted quad addresses? Every 
> useful mail server has at least an A record.

John, maybe I missed something in the discussion, but I thought your 
proposal was to mandate MX records for IPv6 e-mail hosts? Support for 
domain literals seems unrelated.

Requiring an MX record for every mail host certainly would be a paradigm 
shift. The historical use of the MX record is to identify which hosts 
are responsible for the incoming E-mail for a domain, not identifying 
the specific hosts that are able to accept E-mail. There are many 
situations where a sending MTA coerces the RHS of the bounce address to 
its own hostname to ensure that bounces are returned specifically to the 
sending host. This might be done for list management, capacity 
management, internal corporate organization, security, or a number of 
other reasons. If MX records were required, then they'd have to be added 
for every one one of these sending hosts. I know of many organizations 
for which this would be a significant administrative burden.

<csg>

Date: Sun, 30 Mar 2008 19:01:32 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John R Levine <[email-masked]>
CC: [email-masked]
Subject: Re: not delivering, and History of fallback to A
Sender: [email-masked]

John,

[email-masked] wrote:
> 
>>> OK, so let me see if I have this straight. You're claiming that
>>> something we write into a standard is going to change future spammer
>>> behavior in a good and predictable way? I'm afraid I just don't buy it.
> 
>> No, of course not.  It's going to change the way that MTAs are set up which
>> will make it harder for spammers to abuse.

John is making a nicely affirmative assertion.  Clear and to the point.

However some of us don't see it as obviously correct and, in fact, doubt it's 
true.

That creates a  need for a very clear and compelling explanation that a) it 
really is true, and b) it's impact will justify changing a long-standing core 
design feature of Internet mail operations.  One that will actually make some 
administration of email operations markedly more difficult.

As you know, far better than most, a belief in what will alter spammer's impact 
is rarely never correct.  And even when it is correct, it has never yet reduced 
the amount of global spam.

>> Well, of course.  The goal here is to specify something for the legit 
>> operators to follow that will narrow the range for abuse by bad guys.
> 
> No, that isn't the goal at all. The goal is to get a revision to a 
> specification published that is suitable for a move to draft. 
...
> This really isn't open for debate. 

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 30 Mar 2008 21:57:14 -0400
From: John C Klensin <[email-masked]>
To: [email-masked], John Levine <[email-masked]>
cc: [email-masked]
Subject: Re: Minor isn't.  It's a pardigm change
Sender: [email-masked]

Hmm.  We are about to have "one of those" moments in which Dave 
and I agree (mostly) with each other about an architectural 
principle...

--On Sunday, March 30, 2008 4:46 PM -0700 Dave Crocker 
<[email-masked]> wrote:

> John Levine wrote:
>> But since everyone's going to have to add AAAA records anyway
>> to move to IPv6, it seems to me this is the least painful
>> time to make them add MXes for their mail servers as well.

> Folks are missing a very basic point:
>
>     To run an email server, today, an existing host only needs
> to make the server software operational.  No other change is
> required.  For example, no coordination with DNS
> administration is required.
>
>     The "simple" algorithm change that permits only the use of
> an MX, for v6 email address queries changes that.
>
>     This is a fundamental change in the complexity of email
> operations.
>
>     In other words, the change moves the MX from being an
> administrative convenience to instead being a core
> requirement, ie, barrier to deployment.

I am surprised that Dave didn't mention a separate, but 
complementary point.  We've actually had a lot of experience 
with trying to use table-based services external to an 
application, and one major experience with the DNS in 
particular, to indicate whether or not a service is present. 
The experience has not been good, partially because people 
change services around and then simply forget to update DNS 
records (or host table services fields).  For those who do not 
remember, I recommend rereading the last paragraphs of Section 
2.2 and Section 5.2.12 of RFC 1123 and trying to remember or 
reconstruct the conditions that caused them.

Using the DNS to _discover_ where to find the preferred server 
for a particular service for a particular domain is a different 
matter from using the DNS to determine whether or not a 
particular server supports a particular service.  The former is 
an appropriate function of a directory service.  The latter 
mixes things up in ways that reduce the robustness of the 
overall environment.  That is at least one of the reasons I had 
trouble decoding Doug's note that started the parent of this 
thread -- the notions of discovering the presumed location of a 
service and of verifying the presence of that service seemed 
hopelessly muddled together, as they have seemed to be in some 
other parts of the thread.

Two possibly-important asides...

(1) I do not agree with Dave that MX records are simply an 
administrative convenience (nor do I read his comment as 
implying that the DNS more generally is just an administrative 
convenience).  I think they are part of the architecture, an 
architecture that clearly includes DNS use.  I do think there is 
a case to be made that using MXs to isolate the location of a 
mail server from the domain at which the mail address is located 
is an administrative convenience, even though it is, as others 
have pointed out, critical enough to important operational 
service models that identifying and dismissing MXs that way is, 
IMO, inappropriate.  However, while the requirement for relaying 
has become less as we have evolved toward a fully-connected 
Internet, if MXs are relegated to "administrative convenience", 
we would, IMO, need to restore the original RFC 821 model of 
forward and reverse paths.   Put differently, one either has MX 
records or one has to have "came from" and "route through" 
functions in the mail transport syntax and model.  Getting rid 
of those functions turned MX from what might otherwise have been 
an administrative convenience into a fundamental part of the 
architecture.

But that modeling issue doesn't have anything to do with whether 
getting rid of implicit MXs, or restricting them to IPv4, is a 
good idea.  I do see a reason to do that in principle, but I 
don't think it holds up in practice: to the extent that 
"transport over IPv6" is a different service than "transport 
over IPv4", then one might reasonably have SMTP-related reasons 
for preferring one of those services over the other that were 
independent of the considerations of RFC 3484.   That might 
suggest DNS setups like

   foo.bar.baz.  IN MX 10 v4host.smtp.example.com.
                 IN MX 5  v6host.smtp.example.com.
   v4host.smtp.example.com IN A 10.0.0.6
   v6host.smtp.example.com IN AAAA 2001:DB8::6
   ; smtp.example.com  IN AAAA 2001:DB8::6
   ;                   IN A 10.0.0.6

and, all other things being equal, avoiding the MX default to 
help force people to think about those issues.  But, as others 
have said at more length, it appears to me that the horse is 
long out of the barn.

(2) One of the reasons I felt that we should have done "TCPng" 
when we did IPv6 is that I believe, in retrospect, that 
TCP/IP[v4] seriously erred in letting "timeout" or "connection 
reset" be our only real ways to report "service not supported". 
I believe that a server should be able (and required) to return 
a definitive "no service on that port" message at the TCP level 
and perhaps that there should be a definitive way to probe for 
the presence of a service other than opening a TCP connection. 
I believe that having that type of functionality would be an 
effective way to deal with many of the issues that we are now 
trying to push onto the DNS even though it might raise some 
complex issues about negative response caching and would make 
operations like port scanning more efficient.

But that horse is not only out of the barn, it has long since 
disappeared over the horizon.

   john

Date: Sun, 30 Mar 2008 21:20:42 -0400 (EDT)
From: John R Levine <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked]
Subject: Re: not delivering, and History of fallback to A
Cleverness: None detected
Sender: [email-masked]

> I completely fail to see how the availability or nonavailability of DNS
> fallback behavior will lead to increased spam abuse. As I pointed out
> previously, if spammers percieve an advantage to sending directly to
> hosts named in A/AAA records they are going to do so no matter what. By
> the same token, if they don't perceive an advantage they won't do it.

I see that I have been completely unable to explain myself.  I give up.

R's,
John

From: [email-masked]
Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Sun, 30 Mar 2008 18:00:23 -0700 (PDT)
Subject: Re: not delivering, and History of fallback to A
To: John R Levine <[email-masked]>
Sender: [email-masked]

> > OK, so let me see if I have this straight. You're claiming that something we
> > write into a standard is going to change future spammer behavior in a good
> > and predictable way? I'm afraid I just don't buy it.

> No, of course not.  It's going to change the way that MTAs are set up
> which will make it harder for spammers to abuse.

I completely fail to see how the availability or nonavailability of DNS
fallback behavior will lead to increased spam abuse. As I pointed out
previously, if spammers percieve an advantage to sending directly to
hosts named in A/AAA records they are going to do so no matter what. By
the same token, if they don't perceive an advantage they won't do it.

> > I run several secondary MXes here and they are directly targetted by spammers
> > all the time even when the primary is up and the standards clearly say that
> > you shouldn't be sending mail to the secondary.

> Right.  That's one of the reasons I've been telling people for years that
> unless your mail setup is on a really flaky connection, secondary MXes
> create more problems than they solve, since they invariably create
> blowback problems.  Back in the day, when the net was slow and flaky,
> secondaries were useful.  These days, any BCP that recommended them would
> just be wrong.

This reallly isn't relevant to the matter at hand, but whether or not
secondaries create problems depends critically on their ability to do filtering
and address validation. If their filtering is decent and  they validate
recipient addresses they can be very useful indeed, even for relatively
reliable connections.

> > The bottom line is that the spammers are gonna do whatever they want
> > irrespective of what we specify.

> Well, of course.  The goal here is to specify something for the legit
> operators to follow that will narrow the range for abuse by bad guys.

No, that isn't the goal at all. The goal is to get a revision to a
specification published that is suitable for a move to draft. In the process we
certainly don't want to open any new holes if we can help it, but it is NOT a
goal of this exercise to try and tighten things down. As others have stated
repeatedly, if you want to do that you need to stop objecting and start writing
additional specifications and building a consensus behind them.

This really isn't open for debate. The rules for this effort were laid out very
clearly by Tony and John, as was the DRUMS charter before that. If you wanted
to object the time for doing that is long since past.

> > The goal here is to try and come up with an operational policy which, when
> > implemented by legitimate operators, will result in the greatest amount of
> > interoperability in the medium to long term.

> I completely agree.  But how does a design that maximizes the number of
> false MTAs that can't easily be distinguished from temporarily broken MTAs
> advance that goal?

It does so by not preventing a decades-old practice from continuing, one that
has yet to have been shown to cause significant harm. (And I will add that if
the current practice can be shown to cause harm that would call for a change to
the current fallback policy for A records and that in turn would have to be
dealt with in a separate document.)

> >> sendmail that report back every two hours to say that your message hasn't
> >> bounced yet.

> > Um, well, maybe the people you talk to don't, but we spend a
> > not-inconsiderable amount of time trying to convince some fairly large
> > players that retry intervals of _five_ _minutes_ or less are
> > inappropriate for INternet-directed traffic. And we don't always
> > succeed, more's the pity.

> That's not what I said -- there are plenty of MTAs with ridiculous retry
> policies, but it's been a long time since I've seen one that sent a faux
> bounce saying "it's been two hours and I'm still trying."  Those are what
> made people complain.

And that's exactly the sort of policy I was talking about: Five minutes before
complaining about unable to deliver.

> > Actually, I'm not entirely sure what has changed, but right now the
> > majority of the bounces I see personally are legitimate.

> You're extremely lucky.  I see as many as 400,000 bogus bounces a day on
> my tiny network. This is a no kidding serious problem.  I know people
> who've had their networks knocked off the air by bounce storms.

> > IMO the language in 2821bis is not ambiguous. The language in 2821 is. So if
> > you're saying that the current language in 2821bis, which says to allow
> > AAAA fallback, is OK, then I'm also good with that.

> Well, then, we'll have to try to fix it, since for all the reasons I've
> laid out, AAAA fallback will make the current situation worse.  Since it
> looks like people are bound and determined to do that, I guess millions of
> MX . records will have to be a very poor second best.

I'm afraid you haven't even come close to making the case yet as far as I'm
concerned.

				Ned

Date: Sun, 30 Mar 2008 18:13:38 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John R Levine <[email-masked]>
CC: [email-masked]
Subject: Re: Minor is.  It's not a pardigm change
Sender: [email-masked]

John R Levine wrote:
> Quite true.  If the goal is to maximize the total amount of mail 
> delivered to mail servers, legit mail, spam, blowback, phishes, 
> whatever, then fallback to AAAA is definitely the right thing to do.  
> But is that really what we're trying to accomplish?

I thought the goal was to add v6 support to Internet mail.

A rather simple and straightforward task that the current draft satisfies 
reasonably, modulo the usual wordsmith-hacking.

It appears that there has been a spontaneous desire for some spiffy new goals to 
be overloaded onto that one, long-standing *requirement*.

This amounts to retro-active re-design on-the-fly.

With a predictable range of unpredicted implications.

For a spec that is intended merely to be moving from Proposed to Draft.

Bad idea.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 30 Mar 2008 20:38:21 -0400 (EDT)
From: John R Levine <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: [email-masked]
Subject: Re: Minor is.  It's not a pardigm change
Cleverness: None detected
Sender: [email-masked]

>   To run an email server, today, an existing host only needs to make the 
> server software operational.  No other change is required.  For example, no 
> coordination with DNS administration is required.

I suppose that's still true in theory, but when's the last time you saw a 
non-spam message sent to someone@[12.34.56.78] or saw an MTA deliberately 
configured to accept mail to dotted quad addresses? Every useful mail 
server has at least an A record.

>   In other words, the change moves the MX from being an administrative 
> convenience to instead being a core requirement, ie, barrier to deployment.

Quite true.  If the goal is to maximize the total amount of mail delivered 
to mail servers, legit mail, spam, blowback, phishes, whatever, then 
fallback to AAAA is definitely the right thing to do.  But is that really 
what we're trying to accomplish?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: Minor isn't.  It's a pardigm change
Date:  Mon, 31 Mar 2008 02:28:26 +0200
Organization:  <http://purl.net/xyzzy>
Lines: 23
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Dave Crocker wrote:

> the change moves the MX from being an administrative=20
> convenience to instead being a core requirement, ie,
> barrier to deployment.

As far as the wording "implicit MX" means something the
"MX" concept is not only an administrative convenvenience,
but fundamental.  If a paradigm changed it was in RFC 974.=20

The "administrative convenience" was to make this not
explicitly, when it is in a way redundant for a single
IPv4 host acting as its own "implicit" MX.

For the transition to IPv6 many hosts limited to IPvX
will have to arrange for an explicit MX, handling any
non-IPvX mail for them. =20

How many hosts will have both A and AAAA for the time
of the transition, and consider adding an explicit MX
as deployment barrier ?

 Frank

Date: Sun, 30 Mar 2008 16:46:24 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John Levine <[email-masked]>
CC: [email-masked]
Subject: Minor isn't.  It's a pardigm change
Sender: [email-masked]

John Levine wrote:
> But since everyone's going to have to add AAAA records anyway to move
> to IPv6, it seems to me this is the least painful time to make them add
> MXes for their mail servers as well.

Folks are missing a very basic point:

    To run an email server, today, an existing host only needs to make the 
server software operational.  No other change is required.  For example, no 
coordination with DNS administration is required.

    The "simple" algorithm change that permits only the use of an MX, for v6 
email address queries changes that.

    This is a fundamental change in the complexity of email operations.

    In other words, the change moves the MX from being an administrative 
convenience to instead being a core requirement, ie, barrier to deployment.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: 30 Mar 2008 23:05:05 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: History of fallback to A
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>> I am not arguing that the implicit MX should go for IPv4(*). I am just
>> arguing that it shouldn't appear for IPv6.
>
>Ah, okay.  Thank you for the clarification (and I probably should have
>understood originally that's what you meant).

In case there's any uncertainty, that's also what I'm arguing.  The
time to deprecate fallback to A would have been about 1988, not today.

But since everyone's going to have to add AAAA records anyway to move
to IPv6, it seems to me this is the least painful time to make them add
MXes for their mail servers as well.

R's,
John

To: [email-masked]
Subject: Re: History of fallback to A
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 30 Mar 2008 14:45:21 -0700
Sender: [email-masked]

Alex van den Bogaerdt <[email-masked]> writes:
> On Sun, Mar 30, 2008 at 10:51:25AM -0700, Russ Allbery wrote:

>> In general, you should count on human laziness.  If mail works without
>> adding an MX record, people aren't going to add one.  If nothing breaks
>> when the MX record is missing, no one will notice it is missing.

> Then the opposite also holds. As soon as people find out mail doesn't
> work as soon as they are on IPv6 only, they will add an MX record.
>
> I am not arguing that the implicit MX should go for IPv4(*). I am just
> arguing that it shouldn't appear for IPv6.

Ah, okay.  Thank you for the clarification (and I probably should have
understood originally that's what you meant).

> My gut feeling: In IPv6 there will be a lot more hosts, and a
> significantly smaller percentage of those hosts will receive mail.
> Saving in DNS lookups will outweight the inconvenience of publishing MX
> records for those "few" hosts which require it and wouldn't with an
> implicit MX.

Certainly if I were designing DNS from scratch today, it would make sense
to not assume mail services without an MX record.

The issues around upgrading from IPv4 to IPv6 and what can and cannot be
changed in that process is way outside my area of expertise, and I'm happy
to leave it to others to decide whether a fallback to AAAA is appropriate.
I only have strong opinions about the existing A record fallback, which I
don't think anyone wants to drop anyway.  :)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sun, 30 Mar 2008 17:15:54 -0400 (EDT)
From: John R Levine <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked]
Subject: Re: not delivering, and History of fallback to A
Cleverness: None detected
Sender: [email-masked]

> OK, so let me see if I have this straight. You're claiming that something we
> write into a standard is going to change future spammer behavior in a good 
> and predictable way? I'm afraid I just don't buy it.

No, of course not.  It's going to change the way that MTAs are set up 
which will make it harder for spammers to abuse.

> I run several secondary MXes here and they are directly targetted by spammers
> all the time even when the primary is up and the standards clearly say that 
> you shouldn't be sending mail to the secondary.

Right.  That's one of the reasons I've been telling people for years that 
unless your mail setup is on a really flaky connection, secondary MXes 
create more problems than they solve, since they invariably create 
blowback problems.  Back in the day, when the net was slow and flaky, 
secondaries were useful.  These days, any BCP that recommended them would 
just be wrong.

> The bottom line is that the spammers are gonna do whatever they want
> irrespective of what we specify.

Well, of course.  The goal here is to specify something for the legit 
operators to follow that will narrow the range for abuse by bad guys.

> The goal here is to try and come up with an operational policy which, when
> implemented by legitimate operators, will result in the greatest amount of
> interoperability in the medium to long term.

I completely agree.  But how does a design that maximizes the number of 
false MTAs that can't easily be distinguished from temporarily broken MTAs 
advance that goal?

>> sendmail that report back every two hours to say that your message hasn't
>> bounced yet.

> Um, well, maybe the people you talk to don't, but we spend a 
> not-inconsiderable amount of time trying to convince some fairly large 
> players that retry intervals of _five_ _minutes_ or less are 
> inappropriate for INternet-directed traffic. And we don't always 
> succeed, more's the pity.

That's not what I said -- there are plenty of MTAs with ridiculous retry 
policies, but it's been a long time since I've seen one that sent a faux 
bounce saying "it's been two hours and I'm still trying."  Those are what 
made people complain.

> Actually, I'm not entirely sure what has changed, but right now the 
> majority of the bounces I see personally are legitimate.

You're extremely lucky.  I see as many as 400,000 bogus bounces a day on 
my tiny network. This is a no kidding serious problem.  I know people 
who've had their networks knocked off the air by bounce storms.

> IMO the language in 2821bis is not ambiguous. The language in 2821 is. So if
> you're saying that the current language in 2821bis, which says to allow
> AAAA fallback, is OK, then I'm also good with that.

Well, then, we'll have to try to fix it, since for all the reasons I've 
laid out, AAAA fallback will make the current situation worse.  Since it 
looks like people are bound and determined to do that, I guess millions of 
MX . records will have to be a very poor second best.

R's,
John

From: [email-masked]
Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Sun, 30 Mar 2008 13:09:55 -0700 (PDT)
Subject: Re: not delivering, and History of fallback to A
To: John R Levine <[email-masked]>
Sender: [email-masked]

> >> [... that] doesn't seem like much of an argument compared to the
> >> advantages laid out in my last message of having hosts default to not
> >> being mail servers.

> > I assume you're referring to the problem of mail sitting in the queues waitinfg
> > to be delivered to a system that's never going to accept it. I'm afraid I don't
> > buy your reasoning on this one either.

> > 10 years or so ago this used to be a real issue - we used to get customer
> > complaints  all the time about stuck mail to some router, or to lab PCs, or
> > whatever.

> The mail sitting in the queues isn't the problem, it's the load on all of
> the hosts that the bogus mail is hammering on.  Remember my non-mail host
> with the 30,000 spams per day.  Those aren't just attempts, by the way, I
> set up an MTA and collect 30,000 actual spams.  I tried soft failing and
> the load was somewhat more.

OK, so let me see if I have this straight. You're claiming that something we
write into a standard is going to change future spammer behavior in a good and
predictable way? I'm afraid I just don't buy it.

I run several secondary MXes here and they are directly targetted by spammers
all the time even when the primary is up and the standards clearly say that you
shouldn't be sending mail to the secondary.

The bottom line is that the spammers are gonna do whatever they want
irrespective of what we specify. If they perceive some advantage (and it
doesn't have to be a real one) to attempting to send mail to stuff that has a
name and address in the DNS but no "I accept mail" flag then that's what's they
will do.

The goal here is to try and come up with an operational policy which, when
implemented by legitimate operators, will result in the greatest amount of
interoperability in the medium to long term. And yes, a secondary goal should
be not to create situations that spammers can exploit. But AFAICT nothing we
say or do is going to have any effect on what spammers do. And that's even
assuming we can predict the shape of the antispam problem in the medium to long
term - which I very much doubt we can.

> The lack of complaints is probably because we no longer run versions of
> sendmail that report back every two hours to say that your message hasn't
> bounced yet.

Um, well, maybe the people you talk to don't, but we spend a not-inconsiderable
amount of time trying to convince some fairly large players that retry
intervals of _five_ _minutes_ or less are inappropriate for INternet-directed
traffic. And we don't always succeed, more's the pity.

  Most bounces these days are spam blowback, which tells me
> that if the user doesn't see a failure report really soon while he still
> remembers sending the message, it'll be lost in the noise.

Actually, I'm not entirely sure what has changed, but right now the majority of
the bounces I see personally are legitimate. This is in marked contrast to the
situation a few years ago where there was a period during which my getting tens
of thousands of bogus bounces in a single day wasn't at all unusual. It may not
last, but right now I'm enjoying it.

> Speaking of lost in the noise, one thing that's really different from 25
> years ago is that reliable mail depends as much on not delivering spam as
> it depends on delivering the real mail.  I don't know how many of the
> other people in the conversation see the feedback reports when people at
> AOL, Hotmail, and other large ISPs hit the spam button on your users'
> mail, but if you can arrange to see them, do so, because it's a real eye
> opener.

Unfortunately it is difficult for small operators to arrange for such reports
because of - you guessed it - DNS administrative issues. I've tried signing up
for them, but the ISPs I've used have historically had trouble keeping my PTR
records consistent on and up to date, so I always fail the
forward-reverse-forward check and end up getting denied.

I'm with a new ISP now so I suppose I should try again and see if I can't get
this working.

> A message that is hidden in a mailbox full of spam is lost as
> thoroughly as one that was never delivered.  I cannot tell you how many
> spam reports I get for utterly unobjectionable mail that was clearly
> scooped up with a hundred other messages and reported en masse.  I've had
> to tell people on my church's mailing list that no, I can't keep putting
> you back on the list if you keep reporting it as spam.  So with that in
> mind, even if something makes it a little harder for the least competent
> to set up their mail servers, that's OK if will tend to improve mail
> reliability overall.

Unfortunately the incompetent are often amazingly clever at working around such
restrictions (in fact they often seem much more willing to invest huge amounts
of time and effort in working around some problem in a way that causes huge
collateral damage when it would be far easier just to solve the problem). The
competent but overly restricted are usually the ones who end up suffering.

> With respect to DNS setup, I spend a certain amount of time helping people
> fix their SPF records.  (Not because SPF is a good idea, but because it's
> hard to get mail into Hotmail if you don't.)  I see a fair number of DNS
> management control panels, and I don't recall seeing any that made MXes
> hard to set up.  Maybe they exist, but I'd be surprised if they were any
> more common than any other random DNS breakage.

Which itself is incredibly common. You're not exactly convincing me here...

> > So I believe the correct course going forward is to have the same fallback
> > rules for AAAA that we do for A. Having said all this, it certainly isn't a
> > showstopper for me if this goes the other way

> I can live with the current ambiguous language, particularly if we agree
> that we need to have some way to declare in the DNS that a name accepts no
> mail, be it no default to AAAA, MX . or whatever.

IMO the language in 2821bis is not ambiguous. The language in 2821 is. So if
you're saying that the current language in 2821bis, which says to allow
AAAA fallback, is OK, then I'm also good with that.

If, OTOH, you are advocating switching back to what 2821 said, then you are in
effect saying that it is OK for 2821bis to be a proposed standard since that's
what the rules clearly say it will have to be. If you are in fact OK with then
then there's really nothing more to be said.

				Ned

Date: Sun, 30 Mar 2008 21:19:42 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: History of fallback to A
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Mar 30, 2008 at 10:51:25AM -0700, Russ Allbery wrote:
> 
> Alex van den Bogaerdt <[email-masked]> writes:
> 
> > Then: people didn't know MX records and thus didn't use them. Or maybe
> > they did already know about MX records but did not yet support them.
> > Some fallback mechanism was necessary to bridge the gap between pre-MX
> > and post-MX time, or else MX didn't stand a chance.
> >
> > Now: people do know MX records and do use them, except for a couple
> > of spammers maybe. There is no need anymore to design a fallback.
> 
> I think you should collect some data on this before blithely making such
> assertions.  All my available anecdotes contradict your assumption so
> strongly that I find it very dubious.
> 
> 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.

OK, let me rephrase.

Back then, almost a catch-22 situation would exist without the fall back.

Nowadays, using MX records or not is a choice. People know they exist,
how they do their stuff.  Should a fall back not exist, MX records can
be added quickly without much effort.  Not publishing an MX record is
a choice of using the implicit MX -or- the host does not receive mail.

> In general, you should count on human laziness.  If mail works without
> adding an MX record, people aren't going to add one.  If nothing breaks
> when the MX record is missing, no one will notice it is missing.

Then the opposite also holds. As soon as people find out mail doesn't
work as soon as they are on IPv6 only, they will add an MX record.

I am not arguing that the implicit MX should go for IPv4(*). I am just
arguing that it shouldn't appear for IPv6.

My gut feeling: In IPv6 there will be a lot more hosts, and a
significantly smaller percentage of those hosts will receive mail.
Saving in DNS lookups will outweight the inconvenience of publishing
MX records for those "few" hosts which require it and wouldn't with
an implicit MX.

Alex

(*)  I know, IPv4 isn't its official name.

To: [email-masked]
Subject: Re: History of fallback to A
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sun, 30 Mar 2008 10:51:25 -0700
Sender: [email-masked]

Alex van den Bogaerdt <[email-masked]> writes:

> Then: people didn't know MX records and thus didn't use them. Or maybe
> they did already know about MX records but did not yet support them.
> Some fallback mechanism was necessary to bridge the gap between pre-MX
> and post-MX time, or else MX didn't stand a chance.
>
> Now: people do know MX records and do use them, except for a couple
> of spammers maybe. There is no need anymore to design a fallback.

I think you should collect some data on this before blithely making such
assertions.  All my available anecdotes contradict your assumption so
strongly that I find it very dubious.

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.

In general, you should count on human laziness.  If mail works without
adding an MX record, people aren't going to add one.  If nothing breaks
when the MX record is missing, no one will notice it is missing.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sun, 30 Mar 2008 12:39:41 -0400 (EDT)
From: John R Levine <[email-masked]>
To: Ned Freed <[email-masked]>
cc: [email-masked]
Subject: Re: not delivering, and History of fallback to A
Cleverness: None detected
Sender: [email-masked]

> This also ignores the issue of what is the right thing to do in the
> transitional case where there's no MX record but a mixture of A and AAAA
> records. Only falling back to the A record subset seems, well, wrong.

Well, gee, that's what happens right now.  The question is where we go 
from here.

>> [... that] doesn't seem like much of an argument compared to the 
>> advantages laid out in my last message of having hosts default to not 
>> being mail servers.

> I assume you're referring to the problem of mail sitting in the queues waitinfg
> to be delivered to a system that's never going to accept it. I'm afraid I don't
> buy your reasoning on this one either.
>
> 10 years or so ago this used to be a real issue - we used to get customer
> complaints  all the time about stuck mail to some router, or to lab PCs, or
> whatever.

The mail sitting in the queues isn't the problem, it's the load on all of 
the hosts that the bogus mail is hammering on.  Remember my non-mail host 
with the 30,000 spams per day.  Those aren't just attempts, by the way, I 
set up an MTA and collect 30,000 actual spams.  I tried soft failing and 
the load was somewhat more.

The lack of complaints is probably because we no longer run versions of 
sendmail that report back every two hours to say that your message hasn't 
bounced yet.  Most bounces these days are spam blowback, which tells me 
that if the user doesn't see a failure report really soon while he still 
remembers sending the message, it'll be lost in the noise.

Speaking of lost in the noise, one thing that's really different from 25 
years ago is that reliable mail depends as much on not delivering spam as 
it depends on delivering the real mail.  I don't know how many of the 
other people in the conversation see the feedback reports when people at 
AOL, Hotmail, and other large ISPs hit the spam button on your users' 
mail, but if you can arrange to see them, do so, because it's a real eye 
opener.  A message that is hidden in a mailbox full of spam is lost as 
thoroughly as one that was never delivered.  I cannot tell you how many 
spam reports I get for utterly unobjectionable mail that was clearly 
scooped up with a hundred other messages and reported en masse.  I've had 
to tell people on my church's mailing list that no, I can't keep putting 
you back on the list if you keep reporting it as spam.  So with that in 
mind, even if something makes it a little harder for the least competent 
to set up their mail servers, that's OK if will tend to improve mail 
reliability overall.

With respect to DNS setup, I spend a certain amount of time helping people 
fix their SPF records.  (Not because SPF is a good idea, but because it's 
hard to get mail into Hotmail if you don't.)  I see a fair number of DNS 
management control panels, and I don't recall seeing any that made MXes 
hard to set up.  Maybe they exist, but I'd be surprised if they were any 
more common than any other random DNS breakage.

R's,
John

PS:

> So I believe the correct course going forward is to have the same fallback
> rules for AAAA that we do for A. Having said all this, it certainly isn't a
> showstopper for me if this goes the other way

I can live with the current ambiguous language, particularly if we agree 
that we need to have some way to declare in the DNS that a name accepts no 
mail, be it no default to AAAA, MX . or whatever.

Date: Sun, 30 Mar 2008 18:24:57 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: History of fallback to A
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sun, Mar 30, 2008 at 07:42:39AM -0700, [email-masked] wrote:

> > 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.
> 
> Yes, that's more or less the case.

Then: people didn't know MX records and thus didn't use them. Or maybe
they did already know about MX records but did not yet support them.
Some fallback mechanism was necessary to bridge the gap between pre-MX
and post-MX time, or else MX didn't stand a chance.

Now: people do know MX records and do use them, except for a couple
of spammers maybe. There is no need anymore to design a fallback.

> This also ignores the issue of what is the right thing to do in the
> transitional case where there's no MX record but a mixture of A and AAAA
> records. Only falling back to the A record subset seems, well, wrong.

Why?

You present a gut feeling, with no more and no less value than the
opposite gut feeling.

One could also argue that if such a mix is present, this indicates
mail delivery is not possible for that name.

Here's why: the fallback mechanism was designed for receivers not
yet aware of MX records. If receivers know about AAAA records, they
most certainly will also be aware of MX records.

> So I believe the correct course going forward is to have the same fallback
> rules for AAAA that we do for A. Having said all this, it certainly isn't a
> showstopper for me if this goes the other way, if for no other reason than the
> fact that we'll have plenty of time to fix this if whatever decision we make
> turns out to be wrong. The only outcome that is a showstopper for me is for
> this issue to remain unresolved.

I believe adding those fallback rules is wrong.  Apart from the two
arguments I presented above, I have more:

Adding a fallback mechanism for 2^32 minus a bit possible addresses,
in a time when the number of actually used addresses was very low, is
one thing.

Adding the same fallback now, for many more possible addresses, has
the potential of ruining the net.

Last but not least: not having a fallback for AAAA is not a change.
Having a fallback for AAAA is a change.

Date: 30 Mar 2008 16:00:46 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: Defaulting to no mail
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>> Getting rid of the AAAA fallback flips the default to be in line with
>> reality 
>
>Flipping any 20-year default for an global installed base should be
>pursued with an assumption that it won't work, not that it will.

Sure, but what's the installed base?  There's a presumably large set
of hosts accepting mail via A records.  There's no hosts accepting
mail via AAAA records.

Nobody's suggesting that we get rid of default to A.  That would have
had to happen in 1988.

R's,
John

From: [email-masked]
Cc: [email-masked]
Date: Sun, 30 Mar 2008 07:42:39 -0700 (PDT)
Subject: Re: History of fallback to A
To: John Levine <[email-masked]>
Sender: [email-masked]

> I wasn't there, so I hope people who were will correct me if I'm
> wrong.

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

No, spme people implemented it, but the problem was there were too many other
people who didn't bother setting up WKS records. Doing this check caused way
more problems than it solved.

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

Yes, that's more or less the case.

> Now fast forward 20 years.  How many domains are there on the Internet
> that accept mail from the outside world with only AAAA records?

I would assume none, but this is completely beside the point. We're trying to
design something here that is interoperable and which will last through to a
point where it is feasible to run a IPv6-only host. We have no way of knowing
for sure what that world is going to look like so we need to be very careful
when making fundamental architectural changes.

This also ignores the issue of what is the right thing to do in the
transitional case where there's no MX record but a mixture of A and AAAA
records. Only falling back to the A record subset seems, well, wrong.

> Considering that most of the net still can't connect to IPv6 hosts,
> it's rather unlikely that there are any at all other than perhaps a
> few test setups.  The issues of installed base that mattered in 1986
> just don't exist now.

There are in fact plenty of A-record-only mail-receiving hosts out there, but
let's ignore that for the moment. The gap in your reasoning is that you're
assuming that just because the issues that led to this decision being made in
the past are no longer there no other issues have arisen to take their place.

> The transition to v6 is going to involve, among other things,
> renumbering nets from v4 into v6 address space, and then adding AAAA
> records for all the hosts that have A records.  Some of those hosts
> are mail servers.  Is it really an unreasonable burden to ask people
> who are redoing their DNS anyway to add MX records for the small
> number of mail hosts that don't already have them?

The answer is we don't know. What we do know is that it is currently not
uncommon for there to be problems setting up MXes. Mayvbe Keith is right and
this will change going forward - maybe, as IPv6 deploys and the need to
configure AAAA records, the widespread ability to set up MX and SRV will also
appear. (And wouldn't it be great if there was finally a way to get PTR records
set properly?) 

But I've seen way too many examples of widespread cluelessness in various
service oferrings from people who really should know better to want to bet on
this being what happens.

> Maybe somewhere
> there is DNS management software so wierdly broken that it can install
> AAAA records but not MX, but even if there is, that doesn't seem like
> much of an argument compared to the advantages laid out in my last
> message of having hosts default to not being mail servers.

I assume you're referring to the problem of mail sitting in the queues waitinfg
to be delivered to a system that's never going to accept it. I'm afraid I don't
buy your reasoning on this one either.

10 years or so ago this used to be a real issue - we used to get customer
complaints  all the time about stuck mail to some router, or to lab PCs, or
whatever. Thinking back I would say this sort of thing was responsible for a
considerable number of support calls. (And interestly, the option of using an
MX record to redirect traffic to a stub server was rarely if ever selected as a
solution, often due to issue getting the necessary  records installed.)

Fast forward to today, and I cannot recall a single such complaint in the last
couple of years. And this is in spite what is surely a huge drop in the overall
percentage of hosts able to receive mail.

Now, I'l be the first to admit I don't know why this has happened. If I had to
guess I'd say it's due to a bunch of different factors: Decreased use of host
names in email addresses as opposed to more general domains (e.g.,
[email-masked] vs. [email-masked]), increased centralization of
email services bringing with it more consistent configuration, people caring
less about a few stuck messages in a queue full of blow-back spam, increased
used of wildcard MXes to redirect all mail for a given domain to a single
server, and spammers, faced with widespread use of reverse address checks,
abandoning the use of such addreses. But regardless of the reason the fact
remains that this just isn't the support issue it used to be.

Now, of course all this is anecdotal evidence at best, with all that implies. 
I certainly don't have any statistically significant evidence here. But
apparently neither does anybody else (if they do they aren't talking about it),
so anecdotal stuff is likely the best we're going to get. And the bottom line,
for me at least, is that my own experience is that setting up MX records can be
problematic and A record fallback isn't a major source of operational
difficulty currently. Additionally, we have specifications (informational ones
to be sure, but specifications nonetheless) that say the fallback should be
done in the AAAA case, so this is how current implementations are likely to
work.

So I believe the correct course going forward is to have the same fallback
rules for AAAA that we do for A. Having said all this, it certainly isn't a
showstopper for me if this goes the other way, if for no other reason than the
fact that we'll have plenty of time to fix this if whatever decision we make
turns out to be wrong. The only outcome that is a showstopper for me is for
this issue to remain unresolved.

				Ned

Date: Sun, 30 Mar 2008 08:14:35 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: John Levine <[email-masked]>
CC: [email-masked]
Subject: Re: Defaulting to no mail
Sender: [email-masked]

John Levine wrote:
> Under the current setup, any domain that has an A record is presumed
> to be a mail domain, and if it's not, there's no good way to advertise
> that fact.  

> Getting rid of the AAAA fallback flips the default to be in line with
> reality 

Flipping any 20-year default for an global installed base should be pursued with 
an assumption that it won't work, not that it will.  This puts the burden of 
making the case on those lobbying for the change.  And it should make the 
barrier for adoption be pretty high.  In other words, the case needs to be 
compelling, not merely appealing.

That is, the first step in a discussion like this is to recognize that the 
change being discussed in a very big architectural deal, not just minor 
algorithm tuning.

Your assertion about that the change would "flip[] the default to be in line 
with reality" is a helpful example of seeking to satisfy that requirement, since 
it highlights core assumptions and permits debating them.

For example, changing a default alters the strategic orientation of a service. 
An example impact is that it can substantially alter the barrier to entry.  So, 
for example, the proposed change would require a very different degree of 
broad-based DNS administrative capability than is often available, as Ned observed.

> As other people have pointed out, a no-mail default is far more robust
> than the current default, since a fair number of non-mail hosts turn
> out to be running some sort of default SMTP server which will swallow
> and lose mail. 

Here, again, is a helpful assertion, since it is concrete and pragmatic.  But is 
it correct?

Is this a real and serious problem that needs correcting? I had not heard about 
this as a pressing operational problem, but I also don't claim to be deeply 
connected into the SMTP operations community.  Others on this list are.

> Or even if they aren't running an SMTP server, it can
> take a week for the message to time out and bounce.  It'd be much
> better for such messages to fail immediately so the sender will notice
> and can do something about it.

This is an entirely different change to the service model, and one with some 
potentially very large impact, such as dramatically increasing the rate of 
delivery failure.  In effect, it could move email more towards instant 
messaging, in being a model of instantaneous success/failure, rather than being 
the infrastructure-persistence model we now have.

That might sound appealing and it might not.  In all likelihood it does have a 
market that would benefit from it.

One question is to impose this change on the entire email community, rather than 
add it as a option.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 30 Mar 2008 16:10:10 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Defaulting to no mail
Sender: [email-masked]

John Levine writes:
> As other people have pointed out, a no-mail default is far more robust 
> than the current default, since a fair number of non-mail hosts turn 
> out to be running some sort of default SMTP server which will swallow 
> and lose mail. Or even if they aren't running an SMTP server, it can 
> take a week for the message to time out and bounce. It'd be much 
> better for such messages to fail immediately so the sender will 
> notice and can do something about it.

There is another argument: A fair amount of software constructs email 
addresses, most notably

     Sender: something@hostname

and

    MAIL FROM:<something@hostname>

The best I can say for these addresses is that they're syntactically 
valid. It would be a great joy to me if all the muckware would stop 
assuming that blah@hostname is a deliverable email address.

Arnt

Date: 30 Mar 2008 03:51:44 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: History of fallback to A
Organization: 
Sender: [email-masked]

I wasn't there, so I hope people who were will correct me if I'm
wrong.

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.

Now fast forward 20 years.  How many domains are there on the Internet
that accept mail from the outside world with only AAAA records?
Considering that most of the net still can't connect to IPv6 hosts,
it's rather unlikely that there are any at all other than perhaps a
few test setups.  The issues of installed base that mattered in 1986
just don't exist now.

The transition to v6 is going to involve, among other things,
renumbering nets from v4 into v6 address space, and then adding AAAA
records for all the hosts that have A records.  Some of those hosts
are mail servers.  Is it really an unreasonable burden to ask people
who are redoing their DNS anyway to add MX records for the small
number of mail hosts that don't already have them?  Maybe somewhere
there is DNS management software so wierdly broken that it can install
AAAA records but not MX, but even if there is, that doesn't seem like
much of an argument compared to the advantages laid out in my last
message of having hosts default to not being mail servers.

R's,
John

Date: 30 Mar 2008 01:43:07 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Defaulting to no mail
Summary:
Expires:
Followup-To:
Distribution: 
Organization: 
Keywords: 
Cc:
Cleverness: some
Sender: [email-masked]

[ redirected from the main IETF list ]

Ted Ts'o asked:
>But please indulge me --- exactly what is the benefit of deprecating
>the "A" fallback, and/or not doing a lookup on the AAAA record if the
>MX record doesn't exist?

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

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

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

As other people have pointed out, a no-mail default is far more robust
than the current default, since a fair number of non-mail hosts turn
out to be running some sort of default SMTP server which will swallow
and lose mail.  Or even if they aren't running an SMTP server, it can
take a week for the message to time out and bounce.  It'd be much
better for such messages to fail immediately so the sender will notice
and can do something about it.

R's,
John

From: Mark Martinec <[email-masked]>
Organization: Jozef Stefan Institute
To: [email-masked]
Subject: Re: Implicit MX and A RRs (on CNAME again)
Date: Fri, 28 Mar 2008 23:39:16 +0100
Sender: [email-masked]

> Quoting the text from rfc2821bis-09, Section 5.1:
>
>    "The lookup first attempts to locate an MX record associated with the
>     name.  If a CNAME record is found instead, the resulting name is
>     processed as if it were the initial name.  If no MX records are
>     found, but an address RR ... is found, the address RR is treated ...

Sorry for distraction, I know this has been closed previously.
Reading the statement on CNAME again, lets me believe that
it could still be misunderstood if one really wants to.
I'd propose the statement to start with the same wording
as the next statement on RR, i.e.

change from:
  If a CNAME record is found instead,

to:
  If no MX records are found, but a CNAME record is found instead,

Mark

From: [email-masked]
Cc: Bill Manning <[email-masked]>, John Leslie <[email-masked]>, [email-masked]
Date: Thu, 27 Mar 2008 22:33:49 -0700 (PDT)
Subject: Re: How to mark domains that do / do not wish to receive email
To: Mark Andrews <[email-masked]>
Sender: [email-masked]

> > 	turning off smtp service to a domain == NOT an email domain.
> > 	forcing SMTP to require DNS lookups indicates that any one
> > 	who can hijack the DNS data can redirect your DNS lookups
> > 	to someplace that does SMTP w/o your permission and can
> > 	do all sorts of nastiness.
> >
> > 	do you want one attack vector or two?

> 	What's the difference between "MX 0 ." and "MX 0 badhost"?

> 	I don't believe codifying "MX 0 ." changes the threat level.

Given that some widely deployed MTAs already support the . convention, if
anything it lowers it. If the convention changes those MTAs will likely
require a code change.

There are also MTAs that independent of any built in checks have a hook
to allow additional checks to be done per-site (ours is one of these).
Such an MTA can be configured to support any new convention we come up
with, but now we're depending on people deploying things to Do the Right
Thing, at least until once again coding changes can be made.

				Ned

From: [email-masked]
Cc: Bill Manning <[email-masked]>, John Leslie <[email-masked]>, [email-masked]
Date: Thu, 27 Mar 2008 17:48:26 -0700 (PDT)
Subject: Re: How to mark domains that do / do not wish to receive email
To: Mark Andrews <[email-masked]>
Sender: [email-masked]

> >  ah...
> > 	Q: how to mark a domain that does not wish to receive email?
> >  	A: don't run SMTP.

> 	Which is a temporary error to SMTP.

Well, there's always RFC 1846, but that requires running a stub server which
really should not be necessary.

				Ned

From: [email-masked]
Cc: Matti Aarnio <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked], SMTP Interest Group <[email-masked]>
Date: Thu, 27 Mar 2008 17:41:39 -0700 (PDT)
Subject: Re: Implicit MX and A RRs
To: Tony Finch <[email-masked]>
Sender: [email-masked]

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

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

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

				Ned

To: Bill Manning <[email-masked]>
Cc: John Leslie <[email-masked]>, [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: How to mark domains that do / do not wish to receive email 
Date: Fri, 28 Mar 2008 13:37:31 +1100
Sender: [email-masked]

> On Fri, Mar 28, 2008 at 11:34:58AM +1100, Mark Andrews wrote:
> > 
> > > On Fri, Mar 28, 2008 at 11:16:36AM +1100, Mark Andrews wrote:
> > > > 
> > > > >  ah... 
> > > > > 	Q: how to mark a domain that does not wish to receive email?
> > > > >  	A: don't run SMTP.
> > > > 
> > > > 	Which is a temporary error to SMTP.
> > > 
> > > 	yup.  so what?
> > > 	you want the DNS to act as a trusted third party?
> > > 	sounds like an attack vector to me.
> > 
> > 	So does turning off the smtp service and sending lots of
> > 	email to that email domain.  Look at what happens when
> > 	google, hotmail etc. temp fail all email to them because
> > 	of some spam that came from a host without actively attempting
> > 	to fill up the mail spools.
> >  
> > 	Mark
> 
> 	turning off smtp service to a domain == NOT an email domain.
> 	forcing SMTP to require DNS lookups indicates that any one 
> 	who can hijack the DNS data can redirect your DNS lookups
> 	to someplace that does SMTP w/o your permission and can 
> 	do all sorts of nastiness. 
> 	
> 	do you want one attack vector or two?

	What's the difference between "MX 0 ." and "MX 0 badhost"?

	I don't believe codifying "MX 0 ." changes the threat level.

	Mark
 
> --bill
> 
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or otherwise).
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

To: Bill Manning <[email-masked]>
Cc: John Leslie <[email-masked]>, [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: How to mark domains that do / do not wish to receive email 
Date: Fri, 28 Mar 2008 11:34:58 +1100
Sender: [email-masked]

> On Fri, Mar 28, 2008 at 11:16:36AM +1100, Mark Andrews wrote:
> > 
> > >  ah... 
> > > 	Q: how to mark a domain that does not wish to receive email?
> > >  	A: don't run SMTP.
> > 
> > 	Which is a temporary error to SMTP.
> 
> 	yup.  so what?
> 	you want the DNS to act as a trusted third party?
> 	sounds like an attack vector to me.

	So does turning off the smtp service and sending lots of
	email to that email domain.  Look at what happens when
	google, hotmail etc. temp fail all email to them because
	of some spam that came from a host without actively attempting
	to fill up the mail spools.
 
	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Fri, 28 Mar 2008 00:20:16 +0000
From: Tony Finch <[email-masked]>
To: Matti Aarnio <[email-masked]>
cc: Tony Hansen <[email-masked]>, [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: Implicit MX and A RRs
Sender: [email-masked]

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

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

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
TRAFALGAR: NORTHWEST VEERING NORTH 4 OR 5. MODERATE OR ROUGH. MAINLY FAIR.
MAINLY GOOD.

To: Bill Manning <[email-masked]>
Cc: John Leslie <[email-masked]>, [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: How to mark domains that do / do not wish to receive email 
Date: Fri, 28 Mar 2008 11:16:36 +1100
Sender: [email-masked]

>  ah... 
> 	Q: how to mark a domain that does not wish to receive email?
>  	A: don't run SMTP.

	Which is a temporary error to SMTP.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Thu, 27 Mar 2008 17:50:55 -0400
From: John C Klensin <[email-masked]>
To: Matti Aarnio <[email-masked]>, Tony Hansen <[email-masked]>
cc: [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: Implicit MX and A RRs
Sender: [email-masked]

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

> 
> On Wed, Mar 26, 2008 at 10:46:37AM -0400, Tony Hansen wrote:
>> > <[email-masked]> wrote:
>> > 
>> >> ...
>> >>> It would be needed until IPv6 takes over.
>> >>	It will be needed even *after* IPv6 takes over.  There will
>> >>	be lots of queries for A records long after the majority
>> >>	of hosts don't have A records.
>> >> 
>> >>	We need to remove the implict MX from A to prevent the A
>> >>	record lookups occuring as things currently stand.
> 
> There will be lots of legacy codes using legacy APIs for long
> future. I do use  getaddrinfo()  API myself, and permit it do
> all queries to get addresses.  Thus it will also query for A
> in addition to AAAA. It can even be ordered to ignore IPv4 or
> IPv6 as sysadmin wants.
> 
> For the future the previous "query for A record" should
> possibly be altered to "query for network address (IPv6 AAAA
> and/or IPv4 A)" or some such generic wording.

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

   john

Date: Thu, 27 Mar 2008 11:55:29 -0700
To: Sabahattin Gucukoglu <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: How to mark domains that do / do not wish to receive email
Sender: [email-masked]

At 00:33 27-03-2008, Sabahattin Gucukoglu wrote:
>To address the problem that begs for the rule's removal, however: how
>about a fake MX that rejects everything as the draft-rfc2821-bis allows
>with the 554 code on connection opening?  How about not minding that the

If I'm not mistaken, example.com did that before giving up on the 
idea.  Even if a device can be assigned an AAAA RR, it doesn't mean 
that it can run an SMTP service.

Most people won't bother to run a minimal SMTP service as it requires 
resources and can have a negative impact on other running 
services.  The way they address the problem is by adding a MX RR 
pointing to an invalid host.

>sending host is the one with the problem, and not you (not nice, so it'd
>be good to sort it out)?  How about using a known-nonexistent (EG:
>definitely.invalid) host as your MX target (has more bad effects than
>known behaviour but at least it works - and when the rules don't allow us
>to do better than that for now, that's all we can hope for)?  This "MX 0
>." sounds good as well, because it only requires time for implementers to
>get the idea and implement it while it's a bit of bother in the meantime.

That's what some people do.  MX RRs would have to be defined for all 
the hosts with AAAA RRs then.

Regards,
-sm 

Date: Thu, 27 Mar 2008 11:24:36 -0700
To: SMTP Interest Group <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Implicit MX and A RRs
Sender: [email-masked]

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

Please see the suggested text I posted.  It leaves it to the operator 
to decide whether AAAA RRs should be ignored or not if there is no MX 
record which is somewhat similar to what you are doing.

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

That's what rfc2821bis-09 says.  There were some comments on the ietf 
mailing list for and against that.

Regards,
-sm  

Date: Thu, 27 Mar 2008 12:51:32 +0000
From: Tony Finch <[email-masked]>
To: Mark Andrews <[email-masked]>
cc: John Leslie <[email-masked]>, [email-masked]
Subject: Re: Last Call: draft-klensin-rfc2821bis 
Sender: [email-masked]

On Thu, 27 Mar 2008, Mark Andrews wrote:
>
> 	There are already queries for A and AAAA queries for ".".
> 	Codifing the use of "MX 0 ." will, in the long run, reduce
> 	the number of such queries as MTA's get updated.

Exim already does the right (SRV-like) thing for MX n . records, and I
would not be surprised if other MTAs do as well.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL: SOUTHERLY BECOMING CYCLONIC OR WESTERLY 6 TO GALE 8, OCCASIONALLY
SEVERE GALE 9, PERHAPS STORM 10 LATER. VERY ROUGH INCREASING HIGH. RAIN OR
SQUALLY SHOWERS. MODERATE.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: How to mark domains that do / do not wish to receive email
Date:  Thu, 27 Mar 2008 13:43:40 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 31
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Mark Andrews wrote:

> It was more "the only way to prevent the A lookups is
> to remove the fallback".

> If we ever head down this path there would need to be
> years of advance notice.

My =80 0,02:  There is no direct way to get rid of the old
A-fallback, 2821bis can say "please" in a note, maybe an
additional BCP could go as far as SHOULD, and that is it.

Indirectly the great master plan AFAIK is that IPv4 will
die, and without IPv4 the A-fallback also dies.  So what
we now have to decide is if we want an AAAA-fallback for
IPv6, or if we have a chance to kill this AAAA-fallback.

Any "mail opt-out" alternatives like "v=3Dspf1 -all" or
the nullmx draft are odd if the great master plan is to
have names and IPv6 addresses for "everything", notably
billions of things never intending to send or receive
mail.

A "mail opt-in" for IPv6, where only names with an MX
are interested in mail, would be more straight forward.

The "opt-out" alternatives can play a role while IPv4
still exists.  But they would be an ugly kludge for the
brave new IPv6 world.

 Frank

From: "Sabahattin Gucukoglu" <[email-masked]>
To: [email-masked]
Date: Thu, 27 Mar 2008 07:33:00 -0000
Subject: Re: How to mark domains that do / do not wish to receive email
CC: Bill Manning <[email-masked]>
Content-description: Mail message body
Sender: [email-masked]

Hi all,

My very strong opinion is that the zero-preference-MX rule must still 
stand, regardless of how to tackle the domain-owners' problem.  It's law.  
It's also often useful, especially when the DNS administrator isn't handy 
and you want mail service on a single public host, especially on a 
temporary basis.  (It's amusing to think that, now that MX records are the 
commonality for which a transition plan was provided for non-users when 
first introduced, spammers often don't spam hosts without them because of 
their near-universal ubiquity.)

It doesn't matter what itch needs to be scratched to make MX or DNS usage 
perfect; taking the rule away is _going to break compatibility with old 
clients_.  And that's all.  When MX records were introduced, we would 
never have dreamed of doing a thing like that.  So why are we even 
contemplating it now?  (I think I've caught up with all of the discussion 
so far, but please point me to anything if it's already been answered.)

To address the problem that begs for the rule's removal, however: how 
about a fake MX that rejects everything as the draft-rfc2821-bis allows 
with the 554 code on connection opening?  How about not minding that the 
sending host is the one with the problem, and not you (not nice, so it'd 
be good to sort it out)?  How about using a known-nonexistent (EG: 
definitely.invalid) host as your MX target (has more bad effects than 
known behaviour but at least it works - and when the rules don't allow us 
to do better than that for now, that's all we can hope for)?  This "MX 0 
." sounds good as well, because it only requires time for implementers to 
get the idea and implement it while it's a bit of bother in the meantime.

So no, please don't drop that rule.  It's very handy, anyway, even if it 
is an irritating little blister just yearning to be popped, both to make 
semantics and practice clean and current for DNS and SMTP.  But we spent 
ages making the MX record what it is - a record for indicating the names 
and preferences of mail exchangers, with a known behaviour for absent MX 
records.  Changing the meaning of MX from being just a preference list to 
an actual indicator of whether mail is wanted or not would not have made 
sense at the time, and I feel strongly that it still hasn't got even the 
slightest motive for doing so today when practical and long-term solutions 
that can work without breaking compatibility seem possible with the 
minimum of badness.

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:	Thu, 27 Mar 2008 09:00:22 +0200
From: Matti Aarnio <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: Implicit MX and A RRs
Sender: [email-masked]

On Wed, Mar 26, 2008 at 10:46:37AM -0400, Tony Hansen wrote:
> ><[email-masked]> wrote:
> >
> >>...
> >>>It would be needed until IPv6 takes over.
> >>	It will be needed even *after* IPv6 takes over.  There will
> >>	be lots of queries for A records long after the majority
> >>	of hosts don't have A records.
> >>
> >>	We need to remove the implict MX from A to prevent the A
> >>	record lookups occuring as things currently stand.

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

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

-- 
/Matti Aarnio	<[email-masked]>

To: Hector Santos <[email-masked]>
Cc: John Leslie <[email-masked]>, [email-masked], Bill Manning <[email-masked]>
From: Mark Andrews <[email-masked]>
Subject: Re: How to mark domains that do / do not wish to receive email 
Date: Thu, 27 Mar 2008 13:35:38 +1100
Sender: [email-masked]

> Mark Andrews wrote:
> > 
> > 	It was more "the only way to prevent the A lookups is to
> > 	remove the fallback".
> > 
> > 	If we ever head down this path there would need to be years
> > 	of advance notice.
> > 
> > 	Mark
> 
> We use a "1 shot" implicit MX fallback. If we were to remove this, it 
> would have to be done as an option.
> 
> I have no stats on hand how much of the fallback is used among 
> customers, but I can say that just a few months ago while assisting my 
> brother, the fallback was used during the time the domain did not 
> propagate through the net yet.  I expected it in order to get the 
> initial setup going for his new domain setup.

	Domain's don't propogate through the net.  The records
	propogate to authoritative servers only.  There may also
	be time for cached entries (positive and negative) to time
	out.

> In any case, for us, I don't see any issue of making it an option 
> (default ON in the first few new revisions, then eventually default off) 
> to help in deprecating this practice.
> 
> +1 on text to deprecate the Implicit MX.
> 
> -- 
> Sincerely
> 
> Hector Santos, CTO
> http://www.santronics.com
> http://santronics.blogspot.com
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Wed, 26 Mar 2008 22:22:56 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Mark Andrews <[email-masked]>
CC: John Leslie <[email-masked]>, [email-masked], Bill Manning <[email-masked]>
Subject: Re: How to mark domains that do / do not wish to receive email
Sender: [email-masked]

Mark Andrews wrote:
> 
> 	It was more "the only way to prevent the A lookups is to
> 	remove the fallback".
> 
> 	If we ever head down this path there would need to be years
> 	of advance notice.
> 
> 	Mark

We use a "1 shot" implicit MX fallback. If we were to remove this, it 
would have to be done as an option.

I have no stats on hand how much of the fallback is used among 
customers, but I can say that just a few months ago while assisting my 
brother, the fallback was used during the time the domain did not 
propagate through the net yet.  I expected it in order to get the 
initial setup going for his new domain setup.

In any case, for us, I don't see any issue of making it an option 
(default ON in the first few new revisions, then eventually default off) 
to help in deprecating this practice.

+1 on text to deprecate the Implicit MX.

-- 
Sincerely

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

To: John Leslie <[email-masked]>
Cc: [email-masked], Bill Manning <[email-masked]>
From: Mark Andrews <[email-masked]>
Subject: Re: How to mark domains that do / do not wish to receive email 
Date: Thu, 27 Mar 2008 11:55:06 +1100
Sender: [email-masked]

>    (I asked Mark to discuss this on <ietf-smtp> -- I'll provide context
> where it seems needed...)
> 
> Mark Andrews <[email-masked]> wrote:
> > To: John Leslie <[email-masked]>
> >> Mark Andrews <[email-masked]> wrote:
> >>> SM <[email-masked]> wrote:
> >>>> Mark Andrews <[email-masked]> wrote:
> >>>>
> >>>>> It is easy to turn "MX 0 ." into "This domain doesn't support
> >>>>> email" as "." is not confusable with a hostname.  There is no
> >>>>> reason to look up addresses records for "."
> >>>>
> >>>> There was an I-D, draft-delany-nullmx-00, which didn't make it
> >>>> to RFC status.
> >>>>
> >>>>> Which could just be a misconfiguration.   You still have to
> >>>>> look up addresses for "dev.null".
> >>>> 
> >>>> Yes.  People still do it.
> >>>
> >>> Yes they do.  We, the IETF, have failed them by not providing
> >>> them with a clear mechanism to do what they want without bad
> >>> side effects.
> 
>    (The above is to give context.)
> 
> >> I well remember DNS gurus trying to deprecate the use of "."
> >> wherever it might lead to queries to root servers for "." Is
> >> this no longer an issue?
> > 
> > SRV say to use "." for "no service".
> 
>    This is indeed specified in RFC 2782.
> 
> > RP say to use  "." for "does not exist".
> 
>    I think Mark means Responsible Person (RFC 1183).
> 
> > There are already queries for A and AAAA queries for ".".
> > Codifing the use of "MX 0 ." will, in the long run, reduce
> > the number of such queries as MTA's get updated.
> 
>    I'm pretty sure Mark means that the additional usage will speed
> the update of MTAs which now query for "." to stop making this
> useless query.
> 
> > The roots can handle the query load in the mean time.
> 
>    Mark is more of a DNS guru than I, certainly, so I tend to assume
> he's right about this.
> 
>    However, widespread usage of this convention _could_ generate
> rather a lot of potenital DNS queries as spammers continue to forge
> Mail-From addresses which domain administrators attempt to mark as
> "no incoming email accepted".
> 
>    (The volume of spam blowback dwarfs any current use of SRV and
> RP records.)
> 
> >> I'm very confused that Bill Manning seems to be calling for
> >> 
> >> *    MX    .
> > 
> > I think you mean "* MX 0 ."
> 
>    (Indeed, I erred in typing this.)
> 
> > and Bill was not saying that.
> 
>    Frankly, I have a lot of difficulty understanding _what_ Bill
> Manning was saying, except that he didn't want to publish MX records.
> I guessed he might mean that anyone who _didn't_ want a machine
> probed for a port-25 server should publish MX records to say so.
> (But, of course, he might just as well have meant you should block
> port 25 -- I really don't know...)
> 
> > Bill knows that a wildcard record will not have the desired
> > effect.  Adding a "MX 0 ." record along side a existing
> > record will have the desired effect.
> 
>    (Actually, I doubt that either Mark or I should attempt to speak
> for Bill.)
> 
> >>> It will be needed even *after* IPv6 takes over.  There will
> >>> be lots of queries for A records long after the majority
> >>> of hosts don't have A records.
> 
>    This is getting back to Mark's actual point -- that queries for
> A (and/or AAAA) records for domains that don't want to participate
> in SMTP is a bad use of the DNS system.
> 
>    I quite agree.
> 
> >>> We need to remove the implict MX from A to prevent the A
> >>> record lookups occuring as things currently stand.
> 
>    I don't agree with "need to"; but I do think the SMTP world would
> be a better place if we did.

	It was more "the only way to prevent the A lookups is to
	remove the fallback".

	If we ever head down this path there would need to be years
	of advance notice.

	Mark
 
> --
> John Leslie <[email-masked]>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Wed, 26 Mar 2008 20:46:57 -0400
From: John Leslie <[email-masked]>
To: Mark Andrews <[email-masked]>
Cc: [email-masked], Bill Manning <[email-masked]>
Subject: How to mark domains that do / do not wish to receive email
Sender: [email-masked]

   (I asked Mark to discuss this on <ietf-smtp> -- I'll provide context
where it seems needed...)

Mark Andrews <[email-masked]> wrote:
> To: John Leslie <[email-masked]>
>> Mark Andrews <[email-masked]> wrote:
>>> SM <[email-masked]> wrote:
>>>> Mark Andrews <[email-masked]> wrote:
>>>>
>>>>> It is easy to turn "MX 0 ." into "This domain doesn't support
>>>>> email" as "." is not confusable with a hostname.  There is no
>>>>> reason to look up addresses records for "."
>>>>
>>>> There was an I-D, draft-delany-nullmx-00, which didn't make it
>>>> to RFC status.
>>>>
>>>>> Which could just be a misconfiguration.   You still have to
>>>>> look up addresses for "dev.null".
>>>> 
>>>> Yes.  People still do it.
>>>
>>> Yes they do.  We, the IETF, have failed them by not providing
>>> them with a clear mechanism to do what they want without bad
>>> side effects.

   (The above is to give context.)

>> I well remember DNS gurus trying to deprecate the use of "."
>> wherever it might lead to queries to root servers for "." Is
>> this no longer an issue?
> 
> SRV say to use "." for "no service".

   This is indeed specified in RFC 2782.

> RP say to use  "." for "does not exist".

   I think Mark means Responsible Person (RFC 1183).

> There are already queries for A and AAAA queries for ".".
> Codifing the use of "MX 0 ." will, in the long run, reduce
> the number of such queries as MTA's get updated.

   I'm pretty sure Mark means that the additional usage will speed
the update of MTAs which now query for "." to stop making this
useless query.

> The roots can handle the query load in the mean time.

   Mark is more of a DNS guru than I, certainly, so I tend to assume
he's right about this.

   However, widespread usage of this convention _could_ generate
rather a lot of potenital DNS queries as spammers continue to forge
Mail-From addresses which domain administrators attempt to mark as
"no incoming email accepted".

   (The volume of spam blowback dwarfs any current use of SRV and
RP records.)

>> I'm very confused that Bill Manning seems to be calling for
>> 
>> *    MX    .
> 
> I think you mean "* MX 0 ."

   (Indeed, I erred in typing this.)

> and Bill was not saying that.

   Frankly, I have a lot of difficulty understanding _what_ Bill
Manning was saying, except that he didn't want to publish MX records.
I guessed he might mean that anyone who _didn't_ want a machine
probed for a port-25 server should publish MX records to say so.
(But, of course, he might just as well have meant you should block
port 25 -- I really don't know...)

> Bill knows that a wildcard record will not have the desired
> effect.  Adding a "MX 0 ." record along side a existing
> record will have the desired effect.

   (Actually, I doubt that either Mark or I should attempt to speak
for Bill.)

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

   This is getting back to Mark's actual point -- that queries for
A (and/or AAAA) records for domains that don't want to participate
in SMTP is a bad use of the DNS system.

   I quite agree.

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

   I don't agree with "need to"; but I do think the SMTP world would
be a better place if we did.

--
John Leslie <[email-masked]>

To: John Leslie <[email-masked]>
cc: [email-masked]
From: Mark Andrews <[email-masked]>
Subject: Re: Last Call: draft-klensin-rfc2821bis 
Date: Thu, 27 Mar 2008 10:09:35 +1100
Sender: [email-masked]

> Mark Andrews <[email-masked]> wrote:
> > 
> > We, the IETF, have failed them by not providing
> > them with a clear mechanism to do what they want without bad
> > side effects.
> 
>    I well remember DNS gurus trying to deprecate the use of "."
> wherever it might lead to queries to root servers for "." Is
> this no longer an issue?

	SRV say to use "." for "no service".
	RP say to use  "." for "does not exist".

	There are already queries for A and AAAA queries for ".".
	Codifing the use of "MX 0 ." will, in the long run, reduce
	the number of such queries as MTA's get updated.

	The roots can handle the query load in the mean time.

>    I'm very confused that Bill Manning seems to be calling for
> 
> *    MX    .

	I think you mean "* MX 0 ." and Bill was not saying that.
	Bill knows that a wildcard record will not have the desired
	effect.  Adding a "MX 0 ." record along side a existing
	record will have the desired effect.

> > It will be needed even *after* IPv6 takes over.  There will
> > be lots of queries for A records long after the majority
> > of hosts don't have A records.
> > 
> > We need to remove the implict MX from A to prevent the A
> > record lookups occuring as things currently stand.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Wed, 26 Mar 2008 12:25:30 -0700
To: SMTP Interest Group <[email-masked]>
From: SM <[email-masked]>
Subject: Re: Implicit MX and A RRs
Sender: [email-masked]

At 07:46 26-03-2008, Tony Hansen wrote:
>As the shepherd/pseudo-chair for 2821bis effort, our plan of action is
>going to be as follows:
>
>    *)   the implicit MX issue needs to be resolved.

Quoting the text from rfc2821bis-09, Section 5.1:

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

I suggest a change to use the implicit MX rule for A RRs only as follows:

    The lookup first attempts to locate an MX record associated with the
    name.  If a CNAME record is found instead, the resulting name is
    processed as if it were the initial name.  If no MX records are
    found, but an IPv4 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.

    An implicit MX RR using the IPv6 AAAA RR, or its successor may be
    required as a fallback for operational reasons.  Designers
    implementing such a mechanism should have it turned off
    in the default configuration.

Regards,
-sm 

Date: Wed, 26 Mar 2008 10:46:37 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], SMTP Interest Group <[email-masked]>
Subject: Re: Implicit MX and A RRs
Sender: [email-masked]

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

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

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

	Tony Hansen
	[email-masked]

John C Klensin wrote:
> 
> --On Wednesday, 26 March, 2008 22:41 +1100 Mark Andrews
> <[email-masked]> wrote:
> 
>> ...
>>> It would be needed until IPv6 takes over.
>> 	It will be needed even *after* IPv6 takes over.  There will
>> 	be lots of queries for A records long after the majority
>> 	of hosts don't have A records.
>>
>> 	We need to remove the implict MX from A to prevent the A
>> 	record lookups occuring as things currently stand.
> 
> Mark,
> 
> Whether that proposal is a good one or a bad one, it can't be
> done in 2821bis because that is a document moving from Proposed
> to Draft Standard and the implicit MX feature is _very_ widely
> deployed and used.  So, IMO, this discussion is not directly
> relevant to the (already closed) Last Call on 2821bis and should
> probably be move to the ietf-smtp mailing list.
> 
> Second, no matter what is done with standardization, it will be
> many, many years before one could count on those A RR lookups
> not occurring -- too much software out that that is very rarely
> updated.   The advantage of the "MX 0 ." approach over getting
> rid of the implicit MX from A is that, if there were consensus
> for it, it can be deployed in less than geological time.
> 
> But, either way, it seems to me that the correct (and only
> feasible) actions start with an I-D that says something useful
> and is discussed on, at least, the ietf-smtp list.

Date: Wed, 26 Mar 2008 10:46:33 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: resolving the last few items for 2821bis
Sender: [email-masked]

There are several items that have not yet been resolved in 2821bis. 
These fall in to three categories:

    *	The implicit MX issue currently raging on [email-masked].

    *	The issue of "character" vs. "octet" came to a head because of a
	related last call occurring in EAI.

    *	A last-call email from Frank had gotten lost and so was not
	considered when John went to work on creating -09.

I'll be posting several other messages with proposed resolutions for the 
various issues.

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

	Tony Hansen
	[email-masked]

Date: Fri, 21 Mar 2008 12:58:48 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: draft-klensin-rfc2821bis-09
Sender: [email-masked]

John C Klensin wrote:
> After a review by Tony of the comments from the second Last
> Call, I've prepared a clean copy of the document for IESG
> consideration.  It is in the process of being posted.  I hope
> Tony will post a summary of the changes that have been made (and
> not made) but, until he has time to do that, I would encourage
> checking the "Change Log" appendix and/or doing a diff against
> -08.
> 
> The changes are pretty much all fine-tuning or editorial, IMO.

<pseudo-chair hat on>

To see a diff, click on Diff1 or Diff2 links from 
http://tools.ietf.org/html/draft-klensin-rfc2821bis-09

Here are the issues that were raised right around or since last call on 
-08 went out and not previously resolved.

Section 2.1, para 6>>	There's too many "either"s and other possible 
rewrites...

Resolution>>	Concur, too many either's, but other rewrites not necessary.

Section 3.1-3>>	Issues with wording around "transaction".

Resolution>>	Concur, change "transaction" to "mail session".

Section 3.3-8+ and Section 4.1.4-9>>	Suggest replacing "If a ... command 
appears" with "transaction" and add definition section for transaction.

Resolution>>	No, text is adequate as is. Adding a definition section on 
"transaction" is possible for 2821ter.

Section 3.5.2-1>>	wording about VRFY/EXPN normal responses

Resolution>>	Concur with posted suggested clarification

Section 4.1.4-9>>	need ref to EHLO as way to abort command

Resolution>>	Concur with posted suggested clarification

Section 4.2-5>>	Discussion of Greeting response upon connection

Resolution>>	add a statement to end of paragraph discussing Greeting

    (Other server responses upon connection follow the syntax of
    Reply-line.)

Section 4.3.2>>		DATA missing E: 503, 554

Resolution>>	Concur

Appendix B-2>>	bad reference [32]

Resolution>>	Corrected here and section 2.3.7.

Appendix D.4>>	Why use SEND FROM?

Resolution>>	change SEND FROM to MAIL FROM

Other points raised with respect to some minor differences between 
2821bis's ABNF and 2822upd's corresponding ABNF should be re-raised 
during the last call for 2822upd (coming soon).

</pseudo-chair hat off>

	Tony Hansen
	[email-masked]

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: draft-klensin-rfc2821bis-09
Date:  Fri, 21 Mar 2008 12:15:04 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 54
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

John C Klensin wrote on the SMTP list:

> I would encourage checking the "Change Log" appendix and/or
> doing a diff against -08.

No problems in the diff.  Checking -09 against the second LC
comment <http://article.gmane.org/gmane.ietf.general/29277>:

(1)
| In section 4.1.3 <dcontent> is undefined
[...proposed fix...]

RFC 2822 offers <dcontent> with <NO-WS-CTL>, the normative=20
reference 2822upd-06 doesn't have a <dcontent>.  You're not
planning to fix this with an erratum, or are you ?

(2)
| <Standardized-tag> got no valid syntax
[...proposed fix...]

(3)
| For an <IPv6-addr> importing or adapting <IPv6address>
| from STD 66 would be clearer:  The STD 66 syntax works
| as is, without any additional restrictions in comments.

(4)
| In section 4.2 <text> is undefined
[...proposed fix...]

(5)
| In section 4.2.2 (reply codes by function group) 251 and
| 551 should form one group

(6)
| In section 4.1.2 <Keyword> and <Argument> are apparently
| unused and can be removed.  For the collected syntax see
| <http://hmdmhdfmhdjmzdtjmzdtzktdkztdjz.googlepages.com/2821bis.ABNF.1> =

(7)=20
| The  ehlo-greet =3D 1*(%d0-9 / %d11-12 / %d14-127)  allows
| NUL and obs-NO-WS-CTL

If that is intentionally the NULs could get their very own
security consideration.

(8)
Somebody asked where the 2821 Interop and Implemementation=20
report mentioned in the Last Call is.  My own tests in 2007
only showed that (1) <NO-WS-CTL> in <dcontent> doesn't work,
I didn't test (7).  In 2007 I forwarded Dave's request for
reports to the ASRG, RFCI, and SPF devel mailing lists.

 Frank

Date: Thu, 20 Mar 2008 21:43:07 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: draft-klensin-rfc2821bis-09
Sender: [email-masked]

Hi.

After a review by Tony of the comments from the second Last
Call, I've prepared a clean copy of the document for IESG
consideration.  It is in the process of being posted.  I hope
Tony will post a summary of the changes that have been made (and
not made) but, until he has time to do that, I would encourage
checking the "Change Log" appendix and/or doing a diff against
-08.

The changes are pretty much all fine-tuning or editorial, IMO.

     john

From: [email-masked]
Cc: [email-masked]
Date: Fri, 14 Mar 2008 07:03:06 -0700 (PDT)
Subject: Re: email-arch -- comments solicited on I8N
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> > It was widely agreed long ago that we botched the
> > versioning in MIME and therefore the version would almost
> > certainly never change.

> Yes, and it was also almost certain that nobody would dare
> touch US-ASCII in MIME part headers.  Unfortunately EAI did
> it anyway while not updating the version, claiming that all
> uses are strictly limited to the message/global "sandbox".

I don't think that's true at all. The only reason we didn't opt for a
straightforward extension to allow more than US-ASCII in headers, as opposed to
what RFC 2047, is that UTF-8 didn't exist at the time this stuff was designed
and it was far from clear that there was ever going to be an acceptable
universal character set.

> >> My impression for message subtypes in RFC 2046 was that
> >> message/unknown is actually opaque, to be handled like
> >> an application/octet-stream, where B64 is allowed, while
> >> multipart is multipart, where only 7bit / 8bit / binary
> >> counts, other CTEs only within the multipart.
 
> > Not reallly. It was a complex situation, but basically
> > what happened was that there was really never intention
> > of there ever being any additional message subtypes other
> > than rfc822 and partial.

> And external-body - for obscure reasons the IETF announce
> list still desperately tries to use it, causing my old MUA
> to crash when somebody forwarded an announcement "as is".

I routinely use the external body references to pull documents. Works fine in
my MUA at least, although clicking on a URL isn't any more difficult.

> I never found out what exactly the problem is.  But when a
> MIME access type can be erroneously registered as subtype
> for about 15 years I guess that folks don't care about it.
  
I have no idea what this refers to, but if you're talking about a registry
error of some sort that's pretty guaranteed to be an indication of exactly
nothing. There are plent of errors that remain uncorrected despite having been
reported multiple times. IANA is doing much better in this regard now, but
there are many years where stuff slipped through the cracks.

> > I actually proposed message/x400-p2 at one point as a
> > tunnelling mechanism and got roasted for it.

> Meanwhile there are a few more message/*, some in need of
> updated references (1894 => 3464, 2298 => 3798), apparently
> the authors forgot this.  Can I simply suggest this on the
> MIME types list, and submit it to IANA after a timeout ?

If you think it is worth worrying about, sure. But really, outdated
references in registrations stike me as pretty low priority.

				Ned

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: email-arch -- comments solicited on I8N
Date:  Thu, 13 Mar 2008 19:21:26 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 85
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<[email-masked]> wrote:
=20
> This is again wandering off topic, but IMO these attempts
> to tie up every last detail are fundamentally misguided.
> We're letting the best be the enemy of the plenty good enough.

For a topic "Internet, email, the IETF, and all the rest"
we are close enough, and you proposed to bet on 2822upd. :-)=20

The last time I did this was before IETF 70 proposing to put
2821bis + 2822upd + email-arch into a proper WG to make sure
that they are in sync.

John's point about FWS-in-quoted-string was no nonsense, and
at the moment 2821bis and 2822upd disagree about it.  For
the "F" part it might be "good enough", somebody trying to
use CrLf within a quoted-string of the envelope will learn
very fast that it won't fly.  For HTAB it's less clear, and
it would be nice to arrive at "anything matching FWS means
a single SP if used in SMTP" (or similar, all details for
quoted-pairs TBD, I have proposed text some weeks ago here).

I've no idea what 2822upd will do.  But it's important, some
folks think it is a good idea to introduce the quoted-pair
also in EAI for UTF8-non-ascii only because RFC 2822 has it
for any ASCII.  With IMO ugly effects for mailto-eai, apart
from being completely unnecessary to start with.

> I cannot imagine how the resolution of a FWS issue could
> have an impact on the overall email architecture.

IFF we want normative references to 2822upd in 2821bis and
email-arch the impact is "blocked until 2822upd is ready".

[... procedural subtopic skipped, reply in mail ...]

> It was widely agreed long ago that we botched the=20
> versioning in MIME and therefore the version would almost
> certainly never change.

Yes, and it was also almost certain that nobody would dare
touch US-ASCII in MIME part headers.  Unfortunately EAI did
it anyway while not updating the version, claiming that all
uses are strictly limited to the message/global "sandbox".

I don't believe in this assumption, if folks want sandboxes
why can't they play with say javascript instead of email ?

> EAI's change is going to be more... interesting.

+1

>> My impression for message subtypes in RFC 2046 was that
>> message/unknown is actually opaque, to be handled like
>> an application/octet-stream, where B64 is allowed, while
>> multipart is multipart, where only 7bit / 8bit / binary
>> counts, other CTEs only within the multipart.
=20
> Not reallly. It was a complex situation, but basically
> what happened was that there was really never intention
> of there ever being any additional message subtypes other
> than rfc822 and partial.

And external-body - for obscure reasons the IETF announce
list still desperately tries to use it, causing my old MUA
to crash when somebody forwarded an announcement "as is".
I never found out what exactly the problem is.  But when a
MIME access type can be erroneously registered as subtype
for about 15 years I guess that folks don't care about it.
 =20
> I actually proposed message/x400-p2 at one point as a=20
> tunnelling mechanism and got roasted for it.

Meanwhile there are a few more message/*, some in need of
updated references (1894 =3D> 3464, 2298 =3D> 3798), apparently
the authors forgot this.  Can I simply suggest this on the
MIME types list, and submit it to IANA after a timeout ?

> I simply haven't had the cycles to participate actively=20
> in EAI.

It was a kind of fig-leaf WG, relevant folks hiding out in
their private design-team.  <shrug />

 Frank

Date: Wed, 12 Mar 2008 18:22:32 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: email-arch -- Security Considerations
Sender: [email-masked]

On Tue, 11 Mar 2008, Dave Crocker wrote:
>
>      <t>The core of the Internet Mail architecture does not impose any
> security requirements or functions on the end-to-end or hop-by-hop
> components. For example, it does not require participant authentication
> and does not attempt to prevent data disclosure.</t>

Client-server hops do have security requirements: message submission (RFC
5068) and message store access (RFC 3501).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BISCAY FITZROY: SOUTHWESTERLY 5 TO 7 BUT VARIABLE 4 IN SOUTH. VERY ROUGH OR
HIGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

From: [email-masked]
Cc: [email-masked]
Date: Tue, 11 Mar 2008 15:52:23 -0700 (PDT)
Subject: Re: email-arch -- Security Considerations
To: Dave Crocker <[email-masked]>
Sender: [email-masked]

> Dave Crocker wrote:
> > A question has been raised about the very brief Security Considerations
> > section in the email-arch draft.  I've modified the section slight, for the
> > next draft, but the section still defers meaningful discussion to existing
> > specifications.

> Having now received candidate text, and having now worked vigorously to distort
> it beyond any hope of its having benefit, here is what I propose for the
> Security Considertations section:

> <section title="Security Considerations">

>       <t>This document describes existing Internet Mail architecture. It
> introduces no new new capabilities. The security considerations of this deployed
> architecture are already documented extensively in the technical specifications
> referenced by this document. These specifications cover classic security topics,
> such as authentication and privacy. For example, email transfer protocols can
> use standardized mechanisms for operation over authenticated and/or encrypted
> links, and message content has similar protection standards available. </t>

Maybe some references to the relevant SMTP-TLS and SMTP-AUTH specifications
would be good to have here.

>       <t>The core of the Internet Mail architecture does not impose any security
> requirements or functions on the end-to-end or hop-by-hop components. For
> example, it does not require participant authentication and does not attempt to
> prevent data disclosure.</t>

>       <t>Particular message attributes might expose specific security
> considerations.  For example, the "blind carbon copy" feature of the
> architecture invites disclosure concerns, as discussed in section 7.2 of
> [RFC2821] and section 5 of [RFC2822].  Transport of text or non-text content in
> this architecture has security considerations that are discussed in [RFC2822],
> [RFC2045], [RFC2046], and [RFC4288] as well as the security considerations
> present in the IANA media types registry for the respective types. </t>

>       <t>Agents that automatically respond to email have significant security
> considerations, as discussed in [RFC3834].  Gateway behaviors impact end-to-end
> security services, as discussed in [RFC2480]. Security considerations for
> boundary filters are discussed in [RFC3028].</t>

RFC 3028 is obsolete, it has been replaced by RFC 5228. This probably needs to
be updated elsewhere as well.

>       <t>See section 7.1 of [RFC2821] for a discussion of the topic of
> origination validation.  As mentioned in section 4.1.4, it is common practice
> for components of this architecture to use the RFC0791.SourceAddr to make policy
> decisions [RFC2505], although it is possible "spoof" this address -- that is, to
> use it without authorization.  SMTP and Submission authentication [RFC2554],
> [RFC4409] provide more secure alternatives.</t>

>       <t>The current document's discussion of trust boundaries, ADMDs, actors,
> roles  and responsibilities all highlight the relevance and potential complexity
> of security factors for operation of an Internet mail service.  Internet Mail's
> core design to encourage open and casual exchange of message's has met with
> scaling challenges, as the population of email participants has grown to include
> those with problematic practices. For example, spam, as defined in [RFC2505], is
> a consequence of this architecture.  A number of standards track or BCP
> documents on the subject have been issued. [RFC2505], [ID-spamops],[RFC3685].</t>

> </section>

This seems very good overall.

				Ned

> --

>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net

From: [email-masked]
Cc: [email-masked]
Date: Tue, 11 Mar 2008 14:51:54 -0700 (PDT)
Subject: Re: email-arch -- comments solicited on I8N
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> <[email-masked]> wrote:
 
> > it is pretty likely that 2822upd long before EAI has
> > deployment even as an experiment sufficient to warrant
> > mention here. 2822upd is therefore a much better bet.

> If 2821bis, 2822upd, and email-arch end up out of sync
> with contradictions we have definitely dropped the ball.

Sure.

> But I dare not yet bet on 2822upd while John wants it to
> solve the FWS-in-quoted-string problem (after I thought
> that 2822upd is in essence ready for Last Call), that is
> not as easy as shifting cruft to obs-*, or beautifying
> the ABNF where it is forced to preserve the 822 #-rule.

This is again wandering off topic, but IMO these attempts to tie up every last
detail are fundamentally misguided. We're letting the best be the enemy of the
plenty good enough.

But even so I cannot imagine how the resolution of a FWS issue could have an
impact on the overall email architecture.

> >> Not mentioning EAI at all in the I18N considerations
> >> would be odd.
> > No, mentioning it would be.

> Let's agree to disagree here, I certainly don't "insist"
> on mentioning RFC 4952.
 
OK.

> >> If email-arch is for email what TAObis or roadmap are
> >> for the IETF
> > Neither comparison is even close as far as I can tell.

> For a long terminology discussion on the SPF list I tried
> to convice the protagonists that *redefining* terms in
> email-arch would be a seriously bad idea, it is how I see
> email-arch.  Maybe RFC 4949 is a better comparison.

Not really. That's a glossary, and hence focused on invidual terms. Since
there's no overarching architectural context this tends to emphasize small
inconsistencies in ways an architectuure document does not.

In any case, I think RFC 4949 is basically OK. My main problem with it is not
that it redefines terms oddly, but rather that it defines tons of terms that
are rarely if ever used.

> > unfortunately political realities more or less demand
> > that it be standards track.

> No idea why - is that a procedural side-effect of not
> having a proper WG for 2821bis + 2822upd + email-arch ?

I really don't want to get into this here so this is going to be my final note
on this subtopic. The issue is that documents like this have status beyond that
of a random informational specification so informational isn't appropriate,
they aren't an experiment, they don't really define a set of practices so BCP
isn't the right fit, and they don't define a protocol or something that has
obvios interoperability criteria so standards track advancement is problematic.
In short, none of our document statuses are a perfect or even good fit, and the
closest fit seems to be standards track.

Another document with similar issues was the ABNF specification. And then
there's the issue of how to deal with what used to be the ION document series
that's being discussed now on the IETF list.

>  [old 2231 debate]
> > I have no idea why this is supposed to be in any way
> > relevant to the matters at hand.

> RFC 2231 was a MIME update without changing the version
> number, EAI allows UTF-8 without changing the version
> number, both changes could be considered as not strictly
> 1.0 backwards compatible.  Only in theory for the former,
> for the latter it's hard to judge.

It was widely agreed long ago that we botched the versioning in MIME and
therefore the version would almost certainly never change. RFC 2231 was
carefully designed so it is syntactically backwards compatible with non-2231
systems. And in any case, the issues with RFC 2231 in practice have nothing to
do with having broken backwards compatibility.

EAI's change is going to be more... interesting.

> >> s/subtle error/obvious inconsistency/ if that is clearer.
 
> > There is no inconsistency. The message type was intended,
> > as the name implies, to represent messages. Given that
> > the goal was to eliminate any possibility of a nested
> > encoding, it made sense at the time to ban encoding of
> > message parts.

> Sure.  It makes less sense if an UTF8SMTP sender somehow
> manages that the reverse path requires 7bit for a DSN,
> my application/message idea to get over 7bit hops was
> in essence the same as nested B64, nobody on the public
> EAI list liked it.

application/message (sometimes with different names)  has been proposed at
least half a dozen times over the years. I personally don't have a major
problem with it, but regardless of my position tThe idea has never gotten any
traction and I don't see that changing now.

> > What has happened subsequently is that the definition
> > of message has been stretched to cover some things that
> > aren't really messages per se. And EAI is stretching
> > that even further. And this is what has created the
> > "obvious inconsistency" you refer to.

> My impression for message subtypes in RFC 2046 was that
> message/unknown is actually opaque, to be handled like
> an application/octet-stream, where B64 is allowed, while
> multipart is multipart, where only 7bit / 8bit / binary
> counts, other CTEs only within the multipart.

Not reallly. It was a complex situation, but basically what happened was that
there was really never intention of there ever being any additional message
subtypes other than rfc822 and partial. I actually proposed message/x400-p2 at
one point as a tunnelling mechanism and got roasted for it.

> From there I arrived at the conclusion that the RFC 2045
> "expressly forbidden" means MUST for any multipart/* and
> "only" SHOULD for message/unknown, with explicit MUSTard
> for message/rfc822 etc.  A subtle difference, an erratum
> could explain it - likely pointless, nobody on the MIME
> types list bothered to question why message/global wants
> or needs unusual CTE rules.

Operational experience is going to be the determining factor here.

> > Whatever justification floats your boat is fine with me.
> > Just please refrain from applying 20:20 hindsight to
> > complex decisions with a significant political component
> > made well over 15 years ago.

> If there were other _technical_ reasons for the message/*
> and multipart/* difference in RFC 2046 I'm curious what
> they were.

There are no _technical_ reasons behind any of these restrictions. I proved
that during the Atlanta IETF by building and demonstrating in one evening an
efficient nonrecursive MIME decoder capapable of handling nested encodings with
ease.

No, nested encodings were banned because there was a strong consensus that they
were too complex, that implementors wouldn't handle them correctly, that they
would be used profligately and that the result would be messages bloated by
many encoding layers, and no doubt a bunch of other concerns I no longer
recall. This consensus carried the day.

In fact you could argue that a big reason this came about was due to meeting
scheduling. The PEM WG was in full swing at the time, but since it was in the
security area, it's meetings consistently conflicted with those of the IETF-822
WG so that's where all the security types were. The result was that folks like
Jim Galvin, Steve Crocker, and several others who could have pointed out the
consequences of forbidding nested encodings on security enclosures weren't
there to make the arugment. I tried to make this arugment myself but it was
very difficult to do this as a document author and not as a security geek.

> > Like it or not, EAI's success will depend on the extent
> > to which it's adopted and once adopted the extent to which
> > it causes issues for the installed base of email services,
> > including but not limited to the major antispam vendors
> > and a myriad of others.

> I can't say that I "like" or "dislike" EAI, or that I would
> be "happy" if EAI is a success.  It could disappoint folks
> considering US-ASCII as gibberish if it fails, that would be
> sad.  It would be also sad for the folks who worked hard on
> EAI - that is why I'm worried about introducing the "nice to
> have" detail UTF-8 in MIME part headers, if its side-effects
> could contribute to a failure.

Yep, that's a very valid point. Doing the minimal necessary is arguably best in
such cases. But this isn't the EAI group, and unfortunately I simply haven't
had the cycles to participate actively in EAI.

				Ned

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: email-arch -- comments solicited on I8N
Date:  Tue, 11 Mar 2008 21:48:36 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 128
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<[email-masked]> wrote:
=20
> it is pretty likely that 2822upd long before EAI has
> deployment even as an experiment sufficient to warrant
> mention here. 2822upd is therefore a much better bet.

If 2821bis, 2822upd, and email-arch end up out of sync
with contradictions we have definitely dropped the ball.

But I dare not yet bet on 2822upd while John wants it to
solve the FWS-in-quoted-string problem (after I thought
that 2822upd is in essence ready for Last Call), that is
not as easy as shifting cruft to obs-*, or beautifying
the ABNF where it is forced to preserve the 822 #-rule.

>> Not mentioning EAI at all in the I18N considerations
>> would be odd.
> No, mentioning it would be.

Let's agree to disagree here, I certainly don't "insist"
on mentioning RFC 4952. =20
=20
>> If email-arch is for email what TAObis or roadmap are
>> for the IETF
> Neither comparison is even close as far as I can tell.

For a long terminology discussion on the SPF list I tried
to convice the protagonists that *redefining* terms in
email-arch would be a seriously bad idea, it is how I see
email-arch.  Maybe RFC 4949 is a better comparison.

> unfortunately political realities more or less demand
> that it be standards track.

No idea why - is that a procedural side-effect of not
having a proper WG for 2821bis + 2822upd + email-arch ?

> In any case, now is not the time to rehash the whole
> our-document-categories-don't-fit-current-reality thing.
> If you want that take it to the main IETF list - I think
> we're just about due for another round of it there.

Sorry, I have really no clue what you are talking about
wrt email-arch, is one of its five MUST or three SHOULD
critical ?  As far as I can see it they all only reflect
existing MUSTard, they don't introduce really new rules.

  [experimental MIME update in EAI]
>> that boils down to "could please one of Ned / Keith / ...
>> confirm that EAI got it right".

> Again, I simply don't know if EAI got it "right".

Great, the one time I really want you to write "shut up"
you don't.  =20

 [old 2231 debate]=20
> I have no idea why this is supposed to be in any way
> relevant to the matters at hand.

RFC 2231 was a MIME update without changing the version
number, EAI allows UTF-8 without changing the version
number, both changes could be considered as not strictly
1.0 backwards compatible.  Only in theory for the former,
for the latter it's hard to judge.

>> s/subtle error/obvious inconsistency/ if that is clearer.
=20
> There is no inconsistency. The message type was intended,
> as the name implies, to represent messages. Given that
> the goal was to eliminate any possibility of a nested
> encoding, it made sense at the time to ban encoding of
> message parts.

Sure.  It makes less sense if an UTF8SMTP sender somehow=20
manages that the reverse path requires 7bit for a DSN,
my application/message idea to get over 7bit hops was
in essence the same as nested B64, nobody on the public
EAI list liked it.

> What has happened subsequently is that the definition
> of message has been stretched to cover some things that
> aren't really messages per se. And EAI is stretching
> that even further. And this is what has created the
> "obvious inconsistency" you refer to.

My impression for message subtypes in RFC 2046 was that
message/unknown is actually opaque, to be handled like
an application/octet-stream, where B64 is allowed, while
multipart is multipart, where only 7bit / 8bit / binary
counts, other CTEs only within the multipart. =20

>From there I arrived at the conclusion that the RFC 2045=20
"expressly forbidden" means MUST for any multipart/* and
"only" SHOULD for message/unknown, with explicit MUSTard
for message/rfc822 etc.  A subtle difference, an erratum
could explain it - likely pointless, nobody on the MIME
types list bothered to question why message/global wants
or needs unusual CTE rules. =20

> Whatever justification floats your boat is fine with me.
> Just please refrain from applying 20:20 hindsight to
> complex decisions with a significant political component
> made well over 15 years ago.

If there were other _technical_ reasons for the message/*
and multipart/* difference in RFC 2046 I'm curious what
they were.  Intentionally violating a SHOULD is bad enough,
getting it wrong would be FUBAR.  If there's anything above
IETF politics in 1996 that I don't see I'd really like to
know it.  An application/message hack would be clumsy, but
better than breaking the "email architecture" or something.

> Like it or not, EAI's success will depend on the extent
> to which it's adopted and once adopted the extent to which
> it causes issues for the installed base of email services,
> including but not limited to the major antispam vendors
> and a myriad of others.

I can't say that I "like" or "dislike" EAI, or that I would
be "happy" if EAI is a success.  It could disappoint folks
considering US-ASCII as gibberish if it fails, that would be
sad.  It would be also sad for the folks who worked hard on
EAI - that is why I'm worried about introducing the "nice to
have" detail UTF-8 in MIME part headers, if its side-effects
could contribute to a failure.

 Frank

From: [email-masked]
Cc: [email-masked]
Date: Tue, 11 Mar 2008 08:14:20 -0700 (PDT)
Subject: Re: email-arch -- comments solicited on I8N
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> <[email-masked]> wrote:
  
> > The email architecture documeent is needed now and shouldn't
> > have to wait for any of this.

> The text I've proposed just offers a pointer to the existing
> RFC 4952,

And that goes too far. To paraphrase and agree with Dave: This document
describes what is, not what might or will be.

> nothing extravagant like assuming that 2822upd will
> be ready before email-arch, or missing normative references
> for EAI will be trivial, e.g., mailing-lists => mailto-eai =>
> mailto-bis is a chain with a very difficult mailto-bis step.

On the contrary, it is pretty likely that 2822upd long before EAI has
deployment even as an experiment sufficient to warrant mention here. 2822upd is
therefore a much better bet.

> Not mentioning EAI at all in the I18N considerations would be
> odd.

No, mentioning it would be.

> FWIW my proposal also covers "euclidean MIME" RFC 2231,
> RFC 1869, BCP 15, RFC 3282, STD 63, and BCP 47.  Of course it
> depends on what folks reading email-arch actually expect.

Your proposed text is fine except the last paragraph needs to be dropped and 
change "allows to use" -> "allows the use" in the next to last paragraph.

> If email-arch is for email what TAObis or roadmap are for the
> IETF,

Neither comparison is even close as far as I can tell.

> then it should offer the most relevant references for
> all important aspects of the architecture,  the 7bit or 8bit
> or Unicode aspect is important, many RFCs tried to tackle it,
> and there will be more (not limited to EAI).

The word you're missing here is "deployed".

> If readers try to find out how email really works, starting
> with the fundamental concepts of "route" vs." "MX", then I
> can only hope that they read 821/822 first, then 1123, after
> that 2821bis or (2)822(upd) or email-arch could make sense.

> IMO email-arch is more a FYI than standards track.  The lack
> of an explanation for "border MTA" is a problem, and there is
> no way to solve it (in this memo).

I agree it is a little awkward, although not for the reasons you give, but
unfortunately political realities more or less demand that it be standards
track.

In any case, now is not the time to rehash the whole
our-document-categories-don't-fit-current-reality thing. If you want that take
it to the main IETF list - I think we're just about due for another round of it
there.

> Back to EAI:
> >> For one (= ignoring an "expressly forbidden") I think it
> >> is actually only a subtle error in RFC 2045.
 
> > I'm well aware of this issue, and I disagree completely with
> > your chararacterization of this as a "subtle error".

> Well, I went as far as a *request* for external review by the
> unknown MIME expert cited in a mail by John on the EAI list,
> and that boils down to "could please one of Ned / Keith / ...
> confirm that EAI got it right".

Again, I simply don't know if EAI got it "right".

> > The fact of the matter is that nested encodings were
> > extremely contentious issue at the time MIME was created
> > and we were well aware of the consequence - both short and
> > long term - of including this restriction. It was quite
> > simply the only possible path forward.

> > It may be that the time has come to remove the restriction.
> > Or it may not. But no matter how it plays out, the reality
> > is that without this restriction MIME would not have made it
> > out in a usable form.

> Yes, so far it is clear, and as you probably know from some
> USEFOR debates I like MIME 1.0 so much that I even considered
> "euclidean MIME" RFC 2231 as suspicious.  And fortunately you
> told USEFOR in time what you think about "non-euclidean" MIME
> with name=value1; name=value2 instead of name="value1 value2",
> no matter how ugly the effect is for values in quoted strings.

I have no idea why this is supposed to be in any way relevant to 
the matters at hand.

> > This choice is therefore a lot of things, some of them not
> > especially nice, but "subtle error" isn't even close to
> > being on the list.

> If you think that "expressly forbidden" in RFC 2045 is still
> state of the art also for message subtypes EAI has a problem.

Again, the answer is "I don't know". And yes, that means that EAI may  have a
problem - quite possibly a big problem. Or it may not.

> And the "subtle error" ends up in RFC 2046, where the message
> subtypes explicitly specify which CTEs are okay, and multipart
> subtypes have an overall rule, reflecting the 2045 "expressly
> forbidden" rule <http://article.gmane.org/gmane.ietf.ima/2150>

> s/subtle error/obvious inconsistency/ if that is clearer.

There is no inconsistency. The message type was intended, as the name
implies, to represent messages. Given that the goal was to eliminate
any possibility of a nested encoding, it made sense at the time to
ban encoding of message parts.

What has happened subsequently is that the definition of message has been
stretched to cover some things that aren't really messages per se. And EAI is
stretching that even further. And this is what has created the "obvious
inconsistency" you refer to.

> The EAI folks convinced me that their solution should be acceptabl
> and that 2045 slightly exaggerated the intentions for message/*
> in comparison with multipart/*.

Whatever justification floats your boat is fine with me. Just please refrain
from applying 20:20 hindsight to complex decisions with a significant political
component made well over 15 years ago.

>  [UTF-8 in MIME part headers]
> > It could go either way, alrhough my guess is the real issues
> > with EAI will turn out to be things none of us anticipate now.

> ACK, actually I don't care too much about the odd UTF-8 in MIME
> part headers of MIME version 1.0, of course it is wrong, but so
> what, saying version 1.2 (1.1 is a secret for "euclidean MIME")
> could be a worse idea.  I am worried about the *definition* of
> messasge/global requiring MTAs to parse the MIME structure:

> If MTAs look for trouble they will find trouble, and it is not
> my fault if some embedded MIME structures have syntax errors.
> Looking at the message header instead of the complete structure
> should suffice to identify a message/global.

> > For example, I'm very concerned about how EAI will interact
> > with existing antispam mechanisms. A widespread conflict in
> > this regard could render it effectively undeployable.

> No serious conflict with RFC 4408, and for RFC 4871 both sides
> apparently decided to ignore each other for now.  Admittedly I
> was perplexed that folks spend time on EAI instead of trying
> to "solve" the spam problem first, OTOH they'd likely have to
> wait forever otherwise.

I'm sorry, but the notion that SPF in practice, let alone an experimental RFC
that covers only part of the picture, has much if anything to do with real
world spam fighting techniques is nothing short of ludicrious.

Like it or not, EAI's success will depend on the extent to which it's adopted
and once adopted the extent to which it causes issues for the installed base of
email services, including but not limited to the major antispam vendors and a
myriad of others. You may deplore the extent to which we depend on these sorts
of factors we cannot control for successful deployment, and I might even agree
to a certain extent, but our deploring it won't change matters any.

> > none of this is in any way relevant to the matter at hand,
> > which is getting the email architecture document done and
> > out the door.

> Without "border MTA" I can't do much with it in discussions on
> the SPF list, a glossary and overview.  I'll stick to MON and
> MRN and envelope sender address when it better expresses what
> I mean.

I'm sure you'll use whatever terminology you feel is appropriate.

> > You may believe that holding up this document in order to
> > get EAI into it makes sense, but I quite simply disagree.

> I don't believe this, I only answered the question what to
> put in the I18N consideration.  And if the author prefers to
> ignore RFC 2277 that is his decision.  I like Harald's wild
> 50 years master plan (still 40 years to go until UTF-8 will
> be the only charset, according to RFC 2277 ;-)

Really, I don't see why this has to be so hard. RFC 2277 defines policies for
the use of charsets in IETF protocols. This is indirectly related at best to
what's out there, so unless thre's a compelling reason to jump across
that indirection - and you haven't given one - it doesn't warrant mention
in email-arch.

				Ned

Content-class: urn:content-classes:message
Subject: RE: email-arch -- Security Considerations
Date: Tue, 11 Mar 2008 11:18:34 -0400
From: "MH Michael Hammer (5304)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Well wordsmithed. Why does it remind me of a EULA?

Mike

>-----Original Message-----
>From: [email-masked]=20
>[mailto:[email-masked]] On Behalf Of Dave Crocker
>Sent: Tuesday, March 11, 2008 11:06 AM
>To: [email-masked]
>Subject: Re: email-arch -- Security Considerations
>
>
>
>
>Dave Crocker wrote:
>> A question has been raised about the very brief Security=20
>> Considerations section in the email-arch draft.  I've modified the=20
>> section slight, for the next draft, but the section still defers=20
>> meaningful discussion to existing specifications.
>
>
>
>Having now received candidate text, and having now worked=20
>vigorously to distort it beyond any hope of its having=20
>benefit, here is what I propose for the Security=20
>Considertations section:
>
>
>
>
><section title=3D"Security Considerations">
>
>      <t>This document describes existing Internet Mail=20
>architecture. It introduces no new new capabilities. The=20
>security considerations of this deployed architecture are=20
>already documented extensively in the technical specifications=20
>referenced by this document. These specifications cover=20
>classic security topics, such as authentication and privacy.=20
>For example, email transfer protocols can use standardized=20
>mechanisms for operation over authenticated and/or encrypted=20
>links, and message content has similar protection standards=20
>available. </t>
>
>      <t>The core of the Internet Mail architecture does not=20
>impose any security requirements or functions on the=20
>end-to-end or hop-by-hop components. For example, it does not=20
>require participant authentication and does not attempt to=20
>prevent data disclosure.</t>
>
>      <t>Particular message attributes might expose specific=20
>security considerations.  For example, the "blind carbon copy"=20
>feature of the architecture invites disclosure concerns, as=20
>discussed in section 7.2 of [RFC2821] and section 5 of=20
>[RFC2822].  Transport of text or non-text content in this=20
>architecture has security considerations that are discussed in=20
>[RFC2822], [RFC2045], [RFC2046], and [RFC4288] as well as the=20
>security considerations present in the IANA media types=20
>registry for the respective types. </t>
>
>      <t>Agents that automatically respond to email have=20
>significant security considerations, as discussed in=20
>[RFC3834].  Gateway behaviors impact end-to-end security=20
>services, as discussed in [RFC2480]. Security considerations=20
>for boundary filters are discussed in [RFC3028].</t>
>
>      <t>See section 7.1 of [RFC2821] for a discussion of the=20
>topic of origination validation.  As mentioned in section=20
>4.1.4, it is common practice for components of this=20
>architecture to use the RFC0791.SourceAddr to make policy=20
>decisions [RFC2505], although it is possible "spoof" this=20
>address -- that is, to use it without authorization.  SMTP and=20
>Submission authentication [RFC2554], [RFC4409] provide more=20
>secure alternatives.</t>
>
>      <t>The current document's discussion of trust=20
>boundaries, ADMDs, actors, roles  and responsibilities all=20
>highlight the relevance and potential complexity of security=20
>factors for operation of an Internet mail service.  Internet=20
>Mail's core design to encourage open and casual exchange of=20
>message's has met with scaling challenges, as the population=20
>of email participants has grown to include those with=20
>problematic practices. For example, spam, as defined in=20
>[RFC2505], is a consequence of this architecture.  A number of=20
>standards track or BCP documents on the subject have been=20
>issued. [RFC2505], [ID-spamops],[RFC3685].</t>
>
></section>
>
>
>
>
>
>
>
>--=20
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
>
>
>

Date: Tue, 11 Mar 2008 11:06:02 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: email-arch -- Security Considerations
Sender: [email-masked]

Dave Crocker wrote:
> A question has been raised about the very brief Security Considerations 
> section in the email-arch draft.  I've modified the section slight, for the 
> next draft, but the section still defers meaningful discussion to existing 
> specifications.

Having now received candidate text, and having now worked vigorously to distort 
it beyond any hope of its having benefit, here is what I propose for the 
Security Considertations section:

<section title="Security Considerations">

      <t>This document describes existing Internet Mail architecture. It
introduces no new new capabilities. The security considerations of this deployed
architecture are already documented extensively in the technical specifications
referenced by this document. These specifications cover classic security topics,
such as authentication and privacy. For example, email transfer protocols can
use standardized mechanisms for operation over authenticated and/or encrypted
links, and message content has similar protection standards available. </t>

      <t>The core of the Internet Mail architecture does not impose any security
requirements or functions on the end-to-end or hop-by-hop components. For
example, it does not require participant authentication and does not attempt to
prevent data disclosure.</t>

      <t>Particular message attributes might expose specific security
considerations.  For example, the "blind carbon copy" feature of the
architecture invites disclosure concerns, as discussed in section 7.2 of
[RFC2821] and section 5 of [RFC2822].  Transport of text or non-text content in
this architecture has security considerations that are discussed in [RFC2822],
[RFC2045], [RFC2046], and [RFC4288] as well as the security considerations
present in the IANA media types registry for the respective types. </t>

      <t>Agents that automatically respond to email have significant security
considerations, as discussed in [RFC3834].  Gateway behaviors impact end-to-end
security services, as discussed in [RFC2480]. Security considerations for
boundary filters are discussed in [RFC3028].</t>

      <t>See section 7.1 of [RFC2821] for a discussion of the topic of
origination validation.  As mentioned in section 4.1.4, it is common practice
for components of this architecture to use the RFC0791.SourceAddr to make policy
decisions [RFC2505], although it is possible "spoof" this address -- that is, to
use it without authorization.  SMTP and Submission authentication [RFC2554],
[RFC4409] provide more secure alternatives.</t>

      <t>The current document's discussion of trust boundaries, ADMDs, actors,
roles  and responsibilities all highlight the relevance and potential complexity
of security factors for operation of an Internet mail service.  Internet Mail's
core design to encourage open and casual exchange of message's has met with
scaling challenges, as the population of email participants has grown to include
those with problematic practices. For example, spam, as defined in [RFC2505], is
a consequence of this architecture.  A number of standards track or BCP
documents on the subject have been issued. [RFC2505], [ID-spamops],[RFC3685].</t>

</section>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: email-arch -- comments solicited on I8N
Date:  Tue, 11 Mar 2008 14:21:26 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 124
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<[email-masked]> wrote:
 =20
> The email architecture documeent is needed now and shouldn't
> have to wait for any of this.

The text I've proposed just offers a pointer to the existing
RFC 4952, nothing extravagant like assuming that 2822upd will
be ready before email-arch, or missing normative references
for EAI will be trivial, e.g., mailing-lists =3D> mailto-eai =3D>
mailto-bis is a chain with a very difficult mailto-bis step.

Not mentioning EAI at all in the I18N considerations would be
odd.  FWIW my proposal also covers "euclidean MIME" RFC 2231,
RFC 1869, BCP 15, RFC 3282, STD 63, and BCP 47.  Of course it
depends on what folks reading email-arch actually expect.

If email-arch is for email what TAObis or roadmap are for the
IETF, then it should offer the most relevant references for
all important aspects of the architecture,  the 7bit or 8bit
or Unicode aspect is important, many RFCs tried to tackle it,
and there will be more (not limited to EAI).

If readers try to find out how email really works, starting
with the fundamental concepts of "route" vs." "MX", then I
can only hope that they read 821/822 first, then 1123, after
that 2821bis or (2)822(upd) or email-arch could make sense.

IMO email-arch is more a FYI than standards track.  The lack=20
of an explanation for "border MTA" is a problem, and there is
no way to solve it (in this memo). =20

Back to EAI:
>> For one (=3D ignoring an "expressly forbidden") I think it
>> is actually only a subtle error in RFC 2045.
=20
> I'm well aware of this issue, and I disagree completely with
> your chararacterization of this as a "subtle error".

Well, I went as far as a *request* for external review by the
unknown MIME expert cited in a mail by John on the EAI list,
and that boils down to "could please one of Ned / Keith / ...
confirm that EAI got it right".

> The fact of the matter is that nested encodings were
> extremely contentious issue at the time MIME was created
> and we were well aware of the consequence - both short and
> long term - of including this restriction. It was quite
> simply the only possible path forward.

> It may be that the time has come to remove the restriction.
> Or it may not. But no matter how it plays out, the reality
> is that without this restriction MIME would not have made it
> out in a usable form.

Yes, so far it is clear, and as you probably know from some
USEFOR debates I like MIME 1.0 so much that I even considered
"euclidean MIME" RFC 2231 as suspicious.  And fortunately you
told USEFOR in time what you think about "non-euclidean" MIME
with name=3Dvalue1; name=3Dvalue2 instead of name=3D"value1 value2",
no matter how ugly the effect is for values in quoted strings.

> This choice is therefore a lot of things, some of them not
> especially nice, but "subtle error" isn't even close to
> being on the list.

If you think that "expressly forbidden" in RFC 2045 is still
state of the art also for message subtypes EAI has a problem.

And the "subtle error" ends up in RFC 2046, where the message
subtypes explicitly specify which CTEs are okay, and multipart
subtypes have an overall rule, reflecting the 2045 "expressly
forbidden" rule <http://article.gmane.org/gmane.ietf.ima/2150>

s/subtle error/obvious inconsistency/ if that is clearer.  The
EAI folks convinced me that their solution should be acceptable
and that 2045 slightly exaggerated the intentions for message/*
in comparison with multipart/*.

 [UTF-8 in MIME part headers]
> It could go either way, alrhough my guess is the real issues
> with EAI will turn out to be things none of us anticipate now.

ACK, actually I don't care too much about the odd UTF-8 in MIME
part headers of MIME version 1.0, of course it is wrong, but so
what, saying version 1.2 (1.1 is a secret for "euclidean MIME")
could be a worse idea.  I am worried about the *definition* of
messasge/global requiring MTAs to parse the MIME structure:

If MTAs look for trouble they will find trouble, and it is not
my fault if some embedded MIME structures have syntax errors.
Looking at the message header instead of the complete structure
should suffice to identify a message/global.

> For example, I'm very concerned about how EAI will interact=20
> with existing antispam mechanisms. A widespread conflict in
> this regard could render it effectively undeployable.

No serious conflict with RFC 4408, and for RFC 4871 both sides
apparently decided to ignore each other for now.  Admittedly I
was perplexed that folks spend time on EAI instead of trying
to "solve" the spam problem first, OTOH they'd likely have to
wait forever otherwise.

> none of this is in any way relevant to the matter at hand,
> which is getting the email architecture document done and
> out the door.

Without "border MTA" I can't do much with it in discussions on
the SPF list, a glossary and overview.  I'll stick to MON and
MRN and envelope sender address when it better expresses what
I mean.

> You may believe that holding up this document in order to
> get EAI into it makes sense, but I quite simply disagree.

I don't believe this, I only answered the question what to
put in the I18N consideration.  And if the author prefers to
ignore RFC 2277 that is his decision.  I like Harald's wild
50 years master plan (still 40 years to go until UTF-8 will
be the only charset, according to RFC 2277 ;-)

 Frank
--=20
<http://omniplex.blogspot.com/2008/02/patch-that-zeppelin.html>

Date: Tue, 11 Mar 2008 08:08:03 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: email-arch -- comments solicited on I8N
Sender: [email-masked]

[email-masked] wrote:
> 
>> <[email-masked]> wrote:
>  
>>> given that the only document out of EAI that has made
>>> it to RFC status is an informational overview
> 
>> The next two EAI Last Calls started yesterday, there can
>> be four EAI RFCs soon.
> 
> And once there are it will take considerable time for the experiment to even
> start in a meaningful way, assuming it ever does.  The email architecture
> documeent is needed now and shouldn't have to wait for any of this. It can
> always be revised later to reflect the extent to which EAI becomes a reality.

Right.

There has always been a strong temptation to have the document refer to what 
should be, could be, or will be (for some definition of "will", given the 
inability to predict the future successfully.)  After all, these would allow 
casting an improved system, and who doesn't want the system to be better?

But the decision from the start was to have this particular document only 
specify what is.  And believe me, that has been more than enough challenge. 
Astonishingly, even with this constraint, the effort has required more inventive 
design than I've ever had to do, at the least suggesting that we (the aggregated 
email technical and operations community) really haven't had a thorough and 
shared understanding of the current service.

I've chosen to interpret that fact as demonstrating how important it is to stick 
with "is".

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: [email-masked]
Cc: [email-masked]
Date: Tue, 11 Mar 2008 02:29:27 -0700 (PDT)
Subject: Re: email-arch -- comments solicited on I8N
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> <[email-masked]> wrote:
 
> > given that the only document out of EAI that has made
> > it to RFC status is an informational overview

> The next two EAI Last Calls started yesterday, there can
> be four EAI RFCs soon.

And once there are it will take considerable time for the experiment to even
start in a meaningful way, assuming it ever does.  The email architecture
documeent is needed now and shouldn't have to wait for any of this. It can
always be revised later to reflect the extent to which EAI becomes a reality.

  I'm very curious what you think
> about the one or two "experimental MIME updates" in the
> EAI I-Ds.  For one (= ignoring an "expressly forbidden")
> I think it is actually only a subtle error in RFC 2045.

I'm well aware of this issue, and I disagree completely with your
chararacterization of this as a "subtle error". The fact of the matter is that
nested encodings were extremely contentious issue at the time MIME was created
and we were well aware of the consequence - both short and long term - of
including this restriction. It was quite simply the only possible path forward.

It may be that the time has come to remove the restriction. Or it may  not. But
no matter how it plays out, the reality is that without this restriction MIME
would not have made it out in a usable form. This choice is therefore  a lot of
things, some of them not especially nice, but "subtle error" isn't even close
to being on the list.

> For the other (= UTF-8 in MIME part headers) I fear it
> could cause havoc, and is unnecessary for EAI.  Please
> tell me that this is a hallucination on my side, and no
> real EAI design issue.

It could go either way, alrhough my guess is the real issues with EAI will turn
out to be things none of us anticipate now. For example, I'm very concerned
about how EAI will interact with existing antispam mechanisms. A widespread
conflict in this regard could render it effectively undeployable. I'm also
curious to see to who will want this and where.

All of these things are part and parcel of why EAI has been cast as an
experiment.

But really, none of this is in any way relevant to the matter at hand, which is
getting the email architecture document done and out the door. You may believe
that holding up this document in order to get EAI into it makes sense, but I
quite simply disagree.

				Ned

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: email-arch -- comments solicited on I8N
Date:  Tue, 11 Mar 2008 09:34:39 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 17
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

<[email-masked]> wrote:
=20
> given that the only document out of EAI that has made
> it to RFC status is an informational overview

The next two EAI Last Calls started yesterday, there can
be four EAI RFCs soon.  I'm very curious what you think
about the one or two "experimental MIME updates" in the
EAI I-Ds.  For one (=3D ignoring an "expressly forbidden")
I think it is actually only a subtle error in RFC 2045.

For the other (=3D UTF-8 in MIME part headers) I fear it
could cause havoc, and is unnecessary for EAI.  Please
tell me that this is a hallucination on my side, and no
real EAI design issue.

 Frank

From: [email-masked]
Cc: [email-masked]
Date: Mon, 10 Mar 2008 21:57:37 -0700 (PDT)
Subject: Re: email-arch -- comments solicited on I8N
To: SM <[email-masked]>
Sender: [email-masked]

> At 05:05 10-03-2008, Dave Crocker wrote:
> >I believe all that can reasonably be in the document is something
> >along the lines of:
> >
> >
> >      Internet Mail standards currently support the use of non-ASCII character
> >      sets in the message body <rfc 2045> and header fields <rfc 2047>.  There
> >      is an open requirement for this capability in email addresses.

> This document attempts to document the existing email
> architecture.  There can be a mention of the experiment to extend
> existing standards to support Internationalized Email.

That's arguably OK but IMO kind of pointless. And given that the only document
out of EAI that has made it to RFC status is an informational overview, it
is entirely inappropriate to include any technical specifics of EAI at this
time.

				Ned

Date: 11 Mar 2008 04:28:59 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: email-arch -- comments solicited on I8N
Organization: 
Cc: [email-masked]
Sender: [email-masked]

>This is definitely all that should be said about email addresses at this
>point. My understanding is that the output of EAI is experiemental. There's
>a LONG way to go before this is a done deal.

Yeah.  I've looked at EAI which seems awful, but Paul Hoffman tells me
that the alternatives have even worse problems.  So I concur that this
is a swamp that we should refrain from entering.

R's,
John

Date: Mon, 10 Mar 2008 16:53:54 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: email-arch -- comments solicited on I8N
Sender: [email-masked]

At 05:05 10-03-2008, Dave Crocker wrote:
>I believe all that can reasonably be in the document is something 
>along the lines of:
>
>
>      Internet Mail standards currently support the use of non-ASCII character
>      sets in the message body <rfc 2045> and header fields <rfc 2047>.  There
>      is an open requirement for this capability in email addresses.

This document attempts to document the existing email 
architecture.  There can be a mention of the experiment to extend 
existing standards to support Internationalized Email.

Regards,
-sm

Date: Mon, 10 Mar 2008 19:39:50 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: email-arch -- comments solicited on I8N
Sender: [email-masked]

ack. tnx.

d/

[email-masked] wrote:
> 
> 
> 
>> Stephane Bortzmeyer wrote:
>>  >  John Levine <[email-masked]> wrote:
>>  >> I presume that we'll eventually use some version of punycode
>>  >
>>  > This is not really the approach taken by the EAI working group...
> 
> 
> 
> 
>> Well, these two notes in this thread nicely demonstrate a pitfal of 
>> attempting
>> to record the current architecture should not cite work underway or
>> possible for the future.  Things are too fluid and, therefore, 
>> unpredictable.
> 
> 
>> I believe all that can reasonably be in the document is something 
>> along the
>> lines of:
> 
> 
>>       Internet Mail standards currently support the use of non-ASCII 
>> character
>>       sets in the message body <rfc 2045> and header fields <rfc 2047>.
> 
> It's not header fields in general but only comments, free text and
> some parameters. You therefore might want to consider saying "some
> header fields". And you might also consider adding RFC 2231 as a reference.
> 
>>  There
>>       is an open requirement for this capability in email addresses.
> 
> This is definitely all that should be said about email addresses at this
> point. My understanding is that the output of EAI is experiemental. There's
> a LONG way to go before this is a done deal.
> 
>                 Ned
> 

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon, 10 Mar 2008 16:00:51 -0700 (PDT)
Subject: Re: email-arch -- comments solicited on I8N
To: Dave Crocker <[email-masked]>
Sender: [email-masked]

> Stephane Bortzmeyer wrote:
>  >  John Levine <[email-masked]> wrote:
>  >> I presume that we'll eventually use some version of punycode
>  >
>  > This is not really the approach taken by the EAI working group...

> Well, these two notes in this thread nicely demonstrate a pitfal of attempting
> to record the current architecture should not cite work underway or
> possible for the future.  Things are too fluid and, therefore, unpredictable.

> I believe all that can reasonably be in the document is something along the
> lines of:

>       Internet Mail standards currently support the use of non-ASCII character
>       sets in the message body <rfc 2045> and header fields <rfc 2047>.

It's not header fields in general but only comments, free text and
some parameters. You therefore might want to consider saying "some
header fields". And you might also consider adding RFC 2231 as a reference.

>  There
>       is an open requirement for this capability in email addresses.

This is definitely all that should be said about email addresses at this
point. My understanding is that the output of EAI is experiemental. There's
a LONG way to go before this is a done deal.

				Ned

Date: Mon, 10 Mar 2008 18:00:46 -0400
From: Harald Tveit Alvestrand <[email-masked]>
To: Chris Newman <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Request for advancement, draft-hansen-4468upd-mailesc-registry-04
Sender: [email-masked]

I am hereby requesting that the IESG consider advancing 
draft-hansen-4468upd-mailesc-registry-04 to BCP status.
(I choose to apply for BCP status because the major component of the draft 
is establishing and initializing an IANA registry.)

As required by RFC-to-be draft-iesg-sponsoring-guidelines,
this is the current template for the Document Shepherd Write-Up
for individual submissions via the IESG.

Changes are expected over time.  This version is dated February 5, 2007.

   (1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the document
      and, in particular, does he or she believe this version is ready
      for forwarding to the IESG for publication?

	Harald Tveit Alvestrand <[email-masked]>

   (1.b)  Has the document had adequate review both from key members of
      the interested community and others?  Does the Document Shepherd
      have any concerns about the depth or breadth of the reviews that
      have been performed?

	The document has been reviewed on the ietf-smtp mailing list,
	which is the same mailing list as used for the SMTP update.
	The shepherd believes that review has been adequate.

   (1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective, e.g.,
      security, operational complexity, someone familiar with AAA,
      internationalization or XML?

	No.

   (1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he or
      she is uncomfortable with certain parts of the document, or has
      concerns whether there really is a need for it.  In any event, if
      the interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

	No.

   (1.e)  How solid is the consensus of the interested community behind
      this document?  Does it represent the strong concurrence of a few
      individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

	There seems to be solid consensus that this document is needed,
	and consensus that the current document is adequate.

   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

	No.

   (1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
      enough; this check needs to be thorough.  Has the document met all
      formal review criteria it needs to, such as the MIB Doctor, media
      type and URI type reviews?

	yes.
	Note: idnits mentions one obsoleted reference. This is a
	deliberate historical reference.

   (1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that are
      not ready for advancement or are otherwise in an unclear state?
      If such normative references exist, what is the strategy for their
      completion?  Are there normative references that are downward
      references, as described in [RFC3967]?  If so, list these downward
      references to support the Area Director in the Last Call procedure
      for them [RFC3967].

	Yes, no, irrelevant, no.

   (1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document?  If the document specifies protocol extensions, are
      reservations requested in appropriate IANA registries?  Are the
      IANA registries clearly identified?  If the document creates a new
      registry, does it define the proposed initial contents of the
      registry and an allocation procedure for future registrations?
      Does it suggested a reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  If the document
      describes an Expert Review process has Shepherd conferred with the
      Responsible Area Director so that the IESG can appoint the needed
      Expert during the IESG Evaluation?

	Yes.

   (1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML code,
      BNF rules, MIB definitions, etc., validate correctly in an
      automated checker?

	Yes. There are no such sections.

   (1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:

      Technical Summary

   The specification for enhanced mail system enhanced status codes, RFC
   3463, establishes a new code model and lists a collection of status
   codes.  While it anticipated that more codes would be added over
   time, it did not provide an explicit mechanism for registering and
   tracking those codes.  This document specifies an IANA registry for
   mail system enhanced status codes, and initializes that registry with
   the codes so far established in published standards-track documents,
   as well as other codes that have become established in the industry.

      Working Group Summary

	This document has been reviewed on the ietf-smtp mailing list.
	There have been several comments on details, which have largely
	been incorporated, and substantial revisions from the first draft
	to this one. No objection to the effort has been made; the
	authors have been commended for undertaking the effort.

      Document Quality

	The document has been reviewed by the mailing list and the document
	shepherd. The specific codes described here document existing
	practice, except for the newly defined codes that are concerned
	with resolving conflicts between multiple usages of codepoints
	in present usage.

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: email-arch -- comments solicited on I8N
Date:  Mon, 10 Mar 2008 14:46:29 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 13
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Dave Crocker wrote:

> Comments?

I like my proposal better, RFC 4952 is published,
and the "DSN" EAI draft is already in Last Call.

Nobody is going to invent something with punycode
in the local part anytime soon - conflicting IETF
experiments are a known bad idea, no matter what
the IAB said.

 Frank

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Off-topic: Partly unreadable mail from Martin/Eudora
Date:  Mon, 10 Mar 2008 14:29:45 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 50
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> I haven't seen an unGIGOed copy of that particular message

The "raw" ISO-2022-JP input from my "OE behind GMaNe" POV
is <http://article.gmane.org/gmane.ietf.idnabis/1235/raw>
in reply to a From: =3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D

Actually RFC 1468, not RFC 1554, and that could be a part
of the problem, RFC 1554 apparently offers Latin-1 as G2
in conjunction with SS2, it can also invoke Greek as G2.

RFC 1468 apparently doesn't have this feature, and so the
MUA is lost with Latin-1 =3DE4 and =3DF6 in the From, it tries

| Patrik F ESC$B 674D ESC(B str ESC$B 8B4E ESC(B wrote:

Where ESC$B introduces some double byte JIS-1983 chars.s,
certainly not =E4 or =F6, and the m is lost in space.        =20

> If you can fix your MUA or get it fixed

I guess OE does the right thing for 674D and 8B4E, I have
installed support for JP (or rather Martin's MUA), and it
works when it is no case of GiGo, as far as I could figure
it out with a huge GIF of JP glyphs.

> I'm lazy about reporting bugs to big companies.

The latest Eudora is a Thunderbird clone, nothing to do:
http://en.wikipedia.org/wiki/Eudora_(e-mail_client)#Opening_the_source

> Claranet has rejected mail from me since last summer. I=20
> gather I'm an open relay or spammer or something.

No, it used to be an ordinary over quota case for a 150 MB
mailbox getting about 100 MB spam daily, after my OS/2 box
died I was unable to delete the spam for some weeks.  When
I was again POP3-killing spam over a V.90 line claranet.de
changed the password in November, maybe they had enough of
one user occupying a POP3 port about 8 hours per day only
to delete spam, and I also wasn't happy with the situation.

The Reply-To: Gmail address works.  I still hope to revive
the old account for write access on my "primary" homepage
at some point in time, OTOH the old catchall addresses are
hopeless.  At least I can claim that it was my ISP who gave
up with the spam flood to [email-masked], not me :-|

 Frank

Date: Mon, 10 Mar 2008 08:05:55 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: email-arch -- comments solicited on I8N
Sender: [email-masked]

Stephane Bortzmeyer wrote:
 >  John Levine <[email-masked]> wrote:
 >> I presume that we'll eventually use some version of punycode
 >
 > This is not really the approach taken by the EAI working group...

Well, these two notes in this thread nicely demonstrate a pitfal of attempting 
to record the current architecture should not cite work underway or
possible for the future.  Things are too fluid and, therefore, unpredictable.

I believe all that can reasonably be in the document is something along the 
lines of:

      Internet Mail standards currently support the use of non-ASCII character
      sets in the message body <rfc 2045> and header fields <rfc 2047>.  There
      is an open requirement for this capability in email addresses.

Comments?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 10 Mar 2008 12:04:49 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Off-topic: Partly unreadable mail from Martin/Eudora
Cc: Frank Ellermann <[email-masked]>, Frank Ellermann <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> If you can fix your MUA or get it fixed, good test cases are ESC $ B 
> NUL ESC ( B and ESC $ B NUL ESC ( B.

Sorry. That should be one NULs and two.

Arnt

Date: Mon, 10 Mar 2008 11:18:32 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Off-topic: Partly unreadable mail from Martin/Eudora
Cc: Frank Ellermann <[email-masked]>, Frank Ellermann <[email-masked]>
Sender: [email-masked]

Frank Ellermann writes:
> Whatever causes my MUA to display Japanese characters in replies to=20
> Patrik F=E4ltstr=F6m from Martin, I'm willing to blame it on RFC 2130, =
or=20
> rather its RFC 1554 reference. :-)

Martin's MUA (Eudora 6J) sends illegal output. I haven't seen an=20
unGIGOed copy of that particular message, but I looked carefully at=20
some other messages. The messages start with ASCII, to a double-byte=20
character set, and then sends something which doesn't match the=20
"double-byte-segment" syntax. It can be an odd number of bytes or it=20
can be bytes which don't match "one-of-94". If you can fix your MUA or=20
get it fixed, good test cases are ESC $ B NUL ESC ( B and ESC $ B NUL=20
ESC ( B.

I sent Martin a note about it in August 2006. No idea whether I've=20
reported it to Qualcomm. I may have, but I'm lazy about reporting bugs=20
to big companies. Another MUA used by a different IETF regular has the=20
same problem, so it's not just Eudora.

Btw, Frank: Claranet has rejected mail from me since last summer. I=20
gather I'm an open relay or spammer or something.

Arnmt

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: email-arch I18N
Date:  Mon, 10 Mar 2008 03:30:08 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 26
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Keld J=F8rn Simonsen wrote:

>> The purpose of an I18N section in email arch would be to offer some
>> pointers for interested readers, plus context wrt the architecture,
>> BCP 15, UTF-8, MIME, 8BITMIME, lang-tags (maybe), and arguably EAI.
=20
> You could also refer RFC 2130 which describes the IAB policies on the
> issue.

That's a predecessor of RFC 2277 (BCP 15) with lots of interesting
details.  I think it is good enough for the purposes of email-arch
when readers find a reference to RFC 2130 in BCP 15, because BCP 15
is "the real thing" (as amended by "net-utf8" and BCP 137 in 2008). =20

There are subtle differences, BCP 15 requires "I18N considerations"
where RFC 2130 mentions "multilingual considerations", BCP 15 says
UTF-8 where RFC 2130 only has Unicode, and some ideas discussed in=20
RFC 2130 like RFC 1345 mnemonics and UTF-7 are not more considered
as state of the art today. =20

[Archived-At: <http://permalink.gmane.org/gmane.ietf.idnabis/1235>]
Whatever causes my MUA to display Japanese characters in replies to
Patrik F=E4ltstr=F6m from Martin, I'm willing to blame it on RFC 2130,
or rather its RFC 1554 reference. :-)

 Frank

Date: Sun, 9 Mar 2008 13:46:26 -0400
From: Stephane Bortzmeyer <[email-masked]>
To: John Levine <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: email-arch -- comments solicited on I8N
Sender: [email-masked]

On Sun, Mar 09, 2008 at 05:08:18AM -0000,
 John Levine <[email-masked]> wrote 
 a message of 14 lines which said:

> I presume that we'll eventually use some version of punycode 

This is not really the approach taken by the EAI working group...

http://www.ietf.org/html.charters/eai-charter.html

Date: Sun, 09 Mar 2008 09:48:08 -0400
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: email-arch-11-05dc: version for ietf@phili, extensive changes
Sender: [email-masked]

Folks,

I finally processed the backlog of suggestions for the email-arch draft.

The changed version is at:

    <http://bbiw.net/recent.html#emailarch>

I'm hoping there can be some informal, face2face discussion during this w=
eek in=20
Philadelphia, depending on folks' interest.

The list of changes is extensive, and there are still open items, includi=
ng=20
needing to provide the details for some citations and to add those that s=
pecify=20
the normative content to the draft.  Also there will be more indexing ref=
erences.

Here is the Changes documentation for the draft:

> <section anchor=3D"changes" title=3D"Changes for This Version">
>             <t>
>                <list style=3D"hanging">
>                   <t hangText=3D"INSTRUCTIONS TO THE RFC EDITOR:  ">Rem=
ove this
>                      sub-section prior to publication.</t>
>                </list>
>             </t>
>=20
>             <t>Many small editing changes, for wordsmithing improvement=
s and to
>                make details more consistent. This section documents cha=
nges with
>                significant impact.</t>
>=20
>=20
>=20
>             <section title=3D"email-arch-11-04dc">
>                <t>
>                   <list style=3D"hanging">
>                      <t hangText=3D"Decoupled receiving MS:  ">The link=
age between
>                         a local MS and a remote one has been removed, t=
o avoid
>                         dealing with the messy, and apparently very rar=
e,
>                         interaction issues when they are linked.</t>
>                      <t hangText=3D"Reference to common folders:  ">Tun=
ed the
>                         language to emphasize that the text offers a co=
mmon
>                         exemplar, not a requirement or restriction and =
not tied
>                         to imap.</t>
>                      <t hangText=3D"Alias vs. Mailing List:  "> Attempt=
ed to
>                         clarify details about Alias and Mailing List me=
diators,
>                         to make their differences objectively clear. Ho=
wever
>                         it's not clear that the distinction can be held=
 that
>                         cleanly. </t>
>                      <t hangText=3D"Diagrams:  "> Added emphasis to beg=
inning and
>                         end nodes, and distinguished primary paths from=

>                         secondary (return) paths. Before publication, n=
on-ascii
>                         art versions will be added for the xml document=
 source.</t>
>                      <t hangText=3D"Authentication for posting:  ">Clar=
ified
>                         recent, increased used of submission-time authe=
ntication</t>
>                      <t hangText=3D"Submission and Delivery transition:=
  "
>                         >Clarified figure and text to explain transfer =
of
>                         responsibility into and out of MHS, with (S) an=
d (D)
>                         transitions in <xref target=3D"Protocols" /></t=
>
>                      <t hangText=3D"Assigning message-id:  ">Slight twe=
ak of
>                         language about assigning and consuming message-=
id.</t>
>                      <t hangText=3D"BCC">Removed paragraph that elabora=
ted on BCC
>                         usage and styles, instead just referring to RFC=
2822.</t>
>                      <t hangText=3D"Dest ADMD pre-delivery msg mod:  ">=
Added note
>                         that MTA in destination ADMD that changes the m=
essage is
>                         a Gateway, not an MTA...</t>
>                      <t hangText=3D"Multiple Msg-ids:  ">Removed refere=
nce to
>                         messages sometimes having more than one message=
-id.</t>
>                      <t hangText=3D"Mailing list setting Reply-To:  ">A=
dded note
>                         in Mailing List discussion about controversy of=
 setting
>                         Reply-To.</t>
>                      <t hangText=3D"Gateway examples:  ">Added citation=
s to fax,
>                         vpim and mms gateway specs. Did not include X.4=
00, since
>                         it is essentially obsolete</t>
>                      <t hangText=3D"Auto-Responder">** pending RFC3834 =
***</t>
>                      <t hangText=3D"Citations for normative assertions:=
  "> ***
>                         ***</t>
>                      <t hangText=3D"Origin vs. Submission:  ">Clarified=
 Actor
>                         diagram and text to map Originator actor to MSA=

>                         functionality.</t>
>                      <t hangText=3D"Reserved mailbox names:  ">Added me=
ntion of
>                         RFC2142</t>
>                      <t hangText=3D"MTA sub-roles: ">border/inbound/out=
bound/final
>                         mta references.</t>
>                      <t hangText=3D"Mediator common info:  ">Mediator s=
ection
>                         initial text had standalone table of informatio=
n. It has
>                         been changed to refer only to information that =
is common
>                         for all Mediators. Within specific Mediator dis=
cussions,
>                         any listing of this common information is was r=
edundant
>                         and has been removed. </t>
>                      <t hangText=3D"Security Considerations:  ">Meager =
revisions
>                         to Security Considerations, stating that the un=
derlying
>                         service does not attend to them, really, and th=
at
>                         particular specifications cover their particula=
r
>                         Considerations.</t>
>                      <t>This is intended to acknowledge the reality of =
Security
>                         Considerations but defer meaningful handling of=
 them to
>                         concrete specifications. This architecture docu=
ment
>                         defers to specifications where possible, in ord=
er to
>                         avoid divergent discussions.</t>
>                      <t hangText=3D"Internationalization:  ">The docume=
nt contains
>                         no discussion of this important topic. Frankly,=
 I have
>                         not thought of what the document should usefull=
y say
>                         about the topic and am particularly worried tha=
t the
>                         problematic and fluid nature of the topic would=
 cause
>                         the architecture document to conflict with the =
reality
>                         of work that is underway. Offerings of candidat=
e text
>                         for the document, to deal with I8N are encourag=
ed.</t>
>                   </list>
>                </t>
>             </section>
>=20
>=20
>             <section title=3D"email-arch-10">
>                <t>
>                   <list style=3D"hanging">
>                      <t hangText=3D"Originator->Author:  "> The term "O=
riginator"
>                         is used by RFC 2822 more broadly than just the =
From:
>                         field, which specifically defines who the autho=
r of the
>                         content is. I believe this distinguishes two co=
nstructs,
>                         one for the content author and one for the firs=
t agency
>                         that handles the message, in terms of the trans=
fer
>                         service. So the change from "Originator" to "Au=
thor"
>                         seems pretty straightforward. The challenge is =
in using
>                         the term Originator, as defined in RFC 2822 and=
 applying
>                         it to the system's architecture. </t>
>                      <t hangText=3D"Source->Originator:  "> This change=
 is more of
>                         a challenge. We need the "Originator" term and
>                         construct, but the architecture is already comp=
lex
>                         enough. Hence, adding a new construct seems lik=
e a very
>                         poor resolution. The document has used "Source"=
 as an
>                         MHS term for the MSA set of functions. While on=
e could
>                         argue against re-labeling it as Originator, I b=
elieve
>                         this is a reasonable choice and likely to be co=
mfortable
>                         for community use, since "Source" does not have=
 an
>                         established history. </t>
>                      <t hangText=3D"Bounce->Return:  ">'bounce address'=
 is not
>                         accurate, because the address is used for more =
than
>                         that, but it *is* an established term within po=
rtions of
>                         the broader email community. I also believe the=

>                         extensive discussion on this point, last year, =
justifies
>                         the change.</t>
>                      <t>The problem with saying "Bounce" is that is not=
 merely
>                         linguistically impure, it is plain wrong and ha=
s already
>                         caused serious problems. Witness SPF. Frankly, =
we need
>                         to fix RFC2821, but that's a separate battle to=
 fight
>                         and not one for this forum.</t>
>                      <t>Although not a verbatim use of "Reverse Path", =
the
>                         related term that seems to work publicly is "Re=
turn
>                         Address". It is already established in the
>                         bricks-and-mortar postal world and seems to hav=
e some
>                         acceptance within parts of the email community.=
 (I've
>                         done a draft white paper on authentication for =
the
>                         Messaging Anti-Abuse Working Group and the memb=
ership
>                         had some debate about this vocabulary choice an=
d
>                         converged on agreeing to it.)</t>
>                      <t hangText=3D"Is env part of  message?:  ">I don'=
t remember
>                         whether we resolved this. For a variety of reas=
ons, I
>                         believe the message includes its envelope, and =
am
>                         encouraged to find RFC2822upd says: <list>
>=20
>                            <t>In the context of electronic mail, messag=
es are
>                               viewed as having an envelope and contents=
=2E The
>                               envelope contains whatever information is=
 needed
>                               to accomplish transmission and delivery. =
(See
>                               [I-D.klensin-rfc2821bis] (Klensin, J., =93=
Simple
>                               Mail Transfer Protocol,=94 November 2007.=
) for a
>                               discussion of the envelope.) The contents=
 comprise
>                               the object to be delivered to the recipie=
nt. This
>                               specification applies only to the format =
and some
>                               of the semantics of message contents.</t>=

>                            <t hangText=3D"Deliver vs. Access:  ">Cleanu=
p the
>                               discussion about 'delivery' out of the MH=
S, versus
>                               message access by the MUA to the MS.</t>
>                         </list></t>
>=20
>                      <t>rfc2821bis says: <list>
>                            <t>SMTP transports a mail object. A mail obj=
ect
>                               contains an envelope and content.</t>
>                         </list> I think these justify having the term '=
message'
>                         as including the object. </t>
>                      <t hangText=3D"Examples of 'new' messages:  ">Sect=
ion <xref
>                            target=3D"msgid" /> contains a list of examp=
les,
>                         discussing scenarios that might or might not be=
 viewed
>                         as creating a "new" message, rather than retain=
ing an
>                         existing one. The list has been expanded.</t>
>                   </list>
>                </t>
>             </section>
>          </section>

--=20

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 9 Mar 2008 14:28:13 +0100
From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: email-arch I18N
Sender: [email-masked]

On Sun, Mar 09, 2008 at 02:09:25PM +0100, Frank Ellermann wrote:
> 
> Alessandro Vesely wrote:
>  
> > It may be worth to explicitly state that, although the *values* of 
> > some headers may be expressed in different languages an possibly 
> > encoded using different charsets, the headers *names* are *not* to
> > be translated into different languages.
> 
> Yes, but I guess that's too far down into 2821bis + 2822upd details,
> of course we don't "translate" MAIL FROM into say "POST VON" (de) or
> similar, like we don't translate <body> in XHTML.
>  
> > some mail clients translate IMAP special-use folders names _on the
> > server_, resulting in a loss of interoperability with clients that
> > expect the de facto standard names.
> 
> The effect of switching from "en" to "en-GB" with Gmail was funny,
> my MUA needed a hard kick to note that the "trash" is now a "bin" ;-)
>  
> While that's funny I don't think it belongs into email-arch, it has
> a normative reference to RFC 3501.  IMAP I18N is a rathole of its
> own right with interesting "lemonade" flamewars.
> 
> The purpose of an I18N section in email arch would be to offer some
> pointers for interested readers, plus context wrt the architecture,
> BCP 15, UTF-8, MIME, 8BITMIME, lang-tags (maybe), and arguably EAI.

You could also refer RFC 2130 which describes the IAB policies on the
issue.

best regards
keld

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  Re: email-arch I18N
Date:  Sun, 9 Mar 2008 14:09:25 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 27
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Alessandro Vesely wrote:
=20
> It may be worth to explicitly state that, although the *values* of=20
> some headers may be expressed in different languages an possibly=20
> encoded using different charsets, the headers *names* are *not* to
> be translated into different languages.

Yes, but I guess that's too far down into 2821bis + 2822upd details,
of course we don't "translate" MAIL FROM into say "POST VON" (de) or
similar, like we don't translate <body> in XHTML.
=20
> some mail clients translate IMAP special-use folders names _on the
> server_, resulting in a loss of interoperability with clients that
> expect the de facto standard names.

The effect of switching from "en" to "en-GB" with Gmail was funny,
my MUA needed a hard kick to note that the "trash" is now a "bin" ;-)
=20
While that's funny I don't think it belongs into email-arch, it has
a normative reference to RFC 3501.  IMAP I18N is a rathole of its
own right with interesting "lemonade" flamewars.

The purpose of an I18N section in email arch would be to offer some
pointers for interested readers, plus context wrt the architecture,
BCP 15, UTF-8, MIME, 8BITMIME, lang-tags (maybe), and arguably EAI.

 Frank

Date: Sun, 09 Mar 2008 12:35:56 +0100
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: email-arch I18N
Sender: [email-masked]

Frank Ellermann wrote:
> Dave Crocker wrote:
>  
>> As for I8N, I believe that doing more in the document requires some
>> rather compelling consensus among the community -- ie, you folk.
> 
> Proposed text, insert in chapter 6 between "Security" and "IANA":
> 
> Internationalization
> 
>  The core email architecture is still based on US-ASCII headers in
>  message/rfc822 objects including any MIME part headers.  Other
>  charsets and the indication of languages in headers require US ASCII
>  compatible MIME encodings as specified in RFC 2047 and RFC 2231.

It may be worth to explicitly state that, although the *values* of 
some headers may be expressed in different languages an possibly 
encoded using different charsets, the headers *names* are *not* to be 
translated into different languages. Mail clients who understand any 
standard name MAY display its translation instead, provided it is 
clear to users what they do (e.g. no translated source views.)

In addition, some mail clients translate IMAP special-use folders 
names _on the server_, resulting in a loss of interoperability with 
clients that expect the de facto standard names. If it were possible 
to state that *any* translation should be carried out by the client on 
the fly, it may help refraining the temptation to internationalize too 
much...

Date: Sun, 09 Mar 2008 00:14:31 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To:  [email-masked]
CC:  [email-masked]
Subject: Re: email-arch -- Security Considerations
Sender: [email-masked]

Dave Crocker wrote:
> 
> Folks,
> 
> A question has been raised about the very brief Security Considerations 
> section in the email-arch draft.  I've modified the section slight, for 
> the next draft, but the section still defers meaningful discussion to 
> existing specifications.
> 
> This is the latest version:
> 
>> <section title="Security Considerations">
>>             <t>This document does not specify any new Internet Mail
>>                functionality. Consequently it is not intended to 
>> introduce any
>>                security considerations, beyond those already 
>> established for
>>                Internet Mail. </t>
>>             <t>However its discussion of the roles and 
>> responsibilities for
>>                different mail service modules, and the information 
>> they create,
>>                highlights the considerable degree to which security 
>> issues are
>>                present when implementing any component of the Internet 
>> Mail
>>                service. In addition, email transfer protocols can 
>> operate over
>>                authenticated and/or encrypted links, and message 
>> content or
>>                authorship can be authenticated and/or encrypted. </t>
>>             <t>The core of the Internet Mail architecture does not 
>> impose any
>>                security requirements or functions on the end-to-end or
>>                hop-by-hop components. Details of security 
>> considerations for
>>                particular Internet Mail mechanisms are provided in the 
>> detailed
>>                specifications for those mechanisms.</t>
>>          </section>
> 
> 
> As for I8N, I believe that doing more in the document requires some 
> rather compelling consensus among the community -- ie, you folk.
> 
> To the extent that anyone insists the document say more than the above, 
> please consider that requirement to generate candidate text as resting 
> on your own shoulders...
> 
> Again, it's not that my own view is unfriendly to having the document 
> say more, its that I am very concerned about derailing the document with 
> an effort that is clearly difficult to do thoroughly and well, and get 
> agreement from the community.
> 
> d/

Shrug.

It is the mindset thats helped mold and perpetuate security issues we 
have for the past 20 years, and it is same "deferment" attitude that 
will continue or even create new security issues for the next 20. But 
who cares right?  We will probably be dead and bury by then.

Sorry, you asked and I'm from the "Getting it right the first time!" 
engineering quality school of thought.

You see, the thing is, you are going to do what you want anyway. So if 
you are looking for any pat on the backs for ignoring security concerns, 
like in the DKIM/SSP project, I just wish to express that even thought 
one may not able to change your mind, there are those who don't always 
agree with your position being taken for these important areas that will 
have an affect on others.

-- 
Sincerely

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

To: [email-masked]
From:  "Frank Ellermann" <[email-masked]>
Subject:  email-arch I18N (was: email-arch -- Security Considerations)
Date:  Sun, 9 Mar 2008 06:17:37 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 34
Reply-To:  "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Dave Crocker wrote:
=20
> As for I8N, I believe that doing more in the document requires some
> rather compelling consensus among the community -- ie, you folk.

Proposed text, insert in chapter 6 between "Security" and "IANA":

Internationalization

 The core email architecture is still based on US-ASCII headers in
 message/rfc822 objects including any MIME part headers.  Other
 charsets and the indication of languages in headers require US ASCII
 compatible MIME encodings as specified in RFC 2047 and RFC 2231.
=20
 Similar MIME content-transfer encodings allow to use other charsets
 in message bodies, and to indicate any language, even for text/plain
 bodies with a Content-Language header field as specified in RFC 3282
 and RFC 4646, or similar techniques for other content types such as
 text/html. =20

 The 8BITMIME extension of SMTP [STD 10] allows to use many charsets
 "as is" in message/rfc822 bodies without the overhead of a MIME
 content transfer encoding.

 Ongoing work on Email Address Internationalization (EAI) is expected
 to introduce message/global objects allowing to use UTF-8 [STD 63]
 in email addresses and message/global headers, see RFC 4952.

---
Missing references for this text:  RFC 1869 (8BITMIME in STD 10, for
rebels ignoring 2821bis), RFC 4952 (EAI), RFC 4646 (language tags),
RFC 3282 (content-language), RFC 2231 (lang tags in header fields).

 Frank

Date: 9 Mar 2008 05:08:18 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: email-arch -- comments solicited on I8N
Organization: 
Cc: [email-masked]
Sender: [email-masked]

My impression is that MIME has done an adequate job of handling I18N
in message bodies and in Subject: lines.  The remaining ASCII-only
parts of the message are the headers that include addresses.  They
present a difficult I8N problem because the MIME encodings provide
multiple ways to represent a string, but mail addressing demands an
exact match, other than case folding in domains.

I presume that we'll eventually use some version of punycode since
it's essentially the same problem as I18n DNS, but it's way too early
to say anything about that.

R's,
John

Date: Sat, 08 Mar 2008 16:15:46 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: email-arch -- Security Considerations
Sender: [email-masked]

Folks,

A question has been raised about the very brief Security Considerations section 
in the email-arch draft.  I've modified the section slight, for the next draft, 
but the section still defers meaningful discussion to existing specifications.

This is the latest version:

> <section title="Security Considerations">
>             <t>This document does not specify any new Internet Mail
>                functionality. Consequently it is not intended to introduce any
>                security considerations, beyond those already established for
>                Internet Mail. </t>
>             <t>However its discussion of the roles and responsibilities for
>                different mail service modules, and the information they create,
>                highlights the considerable degree to which security issues are
>                present when implementing any component of the Internet Mail
>                service. In addition, email transfer protocols can operate over
>                authenticated and/or encrypted links, and message content or
>                authorship can be authenticated and/or encrypted. </t>
>             <t>The core of the Internet Mail architecture does not impose any
>                security requirements or functions on the end-to-end or
>                hop-by-hop components. Details of security considerations for
>                particular Internet Mail mechanisms are provided in the detailed
>                specifications for those mechanisms.</t>
>          </section>

As for I8N, I believe that doing more in the document requires some rather 
compelling consensus among the community -- ie, you folk.

To the extent that anyone insists the document say more than the above, please 
consider that requirement to generate candidate text as resting on your own 
shoulders...

Again, it's not that my own view is unfriendly to having the document say more, 
its that I am very concerned about derailing the document with an effort that is 
clearly difficult to do thoroughly and well, and get agreement from the community.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sat, 08 Mar 2008 16:10:09 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: email-arch -- comments solicited on I8N
Sender: [email-masked]

Folks,

A concern has been raised about the email-arch document's silence on the 
question of internationalization.  Here's what I've added to the changes 
sections, for now, to explain my view of the dilemma for the document:

                      <t hangText="Internationalization:  ">

                      The document contains
                      no discussion of this important topic.  Frankly, I have not
                      thought of what the document should usefully say about the
                      topic and am particularly worried that the problematic and
                      fluid nature of the topic would cause the architecture
                      document to conflict with the reality of work that is
                      underway.  Offerings of candidate text for the document, to
                      deal with I8N are encouraged.</t>

I would appreciate the list chatting about this, briefly, to see if there is 
anything approaching consensus.  Given the above text, you won't be surprised 
that I will consider anything less than a substantial consensus as meaning that 
the document should continue to be silent on the topic.

I don't consider that a desirable outcome, but am very worried that anything 
else could derail the document's publication.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Sun, 02 Mar 2008 05:52:41 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: random rfc2821bis-08 notes
Sender: [email-masked]

At 12:33 27-02-2008, Mark E. Mallett wrote:
>Appendix D.4  Verifying and Sending Scenario
>
>Do we really want an example using the "SEND FROM" command?  Maybe the
>point of this is whooshing over my head, but if somebody implements a
>server according to this document, the SEND FROM command in this example
>will be rejected (particularly since it's not advertised in the EHLO
>response as per F.6)

The "SEND FROM:" in Appendix D.4 could be replaced with "MAIL FROM:".

Regards,
-sm