Re: Last Call: draft-klensin-rfc2821bis

Bill Manning wrote:

> sounds like a great way to reduce the incoming spam to me.

Dunno, I normally want to know if a mail from me (really,
SPF PASS and all) did not make it, and for that purpose I
want the good bounces.  If legit undeliverable mail ends
up in black holes a.k.a. "spam filters" it can be a PITA. 

> What about the situation where mail emitted from a node
> with only IPv4 addresses is resolvable in the IPv6 world?
> same "one-way" spam.

Is that so ?  There is a way to map IPv4 to IPv6 addresses,
as far as SMTP is concerned you can at least try to report
errors.  If you are on an IPv6 island with no way to reach
the mapped addresses that won't help, but it is no protocol
design issue for SMTP.  

>> they have to query for MX, A, and AAAA to finally find
>> your IPv6 SMTP.

> or... they have to query AAAA, then A, then MX

No, MX comes always first, but you can of course swap AAAA
and A, or in an IPv4-only scenario skip AAAA if you anyway
can't use it.

Q=mx needs to be first for domains without SMTP.  It would
waste time and bandwidth to try to reach them when that is
not possible.  In more convoluted examples it could be very
wrong to send mails to an existing SMTP at the domain, if 
the MX doesn't offer to do this.  That is no new 2821bis
idea, that is as it always was since god posted STD 10 :-)

> your arguing that because an SMTP agent implementation
> policy might be in place, that every one who runs DNS
> is now required (that "mandatory" thing) to install an MX?

I hope we are talking about SMTP over TCP in the Internet.
If we do, senders must somehow find an SMTP at a public IP
for the destination mail addresses.  For a domain literal
that's directly the IP and you don't need DNS.  In normal
cases with a FQDN you need DNS anyway, to get the IP "by
name". 

The standards since STD 10 require to try MX first to get
a list of names and priorities, see above.  And yes, the
proposal for IPv6 is to make MX mandatory, as Keith said
there will be a huge number of AAAA devices, and it would
be a huge waste of time to time to try AAAA after MX for
devices which never send or receive mail, e.g., a forged
mail from webcam.  Adding SPF "v=spf -all" everywhere is
no alternative.  Besides SPF is voluntary, not mandatory.

Null-MX idea is another variant of "opt out" everywhere,
also not attractive, why should all IPv6 devices with AAAA
but no SMTP get null-MX records ?

A realistic idea is "opt in" with an explicit MX.  In your
example you can still send from any AAAA you like, as long
as the addresses use domains with an MX.  Or with the old
"implicit MX" A-fallback.  But please no new AAAA-fallback.

> placing an SMTP dependency in the DNS is (imho) 
> fundamentally wrong.  

AFAIK the MX-concept is *THE* fundamental idea in STD 10, 
later STD 3 eliminated the "source route" alternative(s).

> IPv4 and IPv6 are pragmatically different address families.
> Architecturally, the "right" thing to do would have been
> to create a new class for IPv6

That's something I can't judge, I stay out of all flamewars
about IPv6 and NATs here.  But I know that Internet Drafts
ignoring IPv6 are DoA, worse than forgetting security and
privacy and IANA and I18N considerations... :-)

With the situation as it is, and with respect to SMTP, the
MX records can include an IPvAnything MTA for an otherwise
IPvX-only domain.  MX was always a good at such tasks, e.g.,
UUCP-domains with no IP at all.

> Long and Lean - publication of data elements in the DNS
> does not now and never has equated to reachability for
> bit delivery.

Okay, but 2821bis doesn't discuss SMTP over FidoNet or what
else, it considers DNS with addresses and MX as given.  If
you want a note in 2821bis that this is actually limited to
the IN class and not about Chaos etc. maybe John can do (?)

 Frank

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