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