On Fri 23 Mar 2018 at 10:31:13 (-0000), Dan Purgert wrote: > 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.
In that case, this is the step of least concern to the ".home user" as it's the most distant. What's of concern to this user who's trying to determine whether give their LAN a domain name is mail *submission*, because that's where the difference between a FQDN of foo and foo.home might affect their smarthost's willingness to perform its role. > Let's say I've got a relay setup through the host "mymta.domain.com", > and I believe your email address is "da...@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: da...@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 <da...@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 > dav...@example.com, etc.) So along with Brian and Greg, we've now got a good look at mail relaying in action. But let's take a look at the .home user's view of mail submission. Here's an extract from an early 2004 web page for people in Santa Barbara at UCSB using Cox. http://www.oit.ucsb.edu/chsi.asp "If you provide relaying for your off-campus Cox users, your service may remain functional if you support relaying via another port besides 25. There are a couple of ports commonly used for this purpose, 465 and 587. SMTP servers on port 465 are expected to immediately negotiate TLS (i.e., encrypt everything from the start). This type of operation is generally considered legacy and not preferred. "Port 587 presents a standard SMTP dialog with optional STARTTLS support for encryption. The campus network programmer recommends requiring STARTTLS before accepting authentication credentials. If you configure your SMTP server to support port 587, you should also ensure that all submissions are authenticated, not just relayed messages. Failure to require authentication on all port 587 connections is likely to result in spam delivery via that port. The whole point of port 587 is to support authenticated submission of email for delivery, and not to create a clone of port 25." This is the world that most .home users inhabit, the world of mail submission, not relaying. Let's just pop in an example from 2007's RFC4954 as I'm too lazy to do my own demo. S: 220-smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 Ready to start TLS ... TLS negotiation proceeds, further commands protected by TLS layer ... C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ= S: 235 2.7.0 Authentication successful > >>> [...] > >> > > >> > 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 :) ) OK, so let's put this in the same box as my reminiscences of hand-routing emails to ocenas on the other side of the world. > >> > 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 :). You're now introducing another constituency of users who might not even know what a hostname is, let alone be worrying about what to write as the name of their domain. Shall we agree to leave them to one side? (Mind you, it was a query about the hostname that set this whole thread off: https://lists.debian.org/debian-user/2018/02/msg00639.html ) Cheers, David.
