Mailing List Archive

Weird problem with srs-socketmapd.0.32rc3.pl
I set up the 0.32rc3 installation on multiple servers and tested them to
be sure SRS was working and mails were getting through, especially
forwarding through one mail server in particular (call it "tampa") which
handles a particularly important forwarded email address. Most of the
testing was done from my servers, which all publish and run SPF1.
Everything was okay as of yesterday. SRS was working when "tampa" received
mail from servers with SPF (mine) and those without SPF (yahoo.com).

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'.

Daemon srs-socketmapd is running and there have been exactly NO
configuration changes to sendmail since I started it after the SRS
installation, when it *was* working.

Anybody have a pointer where I should look as to why this spontaneous
meltdown of rewriting? Thanks.

Robert Muchnick
Xenterra.net
720-276-7917

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
RE: Weird problem with srs-socketmapd.0.32rc3.pl [ In reply to ]
> -----Original Message-----
> From: Robert Muchnick [mailto:hostmaster@xenterra.net]
> Sent: donderdag 22 december 2005 22:30
> To: srs-discuss@v2.listbox.com
> Subject: [srs-discuss] Weird problem with srs-socketmapd.0.32rc3.pl
>
> I set up the 0.32rc3 installation on multiple servers and tested them to
> be sure SRS was working and mails were getting through, especially for-
> warding through one mail server in particular (call it "tampa") which
> handles a particularly important forwarded email address. Most of the
> testing was done from my servers, which all publish and run SPF1. Every-
> thing was okay as of yesterday. SRS was working when "tampa" received
> mail from servers with SPF (mine) and those without SPF (yahoo.com).
>
> 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'.
>
> Daemon srs-socketmapd is running and there have been exactly NO configu-
> ration changes to sendmail since I started it after the SRS installa-
> tion, when it *was* working.
>
> Anybody have a pointer where I should look as to why this spontaneous
> meltdown of rewriting? Thanks.

Hello Robert,

What exactly is not working? There are many new ways to invoke the
rewriting (all variations on options regarding class=w). To start with the
most obvious question: you did regenerate your sendmail.cf, right? (with
an option from the new m4).

It would help if you showed me a header, or part of the sendmail log, to
see with what sort of rewriting is occuring, and for what domains. It may
be that no rewriting takes place, or rewriting for a domain in class w for
which no SPF record exists.

Feel free to contact me off-list about it, if you so desire.

- Mark

System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
RE: Weird problem with srs-socketmapd.0.32rc3.pl [ In reply to ]
>> From: Robert Muchnick [mailto:hostmaster@xenterra.net]
>>
>> 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. Here's the exact scenario for my tests.

I send mail using my email address above directly from a machine here with
hostname "ns1.xenterra.net". The mail TO is "sales@metaflash-direct.com" and
the server names there are ns01.metaflash-direct.com and
mail.metaflash-direct.com. Alias in the srs-socketmapd.conf file has been tried
as both "mail.metaflash-direct.com" (a valid DNS entry) and
"metaflash-direct.com".

The target "sales@metaflash-direct.com" is forwarded in virtusertable to local
account "director". That local account is aliased in aliases to email address
"hostmaster@xenterra.net" (since I want to receive sales emails for
metaflash-direct.com domain).

Here is an entry from the maillog at metaflash-direct.com receiving mail from
my hostmaster@xenterra.net account:

Dec 22 19:04:33 ns01 sm-mta[9334]: jBN04RxW009334:
from=<SRS0=R0DfQdaT=2U=xenterra.net=hostmaster@xenterra.net>, size=1025,
class=0, nrcpts=1, msgid=<Pine.LNX.4.62.0512221703570.3619@ns1.xenterra.net>,
proto=ESMTP, daemon=MTA, relay=root@ns1.xenterra.net [216.17.171.131]
Dec 22 19:04:39 ns01 sm-mta[9337]: jBN04RxW009334: to=hostmaster@xenterra.net,
delay=00:00:06, xdelay=00:00:06, mailer=esmtp, pri=31244,
relay=mail.xenterra.net. [216.17.171.131], dsn=5.7.1, stat=User unknown
Dec 22 19:04:39 ns01 sm-mta[9337]: jBN04RxW009334: jBN04dxW009337: DSN: User
unknown
Dec 22 19:04:45 ns01 sm-mta[9337]: jBN04dxW009337:
to=<SRS0=R0DfQdaT=2U=xenterra.net=hostmaster@xenterra.net>, delay=00:00:06,
xdelay=00:00:06, mailer=esmtp, pri=32268, relay=smtp.xenterra.net.
[216.17.171.133], dsn=2.0.0, stat=Sent (jBN04dQp016904 Message accepted for
delivery)

The last entry is the mailer daemon failure notice.

Here's the pertinent part of the bounce message from Mailer Daemon:

----- Transcript of session follows -----
... while talking to mail.xenterra.net.:
>>> DATA
<<< 550 5.7.1 <hostmaster@xenterra.net>... Mail from [63.246.150.60] Rejected.
See
http://spf.pobox.com/why.html?sender=srs0=r0dfqdat=2u=xenterra.net=hostmaster@xenterra.net&ip=63.246.150
.60&receiver=ns1.xenterra.net
550 5.1.1 hostmaster@xenterra.net... User unknown
<<< 503 5.0.0 Need RCPT (recipient)

So, the mail forwarded from metaflash-direct.com was rejected by the receiving
mail server because the right hand side of the @ was not rewritten.

Now here's the weird part. Craigslist.org apparently uses SPF, as well. Here's
the header from a recent craigslist.org post to hostmaster@xenterra.net:

Return-Path:

<SRS0=4kfUZHSo=2T=craigslist.org=bounce-selfpostingkit-sales=metaflash-direct.com@mail.metaflash-dir
ect.com>
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ns1.xenterra.net
X-Spam-Level:
X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE,
SPF_PASS,UPPERCASE_25_50 autolearn=ham version=3.1.0
Received: from ns01.metaflash-direct.com (IDENT:0@mail.metaflash-direct.com
[63.246.150.60])
by ns1.xenterra.net (8.13.5/8.13.5) with ESMTP id jBMH47l5031432
for <hostmaster@xenterra.net>; Thu, 22 Dec 2005 10:04:12 -0700
Received-SPF: pass (ns01.metaflash-direct.com: domain of
bounce-selfpostingkit-sales=metaflash-direct.com@craigslist.org designates
130.94.251.49 as
permitted sender) receiver=ns01.metaflash-direct.com;
client_ip=130.94.251.49;

envelope-from=bounce-selfpostingkit-sales=metaflash-direct.com@craigslist.org;
Received: from mxout4.craigslist.org (mxout4.craigslist.org [130.94.251.49])
by ns01.metaflash-direct.com (8.13.5/8.13.5) with ESMTP id jBMH41n4007063
for <sales@metaflash-direct.com>; Thu, 22 Dec 2005 12:04:06 -0500
Received: from spot.craigslist.org (spot.craigslist.org [130.94.251.23])
by mxout4.craigslist.org (Postfix) with SMTP id 4774936BE1
for <sales@metaflash-direct.com>; Thu, 22 Dec 2005 09:03:55 -0800 (PST)

Here the Return-Path got rewritten to "mail.metaflash-direct.com" and was
accepted by ns1.xenterra.net because the IP address matched up. This happened
when sendmail.mc/cf was HACKed with SRS_LOCAL_SELF. I tried that one and
SRS_ALL with the problem forward and got failure all the time.

> There are many new ways to invoke the
> rewriting (all variations on options regarding class=w). To start with the
> most obvious question: you did regenerate your sendmail.cf, right? (with
> an option from the new m4).

Yes, always. See just above.

> It would help if you showed me a header, or part of the sendmail log, to
> see with what sort of rewriting is occuring, and for what domains. It may
> be that no rewriting takes place, or rewriting for a domain in class w for
> which no SPF record exists.

There are SPF records for all these domains.

BTW, xenterra.net is not in class w for the metaflash-direct.com server and
domain metaflash-direct.com is not in class w for ns1.xenterra.net.

> Feel free to contact me off-list about it, if you so desire.

I hope this is enough to elucidate this problem. If you need anything
more, let me know. I REALLY appreciate the help with this, Mark. I love this
SPF/SRS thing and it's really frustrating, not to mention destroying my email
service, that it's not working 100%.

Robert Muchnick
Xenterra.net
720-276-7917

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com
RE: Weird problem with srs-socketmapd.0.32rc3.pl [ In reply to ]
On Fri, 23 Dec 2005, Robert Muchnick wrote:

>>> From: Robert Muchnick [mailto:hostmaster@xenterra.net]
>>>
>>> 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

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=srs-discuss@v2.listbox.com