headers
ned+ietf-smtp | 1 Apr 2008 01:23

Re: not delivering, and History of fallback to A


> 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.
(Continue reading)

Permalink | Reply | 43 comments |
headers
Frank Ellermann | 1 Apr 2008 04:19
Picon
Picon

Re: nullmx


<ned+ietf-smtp <at> mrochek.com> wrote:

>> Mail to <postmaster> at this host is still supposed to work.

> Say what? That's only the case if the host runs an SMTP server,
> in which case it is entirely logical to require support of a
> postmaster address. It is entirely possible for a host to have
> an SMTP client and no server.

For pure clients I'd look into RFC 4409, 4954, and 5068.  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. 

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.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Dave Crocker | 1 Apr 2008 04:46

Re: not delivering, and History of fallback to A


ned+ietf-smtp <at> mrochek.com 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
(Continue reading)

Permalink | Reply | 40 comments |
headers
Keith Moore | 1 Apr 2008 04:57

Re: not delivering, and History of fallback to A


ned+ietf-smtp <at> mrochek.com 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
John C Klensin | 1 Apr 2008 05:00

Re: Minor is. It's not a pardigm change


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 
<arnt <at> oryx.com> 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 user <at> foo.example.com.  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
(Continue reading)

Permalink | Reply | 12 comments |
headers
Keith Moore | 1 Apr 2008 05:02

Re: dual-stack IP transition is not specific to SMTP


> 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
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 Apr 2008 05:41
Picon
Picon

Re: not delivering, and History of fallback to A


Keith Moore wrote:

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

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

 Frank
Permalink | Reply | 0 comments |
headers
Dave Crocker | 1 Apr 2008 06:11

Re: Minor is. It's not a pardigm change


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
Permalink | Reply | 0 comments |
headers
Robert A. Rosenberg | 1 Apr 2008 06:38
Picon
Favicon

Re: Minor is. It's not a pardigm change


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).
Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 1 Apr 2008 11:03
Favicon

Re: Minor is. It's not a pardigm change


John C Klensin writes:
> One observation, having worked through this several times before 
> realizing that the answer is obvious and feeling a need to be sure 
> that we are in agreement about what we are discussing...

We agree about almost everything. Our only disagreement is about whether 
AAAA records should influence the decision whether to synthesise an MX 
record.

Consider a case where 2821 and 2821bis gives a different result: An 
IPv6-only network printer. Most of my printers can send mail, none 
listen on port 25, and when the IPv4 network becomes tight, the 
printers will be among the first devices to lose their A RRs, so this 
is a good example.

Code implementing the rules in 2821 will correctly decide that mail to 
the network printer's host name isn't deliverable, code implementing 
the rules in 2821bis-06 will infer an MX.

2821: An MTA being told to send mail to the printer rejects at once.
2821bis-06: The MTA tries for a few days, then gives up.

2821: A web form rejects fadsfs <at> printer.example.com as bad
2821bis-06: A web form accepts fadsfs <at> printer.example.com as a valid 
email address.

Similar for the other uses and devices I thought of: 2821 code makes the 
practically correct decision, 2821bis-06 the wrong one.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane