RE: Weird problem with srs-socketmapd.0.32rc3.pl

Robert Muchnick <[email protected]> Sat, 24 Dec 2005 12:48:07 -0700 (MST)
Newsgroups gmane.mail.spam.srs.general
Message-ID <[email protected]>
On Fri, 23 Dec 2005, Robert Muchnick wrote:

>>> From: Robert Muchnick [mailto:[email protected]]
>>> 
>>> Now I'm getting the old SPF broken forward problem on mail sent to the
>>> forwarding address on "tampa": '[sending domain] does not designate ["-
>>> tampa" IP address] as permitted sender'.
>
>> Hello Robert,
>> 
>> What exactly is not working?
>
> It appears that rewriting is not happening on the mail server which forwards 
> the mail.

I worked around this problem with a dirty hack but at least it solved the 
mail forwarding problem.

First, I invoked sendmail with "-D /var/log/sendmail.log -d21.99" to get 
as much output as possible. The category 21 is the TRACEFLAG for rewrite 
(see /usr/local/sendmail-8.13.5/sendmail/TRACEFLAGS). It dumped over 
70,000 lines for just one email, but after scanning about 11,000 I became 
convinced that SRS rewriting was definitely not working properly.

To recap: the RHS of the "@" in Return-Path was not being rewritten to the 
domain of the forwarding machine but rather kept that of the original 
sending machine, causing the SPF equipped receiving machine to reject the 
forwarded mail.

I suspect that because the original sending machine also hosts numerous 
virtual hosts, and sendmail grabs domain names randomly in its reverse 
lookup, that sendmail started out getting confused and stayed that way 
badly enough to cause the SRS rules to get munged.

Forwarding using only the virtusertable or virtusertable in combination 
with the aliases table, therefore, was completely broken. Perhaps there is 
a subtle bug in either the perl file or the rewriting rules from the m4?

The hack, BTW, was to forward the TO address to a local user account that 
had a .procmailrc recipe to forward the mail on to the final recipient 
address. That is NOT an SRS forward; the hash in the SRS-signed mail is 
from the forwarding machine, not the originating machine. But at least 
I'm now getting the mail addressed to the problem address.

Robert Muchnick
Xenterra.net
720-276-7917