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.


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

Reply via email to