On Saturday 12 January 2019 18:14:39 Viktor Dukhovni wrote: > > On Jan 12, 2019, at 6:02 PM, Pali Rohár <[email protected]> wrote: > > > > Meanwhile I decoded postdrop protocol and come up with more easier > > solution: > > > > I renamed postdrop binary to postdrop.real and implemented simple > > postdrop wrapper which reads stdin, injects "R" command and pass it to > > postdrop.real binary. > > Your untrusted users can invoke "postdrop.real" directly. What's your > threat model? Are you hosting users, or just sloppy software you can't > easily fix that emits the wrong envelope sender?
Currently I'm using it just for adding additional bcc. Not for removing or modifying email content. I know that postdrop.real can be invoked directly, but it is not a problem -- just additional bcc is not added -- and it is not a security problem. First thing for which I'm using it is storing all sent emails into mailbox. I'm using more email clients and basically every one needs IMAP configuration for ability to store sent email. Via this wrapper option I do not need any IMAP, because 'R' command (REC_TYPE_RCPT) is injected with local address and postfix deliver this local email. Second thing is getting copy of emails generated by different running software on server. Every software has its own specific configuration and for sending emails can in most cases use /usr/sbin/sendmail binary. And for monitoring purposes unmodified bcc copy of emails is sent to admins (watchers). From time to time, it is needed to change bcc address so it is needed to modify configuration of every software (need to remember every one config file where it is etc...) So easier solution is to let do this work for mail server -- postfix. Configuration of bcc address is on one place, so it simplify configuration and administration. > To enforce use of your wrapper, you'd have to move the setgid bit from > the real postdrop(8) to your wrapper, and make sure your wrapper is > sufficiently robust to not admit exploits. Yes, this is truth, but as I described above I do not need disallowing usage or real postdrop. > The supported way to handle the rewrites you're looking for is via a > content-filter or milter. So.. does it mean that postdrop binary protocol is subject to change? Or just it mean that "preferred way is to use milter"? Because if postdrop protocol is not going to be changed, there should not be problem, right? -- Pali Rohár [email protected]
signature.asc
Description: PGP signature
