Re: 6.4 broke procmail .forward

2018-10-31 Thread Harald Dunkel

Hi Gilles,

On 10/28/18 6:52 PM, Gilles Chehade wrote:


Please do yourselves a favor, ditch procmail in favor of fdm.



I am not sure if fdm is an option. Looking at https://github.com/ft/fdm.git
it seems that this code has been abandoned.

Are there others?


Regards
Harri

--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: 6.4 broke procmail .forward

2018-10-28 Thread Gilles Chehade
On Sun, Oct 28, 2018 at 02:34:53PM -0400, Matt Schwartz wrote:
> fdm looks a whole helluva lot easier to get going too.
> 

yes, I can't find a reason why people still use procmail to be honest.

on a scale from 1 to 10 of horrible, procmail is at 100.


> On Sun, Oct 28, 2018 at 1:52 PM Gilles Chehade  wrote:
> >
> > On Sat, Oct 27, 2018 at 10:11:05PM -0700, William Ahern wrote:
> > > On Sat, Oct 27, 2018 at 09:36:15PM -0700, William Ahern wrote:
> > > > On Sat, Oct 27, 2018 at 08:59:37PM -0700, William Ahern wrote:
> > > > > Immediately after upgrading my procmail setup broke. Near as I can 
> > > > > tell
> > > > > smtpd now executes .forward pipes with the permissions of _smtpd 
> > > > > (same as
> > > > > aliases), whereas previously it executed .forward pipes with the 
> > > > > permissions
> > > > > of the user (similar to delivery to /var/mail mbox).
> > > > >
> > > > > Was this intentional or accidental?
> > > >
> > > > Sorry, I was wrong. What's actually happening is that smtpd is no longer
> > > > adding the From_ line, so when procmail appended the message to my 
> > > > mailbox
> > > > it was effectively concatenated with the previous message.
> > > >
> > > > Can the old behavior be restored? Or at least can an environment 
> > > > variable
> > > > (e.g. SENDER) be added providing the envelope sender which I can easily
> > > > prepend myself?
> > > >
> > >
> > > To respond my own question (again), smtpd will expand %{mbox.from} in the
> > > .forward line. So the fix is to pass it to procmail via the -f option,
> > >
> > >   |/usr/local/bin/procmail -f %{mbox.from}
> > >
> > > like how /usr/libexec/mail.mboxfile is written to the mda_exec string
> > > buffer in lka_session.c:lka_submit.
> > >
> >
> > Nice that you found out by yourself and this is in the list so people
> > can be referred to this thread ;-)
> >
> >
> > Now that I have your attention everyone:
> >
> > Please don't use procmail.
> >
> > I don't have a habit of advising against a particular software, but this
> > is one of the cases where I had a look at the code, and wish people knew
> > the horror.
> >
> > There is nothing good to say about procmail, nothing.
> >
> > I don't want to spread FUD but we're talking about a piece of code which
> > processes untrusted input with unreadable code and advises you to run it
> > setuid root because it doesn't know any better.
> >
> > There are safer, nicer and more modern alternatives such as fdm for one,
> > but quite frankly: even the shittiest 30 lines of sh self-written custom
> > mda makes a better choice than procmail.
> >
> > Please do yourselves a favor, ditch procmail in favor of fdm.
> >
> > If you want to argue why procmail is a nice choice be prepared for me to
> > start sharing samples of code and keep reminding you that the authors do
> > advise you to install it setuid root.
> >
> >
> > --
> > Gilles Chehade
> >
> > https://www.poolp.org  @poolpOrg
> >
> > --
> > You received this mail because you are subscribed to misc@opensmtpd.org
> > To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
> >
> 
> -- 
> You received this mail because you are subscribed to misc@opensmtpd.org
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
> 

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: 6.4 broke procmail .forward

2018-10-28 Thread Matt Schwartz
fdm looks a whole helluva lot easier to get going too.

On Sun, Oct 28, 2018 at 1:52 PM Gilles Chehade  wrote:
>
> On Sat, Oct 27, 2018 at 10:11:05PM -0700, William Ahern wrote:
> > On Sat, Oct 27, 2018 at 09:36:15PM -0700, William Ahern wrote:
> > > On Sat, Oct 27, 2018 at 08:59:37PM -0700, William Ahern wrote:
> > > > Immediately after upgrading my procmail setup broke. Near as I can tell
> > > > smtpd now executes .forward pipes with the permissions of _smtpd (same 
> > > > as
> > > > aliases), whereas previously it executed .forward pipes with the 
> > > > permissions
> > > > of the user (similar to delivery to /var/mail mbox).
> > > >
> > > > Was this intentional or accidental?
> > >
> > > Sorry, I was wrong. What's actually happening is that smtpd is no longer
> > > adding the From_ line, so when procmail appended the message to my mailbox
> > > it was effectively concatenated with the previous message.
> > >
> > > Can the old behavior be restored? Or at least can an environment variable
> > > (e.g. SENDER) be added providing the envelope sender which I can easily
> > > prepend myself?
> > >
> >
> > To respond my own question (again), smtpd will expand %{mbox.from} in the
> > .forward line. So the fix is to pass it to procmail via the -f option,
> >
> >   |/usr/local/bin/procmail -f %{mbox.from}
> >
> > like how /usr/libexec/mail.mboxfile is written to the mda_exec string
> > buffer in lka_session.c:lka_submit.
> >
>
> Nice that you found out by yourself and this is in the list so people
> can be referred to this thread ;-)
>
>
> Now that I have your attention everyone:
>
> Please don't use procmail.
>
> I don't have a habit of advising against a particular software, but this
> is one of the cases where I had a look at the code, and wish people knew
> the horror.
>
> There is nothing good to say about procmail, nothing.
>
> I don't want to spread FUD but we're talking about a piece of code which
> processes untrusted input with unreadable code and advises you to run it
> setuid root because it doesn't know any better.
>
> There are safer, nicer and more modern alternatives such as fdm for one,
> but quite frankly: even the shittiest 30 lines of sh self-written custom
> mda makes a better choice than procmail.
>
> Please do yourselves a favor, ditch procmail in favor of fdm.
>
> If you want to argue why procmail is a nice choice be prepared for me to
> start sharing samples of code and keep reminding you that the authors do
> advise you to install it setuid root.
>
>
> --
> Gilles Chehade
>
> https://www.poolp.org  @poolpOrg
>
> --
> You received this mail because you are subscribed to misc@opensmtpd.org
> To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
>

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: 6.4 broke procmail .forward

2018-10-28 Thread Gilles Chehade
On Sat, Oct 27, 2018 at 10:11:05PM -0700, William Ahern wrote:
> On Sat, Oct 27, 2018 at 09:36:15PM -0700, William Ahern wrote:
> > On Sat, Oct 27, 2018 at 08:59:37PM -0700, William Ahern wrote:
> > > Immediately after upgrading my procmail setup broke. Near as I can tell
> > > smtpd now executes .forward pipes with the permissions of _smtpd (same as
> > > aliases), whereas previously it executed .forward pipes with the 
> > > permissions
> > > of the user (similar to delivery to /var/mail mbox).
> > > 
> > > Was this intentional or accidental?
> > 
> > Sorry, I was wrong. What's actually happening is that smtpd is no longer
> > adding the From_ line, so when procmail appended the message to my mailbox
> > it was effectively concatenated with the previous message.
> > 
> > Can the old behavior be restored? Or at least can an environment variable
> > (e.g. SENDER) be added providing the envelope sender which I can easily
> > prepend myself?
> > 
> 
> To respond my own question (again), smtpd will expand %{mbox.from} in the
> .forward line. So the fix is to pass it to procmail via the -f option,
> 
>   |/usr/local/bin/procmail -f %{mbox.from}
> 
> like how /usr/libexec/mail.mboxfile is written to the mda_exec string
> buffer in lka_session.c:lka_submit.
> 

Nice that you found out by yourself and this is in the list so people
can be referred to this thread ;-)


Now that I have your attention everyone:

Please don't use procmail.

I don't have a habit of advising against a particular software, but this
is one of the cases where I had a look at the code, and wish people knew
the horror.

There is nothing good to say about procmail, nothing.

I don't want to spread FUD but we're talking about a piece of code which
processes untrusted input with unreadable code and advises you to run it
setuid root because it doesn't know any better.

There are safer, nicer and more modern alternatives such as fdm for one,
but quite frankly: even the shittiest 30 lines of sh self-written custom
mda makes a better choice than procmail.

Please do yourselves a favor, ditch procmail in favor of fdm.

If you want to argue why procmail is a nice choice be prepared for me to
start sharing samples of code and keep reminding you that the authors do
advise you to install it setuid root.


-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: 6.4 broke procmail .forward

2018-10-27 Thread William Ahern
On Sat, Oct 27, 2018 at 09:36:15PM -0700, William Ahern wrote:
> On Sat, Oct 27, 2018 at 08:59:37PM -0700, William Ahern wrote:
> > Immediately after upgrading my procmail setup broke. Near as I can tell
> > smtpd now executes .forward pipes with the permissions of _smtpd (same as
> > aliases), whereas previously it executed .forward pipes with the permissions
> > of the user (similar to delivery to /var/mail mbox).
> > 
> > Was this intentional or accidental?
> 
> Sorry, I was wrong. What's actually happening is that smtpd is no longer
> adding the From_ line, so when procmail appended the message to my mailbox
> it was effectively concatenated with the previous message.
> 
> Can the old behavior be restored? Or at least can an environment variable
> (e.g. SENDER) be added providing the envelope sender which I can easily
> prepend myself?
> 

To respond my own question (again), smtpd will expand %{mbox.from} in the
.forward line. So the fix is to pass it to procmail via the -f option,

  |/usr/local/bin/procmail -f %{mbox.from}

like how /usr/libexec/mail.mboxfile is written to the mda_exec string
buffer in lka_session.c:lka_submit.

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



Re: 6.4 broke procmail .forward

2018-10-27 Thread William Ahern
On Sat, Oct 27, 2018 at 08:59:37PM -0700, William Ahern wrote:
> Immediately after upgrading my procmail setup broke. Near as I can tell
> smtpd now executes .forward pipes with the permissions of _smtpd (same as
> aliases), whereas previously it executed .forward pipes with the permissions
> of the user (similar to delivery to /var/mail mbox).
> 
> Was this intentional or accidental?

Sorry, I was wrong. What's actually happening is that smtpd is no longer
adding the From_ line, so when procmail appended the message to my mailbox
it was effectively concatenated with the previous message.

Can the old behavior be restored? Or at least can an environment variable
(e.g. SENDER) be added providing the envelope sender which I can easily
prepend myself?

- Bill

-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org



6.4 broke procmail .forward

2018-10-27 Thread William Ahern
Immediately after upgrading my procmail setup broke. Near as I can tell
smtpd now executes .forward pipes with the permissions of _smtpd (same as
aliases), whereas previously it executed .forward pipes with the permissions
of the user (similar to delivery to /var/mail mbox).

Was this intentional or accidental? With the new behavior it's now
impossible for a user to independently process their own e-mail. Now a user
needs administrator intervention (root permissions) to specialize delivery
in smtpd.conf, to provide a setuid program, or to add a special doas.conf
rule.


-- 
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org