Re: domain names, was: hostname

[David Wright <deblis@lionunicorn.co.uk>]

On Thu 22 Mar 2018 at 08:58:43 (-0400), Greg Wooledge wrote:
> On Wed, Mar 21, 2018 at 06:59:04PM -0500, David Wright wrote:
> > Sure, so in my case, I'd be forced to find out what my router's
> > hostname is so that I can quote a hostname that will resolve to the
> > address that I woud be posting on. Currently this appears to be
> > ip70-179-161-106.fv.ks.cox.net
> > but it changes at random times governed by I know not what.
> 
> First, you're not "forced" to do anything.

No, hence my writing "I'd'. The "would" is predicated on what you
wrote, "a given receiver may choose to perform BOTH tests", … … …

> You can simply acknowledge
> that some SMTP servers will accept your messages, and others will
> reject them.  You can never achieve 100% acceptance anyway, since
> there will always be SOMEONE out there who only accepts messages
> that are cryptographically signed by her grandmother and wrapped in
> tin foil and delivered by RFC 1149.
> 
> Second, the HELO string you use doesn't necessarily have to be YOUR
> hostname.  It just has to be SOME hostname.
> 
> That said, using your actual hostname (more precisely, any hostname
> which resolves to your public IP address) increases the chances that
> your message will be accepted.

… … … and on the second test consisting of the test in this last paragraph.

IOW: Were this the case, it would be necessary to do as outlined in
my paragraph above.

> Having your IP address get mapped to a hostname that maps back to your
> IP address will also increase your odds of acceptance, but for people
> with dynamic IP addresses, that is typically outside of your control.
> 
> Having a static IP address, with control over the DNS mappings in both
> directions, would definitely help you.

I don't need help because the smarthost I've chosen to use does not
insist on this.

> > And what's achieved by this when the next step is AUTH?
> 
> There is no AUTH step when you're sending outgoing mail to the receiver's
> SMTP server.  None.

So that would be a pretty good reason for an ISP to deny access to
that service if you have no other way of showing who you are.

With certain differences, I can do exactly what you have done below in
your example: I wrap it up in SSL and talk to a different port number,
and it works fine with
. junk EHLO string
. no AUTH authentication
. junk MAIL FROM: string
. No From: To: etc, but I add a Subject: to make the incoming result
  easier to find, and a body that describes the nature of the test.
IOW the only sensible information is RCPT TO:.

Of course, the results are as expected, being either
250 2.0.0 Ok: queued as 420E35AE524
for an address that it recognises on home turf, or
454 4.7.1 <valid-username@valid.domain.name>: Relay access denied
for one that it doesn't.

When I authenticate, I can send the mail anywhere, but it's tedious to
demonstrate here as I have to dig out my password/encode it in base64
and all that stuff. I've done it to help others here in the past.

> SMTP looks like this:
> 
> (1) Sender:   HELO sender.name
>     Receiver: 250 receiver.name
> (2) Sender:   MAIL FROM:<user@domain>
>     Receiver: 250 ok
> (3) Sender:   RCPT TO:<user2@domain2>
>     Receiver: 250 ok
> (4) Sender:   DATA
>     Receiver: 354 ok
> (5) Sender:   message headers and body followed by \n.\n
>     Receiver: 250 ok magic numbers
> (6) Sender:   QUIT
>     Receiver: 221 ok (hangup)
> 
> That's it.  That's an entire session.
> 
> Step (1) is just the servers telling each other their own names.  It has
> nothing to do with the message.  It's simply one of the points at which
> some receivers choose to take antispam measures.  A conforming SMTP
> server may choose simply to ignore whatever the sender says.
> 
> A non-naive SMTP receiver will log the sender's ACTUAL IP address as
> well as whatever it called itself in the HELO.
> 
> Step (2) is the envelope sender address.  This is what the receiver is
> supposed to use to bounce an error message back to the sender if the
> mail can't be delivered.  This is where things get really interesting.
> 
> A conforming SMTP receiver that plays by the rules and accepts everything
> ("be liberal in what you accept") and generates bounces for the failing
> addresses is too naive for the current Internet.  SMTP was designed in
> a simpler time.  Playing by the old rules just makes you a joe-job spam
> relay.  You can't do that in the modern era.
> 
> Step (3) is the list of envelope recipient addresses.  This is where
> the mail ACTUALLY goes.  It doesn't matter what's in the headers.
> 
> 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?

> Step (4) is just "that's all the recipients".
> 
> Step (5) is the actual message, including the headers.  Some SMTP
> receivers may perform content analysis during this stage, and may reject
> the message as spam based on its content.  Others do not.
> 
> Step (6) is optional.  The sender may try to send more messages since it
> already has the connection open, assuming it has other messages intended
> for this SMTP receiver.  Or, the sender may simply drop the connection
> itself, instead of sending QUIT and waiting for the receiver to drop
> the connection.
> 
> Bundling of multiple messages for a single SMTP session is fairly
> uncommon, since it's a whole lot of work and complexity for no real
> gain, in a time when bandwidth is plentiful.  Most senders just open
> one connection for each message, typically in parallel.
> 
> There is NO authentication step.  Remember, the sender may not be the
> origin machine of the message.  It may simply be one of a sequence of
> mail relays between the origin and the final destination.

Yes, I got all that. It depends on trust between these relaying hosts.
And were I sending each of my emails to the appropriate host that has
access to a list of valid delivery points, I might not expect to have
to authenticate myself.

However, if in doing that I send loads of spam to these hosts, I might
expect them to take blocking/dropping/refusing action against my IP
address. If you Whois that address, you're going to get a rather large
block of Cox addresses. They might not be too happy, which is
presumably why they don't have a port open for that with their
customers.

My point was that the user who doesn't know whether they ought to be
foo or foo.home is unlikely to be demanding to send their mail in this
way. They are far more likely to be using a smarthost, maybe with their
own ISP, maybe not. With a smarthost, you can just cast one magic spell
for all your emails. (This isn't meant as as a political statement,
which is why I've reverted the Subject line to non-political.)

Here are my points, as it's a month since I made them. I didn't
quite answer the question as posed.

--✄------

> that as well as being asked to supply a hostname I've also been asked
> to supply a domain value.
>
> What, on a home LAN, is that used for?

Nothing, with the possible exceptions of:

. avoiding this message at boot up:
  Mon Feb 19 04:58:38 2018: [....] Starting MTA:hostname --fqdn did not return a fully qualified name,
  Mon Feb 19 04:58:38 2018: dc_minimaldns will not work. Please fix your /etc/hosts setup.

. satisfying a broken smarthost¹,

. causing some discussion here.

--✄------

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.

Currently I have an empty string. When I next reorganise my network
here to include bridging, I might consider using .home (it's the
most appropriate). It affords me no particular advantage as far as
I can see, but I remain open to persuasion that it has some use.
What exactly, though? (Still a genuine question, but keep off email
or we're in danger of getting in a loop.)

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.)

I think the political discussion arises here because people don't
recognise that just contributing to this list makes one unusual in
itself (and I include myself in that). There may be divers diverse
reasons to run a mail server, but count me out along with many others.

Cheers,
David.