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
