ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Multicast MTAs, was Dotless domains and email

2013-07-08 03:52:31
On 8 Jul 2013, at 09:15, Alessandro Vesely <vesely(_at_)tana(_dot_)it> wrote:
On Mon 08/Jul/2013 00:17:56 +0200 Sabahattin Gucukoglu wrote:
As for mDNS, what's the trouble there?  It should work just fine.
Won't be very secure, of course, but anyone in the local namespace
should be able to set up MX and address records to send mail wherever
they'd like, at whatever priority.  It can be, at least in theory,
the apex or any name underneath, and if you have a resolver that
knows to match "local" to mDNS, i.e. in practice all of them, you
just replace managing zone files with responding to the right
multicast messages, basically.  For convenience, you put "local" in
the domain search list, and so it goes.  (On OS X, this is actually
implemented rather better than glibc with the nss module, since the
same process is responsible for both DNS and mDNS, so searching
actually works.)

I don't think everything can be solved by just tinkering with resolvers.

Let me try an example:  Suppose I send to Sabahattin@local --presumably
because I can see you, or equivalent local evidence.  Every local box
having an MTA should reply to my query for a local MX.  An MTA with a
hight priority MX will rply "550 user not local" to my RCPT.  In that
case, a unicast relay must give up, while a multicast MTA had better
behave differently, and possibly keep on querying as it tries each MX in
turn, because that's what the nature of mDNS looks like.

I think that would be against the whole mDNS ethos of having every node take 
complete responsibility for its own little chunk of the namespace.  You'd 
really want to write to sabahattin@sabahattins-mac-mini.local, which of course 
defeats the useful purpose of decoupling the mailbox from the host.  Because, 
otherwise one of my machines will have to assume responsibility for the whole 
subnet, in which case … and so on, and so on, and so forth. :-)  Of course, 
with this strategy all the burden of implementation is moved to the receiver, 
which is nice.  I could register a response for sabahattin.local with an MX for 
all my computers, and now I just have to make sure that the computers organise 
amongst themselves which is going to go bing when I receive the mail (or just 
turn the others off).

Yes, that would require lots of little changes.  The question is if it
can entice people to upgrade their mail software at the same pace that
they upgrade their browsers and web servers.

Probably not, at least not now.  The only reason to suggest it is in realising 
some gleaming future in which every node is autonomous.  Clearly, user 
expectations aren't there yet.

But then again, writing to sales@amazon or support@apple probably isn't in the 
public conscience at the moment either.  ICANN wants to know what the 
implications are for the TLDs; the answer is "The IETF disclaims all 
responsibility for wrongdoing as usual, but wishes to point out that it won't 
work anyway". :-)

Cheers,
Sabahattin

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

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