SMTP tidbits for the to-be postmaster
This is a quick overview of the parts of an SMTP session that are relevant to SPF and mail server setup.
Just a sample SMTP session
For a starter, this is what an ESMTP session between two mail servers talking on port 25 can look like (shamelessly copied from this post, which also shows how I obtained it).
"eli@picky.server.com" <eli@picky.server.com>... Connecting to [127.0.0.1] via relay... 220 theserver.org ESMTP Sendmail 8.14.4/8.14.4; Sat, 18 Jun 2016 11:05:26 +0300 >>> EHLO theserver.org 250-theserver.org Hello localhost.localdomain [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-DELIVERBY 250 HELP >>> MAIL From:<eli@theserver.org> SIZE=864 250 2.1.0 <eli@theserver.org>... Sender ok >>> RCPT To:<eli@picky.server.com> >>> DATA 250 2.1.5 <eli@picky.server.com>... Recipient ok 354 Enter mail, end with "." on a line by itself >>> . 250 2.0.0 u5I85QQq030607 Message accepted for delivery "eli@picky.server.com" <eli@picky.server.com>... Sent (u5I85QQq030607 Message accepted for delivery) Closing connection to [127.0.0.1] >>> QUIT 221 2.0.0 theserver.org closing connection
HELO / EHLO
This is the first thing the client says after the server More precisely, it says something like
HELO mail.example.com
This self-introduction is important: The server knows your IP, and probably makes a quick rDNS check on it, to see if you’re making this domain up. So the domain given in HELO must be the same as in the rDNS record. Exactly.
It doesn’t matter if this domain has nothing to do with the domain of the actual From-sender. Or any other domain, for that matter. Relaying emails is normal. Not having the rDNS set up properly shouldn’t be.
Rumor has it that most mail servers will accept the message even if there’s no match, or even if there’s no rDNS record at all. And I’ve seen plenty of these myself. I’ve also had my server rejected because of this. It’s losing points on being lazy.
EHLO is like HELO, but indicates the start of an ESMTP session. For the purpose of the domain, it’s the same thing.
MAIL FROM:
After the HELO introduction (and possibly some other stuff), the client goes something like:
MAIL FROM:<myself@example.com>
The email address given is often referred to as the envelope sender, envelope-from or smtp.mailfrom.
In its simplest form (and as originally intended), this is the sender of the mail, copied from the “From:” header, as presented to the end user. But even more important, this is the address for bouncing the mail if it’s undeliverable. So one common trick, mostly used by mass relays, is to assign a long and tangled MAIL FROM: bounce addresses from which the relaying server can identify the message better.
The envelope sender appears as the “Return-Path:” header in mail messages as they are reach mailing boxes. Along the Received list in the mail headers, “envelope-from” tags often appear, indicating the envelope sender of the relevant leg.
This way or another, if you’re into SPF, then the SPF record must match the envelope sender, and not necessarily the From: sender. Even though it’s a good idea to cover both. Mail relays are a bit messy on what they check.
VRFY and EXPN
VRFY allows the client to check whether an email address is valid or not on the server. If it is valid, the server responds with a full address of the user.
This allows the client to scan through a range of addresses, and find one that is a valid recipient. Excellent for spammers, which is why this function is commonly unavailable today. For example:
VRFY eli@billauer.co.il 252 Administrative prohibition
on another machine:
VRFY eli@billauer.co.il 252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
EXPN is more or less the same, just with mailing lists: The client gives the name of the list, and gets the list of users. The common practice is not allowing this command. Even not those who allow VRFY despite its issues with spam.
If you’re setting up a mail server, disable this. It’s often enabled by default.