Asking for trouble...
-
@morbiuswilters said:
@tgape said:
In all of the companies I've worked, the outgoing mail servers weren't even accessible to the outside - they could initiate TCP connections to the outside world, but could not receive them. At least one of those companies had blocks on incoming TCP connections at both a 'hardware' firewall layer and a host-based firewall layer - and it wasn't even running an email server on the external interface.
So how do you send mail externally? VPN? You do understand that your experience isn't all that relevent and that plenty of outgoing mail servers are externally accessible? Even if the server is only accessible via the internal network it should still use authentication to prevent forgeries within the organization.
If you're external to the company, and you want to send email with the company domain on it, you send it to the Incoming gateway, because that's the one that's accessible, runs SMTP AUTH, and will let you do your thing. That server will pass it on to the outgoing server if it passes all of the spam and virus checks (apart from the spam checks you bypassed by using SMTP AUTH, of course.)
This setup means that the outgoing server does not need to be running anti-spam, so long as we don't have an outbreak of a spam zombie virus which does SMTP auth. (We do have some activity monitors in place, which have identified and shut down the people who tried generating their own spam. They also collected sufficient data for HR to do their thing.)
The internal outbound email servers runs SMTP AUTH. The external outbound email servers only accepts mail from the internal outbound servers and the external inbound servers. As they do TLS1 talking to it, and the outbound email servers requires that the TLS certs verify and are signed by the specific cert authority that signed them, we don't need to worry about people spoofing their IPs or any such crud.
I realize that my experience does not match everyone else's. I also realize that your experience does not match everyone else's. Further, I realize that there are many companies out there which do not have full proxying DMZs, and there are many companies which are not ISPs. I expect that most companies out there don't know how to do secure, even if they wanted to. I don't think it's a WTF to describe ways to do it, and even if it is, this is the right site for that, too.
1 The cost for the crypto cards to make TLS costs trivial was trivial. The configuration is cookie-cutter; all of our mail servers are TLS capable. SMTP AUTH could be cookie cutter, except that we have paranoid IT Sec folk (the best kind, IMHO - although they can be a pain in pointless ways sometimes) who don't let the external outbound mail servers talk to LDAP... And, since said IT Sec folk are paranoid, even offering the service on those boxes freaks them out.
-
So you assert that an incoming MTA that accepts messags for example.com with a From: address in the example.com domain is misconfigured and shouldn't do this.
I'm not arguing with that as a concept necessarily, but I will maintain that 'most' domains probably don't filter out these messages. It would not be useful as an anti-spam measure, and email forgery would simply not be a problem for a great many domains, eitehr because people don't ever do it, or because they don't trust email for anything vital enough to matter so much.
"misconfiguration" implies that something is broken or won't work properly, where the issue in question is more one of personal preference, surely?
I think you've taken a very minor issue that wouldn't apply to most domains and made a big deal out of it, with a great deal of abuse for good measure. However, in case I've missed something important, what would be the big drama for the incoming MTA server to accept email from "in-domain" addresses? IOW, what consequences for most domains could arise that would be worth the trouble of fixing the problem? How can this harm other Netizens?
Sometimes when doing a risk analysis, the rectification costs outweigh the potential damage. It's possible that admins of many domains have made a deliberate decision to allow this behaviour. Maybe they are all really stupid, but if you're going to claim that, you should provide some kind of example of the dire consequences that they've misunderstood; support your argument.
-
@tgape said:
If you're external to the company, and you want to send email with the company domain on it, you send it to the Incoming gateway, because that's the one that's accessible, runs SMTP AUTH, and will let you do your thing. That server will pass it on to the outgoing server if it passes all of the spam and virus checks (apart from the spam checks you bypassed by using SMTP AUTH, of course.)
That's convoluted as fuck and also wrong. The incoming SMTP server is for accepting mail addressed to the domain from external domains.
@tgape said:
The internal outbound email servers runs SMTP AUTH.
If you're talking about running 2 outgoing mail servers (on accessible only internally, one for external clients) that's fine, but neither of those would be incoming servers. It's also not really necessary if you can set up a VPN or allow external access to the outgoing mail server. Some companies insisit on two separate outgoing servers, although it's not usually necessary.
@tgape said:
The external outbound email servers only accepts mail from the internal outbound servers and the external inbound servers.
Mail should not be routed from an inbound server to an outbound server.
@tgape said:
As they do TLS1 talking to it, and the outbound email servers requires that the TLS certs verify and are signed by the specific cert authority that signed them, we don't need to worry about people spoofing their IPs or any such crud.
IP spoofing isn't even possible anyway, with or without TLS. And setting up TLS on every client is a real PITA, so it's usually only used to encrypt the message stream and handle server-to-server auth, not client auth.
-
@freakwent said:
It would not be useful as an anti-spam measure...
Sure it would. Many people or organizations have rules that allow all mail from local domains through without spam filtering, to prevent false positives. Spammers do exploit this on mail servers that permit forging a local domain as the from address.
Permitting external, unauthorized clients to forge a local address is just stupid. Most MTAs don't even allow it by default and it reduces the reliability of email and possibly opens up a spam loophole. Maybe you don't care if anyone in your company can send messages as anyone else, but clearly there are benefits to locking-down the system so that email accounts are verifiable. Leaving it open is just sloppy and lazy, both of which are considered poor security practice in virtually an aspect of IT. While you're at it, why not just take out firewall rules that are "unnecessary"? Why even bother with least privileged access at all?
-
> Most MTAs don't even allow it by default
qmail, postfix, Exchange 2003 and Exchange 2007 all accept email from the local domain to the local domain without authentication by default.
Some completely random tests. Small sites included as well. Surely not all these are "special" cases. Had much humour with mysql.com...
[root@lameserver ~]# dig mx +short cnn.com
10 atlmail3.turner.com.[root@lameserver ~]# telnet atlmail3.turner.com 25
Trying 157.166.165.29...
Connected to atlmail3.turner.com (157.166.165.29).
Escape character is '^]'.
220 atlmail3 ESMTP
HELO testlol
250 atlmail3
MAIL FROM: imatcnn.com
250 sender <imatcnn.com> ok
RCPT TO: postmaster@cnn.com
250 recipient <postmaster@cnn.com> ok
500 #5.5.1 command not recognized
DATA
354 go ahead
here
.
250 ok: Message 438774241 accepted
QUIT
221 atlmail3
Connection closed by foreign host.[root@lameserver ~]# dig +short mx mysql.com
20 mx3.sun.com.
20 mx4.sun.com.
5 btmx4.sun.com.
5 btmx6.sun.com.
[root@lameserver ~]# telnet mx3.sun.com 25
Trying 192.18.98.31...
telnet: connect to address 192.18.98.31: Connection refused
Trying 192.18.98.43...
telnet: connect to address 192.18.98.43: Connection refused
telnet: Unable to connect to remote host: Connection refused
[root@lameserver ~]# telnet mx4.sun.com 25
Trying 192.18.98.34...
[root@lameserver ~]# telnet btmx4.sun.com 25
Trying 192.5.209.6...
Connected to btmx4.sun.com (192.5.209.6).
Escape character is '^]'.
220 relay4i.sun.com (IntraStore TurboSendmail) ESMTP Service ready
HELO testlol
250 relay4i.sun.com G'day [207.192.72.19]! Why do you call yourself testlol?
MAIL FROM: someuser@mysql.com250 sender <someuser@mysql.com> OK
RCPT TO: postmaster@mysql.com
250 recipient <postmaster@mysql.com> OK
DATA
354 Enter mail, end with "." on a line by itself
goes here
.
250 Message received and queued
QUIT
221 Until later [207.192.72.19]
Connection closed by foreign host.[root@lameserver ~]# telnet mail.php.com 25
Trying 64.71.25.126...
Connected to mail.php.com (64.71.25.126).
Escape character is '^]'.
220 phpsparesv.php.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Thu, 11 Jun 2009 04:22:54 -0700
HELO lol.php.com
250 phpsparesv.php.com Hello [207.192.72.19]
MAIL FROM: loluser@php.com
250 2.1.0 loluser@php.com....Sender OK
RCPT TO: postmaster@php.com
250 2.1.5 postmaster@php.com
DATA
354 Start mail input; end with <CRLF>.<CRLF>
here
.
250 2.6.0 <PHPSPARESVBBsQwY6YH000003b2@phpsparesv.php.com> Queued mail for delivery
QUIT
221 2.0.0 phpsparesv.php.com Service closing transmission channel
Connection closed by foreign host.[root@lameserver ~]# dig +short mx tpg.com.au
10 mx1.tpgi.com.au.
20 mx2.tpgi.com.au.
[root@lameserver ~]# telnet mx1.tpgi.com.au 25
Trying 203.12.160.122...
Connected to mx1.tpgi.com.au (203.12.160.122).
Escape character is '^]'.
220 mx1.tpgi.com.au ESMTP (mail9) Sendmail ready.
HELO imadomain
250 mx1.tpgi.com.au Hello loluser.pants.com [207.192.72.19], pleased to meet you
MAIL FROM: lolhere@tpg.com.au
553 5.1.0 lolhere@tpg.com.au... address does not conform to RFC 2821 syntax
MAIL FROM: <lolhere@tpg.com.au>
250 2.1.0 <lolhere@tpg.com.au>... Sender ok
RCPT TO: <postmaster@tpg.com.a>
550 5.7.1 <postmaster@tpg.com.a>... Relaying denied. Proper authentication required.
RCPT TO: <postmaster@tpg.com.au>
250 2.1.5 <postmaster@tpg.com.au>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
here
.
250 2.0.0 n5BBOp8C024439 Message accepted for delivery
QUIT
221 2.0.0 mx1.tpgi.com.au closing connection
Connection closed by foreign host.I could do this all day. I didn't pick and choose - these were random and I'd implore anyone to show me a single example of a server that's not "misconfigured". I thought you had me at one point - but it was my own typo on TPG. Although the blatantly forged mail going around did get my IP on several RBLs (it's not a mail server.. I can deal with that).
-
@morbiuswilters said:
That's convoluted as fuck and also wrong. The incoming SMTP server is for accepting mail addressed to the domain from external domains.
Question: If an outbound email server that you personally configured receives a connection, which AUTHs as a local user, then sends a MAIL FROM that user, and RCPT TOs it to another local user, and (assuming that it doesn't get any 4xx or 5xx codes in the process of doing that) then sends a DATA portion with a message and a final dot, what happens to the message?
I can see three possibilities:
- It delivers it to the recipient's inbox directly, marking itself as an inbound server, rather than an outbound server. WTF
- It sends it on to the inbound server. I have it on good authority that this is "convoluted as fuck and also wrong", so I'm betting this isn't the answer.
- It rejects the message, leaving anyone who was hoping to simply configure one outbound MTA address in their browser SoL.
None of these possibilities seem very good to me, so I am looking forward to finding out how one should really handle this case.
@morbiuswilters said:
@tgape said:
As they do TLS1 talking to it, and the outbound email servers requires that the TLS certs verify and are signed by the specific cert authority that signed them, we don't need to worry about people spoofing their IPs or any such crud.
IP spoofing isn't even possible anyway, with or without TLS. And setting up TLS on every client is a real PITA, so it's usually only used to encrypt the message stream and handle server-to-server auth, not client auth.
IP spoofing may be possible, if either the attacker can get between the MTA and the machine it is spoofing, or it can talk on the same channel as the machine it is spoofing, the attacker can predict sequence numbers from the MTA machine, the MTA is using an old-style permissive TCP/IP stack, and the attacker can respond quicker on every packet despite the latency gap. Either case is a pretty high barrier to entry. However, it's technically possible. Most companies don't need to worry about it, because they leave enough other avenues of attack which are far easier to exploit to get the same net result. That having been said, let me refer you back to my comment about paranoid IT Security folk...
However, I apologize for confusing you into thinking that I was talking about setting up TLS on clients when I stated, "The external outbound email servers only accepts mail from the internal outbound servers and the external inbound servers. As they do TLS1 talking to it, ".
1 Just so y'all don't seg-fault on a bad pointer, I'll say something about how fricking trivial it is to set up an email client to do TLS on the basis of the host cert only. I believe some clients will just do it out of the box whenever talking to a TLS capable MTA, until you tell them not to. However, I haven't verified this claim. What I have verified is that the companies where I used to be involved with the mailhost teams generally had a lot more DHCP addresses talking TLS than one would expect, given the apparent lack of security awareness of the typical rank and file employee.
