Re: domain names, was: hostname

[Dan Purgert <dan@djph.net>]

David Wright wrote:
> On Thu 22 Mar 2018 at 22:17:02 (-0000), Dan Purgert wrote:
>> David Wright wrote:
>> > On Thu 22 Mar 2018 at 08:58:43 (-0400), Greg Wooledge wrote:
>> >> [...]
>> >> An SMTP receiver SHOULD validate the recipient address right here,
>> >> right now.  It SHOULDN'T just accept everything and then figure out
>> >> whether it's deliverable later -- that enables joe-job spam.
>> >
>> > How is it meant to do that. If it's relaying, the system it's
>> > eventually going to send the message to might not even be
>> > running just now. Email is store and forward, isn't it?
>> 
>> If it's *relaying*, it is not *receiving*; there's a subtle but key
>> difference there.  At most, a relay will likely validate 
>> 
>>  
>>  - source (host or user) is allowed to relay via me.
>>  - destination is a FQDN
>> 
>> The closest that a relay will "store-and-forward" is in essence similar
>> to if your roommate (significant other, etc.) is going out ... you say
>> "hey, since you're gonna go past the mailbox, mind dropping these in
>> there for me?".  That is, it will only "store" the message long enough
>> to dump it off at the intended recipient (as defined by the MX Host for
>> the target domain).
>
> I took "receiver" to mean the sense used here:
> "Message transfer can occur in a single connection between two MTAs, or
> in a series of hops through intermediary systems. A receiving SMTP
> server may be the ultimate destination, an intermediate "relay" (that
> is, it stores and forwards the message) or a "gateway" (that is, it
> may forward the message using some protocol other than SMTP). Each hop
> is a formal handoff of responsibility for the message, whereby the
> receiving server must either deliver the message or properly report
> the failure to do so."
> https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

This is where things get messy, due to language.  In the context that
Greg is using, "receiver" is the ultimate destination MTA, and not the
intermediary MTA(s) that a message may be handled by.

Let's say I've got a relay setup through the host "mymta.domain.com",
and I believe your email address is "david@example.com".  The only thing
that my relay will really do is:

 - Check that I am allowed to relay through it (I am)
 - Check that I'm sending to a valid email address (I am)
 - Check that it doesn't actually host that domain (it doesn't)

At this point, "myMTA" has fully accepted the message I want to send
you, and initiates the connection to your MTA:

 - "Welcome to mail.example.com"
 - EHLO mymta.domain.com
 - (list of options)
 - MAIL FROM: <me>
 - RCPT TO: david@example.com
   ^^^^^^^^^^^^^^^^^^^^^^^^^^ It is RIGHT HERE that *your* MTA will
   determine whether or not the mail is allowed to pass.

"mymta" will get one of (at least) two responses:

 - 250 2.1.5 Ok 
 - 550 5.1.1 <david@example.com>: Recipient address rejected


In the first case, "mymta" is now OK to issue the DATA command, and
start sending the actual email.

In the second, "mymta" will relay the information that the email address
I used was invalid (perhaps your proper email address is
davidw@example.com, etc.)

>>> [...]
>> >
>> > My last point may become less true over time because, as I already
>> > just posted, there is now an authoritative answer: If you don't
>> > know what to put, put home, corp, or mail, as you wish. They are
>> > guaranteed never to become TLDs in the future.
>> 
>> They're as guaranteed to "not" become as TLD as much as ".local" or
>> ".me" or ".tech" were guaranteed to "not" be a TLD in the 1990s.
>
> Perhaps this was pre-ICANN? Do you have a reference? Or a contact inside
> ICANN that knows something nobody else knows about resolution
> 2018.02.04.12

My point was that in the 1990s, the prevailing wisdom was "we're only
ever going to have .com / .org / .net / .edu / .gov ... and maybe a
couple test tlds in an RFC somewhere". However, things changed and now
we have a gazillion TLDs today.

I'm not saying it's a certainty that ".home" would ever become a
registered TLD ... but at the same time, we learn things down the road
that we didn't know when something was initially set up (e.g. giving /8s
to companies :) )

>
>> > I'm not convinced that I, and many in my situation, would be better
>> > off running a mail server rather than having an organisation run a
>> > smarthost to do it on my behalf. (They also take care of incoming mail
>> > by running an IMAP server.)
>> 
>> Ultimately it depends on how far you trust your ISP.  Cox is pretty good
>> (at least they were when I was in their service area).  TWC/Spectrum was
>> generally good, but they could break hard.  AT&T (Yahoo) is completely
>> useless.
>> 
>> Also, by running your own mailserver, you are not bound to your ISPs (or
>> google's, etc.) size limits / ads / etc.  For example, my parents can
>> send me 50MB emails (old and refuse to learn dropbox / owncloud for pics
>> of their grandkids ... so they send mails, and I put them where they
>> belong).
>
> Yes, it's tedious that Cox sends a marketing letter every week expounding
> their TV service. Oh, you didn't mean that? Which ads do you mean?

The ones that're plastered all over the webmail interface that "joe
typical home user" uses, because thunderbird is too hard :).


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281