[Top] [All Lists]

IPv6 considerations (was: I-D Action:draft-klensin-rfc2821bis-10.txt)

2008-04-19 14:43:30

Hector Santos wrote:

Must all mail senders have a RECEIVER available 
"somewhere" in order to receive a notification?

If you are talking about envelope sender addresses,
sure, that is the idea, otherwise an empty reverse-
path would do.

Must all transaction expose a valid RECEIVER in
the 2822 message reply fields (Reply-To:,  From:)
in order for the user or some mailbot to send

Yes, again the idea of Reply-To (or implicitly the
2822-From if no explicit Reply-To address is given)
is to send replies to it, as the name says.

Mailbots better use the reverse-path as explained
in RFC 3834 when talking to unknown strangers, I've
just "spamcopped" two auto-replies to the 2822-From.

Just consider the many transactions with addresses
such as:
    no-reply @
that many feedbacks system use today, including bad
guys and the bad/good direct marketing people.

The auto-replies reported as spam above were triggered
by a mail to the SPF help list.  It has nothing to do
with IPv6 or MX.

I don't think I am saying anything odd here.
RFC 3484 does not have not even one mentioning of MX

Apparently RFC 3484 is about IP, two layers below SMTP,
why should it mention MX ?  It also does not mention
X.75, V.90, or ISDN records.

But check out RFC 3482

An informational RFC about E.164, why should I look in
this memo, is "3482" a typo ?

Then also read the following:

I'm not going to read tons of RFCs I have never before
heard of, I believe you when you say that they do not
mention MX or SMTP.  

In 4038 section 3.2, this note covers what we been
partially debating:
| 3.2.  DNS Does Not Indicate Which IP Version Will Be Used

We have even worked out how to solve this problem here:

dom.example.      IN MX   10 ipv4.dom.example.
                  IN A
                  IN AAAA 2001:DB8::CD30
ipv4.dom.example  IN A

It touches base with using not MX but SRV as a discovery
method.  But note again, not even one mentioning of MX

They did not need to mention MX, because that is the one
case where the solution is obvious (using MX, see above).

In RFC 4472, section 4.1 it says:

Fine, another solution, use smtp.dom.example. for SMTP,
change all dom.example. addresses to smtp.dom.example.,
or maybe just use an MX pointing to smtp.dom.example. :-)

| in the specific case of SMTP relaying, the server itself
| must typically also be configured to know all its names
| to ensure that loops do not occur.

Also to ensure that postmaster(_at_)smtp(_dot_)dom(_dot_)example (etc.)
work as expected, yes.

| (Obviously, when wanting to reach a specific node, one 
| should use the hostname rather than a service name.)
Note that last sentence as well - a continuation of the
implicit MX concept.

Just because a name contains www / ftp / smtp does not
necessarily mean that a host supports http / ftp / smtp,
let's say that IAB RFC 4367 info trumps RFC 4472 info:
"What's in a Name: False Assumptions about DNS Names"


<Prev in Thread] Current Thread [Next in Thread>