Communication Networks/SMTP Protocol
SMTP - Simple Mail Transfer Protocol[edit | edit source]
Normally attributed to the TCP/IP port 25 the SMTP is the result of boiling down the following RFCs
- RFC 821 - Simple Mail Transfer Protocol (Standard)
- RFC 1870 - SMTP Service Extension for Message Size Declaration (Standard)
- RFC 2821 - Simple Mail Transfer Protocol (Proposed)
- RFC 2822 - Internet Message Format (Proposed)
- RFC 2920 - SMTP Service Extension for Command Pipelining (Standard)
- RFC 3030 - SMTP Service Extensions for Transmission of Large and Binary MIME Messages (Proposed)
- RFC 2487 - SMTP Service Extension for Secure SMTP over TLS (Proposed?)
- RFC 5321 - Simple Mail Transfer Protocol (Draft Standard - Obsoletes RFC 2821)
Technically, some of these make up ESTMP, but I tend to lump them all together. Where I deal with emails, there doesn't seem to be much difference (or I don't know any better).
NB: I'm going to rant a little in this.
Even though I do provide links to the above RFCs, I haven't taken the time to go read them. That's the job of someone who writes the MTA ;) I just find bugs, fix them if I can, and try to kill off any much junk from getting to my users as humanly, and computationally, possible. My use of should in the following areas is based on personal opinion and experience, not the RFCs. Although they do generally match, I'm a lot more strict on what is acceptable.
You may also notice that I say to reject the mail at certain points in the SMTP conversation. Why not? If the other end is a mail server then it's quite capable of making a bounce message and sending it back to whom ever wrote the email, AND it will be in a format that the local system administrator will know and can deal with. If it's a spam engine or a virus, then your bounce message becomes a spam itself - if you reject before accepting the message, there's no bounce message made.
HELO/EHLO[edit | edit source]
Allowed - valid hostnames & IP's
[x.x.x.x] - Not likely to find a mail server that does this any more, but I still accept it.
mail.example.com - perfect.
Dis-allowed - The rest!
x.x.x.x - missing the square brackets
ms_server.example.com - underline is an illegal character! (MS$ puts it in place of spaces - oops)
The hostname provided at HELO time should resolve to IP address of the host connecting. The reverse IP could match the forward, but with the increase in small business on ADSL (and other BB links), many servers don't have access to their rdns records.
MAIL FROM:[edit | edit source]
Supposed to be the email address to send all bounce messages and any status update messages to. Usually the person sending the email, a script that handles bounces, or something else you can think up. Spam senders make up fake ones (for now) so this is a good way to kill off a lot of it. Verify it with a callout, or whatever your favorite MTA provides. Long live [Exim]
Email addresses should be in the form "Real Name" <email@example.com>
RCPT TO:[edit | edit source]
To whom are you sending your email?
The final recipient of the message. This should be validated at this time with possible dictionary attack prevention. This is a minor mung of the Standards (so I've been told), but has reduced the amount of traffic by at least 50% at some sites. It also stops spammers using your MTA as a host for bounce spamming (Many servers accept bounce emails with a lot less restrictions that normal emails).
See MAIL FROM: for format.
DATA[edit | edit source]
The meat of the message. Should filter this for spam and viruses and reject here if there's something wrong. Save the world from useless bounce messages.
Format is Headers followed by an empty line, the message body, and then CRLF.CRLF (full stop on a line of its own).
Headers a single line things - Header: content
If wrapping is required, the second and further lines must start with a white space.
Body can be pretty much any 7bit ASCII character.
I'm sure there's a million other things to add to this, however, that's why this is a wiki! Contribute away.