Patrick Ben Koetter
2011-05-30 13:16:45 UTC
Wietse,
we've already discussed this once and I would like to catch up on the idea to
expand SASL login to sender mapping to a more general identity to sender
mapping.
Status Quo
Postfix currently supports SASL login name to envelope sender mapping in order
to control which SASL login name may use a particular envelope sender address.
Goal
I suggest to open this mapping to a more generic context where also TLS client
certificate fingerprints and TLS client public key fingerprints may be used to
associate them with an envelope sender address.
The map logic as well as the restrictions to enforce usage identity to
envelope sender are already in place, but their names are specific to SASL
login names.
I propose we add functionality to identify clients by TLS client
certificate fingerprints and TLS client public key fingerprints and
additionally change the SASL login specific names to a more generic form that
makes them recognizable in a wider context.
I've used existing documentation to demonstrate how these names could change
(see attached smtpd_identity_sender_mapping.txt) and what their purpose would
be. Whenever I changed an options name I've put the old on in square brackets
behind the new name.
Additionally I suggest I'd write documentation that extracts relevant parts
from TLS_README and SASL_README and brings them together in a new
IDENTITY_README.
***@rick
P.S.
In an even wider scope it might be interesting to map a client IP address to a
sender name. One could restrict a satellite server to e.g. use only
***@satellite as envelope sender limiting it to something cron messages only.
Not sure if this is a real good feature, but it fits in the context of mapping
an identity to a sender name.
we've already discussed this once and I would like to catch up on the idea to
expand SASL login to sender mapping to a more general identity to sender
mapping.
Status Quo
Postfix currently supports SASL login name to envelope sender mapping in order
to control which SASL login name may use a particular envelope sender address.
Goal
I suggest to open this mapping to a more generic context where also TLS client
certificate fingerprints and TLS client public key fingerprints may be used to
associate them with an envelope sender address.
The map logic as well as the restrictions to enforce usage identity to
envelope sender are already in place, but their names are specific to SASL
login names.
I propose we add functionality to identify clients by TLS client
certificate fingerprints and TLS client public key fingerprints and
additionally change the SASL login specific names to a more generic form that
makes them recognizable in a wider context.
I've used existing documentation to demonstrate how these names could change
(see attached smtpd_identity_sender_mapping.txt) and what their purpose would
be. Whenever I changed an options name I've put the old on in square brackets
behind the new name.
Additionally I suggest I'd write documentation that extracts relevant parts
from TLS_README and SASL_README and brings them together in a new
IDENTITY_README.
***@rick
P.S.
In an even wider scope it might be interesting to map a client IP address to a
sender name. One could restrict a satellite server to e.g. use only
***@satellite as envelope sender limiting it to something cron messages only.
Not sure if this is a real good feature, but it fits in the context of mapping
an identity to a sender name.
--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.
saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>