Mailing List Archive

Recompile sendmail from source with socket map support (-DSOCKETMAP).
In the devtools/Site/site.config.m4 file you'll need a line like:

APPENDDEF(`confMAPDEF', `-DSOCKETMAP')

You might need a lot more in that file too. You'll want to start with
the RHEL4 source RPM, so that all of their patches are already applied.
Otherwise you have to reconstruct their customizations if you try to
compile from original sendmail source.

-- ============================
Tom Lahti
BIT Statement LLC

(425)251-0833 x 117
http://www.bitstatement.net/
-- ============================R

David MacQuigg wrote:
> We upgraded our installation of Redhat Linux from EL3 to EL4, and everything worked after the reboot except SRS. Looks like there may be a problem between the latest SRS and EL4. I'm considering dropping SRS, since hardly anyone is using it, but I would like to stay as much compliant with SPF as possible.
>
> Here is what I have so far:
> Immediately after the upgrade, Sendmail was down, so I attempted to start it manually.
>
>> [root@open-mail milter]# /etc/init.d/sendmail restart
>> Shutting down sendmail: [ OK ]
>> Shutting down sm-client: [FAILED]
>> Starting sendmail: 554 5.0.0 /etc/mail/sendmail.cf: line 179: readcf: map make_srs: class socket not available
>> 554 5.0.0 /etc/mail/sendmail.cf: line 181: readcf: map reverse_srs: class socket not available
>> [FAILED]
>> Starting sm-client: [ OK ]
>
> Taking the SRS lines out of sendmail.cf fixed the problem, so it is not something else.
>
> We actually don't have the latest SRS in our Linux distribution,
>
>> [dave@open-mail ~]$ rpm --query sendmail
>> sendmail-8.13.1-3.RHEL4.5
>> [dave@open-mail ~]$ rpm --query pysrs
>> pysrs-0.30.9-1.EL3
>
> so I downloaded the latest pysrs and and installed it.
>
>> -rw-r--r-- 1 dave admin 38508 Dec 31 13:53 pysrs-0.30.11-2.noarch.rpm
>> ... Installed above using Webmin ...
>> [root@open-mail milter]# /etc/init.d/pysrs restart
>> Shutting down pysrs: [ OK ]
>> Starting pysrs: [ OK ]
>> [root@open-mail milter]# rpm --query pysrs
>> error: Macro % has illegal name (%define)
>> pysrs-0.30.11-2
>> [root@open-mail milter]# /etc/init.d/pysrs status
>> pysrs (pid 29356) is running...
>
> Restoring the SRS lines in sendmail.cf brings back the original errors. Sendmail won't start.
>
> Any suggestions? Help will be greatly appreciated.
>
> -- Dave
> ************************************************************ *
> * David MacQuigg, PhD email: macquigg at open-mail.org * *
> * President, Open-Mail dot org phone: USA 520-721-4583 * * *
> * Postmaster, Box67 dot com * * *
> * 9320 East Mikelyn Lane * * *
> * http://purl.net/macquigg Tucson, Arizona 85710 *
> ************************************************************ *
>
> -------------------------------------------
> Sender Policy Framework: http://www.openspf.org
> Archives: http://v2.listbox.com/member/archive/1129/=now
> RSS Feed: http://v2.listbox.com/member/archive/rss/1129/
> Modify Your Subscription: http://v2.listbox.com/member/?&
> Powered by Listbox: http://www.listbox.com

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1129/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1129/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311535&id_secret=81104040-606418
Powered by Listbox: http://www.listbox.com

On Wed, 2 Jan 2008, David MacQuigg wrote:

> We upgraded our installation of Redhat Linux from EL3 to EL4, and everything
> worked after the reboot except SRS. Looks like there may be a problem
> between the latest SRS and EL4. I'm considering dropping SRS, since hardly
> anyone is using it, but I would like to stay as much compliant with SPF as
> possible.

Your email from me is bouncing. You need to recompile sendmail SRPM
with SOCKETMAP enabled.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1129/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1129/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311535&id_secret=81302963-b3369d
Powered by Listbox: http://www.listbox.com

On Wed, 2 Jan 2008, David MacQuigg wrote:

> between the latest SRS and EL4. I'm considering dropping SRS, since hardly
> anyone is using it, but I would like to stay as much compliant with SPF as
> possible.

SRS is mainly used to block forged DSNs. It doesn't matter whether anyone
else uses it. Other schemes such as BATV will also block forged DNSs, but
they require rewriting envfrom also (and hence also require SOCKETMAP
in sendmail until you upgrade to sendmail-8.14, which supports
rewriting envfrom via milter).

You are correct that the original function of SRS to enable forwarders to
pass SPF with naive clients is not much used. It turns out to be far
simpler for the clients to be less naive and simply configure their
forwarders in their SPF checker. Why should the forwarder change when
it is the client who decides to check SPF?

That said, I use SRS to handle mail aliases - I put my business
email as 'postmaster' on mail systems I administer, and don't want to
configure every customer as a forwarder in my mail gateway. With the
customer running pysrs anyway to block forged bounces, it automatically
SRS encodes any mail to postmaster before passing it on to me, so the
forwarded mail passes SPF as designed.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1129/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1129/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311535&id_secret=81310675-181642
Powered by Listbox: http://www.listbox.com

On Thu, 3 Jan 2008, Stuart Gathman wrote:
>On Wed, 2 Jan 2008, David MacQuigg wrote:
>
>> between the latest SRS and EL4. I'm considering dropping SRS, since hardly
>> anyone is using it, but I would like to stay as much compliant with SPF as
>> possible.
>
>SRS is mainly used to block forged DSNs. It doesn't matter whether anyone
>else uses it. Other schemes such as BATV will also block forged DNSs, but
>they require rewriting envfrom also (and hence also require SOCKETMAP
>in sendmail until you upgrade to sendmail-8.14, which supports
>rewriting envfrom via milter).

Cool! I will upgrade to 8.14, and greatly simplify our Border Patrol MTA package. Any plans for an SRS milter?

>You are correct that the original function of SRS to enable forwarders to
>pass SPF with naive clients is not much used. It turns out to be far
>simpler for the clients to be less naive and simply configure their
>forwarders in their SPF checker. Why should the forwarder change when
>it is the client who decides to check SPF?

Because often the "client" (in our case an MDA chosen by a subscriber/recipient at box67.com) is unaware that the mail was forwarded, and is usually unwilling or unable to allow recipients to whitelist their own forwarders.

>That said, I use SRS to handle mail aliases - I put my business
>email as 'postmaster' on mail systems I administer, and don't want to
>configure every customer as a forwarder in my mail gateway. With the
>customer running pysrs anyway to block forged bounces, it automatically
>SRS encodes any mail to postmaster before passing it on to me, so the
>forwarded mail passes SPF as designed.

I also find SRS very convenient to redirect all bounces back to our own servers, and deal with the problem immediately, usually by suspending the account that generated the bounce until while we notify our subscriber of the problem via a backup address. These bounces should never happen, since we forward only to recipients whose forwarding addresses were verified at signup.

-- Dave

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1129/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1129/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311535&id_secret=81397203-2f5e69
Powered by Listbox: http://www.listbox.com

On Thu, 3 Jan 2008, David MacQuigg wrote:

> >You are correct that the original function of SRS to enable forwarders to
> >pass SPF with naive clients is not much used. It turns out to be far
> >simpler for the clients to be less naive and simply configure their
> >forwarders in their SPF checker. Why should the forwarder change when
> >it is the client who decides to check SPF?
>
> Because often the "client" (in our case an MDA chosen by a
> subscriber/recipient at box67.com) is unaware that the mail was forwarded,
> and is usually unwilling or unable to allow recipients to whitelist their own
> forwarders.

I'm representing the forwarders point of view. If the client is unable
or unwilling to properly check SPF, then they shouldn't do it - it only
makes things worse. It is still good to publish. That said, I agree
with Frank that if checkers (who can/will not configure fowarders) would only
reject SPF fail with 551, then the redirection could be handled by the sender
(unless their MTA eats DSNs, which I've seen some of the "friendly" ones do).

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1129/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1129/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311535&id_secret=81517388-71425b
Powered by Listbox: http://www.listbox.com

Tom, thanks for your help.

At 04:46 PM 1/2/2008 -0800, you wrote:

>Recompile sendmail from source with socket map support (-DSOCKETMAP).
>In the devtools/Site/site.config.m4 file you'll need a line like:
>
>APPENDDEF(`confMAPDEF', `-DSOCKETMAP')

I cannot find the file site.config.m4 anywhere in packages sendmail-cf 8.13.1-3.RHEL4.5 or sendmail-devel 8.13.1-3.RHEL4.5

>You might need a lot more in that file too. You'll want to start with
>the RHEL4 source RPM, so that all of their patches are already applied.
> Otherwise you have to reconstruct their customizations if you try to
>compile from original sendmail source.

We need a simple procedure that will work for any system admin installing our Border Patrol MTA package. Installing a milter is pretty simple. Asking them to worry about patches is too much. It could also be a huge support burden on our end. Every time they upgrade their system, they will run into the same problem we did. Only SRS broke, out of 100 or so packages that were upgraded. The admin who originally installed our SRS package was not available.

I really like Stuart's suggestion of using the new milter functionality in Sendmail 8.14. I was not aware of this. It isn't in their API reference page at http://www.sendmail.org/doc/sendmail-current/libmilter/docs/api.html, but there is a brief mention of a new function smfi_chgfrom(), buried in the documentation at http://www.sendmail.org/ftp/RELEASE_NOTES.

Now I just need to find a Sendmail package with all the right patches for Red Hat RHEL4. At rpmfind.net I see 361 packages for sendmail. The latest for RHEL4 is 8.13, and we need 8.14. I might try <ftp://rpmfind.net/linux/fedora/development/i386/os/Packages/sendmail-8.14.2-2.fc9.i386.rpm>sendmail-8.14.2-2.fc9.i386.rpm since Red Hat Fedora should be pretty close to Red Hat RHEL4, but before doing a bunch of experiments, I would like to see if anyone has a suggestion.

-- Dave


>David MacQuigg wrote:
>> We upgraded our installation of Redhat Linux from EL3 to EL4, and everything worked after the reboot except SRS. Looks like there may be a problem between the latest SRS and EL4. I'm considering dropping SRS, since hardly anyone is using it, but I would like to stay as much compliant with SPF as possible.
>>
>> Here is what I have so far:
>> Immediately after the upgrade, Sendmail was down, so I attempted to start it manually.
>>
>>> [root@open-mail milter]# /etc/init.d/sendmail restart
>>> Shutting down sendmail: [ OK ]
>>> Shutting down sm-client: [FAILED]
>>> Starting sendmail: 554 5.0.0 /etc/mail/sendmail.cf: line 179: readcf: map make_srs: class socket not available
>>> 554 5.0.0 /etc/mail/sendmail.cf: line 181: readcf: map reverse_srs: class socket not available
>>> [FAILED]
>>> Starting sm-client: [ OK ]
>>
>> Taking the SRS lines out of sendmail.cf fixed the problem, so it is not something else.
>>
>> We actually don't have the latest SRS in our Linux distribution,
>>
>>> [dave@open-mail ~]$ rpm --query sendmail
>>> sendmail-8.13.1-3.RHEL4.5
>>> [dave@open-mail ~]$ rpm --query pysrs
>>> pysrs-0.30.9-1.EL3
>>
>> so I downloaded the latest pysrs and and installed it.
>>
>>> -rw-r--r-- 1 dave admin 38508 Dec 31 13:53 pysrs-0.30.11-2.noarch.rpm
>>> ... Installed above using Webmin ...
>>> [root@open-mail milter]# /etc/init.d/pysrs restart
>>> Shutting down pysrs: [ OK ]
>>> Starting pysrs: [ OK ]
>>> [root@open-mail milter]# rpm --query pysrs
>>> error: Macro % has illegal name (%define)
>>> pysrs-0.30.11-2
>>> [root@open-mail milter]# /etc/init.d/pysrs status
>>> pysrs (pid 29356) is running...
>>
>> Restoring the SRS lines in sendmail.cf brings back the original errors. Sendmail won't start.
>>
>> Any suggestions? Help will be greatly appreciated.
>>
>> -- Dave
>> ************************************************************ *
>> * David MacQuigg, PhD email: macquigg at open-mail.org * *
>> * President, Open-Mail dot org phone: USA 520-721-4583 * * *
>> * Postmaster, Box67 dot com * * *
>> * 9320 East Mikelyn Lane * * *
>> * http://purl.net/macquigg Tucson, Arizona 85710 *
>> ************************************************************ *

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1129/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1129/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311535&id_secret=81528061-4ec108
Powered by Listbox: http://www.listbox.com

On Thu, 3 Jan 2008, David MacQuigg wrote:

> Tom, thanks for your help.
>
> At 04:46 PM 1/2/2008 -0800, you wrote:
>
> >Recompile sendmail from source with socket map support (-DSOCKETMAP).
> >In the devtools/Site/site.config.m4 file you'll need a line like:
> >
> >APPENDDEF(`confMAPDEF', `-DSOCKETMAP')
>
> I cannot find the file site.config.m4 anywhere in packages sendmail-cf
> 8.13.1-3.RHEL4.5 or sendmail-devel 8.13.1-3.RHEL4.5

In the redhat SRPM, it is called redhat.config.m4, and is generated
in the SPEC file. So you need to edit SPECS/sendmail.spec.
Here is the section from my sendmail.spec for 8.13.8:

# generate redhat config file
cat > redhat.config.m4 << EOF
define(\`confMAPDEF', \`-DNEWDB -DNIS -DHESIOD -DMAP_REGEX')
define(\`confOPTIMIZE', \`${RPM_OPT_FLAGS}')
define(\`confENVDEF', \`-I/usr/include/db4 -I/usr/kerberos/include -Wall -DXDEBUG=0 -DTCPWRAPPERS -DNETINET6 -DHES_GETMAILHOST -DUSE_VENDOR_CF_PATH=1 -D_FFR_WORKAROUND_BROKEN_NAMESERVERS -D_FFR_SMTP_SSL -DSOCKETMAP')
define(\`confLIBDIRS', \`-L/usr/kerberos/%{_lib}')
define(\`confLIBS', \`-lnsl -lwrap -lhesiod -lcrypt -ldb')
define(\`confMANOWN', \`root')
define(\`confMANGRP', \`root')
define(\`confMANMODE', \`644')
define(\`confMAN1SRC', \`1')
define(\`confMAN5SRC', \`5')
define(\`confMAN8SRC', \`8')
define(\`confSTDIR', \`%{stdir}')
define(\`STATUS_FILE', \`%{stdir}/statistics')
EOF

You can get my SRPM from

http://bmsi.com/linux/el4/sendmail-8.13.8-1.RHEL4.1.src.rpm

Binaries are there also.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1129/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1129/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311535&id_secret=81550615-ab51bd
Powered by Listbox: http://www.listbox.com