RE: Last Call: draft-klensin-rfc2821bis

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: RE: Last Call: draft-klensin-rfc2821bis

 

I don't undestand the reasoning here.

 

My understanding is that we implicitly deprecated receivers relying on fallback to A in 2821. Section 5 makes it clear that you look for MX first and that MX takes priority.

 

It is thus not compliant to look at AAAA records today and I see no reason to change this in the future. Instead any 2821Bis should do the job of a bis and deprecate reliance on A fallback, but not support for it. suggesting that people write a BCP to deprecate a protocol feature instead of a bis seems backwards to me.

 

 

Mail is a service lookup, not a host name lookup. Support for use of fallback to IPv4 host name lookup is a historical accident due to the fact that the distinction was not understood at the time. We do not require IPv6 host name fallback, IPv6 host name fallback has a significant cost that will have immediate impact on every mail service lookup that is compliant.

IPv6 should use the service resolution lookup.

 

We should prohibit fallback to AAAA outright and deprecate configurations that rely on A.

 

 

---

From: ietf-bounces@xxxxxxxx on behalf of Tony Hain
Sent: Wed 26/03/2008 3:14 PM
To: ietf@xxxxxxxx
Subject: RE: Last Call: draft-klensin-rfc2821bis

John Levine wrote:
> >> Not to be cynical or anything, but regardless of what we decree, I
> >> think it's vanishingly unlikely that many systems on the public
> >> Internet* will accept mail from a domain with only an AAAA record.
>
> > I think it's vanishing unlikely that email will be useful at all, if
> spam
> > filter writers keep trashing mail based on such dubious criteria.
>
> Not to reignite the usual spam argument, but it is (unfortunately in
> this
> case) not 1988 or even 1998 any more.  When upwards of 90% of all mail
> is
> spam, keeping mail usable is at least as dependent on limiting the spam
> that shows up in people's mailboxes as delivering the trickle of good
> mail.
>
> Real life spam filters use metrics and tune to the actual behavior of
> mailers.  If most of the mail that comes from domains with AAAA and no
> MX
> is spam, they'll tune for that, and it won't be a mistake.  For the
> forseeable future, most such mail will be from zombies, and it'll all
> be
> spam.

This document is not the place to fight spam. If you want a BCP to deprecate
the fall-back, then write one. Until all the implementations remove
fall-back to A, the correct behavior is to also fall-back to AAAA. People
(particularly the apps dev & support communities) are having a hard enough
time getting their heads around even thinking about IPv6 that making your
proposed procedural change is insane. Whatever reasons people have for not
implementing MX will not change just because they are deploying IPv6.

The current text is just fine the way it is.

Tony




_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf