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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
