6.4 broke procmail .forward
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
Re: 6.4 broke procmail .forward
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
Re: 6.4 broke procmail .forward
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: log subject of mail in maillog
On Thu, Jul 15, 2021 at 03:20:56PM +0200, Marcus MERIGHI wrote: > Hello! > > m...@protonmail.ch (mabi), 2021.07.15 (Thu) 08:16 (CEST): > > I was wondering with OpenSMTPD if it is possible to log the subject of > > the mail in the maillog? Currently the from/to are being logged and I > > wanted to also log the subject if possible. > > Daemons that handle the Simple Mail Transfer Protocol do not care about > the content of the message. The Subject: ist part of the content, as > seen from the POV of the smtpd. > > Spam filters and local delivery agents inspect the content, though. > > I know you can make rspamd and dovecot-lda log the Subject:. > > Marcus Moreover, as a practical matter there's no singularly *correct* way to identify the Subject header for malformed messages, which means the Subject displayed by your MUA may not be the same identified by the MTA. Mostly that's thanks to Microsoft Exchange and Outlook. The traditional way to parse headers--as implemented by Sendmail and copied by *most* software--is to stop at the first line that is neither a header continuation (leading space) nor a valid start of header (field name + colon).[1] This matches a proper end-of-headers delimiter (empty line), as well as when a message begins without an end-of-headers break, usually with a line that does not parse as a header. Microsoft Exchange and Outlook, though, has alot of magic code to try to catch malformed header continuations (i.e. missing leading space) for Content-Type and similar headers. This means a malformed message can be parsed two different ways depending on the MTA or MUA. This allows smuggling not only different Subject headers, but entirely different bodies and attachments as you can effectively present different Content-Type, Content-Disposition, etc. headers to the parser. Smart software should just do like Sendmail does. Or like GMail--which parses like Sendmail but also triggers protective measures when malformedness is detected (e.g. to help prevent sneaking a trojan attachment past the GMail scanner through to Microsoft Exchange or Outlook). But these are choices that can leave a large number of people dissatified. Better to not put yourself in the position of having to make that choice if you can help it, like when you're a simple MTA that focuses on SMTP, relying on user plugins to handle any and all message parsing. [1] Sendmail was also tolerant of a leading Unix "From " line as typically inserted for Berkeley MBOX storage. Alot of older software also tolerates this, but plenty doesn't and you rarely see this in the wild anymore. Usually only locally if at all.
