On 2008-01-15 at 14:01 -0800, Jeroen van Aart wrote:
> What is wisdom in this mess? Insist on everyone using port 587? ignore
> 587 and support a host of legacy clients with port 465 and allow port 25
> for submissions? Open all 3 ports and allow whatever people want on any
> port? Users have been told for years to use 25 (and 465), to add to the
> confusion.
Don't break anything you're already doing for users/customers.
Don't start things which will cause you headache down the road.
Use different hostnames for MX service and for mail submission. Eg,
mx.spodhuis.org vs smtp.spodhuis.org. This lets you scale the two
external interfaces independently and split them off to be separate
hardware. Customer smarthosts are not inbound mail acceptors.
If you can start with separate IP addresses, it makes it easier to keep
customers from misconfiguring their client software to use the service
on the wrong hostname.
You only need SMTP on port 25 for MX. You don't need to support AUTH
there and doing so can sometimes cause problems for remote MTAs which
get confused about being asked for authentication when they don't have
any configured. I'm not sure if any such systems are still around,
though. If you support TLS on 25 for MX then you need to use a
certificate signed by a very widespread Certificate Authority; you might
still have deliverability problems from clients with no CA certs
installed and which insist on trying (but failing) to use TLS when it's
offered. But fewer problems and if you used a widespread CA then in the
(hopefully unlikely) event that this ever happens and causes a problem
for mail to you, then you can _firmly_ point out that it's not a problem
on your end and there's _nothing_ you could do to prevent this whilst
still offering hop-by-hop security. Well, short of having two MXs and
not having TLS on the higher-numbered (less-preferred) MX and hoping
that such broken remote servers do at least fall back across MX
properly.
Do turn on all server fixups on 587 and be as lenient as possible to
systems which have successfully authenticated.
For submission, it depends upon what you need to support. If you have
historically supported non-MTA service on port 25 then be careful about
withdrawing it.
You should definitely provide service on port 587, with TLS and AUTH
(unless you have very very good reason and your setup is proven safe);
this lets people behind forced-proxy port 25 ISPs still connect to you.
You only need to ensure that the certificate authority signing the cert
is one also supported by your userbase; this also applies to port 465.
Port 587 is "internal" and can have whatever policy controls you want on
it, since the only clients authorised to use the service are those you
explicitly authorise to do so.
Read RFCs:
4409 Message Submission for Mail
5068 Email Submission Operations: Access and Accountability Requirements
Note that RFC 5068 is BCP 134 and the BCP documents are something which
administrators should read. They're not protocol specifications. All
professional mailadmins SHOULD ;-) read the relevant SMTP/email BCP
documents; there are only two:
BCP 30 / RFC 2505
Anti-Spam Recommendations for SMTP MTAs
BCP 134 / RFC 5068
Email Submission Operations: Access and Accountability Requirements
Treat 465 much the same as 587. Be aware that there might possibly be
issues with clients which speak TLS 1.x to 587 but SSLv2 to 465; I've a
vague recollection of someone discovering that with some client.
> Out of curiosity, why is it so wrong to use 465? It's just a port
> number, not a religion. :-) Instead of choosing another port, those who
> "decide" (who?) could have renamed port 465 to read "submission". Or not?
Use of TLS/SSL is orthogonal to the use of SMTP for mail submission.
The idea was to roll all the <protocol>s assignments back into
<protocol> instead of assigning a second port for every protocol which
might have use-cases both with and without SSL/TLS.
You can use TLS/SSL for hop-by-hop encryption; however, since no MTAs
use that, in practice 465 is a submission service, mostly kindof.
The IETF has a religious screed against imaps, smtps, pop3s, etc. I
disagree with the IETF's "official" stance, but I'm just weird like
that. I suspect this is probably IESG originated anyway, but haven't
looked into it. The IETF per se doesn't quite have official stances.
*cough*
-Phil
