-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HI gang, In my town, I've noticed that other town employees with whom I send email are unable to send return email to me. This started happening about a month ago. My ISP is Comcast. This description was sent to me by a town employee: o In an attempt to limit the amount of SPAM on the Comcast Internet system, Comcast does not allow external email servers to send mail to Comcast email accounts where the sending email server's MX records do not match. o Because the TOWN mail server is behind our firewall our incoming mail IP address is different from our sending mail IP address. In other words our MX records do not match consequently Comcast blocks our mail from being sent to Comcast email addresses. Basic questions: - - What is an MX record? - - Is it normal for the mail server to be behind the firewall? I thought perhaps it would be either exposed to the net or on the DMZ. I am wondering if there is some misconfiguration or perhaps a different configuration that could be used to alleviate this problem. I have no expertise running a mail server and thought somebody on this list might be able to help. Thanks! Andy - -- Andy Stewart, Founder Worcester Linux Users' Group Worcester, MA, USA http://www.wlug.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFETaM0Hl0iXDssISsRAqzYAKCIypfN3gf2xKOxc3QGaaeJdfvjxQCdHFTZ 2HNpPjjH/PvR9p2VdTcHzrA= =nnna -----END PGP SIGNATURE-----
From: Andy Stewart <andystewart@comcast.net>
In my town, I've noticed that other town employees with whom I send email are unable to send return email to me. This started happening about a month ago. My ISP is Comcast.
I am just going to type something crazy off the top of my head and go to sleep. Take two and call me in the morning.
This description was sent to me by a town employee:
o In an attempt to limit the amount of SPAM on the Comcast Internet system, Comcast does not allow external email servers to send mail to Comcast email accounts where the sending email server's MX records do not match.
o Because the TOWN mail server is behind our firewall our incoming mail IP address is different from our sending mail IP address. In other words our MX records do not match consequently Comcast blocks our mail from being sent to Comcast email addresses.
Your town employees are impressively well informed.
Basic questions:
- - What is an MX record?
A Mail eXchange record is given by a DNS server when you ask for it. You did not say the domain you are sending to, but you can see comcast.com mx records thus: C:> $ dig comcast.net mx C:> C:> <Redacted> C:> C:> comcast.net. 900 IN MX 5 gateway-r.comcast.net. C:> comcast.net. 900 IN MX 5 gateway-s.comcast.net. There you see the name of two servers that will (aledgedly) accept mail for goodguy@comcast.net. C:> <Redacted> C:> C:> gateway-r.comcast.net. 900 IN A 216.148.227.126 C:> gateway-r.comcast.net. 900 IN A 204.127.198.26 C:> gateway-s.comcast.net. 900 IN A 63.240.76.26 C:> gateway-s.comcast.net. 900 IN A 204.127.202.26 There you see their IP addresses. You can talk to them like this C:> $ telnet 216.148.227.126 smtp C:> Trying 216.148.227.126... C:> Connected to gateway-r.comcast.net (216.148.227.126). C:> Escape character is '^]'. C:> 220 rwcrmxc18.comcast.net - Maillennium ESMTP/MULTIBOX rwcrmxc18 #337 C:> helo dsl.keithdiane.us C:> 250 rwcrmxc18.comcast.net C:> mail from: kwright@keithdiane.us C:> 501 need MAIL FROM:<name@domain> C:> MAIL FROM: <kwright@keithdiane.us> C:> 250 ok C:> RCPT TO: <andystewart@comcast.net> C:> 250 ok C:> DATA C:> 354 ok C:> This is just kwright goofing on you. C:> Read your WLUG messages I will explain. C:> . C:> 250 ok . id=20060425052454r1800cg1fje [f] C:> quit C:> 221 rwcrmxc18.comcast.net C:> QUIT C:> Connection closed by foreign host. It seemed to work, and I am typing this on a machine behind an NAT translation firewall (other kinds should be transparent). This is not my mail server, but it seemed to work. Only Andy can say whether they accepted the message and then trashed it in flagrant violation of RFC-2821, which tells how to do such things. They are more tight-assed than most about using the proper case, and I have never seen one that required the <brackets.com> around the address.
- - Is it normal for the mail server to be behind the firewall? I thought perhaps it would be either exposed to the net or on the DMZ.
If you have only one IP addresses, it seems that either your mail server must _be_ the firewall, or be behind it. I don't think it's crazy, but the only way to find out how "normal" it is would be to break it and see if the people who complain are normal.
I am wondering if there is some misconfiguration or perhaps a different configuration that could be used to alleviate this problem.
I am not convinced the problem has been exactly described, although your town employee seems to know a lot more than I do about it. You may be standing in the middle of a pissing contest. If a customer and a local authority work together you might get comcast's leg quite wet.
I have no expertise running a mail server and thought somebody on this list might be able to help.
I hope you have learned your lesson about expecting help from people with expertise. That reminds me of a short FAQ that appeared in the Managment School Student Newspaper: Q: What are those strange creatures in the hall? At first, I took them for apes, but they all wear bluejeans. A: Those are not apes, those are PhD candidates. The hair, grunting, and hunched gait become more pronounced just before Qualifying Exams. Rather than run from them, you will find that you can speak to them, if you ask questions about your homework. The answers can be helpful if you can keep them focused on your problem. If the answer begins "In equilibrium..." you know you have asked the wrong one. -- Keith
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keith gave the basics on mx records. The only thing I would add is mail servers talk to each other, so if you look at your mail headers you can see all of the mail servers that your email has gone to. One problem with modern spam solutions is they themselves are a mail server apppliance, as opposed to software. Allow me to elaborate with two common configurations. Mail comes in via mail.local.domain. mail.local.domain is a spam filter pointed to the internet, which results in the mx record for local.domain to be mail.local.domain. This is a less expensive solution, so it only filters one way. Behind this is a M$ exchange server with an smtp connector. When I write an email, the smtp connector stamps it's id on my email outbound to the comcast servers. See where this is going? We don't want exhange.local.domain to be an mx record for my domain, it doesn't even face the internet. By this solution that Comcast is using, all email from local.domain would be bounced. The other configuration is roughly the same, except the mail appliance filters on both directions, therefore allowing mail to pass. (Software on your mail gateway falls into this category). While this solution sounds great on paper, I think they are going to inadvertently drop a lot of legit email. Granted, I don't handle my employer's spam solution (although I used to at my last job) so I could just be blowing steam. Hope they iron out the kinks. BTW, where do I get ISP people that I can talk to on the phone who know about MX records? My guys don't even know what cable modems are. Keith Wright wrote:
From: Andy Stewart <andystewart@comcast.net>
In my town, I've noticed that other town employees with whom I send email are unable to send return email to me. This started happening about a month ago. My ISP is Comcast.
I am just going to type something crazy off the top of my head and go to sleep. Take two and call me in the morning.
This description was sent to me by a town employee:
o In an attempt to limit the amount of SPAM on the Comcast Internet system, Comcast does not allow external email servers to send mail to Comcast email accounts where the sending email server's MX records do not match.
o Because the TOWN mail server is behind our firewall our incoming mail IP address is different from our sending mail IP address. In other words our MX records do not match consequently Comcast blocks our mail from being sent to Comcast email addresses.
Your town employees are impressively well informed.
Basic questions:
- - What is an MX record?
A Mail eXchange record is given by a DNS server when you ask for it. You did not say the domain you are sending to, but you can see comcast.com mx records thus:
C:> $ dig comcast.net mx C:> C:> <Redacted> C:> C:> comcast.net. 900 IN MX 5 gateway-r.comcast.net. C:> comcast.net. 900 IN MX 5 gateway-s.comcast.net.
There you see the name of two servers that will (aledgedly) accept mail for goodguy@comcast.net.
C:> <Redacted> C:> C:> gateway-r.comcast.net. 900 IN A 216.148.227.126 C:> gateway-r.comcast.net. 900 IN A 204.127.198.26 C:> gateway-s.comcast.net. 900 IN A 63.240.76.26 C:> gateway-s.comcast.net. 900 IN A 204.127.202.26
There you see their IP addresses. You can talk to them like this
C:> $ telnet 216.148.227.126 smtp C:> Trying 216.148.227.126... C:> Connected to gateway-r.comcast.net (216.148.227.126). C:> Escape character is '^]'. C:> 220 rwcrmxc18.comcast.net - Maillennium ESMTP/MULTIBOX rwcrmxc18 #337 C:> helo dsl.keithdiane.us C:> 250 rwcrmxc18.comcast.net C:> mail from: kwright@keithdiane.us C:> 501 need MAIL FROM:<name@domain> C:> MAIL FROM: <kwright@keithdiane.us> C:> 250 ok C:> RCPT TO: <andystewart@comcast.net> C:> 250 ok C:> DATA C:> 354 ok C:> This is just kwright goofing on you. C:> Read your WLUG messages I will explain. C:> . C:> 250 ok . id=20060425052454r1800cg1fje [f] C:> quit C:> 221 rwcrmxc18.comcast.net C:> QUIT C:> Connection closed by foreign host.
It seemed to work, and I am typing this on a machine behind an NAT translation firewall (other kinds should be transparent). This is not my mail server, but it seemed to work. Only Andy can say whether they accepted the message and then trashed it in flagrant violation of RFC-2821, which tells how to do such things. They are more tight-assed than most about using the proper case, and I have never seen one that required the <brackets.com> around the address.
- - Is it normal for the mail server to be behind the firewall? I thought perhaps it would be either exposed to the net or on the DMZ.
If you have only one IP addresses, it seems that either your mail server must _be_ the firewall, or be behind it. I don't think it's crazy, but the only way to find out how "normal" it is would be to break it and see if the people who complain are normal.
I am wondering if there is some misconfiguration or perhaps a different configuration that could be used to alleviate this problem.
I am not convinced the problem has been exactly described, although your town employee seems to know a lot more than I do about it. You may be standing in the middle of a pissing contest. If a customer and a local authority work together you might get comcast's leg quite wet.
I have no expertise running a mail server and thought somebody on this list might be able to help.
I hope you have learned your lesson about expecting help from people with expertise. That reminds me of a short FAQ that appeared in the Managment School Student Newspaper:
Q: What are those strange creatures in the hall? At first, I took them for apes, but they all wear bluejeans.
A: Those are not apes, those are PhD candidates. The hair, grunting, and hunched gait become more pronounced just before Qualifying Exams. Rather than run from them, you will find that you can speak to them, if you ask questions about your homework. The answers can be helpful if you can keep them focused on your problem. If the answer begins "In equilibrium..." you know you have asked the wrong one.
-- Keith _______________________________________________ Wlug mailing list Wlug@mail.wlug.org http://mail.wlug.org/mailman/listinfo/wlug
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFETf9vaI8VEtSi4H8RApUdAJ40Z5ZleYLDzWmPDexxPhXqD+g5wgCeP5Ro I6DYshgubsdL5XiXt9TLWL0= =bMM1 -----END PGP SIGNATURE-----
On Tue, Apr 25, 2006 at 06:52:32AM -0400, Eric Martin wrote:
this is a M$ exchange server with an smtp connector. When I write an email, the smtp connector stamps it's id on my email outbound to the comcast servers. See where this is going? We don't want exhange.local.domain to be an mx record for my domain, it doesn't even face the internet. By this solution that Comcast is using, all email from local.domain would be bounced.
I'll add that WPI uses separate servers for receiving and sending SMTP connections. The sending servers are not in any DNS MX records, so any site using "spam blocking" tactics that require the sending SMTP server to be listed as an MX would block WPI email.
Then this isn't the full Comcast story, because I just received your mail on a comcast.net account. Steve On Apr 25, 2006, at 9:36 AM, Chuck Anderson wrote:
On Tue, Apr 25, 2006 at 06:52:32AM -0400, Eric Martin wrote:
this is a M$ exchange server with an smtp connector. When I write an email, the smtp connector stamps it's id on my email outbound to the comcast servers. See where this is going? We don't want exhange.local.domain to be an mx record for my domain, it doesn't even face the internet. By this solution that Comcast is using, all email from local.domain would be bounced.
I'll add that WPI uses separate servers for receiving and sending SMTP connections. The sending servers are not in any DNS MX records, so any site using "spam blocking" tactics that require the sending SMTP server to be listed as an MX would block WPI email. _______________________________________________ Wlug mailing list Wlug@mail.wlug.org http://mail.wlug.org/mailman/listinfo/wlug
On Tue, 25 Apr 2006, Stephen Ketcham wrote:
Then this isn't the full Comcast story, because I just received your mail on a comcast.net account.
Same. Any specifics on the bounce error they're getting? I know Comcast, like many providers, will refused SMTP connections that originate from what it or its blacklist consider dynamic IP ranges (cable, DSL, etc), so to get around it I have to relay any mail I send to Comcast addresses through my ISP's mail server (adding "comcast.net smtp:my.isps.mailserver.com" to /etc/postfix/transport or /etc/mail/mailertable for Postfix and Sendmail, respectively). Of course, I'd imagine Comcast distinguishes business class customers from standard home connections, but any more info on the error could be helpful. Brian J. Conway bconway(at)alum.wpi.edu "LINUX is obsolete" - Andrew S. Tanenbaum, creator of Minix - Jan 29, 1992
On Tue, Apr 25, 2006 at 09:36:20AM -0400, Chuck Anderson wrote:
I'll add that WPI uses separate servers for receiving and sending SMTP connections. The sending servers are not in any DNS MX records, so any site using "spam blocking" tactics that require the sending SMTP server to be listed as an MX would block WPI email.
Most mid-to-large organizations will do this as well. It would be complete stupidity for a receiver to not accept mail from a server whose domain MX record doesn't include that server -- they'd be blocking a vast majority of domains. What's more plausible is that the receiver is blocking mails from domains lacking an MX record, but even that's going to cause false positives (FPs) on a large amount of domains. The usual thing that happens is that receivers block mails where the host part of the email address (to the right of the @) has no A or MX record at all. Since to the receiver it looks like that host doesn't exist, why accept mail from it? ie: HELO nonexistant.example.com where, typically, nonexistant is a host behind a firewall, but isn't in the external DNS zone. Usually all hosts behind a firewall send to a relay gateway which masquerades the headers and envelope so that the receiving server sees an externally available name. ie: nonexistant.example.com (helo nonexistant ...) -> relay.example.com (helo example.com) -> your-server so when your-server gets the mail, it looks up "example.com" and finds A/MX records, so accepts the mail. -- Randomly Generated Tagline: "Many people equate the word 'daemon' with the word 'demon,' implying some kind of Satanic connection between UNIX and the underworld." - Evi Nemeth
On Tue, Apr 25, 2006 at 11:58:13AM -0400, Theo Van Dinter wrote:
_______________________________________________ Wlug mailing list Wlug@mail.wlug.org http://mail.wlug.org/mailman/listinfo/wlug
Date: Tue, 25 Apr 2006 12:03:30 -0400 Subject:
Content-Description: ATT10815498.txt
On Tue, Apr 25, 2006 at 09:36:20AM -0400, Chuck Anderson wrote:
I'll add that WPI uses separate servers for receiving and sending SMTP connections. The sending servers are not in any DNS MX records, so any site using "spam blocking" tactics that require the sending SMTP server to be listed as an MX would block WPI email.
Most mid-to-large organizations will do this as well. It would be complete stupidity for a receiver to not accept mail from a server whose domain MX record doesn't include that server -- they'd be blocking a vast majority of domains. What's more plausible is that the receiver is blocking mails from domains lacking an MX record, but even that's going to cause false positives (FPs) on a large amount of domains.
The usual thing that happens is that receivers block mails where the host part of the email address (to the right of the @) has no A or MX record at all. Since to the receiver it looks like that host doesn't exist, why accept mail from it?
ie:
HELO nonexistant.example.com
where, typically, nonexistant is a host behind a firewall, but isn't in the external DNS zone. Usually all hosts behind a firewall send to a relay gateway which masquerades the headers and envelope so that the receiving server sees an externally available name. ie:
nonexistant.example.com (helo nonexistant ...) -> relay.example.com (helo example.com) -> your-server
so when your-server gets the mail, it looks up "example.com" and finds A/MX records, so accepts the mail.
-- Randomly Generated Tagline: "Many people equate the word 'daemon' with the word 'demon,' implying some kind of Satanic connection between UNIX and the underworld." - Evi Nemeth
I'm wondering whether it might actually be a reverse lookup issue. I recently had to opt into a static IP at my web & mail services provider so that reverse lookups would work. AOL has started blocking email from senders that don't have a valid PTR record. If the mail server is behind a firewall, this _could_ be the issue. I use a mail server at home behind a firewall, but I don't send directly to the recipient -- I use the "smart host" feature of sendmail. The "masquerade_as" feature might be what they need. The trick is to make the smtp server look as though it's using the "external" hostname and IP address. I'm just guessing, though. :-) Bill
(See bottom)
From: Keith Wright <kwright@keithdiane.us>
From: Andy Stewart <andystewart@comcast.net>
In my town, I've noticed that other town employees with whom I send email are unable to send return email to me. This started happening about a month ago. My ISP is Comcast. ... C:> $ telnet 216.148.227.126 smtp C:> Trying 216.148.227.126... C:> Connected to gateway-r.comcast.net (216.148.227.126). C:> Escape character is '^]'. C:> 220 rwcrmxc18.comcast.net - Maillennium ESMTP/MULTIBOX rwcrmxc18 #337 C:> helo dsl.keithdiane.us C:> 250 rwcrmxc18.comcast.net C:> MAIL FROM: <kwright@keithdiane.us> C:> 250 ok C:> RCPT TO: <andystewart@comcast.net> C:> 250 ok C:> DATA C:> 354 ok C:> This is just kwright goofing on you. C:> Read your WLUG messages I will explain. C:> . C:> 250 ok . id=20060425052454r1800cg1fje [f] C:> QUIT C:> Connection closed by foreign host.
It seemed to work, and I am typing this on a machine behind an NAT translation firewall (other kinds should be transparent). This is not my mail server, but it seemed to work. Only Andy can say whether they accepted the message and then trashed it in flagrant violation of RFC-2821, which tells how to do such things.
Andy never said whether he got that message. You should have seen a two line message from me with almost no headers. If you got the message then I suspect that the problem with the town is not the firewall, but the reverse DNS. Could you post the domain name of the town? I would like to poke at its MX and PTR records to see if there is anything that I might feel like rejecting. Speaking of rejecting, when the town can not send mail to you do they get a bounce message with a reason for non-delivery, or does it just go into a black hole, looking like it was delivered but never showing up? -- Keith
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HI all, Comcast appears unwilling to whitelist the Town email domain since this is quite easily spoofed by spam generators. The Town is considering using port forwarding on their firewall to reach the mail server. The Town is unwilling to put the mail server on or outside of the firewall, claiming that the risk level is too high for them to support. Later, Andy - -- Andy Stewart, Founder Worcester Linux Users' Group Worcester, MA, USA http://www.wlug.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFETpgZHl0iXDssISsRArvsAJ95z2vFXZiZVK7eu/A/zBwxgBVWIQCfebM/ gDQBjl+MCVf9/PE68lIpEmE= =Sfj+ -----END PGP SIGNATURE-----
Date: Tue, 25 Apr 2006 17:43:53 -0400 From: Andy Stewart <andystewart@comcast.net> Comcast appears unwilling to whitelist the Town email domain since this is quite easily spoofed by spam generators. The Town is considering using port forwarding on their firewall to reach the mail server. The Town is unwilling to put the mail server on or outside of the firewall, claiming that the risk level is too high for them to support. Can't you just use an MX record with a high priority number (or whatever it's called, I've long since forgotten) and have your firewall eat packets targeted to it? -- Robert Krawitz <rlk@alum.mit.edu> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lpf@uunet.uu.net Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
participants (9)
-
Andy Stewart -
Bill Mills-Curran -
Brian J. Conway -
Chuck Anderson -
Eric Martin -
Keith Wright -
Robert L Krawitz -
Stephen Ketcham -
Theo Van Dinter