[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-30 16:37:26

John C Klensin wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


IETF mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews(_at_)isc(_dot_)org
IETF mailing list