Domain Routing to Postfix from Sendmail = Wrong IP information in Mail Logs!
 

This may sound like a silly question, but does anyone know how to get the correct mail relay IP when using domain routing/mailertables in Sendmail to forward all traffic for a domain to Postfix, which is on another machine inside the LAN?

From the Postfix Mail Log, here’s an example:

May 19 17:04:21 mail postfix/smtpd[7004]: connect from unknown[192.168.1.200]

May 19 17:04:21 mail postfix/smtpd[7004]: 806E32E600: client=unknown[192.168.1.200]

May 19 17:04:21 mail postfix/cleanup[7005]: 806E32E600: message-id=<20040519205531.87935.qmail@web41203.mail.yahoo.com>

May 19 17:04:21 mail postfix/nqmgr[4146]: 806E32E600: from=<me@yahoo.com>, size=972, nrcpt=1 (queue active)

May 19 17:04:21 mail postfix/smtpd[7004]: disconnect from unknown[192.168.1.200]

May 19 17:04:22 mail postfix/smtp[7007]: 806E32E600: to=<someone@at-my-domain.com>, relay=192.168.1.202[192.168.1.202], delay=1, status=sent (250 Ok: queued as D7EA45A069)

Here’s the same message, “before” it was routed through Postfix:

May 19 17:41:33 mirage sendmail[1629]: i4JLfT001629: from=<me@yahoo.com>, size=535, class=0, nrcpts=1, msgid=<20040519214341.28052.qmail@web41205.mail.yahoo.com>, bodytype=8BITMIME, proto=SMTP, daemon=MTA, relay=web41205.mail.yahoo.com [66.218.93.38]

May 19 17:41:34 mirage sendmail[1631]: i4JLfT001629: to=<me@my-domain.com>, delay=00:00:01, xdelay=00:00:01, mailer=smtp, pri=30535, relay=[192.168.1.201] [192.168.1.201], dsn=2.0.0, stat=Sent (Ok: queued as 3EF502E600)

See what I mean? “relay=web41205.mail.yahoo.com [66.218.93.38]” is present in the Sendmail log, but is stripped and replaced with my server IP when it’s routed through Postfix.

Why is this a bad thing? It’s not the end of the world, however I’m testing Postfix on a test machine inside my Lan. Without the correct “originating” IP information, this renders Postfixe’s many Spam prevention features pretty much useless, and because all it sees is 192.168.1.200 or 192.168.1.201. In fact, it makes testing UCE features almost impossible, as these features rely on the originating IP information.

Maybe this is an inherent, and unavoidable side effect when routing through another host perhaps? I don’t know, but I’ve tried everything, and I can’t get that dam originating IP information to show up in the Postfix logs. Is this even possible, or am I wasting my time here?

Would really appriciated some help people :)

Dave H

It's unavoidable the way your have your architecture setup. The MTA only sees the IP that it receives the message from, nothing else can be trusted (because it may have been altered). If Sendmail is attaching Received: headers to the body, than the IP that Sendmail received the message from will be in the body of the message (otherwise known as the RFC[2]822 section), but it won't be on the envelope (the RFC[2]821 section).

The short answer is no, you cannot make that show up in the Postfix logs and your RBLs or other IP-based anti-spam measures will not work (unless they scan the message body headers, but MTAs never look at that).

I have another box I’m not doing anything with, so I installed Postfix on that. On the Linksys, I’m now pointing port 25 to this box, and using Postfixes domain routing to route my domains back to the Sendmail box, as well as another mail server I’m setting up, (also with Postfix on it). This way, Postfix receives all inbound traffic first.

What I don’t know yet, is if the Postfix UCE features are actually applicable to domains that are routed from it. Ideally speaking, I could utilize all its UCE features before mail is routed to the other servers. Grin… That would be too easy, and I bet I’ll probably discover otherwise. The real pitfall, is that all testing will need to done without disrupting my 'live' domains.

Man… How the hell do these admins setup a server farm consisting of 10’s or hundreds of servers without losing a few years off their life. Albeit this is small home based setup, the amount of complexities that can emerge with a “multiple” MTA configuration is beyond description.

Thanks for your help chort –really appreciate it! :)

Dave