Board index Freebsd

smail 3.1.29.1 delivery problems

smail 3.1.29.1 delivery problems

Post by Fair p » Thu, 08 Aug 1996 04:00:00



Hello,

there are problems with mail delivery to local mail boxes by SMAIL
3.1.29.1 under FreeBSD 2.1.0 on local host.

local transport was reconfigured to use mail.local, however this still
causes mail to root to fail always.  If default smail local transport
is used, then this causes mail delivery to fail always for any users
on the system. This is related to file permission and locks somehow,
I suspect.

Could anybody using SMAIL on v2.1.0 or later send his/her smail
configuration files ? What else could the cause ?

Thanks in advance. Dima

 
 
 
Top

smail 3.1.29.1 delivery problems

Post by Serge K. Polyak » Tue, 13 Aug 1996 04:00:00


  >  Hello,

  >  there are problems with mail delivery to local mail boxes by SMAIL
  >  3.1.29.1 under FreeBSD 2.1.0 on local host.

  >  local transport was reconfigured to use mail.local, however this still
  >  causes mail to root to fail always.  If default smail local transport
  >  is used, then this causes mail delivery to fail always for any users
  >  on the system. This is related to file permission and locks somehow,
  >  I suspect.

You can try to set up permissions on /var/mail: rwxrwxrwt (set sticky-bit)
--
Serge Polyakov.
        phone:  +7-8452-243128 (8.00 - 17.00, MSK)
        fax:    +7-8452-516280


 
 
 
Top

smail 3.1.29.1 delivery problems

Post by J Wuns » Tue, 13 Aug 1996 04:00:00



Quote:> You can try to set up permissions on /var/mail: rwxrwxrwt (set sticky-bit)

This is a bad idea security-wise, since there are known race
conditions that might compromise the security of the mail spool files.

Smail can be setup so it uses /usr/libexec/mail.local to perform the
actual delivery.

--
cheers, J"org


Never trust an operating system you don't have sources for. ;-)

 
 
 
Top

smail 3.1.29.1 delivery problems

Post by Tom Torrance at ho » Sat, 17 Aug 1996 04:00:00


I am using smail with mail.local with success.  The only tricky
thing I found was that under 2.1 the smail package install was
faulty.  Do a 'man smail' then 'find' all the aliases of that
program. if they do not point to 'smail', delete the old
sendmail stuff and put in symbolic links to 'smail'.


: > You can try to set up permissions on /var/mail: rwxrwxrwt (set sticky-bit)

: This is a bad idea security-wise, since there are known race
: conditions that might compromise the security of the mail spool files.

: Smail can be setup so it uses /usr/libexec/mail.local to perform the
: actual delivery.

: --
: cheers, J"org


: Never trust an operating system you don't have sources for. ;-)

 
 
 
Top

smail 3.1.29.1 delivery problems

Post by Ron Echever » Sat, 17 Aug 1996 04:00:00


As an aside, smail 3.1.x has a security hole that allows people to
forge email through the smail machine without leaving evidence inside
the email's headers of which host the email originated from.  You
should upgrade to smail 3.2.

rone
--

 
 
 
Top

1. Problem with Smail 3.1.29.1 under Linux 1.3.12

I've been trying for a couple fo days to get Smail 3.1.29.1 running under
Linux 1.2.13 (Slackware 3.0) without much luck. Mail going outside the local
machine works fine but local delivery fails. Well, actually sometimes it
works and sometimes it doesn't. Mostly it doesn't. To test this, I've been
entering the following command (as root):

        smail -d userid <testfile

where testfile is just something I had lying around and userid is one of
several things:

 - if userid is an invalid local user (i.e. not in the passwd file)
   the smail debug output correctly indicates that the user is unknown.

 - if userid is pbash (a valid user), I get
   "... deferred: (ERR_134) transport local: failed to lock mailbox".
   Further investigation reveales that this is failing with a
   "Permission denied" error trying to lock "/var/spool/mail/pbash".
   /var/spool/mail/pbash exists and has owner "pbash" and group "mail"
   with "-rw-rw----" permissions. Smail is installed suid root.

 - if userid is "root", I get a segmentation fault (this is repeatable)

 - if userid is "postmaster", an alias for root, the mail is correctly
   delivered to root! (???)

Just from looking at the code, it seems that part of the problem is that
smail defaulted to the "nobody" userid for some reason. The code implies that
for some reason it couldn't find "pbash" so it took a default. The problem
is that "pbash" certainly exists. None of this explains the segmentation
fault when trying to mail root.

I built smail from scratch using the conf/os/linux configuration file. While
this was done for a Debian release, I've not seen anything in it that
wouldn't work for Slackware.

Any help at all would be appreciated.

--
Paul Bash  

2. Borland Products for Linux

3. Smail 3.1.29.1 & Linux problem

4. Konqueror is broken. Can't deal with cookies and daylight savings time.

5. Smail 3.1.29.1 and Solaris 2.4?

6. Squid 2.4 and MSFT auth module

7. Linux 1.2.8 and Smail 3.1.29.1

8. CTR book (report) on disaster recovery -- recommendations?

9. Smail 3.1.29.1 broken in linux 2.0 kernels

10. Any users of smail 3.1.28/29 on linux 2.0 kernels

11. smail 3.1.29.1 help?

12. Smail 3.1.29.1; From: line in outgoing mail wrong

13. SMail 3.1.29.1


All times are UTC
Board index