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 Some of us remember when emails passed through several gateways and could take a couple of days to reach their destination. We used to spend our time juggling addresses containing multiple ::, @, and % delimiters, with hops through JANET (which at that time wrote its addresses backwards), EARN, BITNET and Inmarsat, all kicked off by pasting the message into a Telex on BT Gold. Academic institutions could only afford to link up through Inmarsat a couple of times a day at most. I could only afford BT Gold (out of hours) because a friend managed an experimental comms project at university. This was how it was in the mid-late 1980s. > > [...] > > > > 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. > > 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? Cheers, David.
