Re: Federated, decentralised communication on the internet (was: domain names, was: hostname)
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. 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.
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.
> 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.
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.
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.
Reply to: