On 9/4/12, Mark Andrews <marka@isc.org> wrote:
In message <CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=FhCS+Ty_yo5OAA@mail.gmail.com>, Suresh Ramasubramanian writes: STARTTLS from anywhere to anywhere is possible today and is not vulnerable to interception except in the MX's themselves. You can secure the MX records (and their absense) and secure the CERTs used by STARTTLS.
You can also use SMTPS on port 465; or STARTTLS on port 587. Most MX servers don't support TLS or SSL, so it could be privacy neutral, and many MX server operators utilize dynamic host RBLs, even if STARTTLS connections are allowed. It is possible for end user to tunnel SMTP traffic over VPN, SSL, or SSH to a private submit server on a trusted network. Blocking initial outgoing TCP SYN for port 25 completely creates a predictable failure scenario. which is to be encouraged. ISPs very commonly block outgoing initial SYNs to that port. And ISPs also commonly block 23, 135 - 139, 190, 389, 445, 1025, 1080, 1433 - 1434, 3380, 3389, 5060, 5070, 5631, 6667, 31337, 559. Some may block connections to all outgoing ports, except a small number. Those are all accepted practices, with increasing annoyance, and increasing predictable breakage, the more ports are messed with. Blocking few/no ports is desirable; and port 25 is so widely blocked, that MUAs should be set to 587 + authenticated submit in the first place. Tampering with the contents of packets, "blocking" application level traffic by creating fake application layer error messages, for example fake nxdomain/servfail response, or fake "550 rejected" SMTP response, is to be strongly discouraged, because it causes unpredictable application failures. ISP routers aren't supposed to reject/accept packets based on application layer data. The exception would be you manage the end user computers, and dictate a very precise list of applications, so you can pick ones whose vendors list it as a supported thing, or you have gone through rigorous testing procedures. (Enterprise IDS units, that analyze packets and seek to block attacks by reacting to application content, are OK, for example)
Of course a bot can build up a rich cache of MX records from elsewhere and send from a botted 3g modem connected host on his network
Yes. It can also "probe" randomly for servers listening on port 25 based on A record lookup instead of MX, or by using Reverse DNS to find a domain, and then guess e-mail addresses.
-- Mark Andrews, ISC -- -JH