No, you're wrong. What the OP should do, is to enforce SPF/DKIM on specific RECEIVERS. For example, enforcing SPF/DKIM on for example webappad...@example.org.
-----Ursprungligt meddelande----- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För li...@lazygranch.com Skickat: den 5 september 2016 19:20 Till: postfix-users@postfix.org Ämne: Re: advice on securing a transport First of all, be wary taking advice from a newbie like me. That said, if you enforce SPF and DKIM in postfix, you will be rejecting a lot of mail. If there is a way to enforce SPF and DKIM on specific senders, that would be another story. But look at this line from the original message : "What I would really like to do is be able to send structured emails to the server, and have postfix pass them through a transport to the webapp (a Django site), which would parse the emails and do CRUD stuff with the database." Normally we read our email from a delivery agent like dovecot, but this mail will, if I understand the objective, with be "machine" read. That step is where you want to enforce SPF and DKIM. Original Message From: Sebastian Nielsen Sent: Monday, September 5, 2016 9:54 AM To: postfix-users@postfix.org Subject: SV: advice on securing a transport There is possibility to use SPF or DKIM to ensure the sender is not spoofed. For this particular service, you can run your SPF and/or DKIM validator in mandatory mode, eg, a missing SPF record will be treated as -all, and a missing DKIM signature is treated as a invalid one. Then you can actually use a list of authorized email adresses, even for third-party operators like GMAIL and such. So if a authorized user, sends a mail, using a server that is authorized either per that domain's SPF records or DKIM signature, then the mail will get accepted. Else it will be rejected. -----Ursprungligt meddelande----- Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] För Sean Greenslade Skickat: den 5 september 2016 18:36 Till: Eric Abrahamsen <e...@ericabrahamsen.net> Kopia: postfix-users@postfix.org Ämne: Re: advice on securing a transport On Mon, Sep 05, 2016 at 07:52:02PM +0800, Eric Abrahamsen wrote: > I have a postfix/dovecot installation on the same server as my > company's webapp. This webapp involves a lot of regular data entry, > which is a real pain to do using HTML forms. What I would really like > to do is be able to send structured emails to the server, and have > postfix pass them through a transport to the webapp (a Django site), > which would parse the emails and do CRUD stuff with the database. > > I can figure the details out myself, but I'm hoping to get advice on > one particular question: security. > > I guess the safest thing would be to require logged-in users: > presumably I could find a way to only accept emails from a local > account, but that would require everyone who had access to this system > to have an account on the server. > > The other option would be to maintain a list of authorized email > addresses, and then check incoming messages against this list. This > would be preferable, in that I don't have to bother users to create > and set up (and remember to use) a separate email account. My question > is, is there a truly secure way of only accepting emails from > authorized addresses? Or should I just go with option one and require > users to have accounts? Envelope sender / From: field is not to be trusted. Anyone can submit a message with any envelope sender to an unauthenticated mail server. I can see two ways of handling this. One is to implement standard submission port authentication / TLS on this machine, possibly with virtual users to prevent the need for all users to have local accounts. The other way is to configure the machine to only accept incoming mail from your organization's main mail server(s). That way, your regular mail servers will perform the sender authentication, and then you can rely on the envelope sender (presuming your main mail servers do not allow sender spoofing). --Sean
smime.p7s
Description: S/MIME Cryptographic Signature