smail -bs with version 3.2.0.104
Thomas Richter
please excuse me, if this has been discussed before. I was absent from
smail3-users for a couple of month. Searching the archives did not help.
When pine tries to use the -bs option of sendmail, this fails for any
remote address. This is due to the changed smtp_remote_allow handling
in later smail releases (3.2.0.104 vs .101). smail has no sender_host_addr
in this mode, i.e. nothing to match against smtp_remote_allow. As a
result remote delivery is not allowed.
I changed this behaviour to always allow remote delivery if the
sender_host_addr is not set, assuming that this might only happen
when smail is called locally. The trivial patch is appended below.
I just wonder if this assumption is true, or if it opens some security
hole.
-- Thomas Richter
--- smtprecv.c.orig Mon Jan 18 17:30:13 1999
+++ smtprecv.c Thu Jan 21 16:23:31 1999@@ -2028,7 +2028,8 @@
* us. We do this first to avoid unnecessary DNS lookups should the sender
* in fact be listed in smtp_remote_allow.
*/
- if (sender_host_addr && smtp_remote_allow && match_ip(sender_host_addr, smtp_remote_allow)) {
+/* if (sender_host_addr && smtp_remote_allow && match_ip(sender_host_addr, smtp_remote_allow)) { */
+ if (!sender_host_addr || smtp_remote_allow && match_ip(sender_host_addr, smtp_remote_allow)) {
DEBUG2(smtp_remote_allow ? DBG_ADDR_HI : DBG_ADDR_LO,
"permitting remote relay by [%s] to %s.\n",
sender_host_addr ? sender_host_addr : "UNKNOWN", in->in_addr);
Greg A. Woods
> Subject: smail -bs with version 3.2.0.104
> please excuse me, if this has been discussed before. I was absent from
> smail3-users for a couple of month. Searching the archives did not help.
That's surprising because I'm sure this has been discussed several times
before. Perhaps the archives aren't as easy to search as I imagine they
could be.....
> When pine tries to use the -bs option of sendmail, this fails for any
> remote address. This is due to the changed smtp_remote_allow handling
> in later smail releases (3.2.0.104 vs .101). smail has no sender_host_addr
> in this mode, i.e. nothing to match against smtp_remote_allow. As a
> result remote delivery is not allowed.
Smail's '-bs' option is really only to be used only when smail is
attached to a TCP/IP socket connection (eg. when invoking it from
inetd). It should not be used by applications attempting to converse
over a Unix pipeline in an SMTP-like fashion.
Any application which attempts to use an SMTP-like protocol to interact
with a mailer should use '-bS' instead (i.e. "batched-SMTP" mode).
However this is not necessary with pine because pine can be configured
to use the normal command-line and avoid all the SMTP nonsense. Just
set 'sendmail-path' in either ~/.pinerc or the system pine.conf file
like this:
sendmail-path=/usr/lib/sendmail -oem -oi -t
FYI, in 3.2.0.104 (and probably all future versions), smail will permit
a HELO value that is a fully qualified host name which resolves to
INADDR_LOOPBACK, aka 127.0.0.1, even if STDIN is not connected to a
socket. However I don't know how to get Pine to use "localhost.domain"
instead of the proper hostname, nor should it.... This "fix" does make
it slightly easier to test SMTP handling from the command-line, at least
without using '-oX port' and telnet....
> I changed this behaviour to always allow remote delivery if the
> sender_host_addr is not set, assuming that this might only happen
> when smail is called locally. The trivial patch is appended below.
>
> I just wonder if this assumption is true, or if it opens some security
> hole.
I wouldn't recommend anyone apply your patch, as though I've not
analyzed the implications of it, I don't feel comfortable about it.
In any case SMTP is the wrong protocol to use when interacting with a
mailer on the local host.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwo...@acm.org> <robohack!woods>
Planix, Inc. <wo...@planix.com>; Secrets of the Weird <wo...@weird.com>
Louis Bertrand
> That's surprising because I'm sure this has been discussed several times
> before. Perhaps the archives aren't as easy to search as I imagine they
> could be.....
>
Speaking of archives, where are they?
Thanks
--Louis
Louis Bertrand, Bowmanville, ON, Canada
<lo...@signalpath.on.ca>
vox +1.905.623.8925 fax +1.905.623.3852
OpenBSD: Security matters <www.OpenBSD.org>