Ask-a-Muse: Follow up on FQDN in CFMAIL
Muse reader Eric Cobb, whose CFgears blog is an great read, made an excellent point regarding my statement that the designated server for a CFMAIL tag should be a full qualified domain name instead of just an IP address.
Eric wrote:
To me, this seems like it would be a problem with your mail server, not CF. The mail server is responsible for telling the world the FQDN the email is coming from, not CF. All the mail server settings in the CF Administrator do is tell CF who to pass the mail to so it can be sent, right? The mail server does the actual sending of the mail, and should have everything set up to report its FQDN. So if you specify the mail server's IP address in the CF Administrator, that should be fine since the mail server itself is the one actually sending the email. All CF needs to know is which machine to pass the mail to so it can be sent.
I may have a misunderstanding of how things work, but CF isn't a mail server, it just connects to one and lets it do its job, right?
I got to thinking about this and I wanted to be sure - so I ran a test. Here's what I found.
The Test
I set up a test by sending 2 mail messages through the same relay. One I sent using the IP address and the other using a fully qualified domain name. Both were exactly the same.
to="*muse email*"
subject="test from ip address"
server="10.4.2.18">
This message comes from the IP address relay.
</cfmail>
<cfmail from="*muse email*"
to="*muse email*"
subject="test from ip address"
server="internalrelay.cfwebtools.com">
This message comes from the FLQDN relay.
</cfmail>
When the 2 emails arrived I took some time to examine the headers of each of them. I wanted to see if that IP address shows up anywhere in the header information. I suspect that Eric is right and that the email server reports it's own FLQDN, but that doesn't mean the IP doesn't show up right? And if it shows up anywhere I'm guessing it's a tipoff to a spam filter some how. Here are the 2 headers (with some stuff removed):
Sent Via IP Address
Hmmm... it looks as if Eric is correct. The mail server identied itself as "internalrelay" on lines 5 and line 9. So yes, the relay server is writing into the header the information to correctly identify the origin. But take a look at line 14.
1: Authentication-Results: ...
2: DomainKey-Status: ...
3: Authentication-Results: ...
4: Return-Path: <*muse email*>
5: Received: from internalrelay.cfwebtools.com [10.4.2.18]
6: by mail.cfwebtools.com with SMTP;
7: ...
8: Received: from web-dev3.cfwebtools.com (web-dev3 [10.4.2.211])
9: by internalrelay (8.13.1/8.13.8) with ESMTP id n1DK4tKs028292
10: for <*muse email*>; Fri, 13 Feb 2009 14:04:55 -0600
11: Date: Fri, 13 Feb 2009 14:04:55 -0600 (CST)
12: From: *muse email*
13: To: *muse email*
14: Message-ID: <5097026....@10.4.2.18>
15: Subject: test from ip address
16: MIME-Version: 1.0
17: Content-Type: text/plain; charset=UTF-8
18: Content-Transfer-Encoding: 7bit
19: X-Mailer: ColdFusion 8 Application Server
Perhaps what Declude is clued into is the messageID (a sort of unique signature used by mail servers). The message ID seems to source the message by the IP address of the mail server instead of its FLQDN. If I examine the other message - the one sent using the FLQDN - I'm betting that line will look different, right?
14: Message-ID: <5097026....@10.4.2.18>
Sent Via FLQDN
1: Authentication-Results: ...
2: DomainKey-Status: ...
3: Authentication-Results: ...
4: Return-Path: <*muse email*>
5: Received: from internalrelay.cfwebtools.com [10.4.2.18]
6: by mail.cfwebtools.com with SMTP;
7: ...
8: Received: from web-dev3.cfwebtools.com (web-dev3 [10.4.2.211])
9: by internalrelay (8.13.1/8.13.8) with ESMTP id n1DK4tKs028292
10: for <*muse email*>; Fri, 13 Feb 2009 14:04:55 -0600
11: Date: Fri, 13 Feb 2009 14:04:55 -0600 (CST)
12: From: *muse email*
13: To: *muse email*
14: Message-ID: <54313234....@web-dev3.cfwebtools.com>
15: Subject: test from ip address
16: MIME-Version: 1.0
17: Content-Type: text/plain; charset=UTF-8
18: Content-Transfer-Encoding: 7bit
19: X-Mailer: ColdFusion 8 Application Server
Huh? Even though I was prepared to see a FLQDN in the message ID, I have to say this is not what I expected. What I had expected to see was "*unique signature*@internalrelay.cfwebtools.com". Instead, the signature actually shows the FLQDN of the server where the message originated. In other words, the web server. Somehow, specifying the domain of the server I was relaying through caused that server to reassign my message ID domain to be the FLQDN of the server which was making contact. It's more information to be sure and I can understand why Declude might see it as more legit since so much spam relays through agents on desktops and TOR etc. Still, it came as a surprise.
Now since this is news to me I would love for some savvy Muse Readers to set me straight on what is actually going on here. If you have a clue please fire away.
5 Comments
-
I have to wonder if you'd get a third answer if you tried just "internalrelay" instead of the full hostname.
Thinking out loud here ...
By putting in the FQDN you cause CF to have to do a DNS query for an MX record for that "cfwebtools.com" domain. Do you have an MX record setup on the inside, or just on the outside? If it's getting the external IP, then the sender is going to connect to the mail server's external address, using its own external address (through the NAT router), not the internal one. By doing so, the mail server's going to see the sender's external address, not the inside one. When it does a DNS lookup on the sender's external address, it gets "web-dev3...".
But ... when sent with just the internal IP, all the addresses will be internal/private. Do you have PTR records set up for your inside? And if so, is the mail server set up to correctly do reverse lookups for the inside? If not, then 10.x.x.x isn't reverse-translatable, so it can't get the sender's hostname.
I am rather surprised that it uses its own IP and not the sender's IP. But maybe it's making the assumption that since it's coming from a private IP range then the sending server must be a client? -
Rick,
To answer your question - we have an "interal" DNS which will return an "interal" IP address for the connection... Same address as if I used the IP. In fact we do NOT have reverse PTR for that record - and I don't think we have external reverse PTR for it either.... (it's a dev server).
So My take would be that CF looks up "internalrelay.cfwebtools.com" and connects to on the internal subnet (same subnet actually).
Does that help or confuse you more? :) -
Just FYI, it's FQDN without an L :) http://en.wikipedia.org/wiki/FQDN -
Hi Mark
I'm not a mail guru and I don't have *the answer*, but a couple of comments:
Firstly, while Eric is right that CF doesn't actually send the email, it does generate, or at least influence the generation of the message-ID header. I don't understand the exact mechanism, but if CF had nothing to do with it, we wouldn't have had the problem Charlie Arehart describes with mail sent from CF7 and below ( see http://www.carehart.org/blog/client/index.cfm/2008... ), which was fixed in CF8.
So how you set mail handling in CF clearly is important in terms of the generated headers.
Secondly, having done a few tests, I think Rick is probably right about the cause being your internal DNS.
Our set up is similar to yours in that the mail server is on a separate machine on the same internal network as the CF server. Both have public FQDNs and PTRs, but we have no internal DNS, so any lookups will return the public IPs.
Using the mail server's internal IP address in the cfmail tag, the results are the same as yours and as you would expect: the message-ID is stamped with the mail server's internal IP address.
But using the mail server's FQDN (our normal practice), the message-ID correctly appends the mail server's FQDN, *not* the CF server's as in your test. This is the expected and desired behaviour in CF8.
The difference is that the DNS lookups recorded in the "received from" and "message-ID" headers in ours all resolve to *public* IPs, whereas in yours they resolve to internal IPs (because of your internal DNS).
So it *seems* to be the fact that the mail server FQDN resolves to a private IP that results in it being dropped and the CFserver FQDN used instead.
Why that happens, and whether it's CF or the mail server that makes the decision, I'm not sure, but clearly the lesson is that to please the spam filters you should ensure CF is set to use a FQDN that resolves to a public IP (and with PTR and SPF records as well).
Sites to Watch
Aggregators
RSS
