Bug#405584: Without setuid, I can't use maildrop with esmtp
On Tue, 9 Jan 2007, Stefan Hornburg (Racke) wrote: Yes, there is no issue with sending to root, but it should be aliased to a regular user or an email account outside the host. I'll file a wishlist bug against esmtp :) ssmtp aliases root in particular, and other users in general if you want, but can't connect to a local MDA. -- http://rrt.sc3d.org/ | resolute, a. obstinate in a good cause (Bierce) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
Reuben Thomas wrote: On Tue, 9 Jan 2007, Stefan Hornburg wrote: Just my two cents: sending email to the root account (physically) instead using an alias is unnecessary and therefore deprecated by the standard MTA on Debian. Yes, I guess this is a weakness of esmtp (i.e. presumably you're not saying that you shouldn't send to the address "root", just that it should be aliased). Yes, there is no issue with sending to root, but it should be aliased to a regular user or an email account outside the host. Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Tue, 9 Jan 2007, Josip Rodin wrote: It's actually a bit fuzzy to me. Why should any user be able to do deliver e-mail to another user using only the MDA? A really simple reason against it is when the other user uses a MTA-side-mechanism to redirect their mail elsewhere (~user/.forward?), That requires having an MTA installed in the first place! In fact, we probably *should*, because it's not necessarily an effective notification interface in this setting - at least I've yet to see a desktop Linux user who actually reads their $MAIL. They just use a MUA that connects to outside mail accounts. Fair enough. I just use an MUA that reads my $MAIL, and all mail, external and internal, is dumped there. I find it bizarre that MUAs reimplement mail fetching (after all, most users are using POP, not IMAP, where there's an excuse to have a client built into the MUA). Anyway, thanks for the illuminating asides! -- http://rrt.sc3d.org/ | wet nurse, n. lactating lackey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Tue, 9 Jan 2007, Stefan Hornburg wrote: Just my two cents: sending email to the root account (physically) instead using an alias is unnecessary and therefore deprecated by the standard MTA on Debian. Yes, I guess this is a weakness of esmtp (i.e. presumably you're not saying that you shouldn't send to the address "root", just that it should be aliased). -- http://rrt.sc3d.org/ | Brevity is the soul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Tue, Jan 09, 2007 at 12:59:35AM +, Reuben Thomas wrote: > >And then someone files a bug saying they made it setuid but now it's > >completely open to the world... what do I do then? :) > > This is the way that procmail works, and it's hardly "open to the world", > it's just more susceptible to bugs. It's actually a bit fuzzy to me. Why should any user be able to do deliver e-mail to another user using only the MDA? A really simple reason against it is when the other user uses a MTA-side-mechanism to redirect their mail elsewhere (~user/.forward?), and so mails don't necessarily reach the user just because the MDA made a delivery where it thought it should. Maildrop avoids that issue by making it so that only known privileged users are able to invoke it in order to deliver to others. If someone goes to that much length to run it privileged, then they probably have some authority over other users. If not, revert to using MTAs (who may then invoke MDAs) to start mail delivery; it's common for MTAs to know what they're doing, the MDAs are their bell-hops :) > >Well, for that matter, most users don't need an MTA to begin with. It > >sounds like you want it (esmtp) in order to get the standard > >/usr/sbin/sendmail interface, but on the other hand, for most users that > >whole thing is just another piece of overhead. > > That's not quite true: a lot of other packages require this interface that > have nothing to do with sending internet mail, typically administration > packages like cron-apt and logwatch that want to notify the administrator > of certain events. email is the obvious way to do this, and the > /usr/lib/sendmail interface the obvious way to send mail, as it requires > only the ability to send text to a command. These are the sorts of package > that a user might well want to run on a personal machine: they keep the > machine up to date and monitor for possible security breaches and hardware > failure (e.g. smartctl). This is hardly sysadmin or esoteric territory. That's just because we are basically using an old Unixoid interface on personal machines. We could just as well have other provisions for these kinds of things. In fact, we probably *should*, because it's not necessarily an effective notification interface in this setting - at least I've yet to see a desktop Linux user who actually reads their $MAIL. They just use a MUA that connects to outside mail accounts. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
Reuben Thomas wrote: On Tue, 9 Jan 2007, Josip Rodin wrote: And then someone files a bug saying they made it setuid but now it's completely open to the world... what do I do then? :) This is the way that procmail works, and it's hardly "open to the world", it's just more susceptible to bugs. (Any suggestion what to do with this bug? close? wontfix?) Suggest "wontfix". That's what it looks like to me :) Well, for that matter, most users don't need an MTA to begin with. It sounds like you want it (esmtp) in order to get the standard /usr/sbin/sendmail interface, but on the other hand, for most users that whole thing is just another piece of overhead. That's not quite true: a lot of other packages require this interface that have nothing to do with sending internet mail, typically administration packages like cron-apt and logwatch that want to notify the administrator of certain events. email is the obvious way to do this, and the /usr/lib/sendmail interface the obvious way to send mail, as it requires only the ability to send text to a command. These are the sorts of package that a user might well want to run on a personal machine: they keep the machine up to date and monitor for possible security breaches and hardware failure (e.g. smartctl). This is hardly sysadmin or esoteric territory. Just my two cents: sending email to the root account (physically) instead using an alias is unnecessary and therefore deprecated by the standard MTA on Debian. Bye Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Tue, 9 Jan 2007, Josip Rodin wrote: And then someone files a bug saying they made it setuid but now it's completely open to the world... what do I do then? :) This is the way that procmail works, and it's hardly "open to the world", it's just more susceptible to bugs. (Any suggestion what to do with this bug? close? wontfix?) Suggest "wontfix". That's what it looks like to me :) Well, for that matter, most users don't need an MTA to begin with. It sounds like you want it (esmtp) in order to get the standard /usr/sbin/sendmail interface, but on the other hand, for most users that whole thing is just another piece of overhead. That's not quite true: a lot of other packages require this interface that have nothing to do with sending internet mail, typically administration packages like cron-apt and logwatch that want to notify the administrator of certain events. email is the obvious way to do this, and the /usr/lib/sendmail interface the obvious way to send mail, as it requires only the ability to send text to a command. These are the sorts of package that a user might well want to run on a personal machine: they keep the machine up to date and monitor for possible security breaches and hardware failure (e.g. smartctl). This is hardly sysadmin or esoteric territory. -- http://rrt.sc3d.org/ | Enlightenment is understanding becoming belief -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Tue, Jan 09, 2007 at 12:27:58AM +, Reuben Thomas wrote: > I agree that use with esmtp is a minority case. The one reason I think > changing this default might be reasonable is precisely because maildrop is > not shipped setuid root in Debian, so its behaviour when setuid root could > arguably be looser. And then someone files a bug saying they made it setuid but now it's completely open to the world... what do I do then? :) (Any suggestion what to do with this bug? close? wontfix?) > One last security point: using esmtp rather than a full-blown MTA is a big > security win anyway: no setuid binaries, and much less code in which to > find security bugs. Most users don't want or need a full MTA anyway, and I > think for these reasons it's nice to make it easier to avoid. Well, for that matter, most users don't need an MTA to begin with. It sounds like you want it (esmtp) in order to get the standard /usr/sbin/sendmail interface, but on the other hand, for most users that whole thing is just another piece of overhead. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Mon, 8 Jan 2007, Josip Rodin wrote: Restricting -d to trusted users has been the default for as long as I can remember. Tracking back old versions, I can confirm that it's been done since at least six years ago. It's a pretty sane default and changing it would be a mistake IMHO. I agree that use with esmtp is a minority case. The one reason I think changing this default might be reasonable is precisely because maildrop is not shipped setuid root in Debian, so its behaviour when setuid root could arguably be looser. In any case, I can just use procmail, as previously indicated. Not ideal (I switched from using procmail to maildrop because it is more user-friendly), but not disastrous either. I guess the procmail authors don't agree with the authors of maildrop! One last security point: using esmtp rather than a full-blown MTA is a big security win anyway: no setuid binaries, and much less code in which to find security bugs. Most users don't want or need a full MTA anyway, and I think for these reasons it's nice to make it easier to avoid. -- http://rrt.sc3d.org/ | competent, a. under-promoted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Mon, Jan 08, 2007 at 07:43:41PM +, Reuben Thomas wrote: > >Well, the solution to this is to have esmtp run that command either > >as the user root, daemon or mail (the trusted users), or not use -d. > >Can you do either of this? > > I can't do either of those. I can't make esmtp run the command as root, > because it itself is not setuid, and sendmail is just an alias for esmtp. I > If I don't use -d to maildrop, then maildrop thinks it's delivering to > root, and so just fork-bombs. > The problem here seems to be that esmtp has no daemon running as root, and > the way you're expecting me to use it requires some part of the MDA to be > root, unless I misunderstand. It's basically a security feature in maildrop - to go on and do something that requires root privileges (change uid and write to other users' files), you have to be a 'trusted user'. If you want to circumvent this, you have to change the source and recompile without this restriction. Restricting -d to trusted users has been the default for as long as I can remember. Tracking back old versions, I can confirm that it's been done since at least six years ago. It's a pretty sane default and changing it would be a mistake IMHO. Anyway, this doesn't generally happen with normal MTAs, only with esmtp which is trying to be an MTA, but it really isn't much of it... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Mon, 8 Jan 2007, Josip Rodin wrote: Well, the solution to this is to have esmtp run that command either as the user root, daemon or mail (the trusted users), or not use -d. Can you do either of this? I can't do either of those. I can't make esmtp run the command as root, because it itself is not setuid, and sendmail is just an alias for esmtp. I If I don't use -d to maildrop, then maildrop thinks it's delivering to root, and so just fork-bombs. If we made all users trusted, you would have a potentially unsafe setuid binary that can be run and poked at by everyone. Right, but that's my fault for making it setuid; by default it isn't setuid. The problem here seems to be that esmtp has no daemon running as root, and the way you're expecting me to use it requires some part of the MDA to be root, unless I misunderstand. -- http://rrt.sc3d.org/ Extreme programming: burn your bridges when you come to them -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Mon, Jan 08, 2007 at 06:35:45PM +, Reuben Thomas wrote: > >What exactly happens in your case? What is the exact error message? > > This is the case that I was hoping should work: > > $ sudo chmod u+s /usr/bin/maildrop > $ ls -l /usr/bin/maildrop > -rwsr-sr-x 1 root mail 162132 2006-10-08 23:11 /usr/bin/maildrop > $ echo foo | maildrop -V2 -d root > ERR: authdaemon: s_connect() failed: No such file or directory > maildrop: You are not a trusted user. > > This case doesn't work, but there's no problem: > > $ sudo chmod u-s /usr/bin/maildrop > $ ls -l /usr/bin/maildrop > -rwxr-sr-x 1 root mail 162132 2006-10-08 23:11 /usr/bin/maildrop > $ echo foo | maildrop -V2 -d root > ERR: authdaemon: s_connect() failed: No such file or directory > maildrop: Cannot set my user or group id. Well, the solution to this is to have esmtp run that command either as the user root, daemon or mail (the trusted users), or not use -d. Can you do either of this? If we made all users trusted, you would have a potentially unsafe setuid binary that can be run and poked at by everyone. If maildrop is not setuid root itself, normal users have no chance to ever use -d . -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Mon, 8 Jan 2007, Josip Rodin wrote: [Note to self: always re-read what you wrote originally.] Sorry, I've confused the issue by mis-restating it. My problem is with sending mail *to* root, not *from* root. What exactly happens in your case? What is the exact error message? This is the case that I was hoping should work: $ sudo chmod u+s /usr/bin/maildrop $ ls -l /usr/bin/maildrop -rwsr-sr-x 1 root mail 162132 2006-10-08 23:11 /usr/bin/maildrop $ echo foo | maildrop -V2 -d root ERR: authdaemon: s_connect() failed: No such file or directory maildrop: You are not a trusted user. This case doesn't work, but there's no problem: $ sudo chmod u-s /usr/bin/maildrop $ ls -l /usr/bin/maildrop -rwxr-sr-x 1 root mail 162132 2006-10-08 23:11 /usr/bin/maildrop $ echo foo | maildrop -V2 -d root ERR: authdaemon: s_connect() failed: No such file or directory maildrop: Cannot set my user or group id. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Sun, Jan 07, 2007 at 11:59:29PM +, Reuben Thomas wrote: > >Well, it should work if esmtp runs it as one of the so-called trusted > >users. > >The compiled-in default includes: root mail daemon. What does esmtp run it > >as? > > esmtp runs it as whatever user it is run as. In this case, the problem > occurs when I run esmtp as root. In that case, I can't reproduce your problem. % sudo chmod u+s =maildrop % v =maildrop -rwsr-sr-x 1 root mail 173104 2006-10-09 08:18 /usr/bin/maildrop* % echo foo | sudo maildrop -V2 -d root Password: ERR: authdaemon: s_connect() failed: No such file or directory maildrop: Changing to /root Message start at 0 bytes, envelope sender=root maildrop: Attempting .mailfilter maildrop: Delivering to /var/mail/root % sudo chmod u-s =maildrop % v =maildrop -rwxr-sr-x 1 root mail 173104 2006-10-09 08:18 /usr/bin/maildrop* % echo foo | sudo maildrop -V2 -d root ERR: authdaemon: s_connect() failed: No such file or directory maildrop: Changing to /root Message start at 0 bytes, envelope sender=root maildrop: Attempting .mailfilter maildrop: Delivering to /var/mail/root What exactly happens in your case? What is the exact error message? > OK, so arguably esmtp is limited in this respect, but can we concentrate on > the apparent problem, namely that you say it should work when maildrop is > run as root (i.e. root is trusted) and for me this is only the case when > you do -d but not -d root? The problem is that I can't reproduce this behaviour :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Sun, 7 Jan 2007, Josip Rodin wrote: Well, it should work if esmtp runs it as one of the so-called trusted users. The compiled-in default includes: root mail daemon. What does esmtp run it as? esmtp runs it as whatever user it is run as. In this case, the problem occurs when I run esmtp as root. Also, the most straightforward way to avoid the trusted user requirement is to avoid the -d option (and avoid setuid, too). You can do that if you can tell esmtp to change the environment for you. For example the way Postfix does it: http://www.postfix.org/postconf.5.html#mailbox_command It says "The command is run with the user ID and the primary group ID privileges of the recipient." So it is still running as root, so surely something must be setuid, because otherwise how could a normal user send something to root? esmtp has no way of changing user on the MDA command, anyway. Exim can also do it: http://www.exim.org/exim-html-4.63/doc/html/spec_html/ch23.html OK, so arguably esmtp is limited in this respect, but can we concentrate on the apparent problem, namely that you say it should work when maildrop is run as root (i.e. root is trusted) and for me this is only the case when you do -d but not -d root? -- http://rrt.sc3d.org/ | Slow Pedestrian Crossing (Anon) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Sun, Jan 07, 2007 at 07:43:17PM +, Reuben Thomas wrote: > >There you go. Unless you quote the argument to "to", it is evaluated. > >!rrt means 'not string', and that means 0. That's why maildrop said that > >it delivered to 0. > > Thanks. However, this only cures the side note about mail seemingly > disappearing altogether, not the main part of the original report about > mailfilter failing to change to uid 0 when run as root. Running mailfilter > directly is not the problem, running it with -d root as root is. You said: > if I setuid it it refuses to work (which is fine given current policy, but > doesn't help me to get maildrop to work with esmtp). Well, it should work if esmtp runs it as one of the so-called trusted users. The compiled-in default includes: root mail daemon. What does esmtp run it as? Also, the most straightforward way to avoid the trusted user requirement is to avoid the -d option (and avoid setuid, too). You can do that if you can tell esmtp to change the environment for you. For example the way Postfix does it: http://www.postfix.org/postconf.5.html#mailbox_command Exim can also do it: http://www.exim.org/exim-html-4.63/doc/html/spec_html/ch23.html -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Sun, 7 Jan 2007, Josip Rodin wrote: There you go. Unless you quote the argument to "to", it is evaluated. !rrt means 'not string', and that means 0. That's why maildrop said that it delivered to 0. Thanks. However, this only cures the side note about mail seemingly disappearing altogether, not the main part of the original report about mailfilter failing to change to uid 0 when run as root. Running mailfilter directly is not the problem, running it with -d root as root is. -- http://rrt.sc3d.org/ | dumb blonde, n. susbt. phr. peroxymoron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Sat, Jan 06, 2007 at 08:04:16PM +, Reuben Thomas wrote: > On Sat, 6 Jan 2007, Josip Rodin wrote: > > >Uhh. cat /root/.mailfilter ? > > to !rrt > > (rrt is the name of my normal user) There you go. Unless you quote the argument to "to", it is evaluated. !rrt means 'not string', and that means 0. That's why maildrop said that it delivered to 0. Quote it! -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Sat, 6 Jan 2007, Josip Rodin wrote: Uhh. cat /root/.mailfilter ? to !rrt (rrt is the name of my normal user) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Sat, Jan 06, 2007 at 01:44:19AM +, Reuben Thomas wrote: > >Can you run this trivial test: > > > >echo foo > /tmp/foo > >su -c 'maildrop -V2 < /tmp/foo' > > > >And paste the output? > > maildrop: Changing to /root > Message start at 0 bytes, envelope sender=root > maildrop: Attempting .mailfilter > maildrop: Delivering to 0 Uhh. cat /root/.mailfilter ? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Fri, 5 Jan 2007, Josip Rodin wrote: Can you run this trivial test: echo foo > /tmp/foo su -c 'maildrop -V2 < /tmp/foo' And paste the output? maildrop: Changing to /root Message start at 0 bytes, envelope sender=root maildrop: Attempting .mailfilter maildrop: Delivering to 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Fri, Jan 05, 2007 at 12:40:11AM +, Reuben Thomas wrote: > >BTW, it should deliver to /var/mail/root, or whatever you used in > >/etc/maildroprc as the default $DEFAULT. It doesn't? > > I have nothing configured in /etc/maildroprc. Should I? Again, I just left > it alone when I installed it. No, you don't need to edit it. Can you run this trivial test: echo foo > /tmp/foo su -c 'maildrop -V2 < /tmp/foo' And paste the output? BTW, please keep the bug address in the Cc: when replying (use group-reply or reply-to-all functions). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Thu, Jan 04, 2007 at 06:45:59PM +, Reuben Thomas wrote: > If I drop the "-d %T" in esmtp's configuration, then mail from root > (whether to root or another user) goes AWOL with no messages and no record > that I can discover BTW, it should deliver to /var/mail/root, or whatever you used in /etc/maildroprc as the default $DEFAULT. It doesn't? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
On Thu, Jan 04, 2007 at 06:45:59PM +, Reuben Thomas wrote: > Package: maildrop > Version: 2.0.2-11 > Severity: normal > > I was using maildrop as the MDA with esmtp-run. In this configuration > it's set up to run as "/usr/bin/maildrop -d %T", and %T is the local > part of the address. > > This fails when I try to send mail to root, complaining that it can't > change user, which is not a surprise, as it's only setgid mail, not > setuid root. > > If I use procmail instead of maildrop I don't get this problem. If I > drop the "-d %T" in esmtp's configuration, then mail from root > (whether to root or another user) goes AWOL with no messages and no > record that I can discover, while mail from a non-root user to root > works fine. Do you happen to have courier-authdaemon installed and running? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405584: Without setuid, I can't use maildrop with esmtp
Package: maildrop Version: 2.0.2-11 Severity: normal I was using maildrop as the MDA with esmtp-run. In this configuration it's set up to run as "/usr/bin/maildrop -d %T", and %T is the local part of the address. This fails when I try to send mail to root, complaining that it can't change user, which is not a surprise, as it's only setgid mail, not setuid root. If I use procmail instead of maildrop I don't get this problem. If I drop the "-d %T" in esmtp's configuration, then mail from root (whether to root or another user) goes AWOL with no messages and no record that I can discover, while mail from a non-root user to root works fine. It seems that this might be a reasonable circumstance in which to have maildrop work setuid root, but if I setuid it it refuses to work (which is fine given current policy, but doesn't help me to get maildrop to work with esmtp). In summary, I don't expect maildrop to come setuid out of the box, but it seems that if I haven't missed anything then it would be nice if it did work setuid. If I've overlooked something, please point it out. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages maildrop depends on: ii courier-authlib 0.58-4 Courier authentication library ii esmtp-run [mail-transport-ag 0.5.1-4 User configurable relay-only MTA ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-19 GCC support library ii libgdbm3 1.8.3-3 GNU dbm database routines (runtime ii libpcre3 6.7-1 Perl 5 Compatible Regular Expressi ii libstdc++6 4.1.1-19The GNU Standard C++ Library v3 maildrop recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
