Re: Last Call: draft-klensin-rfc2821bis

[Mark Andrews <[e-mail]>]

> 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.  
> 
>  Frank
> 
> _______________________________________________
> IETF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf