LazyGranch: I look it at the point of view of the server who are receiving the mail. So basically, the OP has some email adress like "webapprecei...@example.org" that receives mail and processes this automatically into a database.
Only authorized users are allowed to send to this specifically crafted email adress. Thus, the receiving postfix server, could be configured to add a pass/fail header of SPF and DKIM authentication. Then the program acting on transport (eg, the actual /usr/bin program that is configured as transport destination for webapprecei...@example.org) just checks this header. If not at least one of them is PASS and the Return-Path: header matches whats on a authorized list, the program could be configured to just ignore the received mail in question. Care needs to be taken so not anyone can fool the validation by inserting a fraudulent SPF or DKIM header, which would result in a duplicate, one genuine and one fake header. This can be accomplished by either checking for duplicate headers and failing authentication if there is duplicate SPF or DKIM header. (note: DKIM-header = The header with the validation result, inserted by the local validator, NOT the actual signature). Or you can configure the validation process to always purge out any existing validation headers before inserting its own. Thus, actually, the postfix server does not need to reject any mail, this could be coded into the transport program which also does all the modification to the django app database, to dump all unauthenticated (eg, no valid SPF or DKIM) and unauthorized (not on authorized list) into /dev/null. Sean Greenslade: Thats the responsibility of the server who is authorized to act on behalf of that domain.
smime.p7s
Description: S/MIME Cryptographic Signature