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



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to