Arnim Sommer: Willst Du schon wieder die vier Server der Apokalypse aufzählen?
Juergen P. Meier: Ken, David, Exchange und Notes.
Als sich diese vier Mailserver der Apokalypse auf ihre Rechner geschwungen haben, und ueber die Netzwelt ritten, wurde das Ende der Welt eingeleutet. Aus der Unterwelt brachen Horden von
Spammern ueber uns herein...
A newsgroup post in de.alt.sysadmin.recovery
This is by far not limited to Outlook, but this is the situation where I have seen this first and most often.
SMTP is defined in RfC 821, which is more or less superseded by RfC 2821. The former does not specify the syntax in such a formal way, so I'll use the latter here. Section 4.1.1.2 says:
Syntax:
"MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF
RfC 2821 is now superseded by RfC 5321, but that has in the same section:
mail = "MAIL FROM:" Reverse-path [SP Mail-parameters] CRLF
As you might have noticed there is an explicit mentioning of SP before extra parameters. This means there has to be a single whitespace if you want to add a parameter behind the closing bracket and the start of the parameter. Other spaces may not appear on the line. Really simple.
To make it even more clear RfC 5321 thankfully added this paragraph in section 3.3 (page 19):
Since it has been a common source of errors, it is worth noting that spaces are not permitted on either side of the colon following FROM in the MAIL command or TO in the RCPT command. The syntax is exactly as given above.
Micro$oft again messed it up. They use a space between the colon and the opening bracket, violating the RfC. Many mail servers are quite friendly and accept this, but I'm not. This has two reasons: first this does not bloat up the parser. Simple syntax, simple parser. Less errors, less memory, less execution time. Live can be so simple. The second one is even better: many virus programmers are also dumb. They make the same mistake, so you can easily avoid all the traffic and risks of the mass mailing worms like Sober by just being a bit anal about SMTP syntax. No real mail server does it wrong (at least no one I've ever seen) so you get this really for free. Is there any good reason for Micro$oft to do it wrong? I can't imagine, but they do.
I've created a workaround for this: Qsmtpd accepts the wrong syntax and uses it as input for user definable filters. So users can decide if they want to allow this broken syntax at all, only for authenticated clients, for servers using EHLO and STARTTLS, or never. This way I can get rid of the spammers but Outlook clients can still send their mail using my server. I've seen this bug in Outlook 2003, but probably other versions are broken to. Why was it no real surprise to me to see Outlook break the rules? Even the mail client included in Windows7 still has the bug.
Other places where I have seen this:
The HELO command is defined in RfC 821 as HELO <SP> <domain>
. The term of domain is defined to what's widely used today, saying for example Whenever domain names are used in SMTP only the official names are used, the use of nicknames or aliases is not allowed
. Keep in mind that the internet was somehow different in 1982 when this RfC was written.
If the client can't figure out his official name (for example when he is behind a NAT gateway) he should use an address literal (e.g. [192.168.2.42]). Outlook doesn't care, it just always send's the computers nickname. That's why you find often things like OEMCOMPUTER in this place.
Small sidenote: plain qmail doesn't treat [ and ] as valid characters in HELO when printing it to the received line.
For those who have never heard of this product: be happy. It's the worst piece of binary hazardous waste I've ever seen. It sucks universes through nanotubes: in normal operation it corrupts it's own databases. The tools can't fix this, some upgrades are not able to run with this corrupt databases. The storage stuff is horrible. If you ever see such a thing installed on a machine release the poor hardware and EMP it to death.
After this, here is the story. I played a bit around with this beast and found out that you can use STARTTLS extension for sending outgoing mail. This was very useful, the company used a smarthost to send out their mail so this would prevent a clear text password to be sent over the net. So both SMTP extension have to be used, AUTH and STARTTLS. Of course there are two possible orders they can be used. Just let us think for a second which one might be the correct one:
Password are always critical data. So if you have the option to send them encrypted you always will, just to be sure. Don't you?
If you are not sure yet you could simply read RfC 3207. You have to do anyway if you want to know how to implement STARTTLS. In section 5.2 you can find this:
Upon completion of the TLS handshake, the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting). The server MUST discard any knowledge obtained from the client, [...]
So if you had done AUTH before it would be of no use at all because the server MUST forget this. You would have to do the authentication again so there is no reason at all to do it before you announce STARTTLS to the server.
As you will have guessed already, they f*cked it up. They first send AUTH (over unencrypted line), then do STARTTLS. And then they wonder why the server rejects any incoming mail with "relaying denied". Clear case, it's an implementation bug. I opened a bug report for this. No, not really. I filed a support request, you can't open bug reports. I told what's wrong, quoted the RfC, explained how it had to be fixed. I even included the log of the SMTP session. What happened? They told me it was a configuration error on my side. You can only click on a checkbox "use encryption" (or however it is called, don't remember) and choose somewhere else to use authentication. No way to configure the order of what happened. I told them again, they still believe it's my fault. Sorry dudes, you really have no clue at all. Burn in hell.