Feature-request: rfc5322_from_login_maps

[Dominik Chilla]

Hello together,

my postfix setup (submission-relay only!) requires an authenticated
(SMTP-AUTH plain/login) sender. Further it checks if the envelope-sender
matches the authenticated user-id by using sender_login_maps in
conjunction with LDAP. In envelope context this is a very usefull and
important feature, but it doesn´t prevent one to use a different email
address in the RFC5322-From header. So why not thinking about something
like rfc5322_from_login_maps?

Alternatively a restriction
"reject_rfc5322_from_envelope_sender_mismatch" (or the like) would be
thinkable.

Of course this could be done by a content scanner like
Amavis/Spamassassin, but I´m looking for a pure-postfix solution ;)

Thanks in advance and greetings from Germany,
Dominik

[Wietse Venema]

Post by Dominik Chilla
Hello together,
my postfix setup (submission-relay only!) requires an authenticated
(SMTP-AUTH plain/login) sender. Further it checks if the envelope-sender
matches the authenticated user-id by using sender_login_maps in
conjunction with LDAP. In envelope context this is a very usefull and
important feature, but it doesn?t prevent one to use a different email
address in the RFC5322-From header. So why not thinking about something
like rfc5322_from_login_maps?
Alternatively a restriction
"reject_rfc5322_from_envelope_sender_mismatch" (or the like) would be
thinkable.

Do you have a design for that? Note that most reject_mumble features
are designed to block mail BEFORE the "DATA" command, whereas the
message header is received AFTER the DATA command.

You might be better off implementing this with a Milter

In Postfix: require that MAIL FROM matches SASL login

In Milter: require that MAIL FROM matches From: header.

Post by Dominik Chilla
Of course this could be done by a content scanner like
Amavis/Spamassassin, but I?m looking for a pure-postfix solution ;)

Postfix does not have to implement all possible content restrictions,
that is what Milters and Amavis/Spamassassin are for.

Wietse

[Patrick Ben Koetter]

Post by Wietse Venema

Post by Dominik Chilla
Hello together,
my postfix setup (submission-relay only!) requires an authenticated
(SMTP-AUTH plain/login) sender. Further it checks if the envelope-sender
matches the authenticated user-id by using sender_login_maps in
conjunction with LDAP. In envelope context this is a very usefull and
important feature, but it doesn?t prevent one to use a different email
address in the RFC5322-From header. So why not thinking about something
like rfc5322_from_login_maps?
Alternatively a restriction
"reject_rfc5322_from_envelope_sender_mismatch" (or the like) would be
thinkable.

Do you have a design for that? Note that most reject_mumble features
are designed to block mail BEFORE the "DATA" command, whereas the
message header is received AFTER the DATA command.
You might be better off implementing this with a Milter

IIRC Christian wrote a MILTER that does exactly what you want about two years
ago. I'm not sure if he's willing or able to release it as open source.

***@rick

[Christian Rößner]

Post by Patrick Ben Koetter

Post by Wietse Venema

Post by Dominik Chilla
Hello together,
my postfix setup (submission-relay only!) requires an authenticated
(SMTP-AUTH plain/login) sender. Further it checks if the envelope-sender
matches the authenticated user-id by using sender_login_maps in
conjunction with LDAP. In envelope context this is a very usefull and
important feature, but it doesn?t prevent one to use a different email
address in the RFC5322-From header. So why not thinking about something
like rfc5322_from_login_maps?
Alternatively a restriction
"reject_rfc5322_from_envelope_sender_mismatch" (or the like) would be
thinkable.

Do you have a design for that? Note that most reject_mumble features
are designed to block mail BEFORE the "DATA" command, whereas the
message header is received AFTER the DATA command.
You might be better off implementing this with a Milter

IIRC Christian wrote a MILTER that does exactly what you want about two years
ago. I'm not sure if he's willing or able to release it as open source.

Yes ;-) Thanks for pointing that out

https://github.com/croessner/vrfydmn

Christian

[Benny Pedersen]

Post by Christian Rößner

Post by Patrick Ben Koetter
IIRC Christian wrote a MILTER that does exactly what you want about
two years
ago. I'm not sure if he's willing or able to release it as open
source.

Yes ;-) Thanks for pointing that out
https://github.com/croessner/vrfydmn

still no gentoo ebuild :(

[Dominik Chilla]

Hello Wietse,

thanks for your reply...

Post by Wietse Venema

Post by Dominik Chilla
Hello together,
my postfix setup (submission-relay only!) requires an authenticated
(SMTP-AUTH plain/login) sender. Further it checks if the envelope-sender
matches the authenticated user-id by using sender_login_maps in
conjunction with LDAP. In envelope context this is a very usefull and
important feature, but it doesn?t prevent one to use a different email
address in the RFC5322-From header. So why not thinking about something
like rfc5322_from_login_maps?
Alternatively a restriction
"reject_rfc5322_from_envelope_sender_mismatch" (or the like) would be
thinkable.

Do you have a design for that? Note that most reject_mumble features
are designed to block mail BEFORE the "DATA" command, whereas the
message header is received AFTER the DATA command.

I´m aware of this fact, but what about smtpd_data_restrictions? What is
the goal of this restriction class? IMO that restriction could be
implemented there. Comparing two email addresses doesn´t look to me too
exotic, no matter in which SMTP step they appear.

A milter application would also need to consume that whole headers stuff
after DATA command, push it into the private-milter-blob after each
milter-phase to finaly compare the addresses to fulfill this
requirement. Additionally, each milter causes overhead, which causes
further delay and multiple resource consumption for each milter and so
on... but that´s nothing new. I´m a big fan of milters, but not in any case.

Post by Wietse Venema
You might be better off implementing this with a Milter

I expected an answer like this, nevertheless I wanted to give it a try
;) This idea came up after seeing an m$ exchange smtp-connector
rejecting such "forged" emails.

Post by Wietse Venema
In Postfix: require that MAIL FROM matches SASL login
In Milter: require that MAIL FROM matches From: header.

Post by Dominik Chilla
Of course this could be done by a content scanner like
Amavis/Spamassassin, but I?m looking for a pure-postfix solution ;)

Postfix does not have to implement all possible content restrictions,
that is what Milters and Amavis/Spamassassin are for.

Thanks for the discussion. I appreciate your work very much!

Post by Wietse Venema
Wietse

Dominik

[Dominik Chilla]

Post by Christian Rößner

Post by Patrick Ben Koetter

Post by Wietse Venema

Post by Dominik Chilla
Hello together,
my postfix setup (submission-relay only!) requires an authenticated
(SMTP-AUTH plain/login) sender. Further it checks if the envelope-sender
matches the authenticated user-id by using sender_login_maps in
conjunction with LDAP. In envelope context this is a very usefull and
important feature, but it doesn?t prevent one to use a different email
address in the RFC5322-From header. So why not thinking about something
like rfc5322_from_login_maps?
Alternatively a restriction
"reject_rfc5322_from_envelope_sender_mismatch" (or the like) would be
thinkable.

Do you have a design for that? Note that most reject_mumble features
are designed to block mail BEFORE the "DATA" command, whereas the
message header is received AFTER the DATA command.
You might be better off implementing this with a Milter

IIRC Christian wrote a MILTER that does exactly what you want about two years
ago. I'm not sure if he's willing or able to release it as open source.

Yes ;-) Thanks for pointing that out
https://github.com/croessner/vrfydmn
Christian

@ Patrick/Christian: Big thanx :)

[/dev/rob0]

Post by Dominik Chilla

Post by Wietse Venema

Post by Dominik Chilla
my postfix setup (submission-relay only!) requires an
authenticated (SMTP-AUTH plain/login) sender. Further it checks
if the envelope-sender matches the authenticated user-id by using
sender_login_maps in conjunction with LDAP. In envelope context
this is a very usefull and important feature, but it doesn?t
prevent one to use a different email address in the RFC5322-From
header. So why not thinking about something like
rfc5322_from_login_maps?
Alternatively a restriction
"reject_rfc5322_from_envelope_sender_mismatch" (or the like)
would be thinkable.

Do you have a design for that? Note that most reject_mumble
features are designed to block mail BEFORE the "DATA" command,
whereas the message header is received AFTER the DATA command.

I´m aware of this fact, but what about smtpd_data_restrictions?

You're thinking of smtpd_end_of_data_restrictions, but there still
your idea has a problem: smtpd is not examining the DATA, but merely
passing it along to cleanup(8). The cleanup service is where the
only native Postfix content checking (header and body checks, see the
header_checks(5) manual and BUILTIN_FILTER_README) is done.

Post by Dominik Chilla
What is the goal of this restriction class? IMO that restriction

The idea of mumble in smtpd_mumble_restrictions is that restrictions
can be imposed at any point in the SMTP dialogue. The
smtpd_data_restrictions are evaluated when the client issues the
"DATA" command.

Post by Dominik Chilla
could be implemented there.

With a major rewrite of smtpd, or another hook into cleanup. This
doesn't sound like a good idea to me.

Post by Dominik Chilla
Comparing two email addresses doesn´t look to me too exotic,
no matter in which SMTP step they appear.

Except that all the DATA payload would have to be parsed and the
headers From: and Sender: would have to be identified.

Post by Dominik Chilla
A milter application would also need to consume that whole headers
stuff after DATA command, push it into the private-milter-blob
after each milter-phase to finaly compare the addresses to fulfill
this requirement.

Milters exist for this purpose. They do that.

Post by Dominik Chilla
Additionally, each milter causes overhead, which causes further
delay and multiple resource consumption for each milter and so
on... but that´s nothing new. I´m a big fan of milters, but not
in any case.

Your idea would bloat smtpd, and while not running as a separate
process, it certainly would cause more overhead.

Post by Dominik Chilla

Post by Wietse Venema
You might be better off implementing this with a Milter

I expected an answer like this, nevertheless I wanted to give
it a try ;) This idea came up after seeing an m$ exchange
smtp-connector rejecting such "forged" emails.

Postfix is not necessarily the best MTA for all use cases. For
integrated content filtering, Sendmail and Exim can sometimes be
superior. They have the benefit (and drawback!) of doing the whole
job in a single monolithic binary. So content filtering decisions
can be made while mindful of what was decided prior to DATA.

[Wietse Venema]

/dev/rob0:
[ Charset ISO-8859-1 converted... ]

Post by /dev/rob0

Post by Wietse Venema

Post by Dominik Chilla
my postfix setup (submission-relay only!) requires an
authenticated (SMTP-AUTH plain/login) sender. Further it checks
if the envelope-sender matches the authenticated user-id by using
sender_login_maps in conjunction with LDAP. In envelope context
this is a very usefull and important feature, but it doesn?t
prevent one to use a different email address in the RFC5322-From
header. So why not thinking about something like
rfc5322_from_login_maps?
Alternatively a restriction
"reject_rfc5322_from_envelope_sender_mismatch" (or the like)
would be thinkable.

Do you have a design for that? Note that most reject_mumble
features are designed to block mail BEFORE the "DATA" command,
whereas the message header is received AFTER the DATA command.

I'm aware of this fact, but what about smtpd_data_restrictions?

You're thinking of smtpd_end_of_data_restrictions, but there still
your idea has a problem: smtpd is not examining the DATA, but merely
passing it along to cleanup(8). The cleanup service is where the
only native Postfix content checking (header and body checks, see the
header_checks(5) manual and BUILTIN_FILTER_README) is done.

Presumably this would be done in the cleanup daemon (compare
rfc5321.from with rfc5322.from). I don't think that 'it can be done
in Postfix' means that doing so is necessarily a good idea.

Wietse

[Dominik Chilla]

Post by /dev/rob0
You're thinking of smtpd_end_of_data_restrictions, but there still
your idea has a problem: smtpd is not examining the DATA, but merely
passing it along to cleanup(8). The cleanup service is where the
only native Postfix content checking (header and body checks, see the
header_checks(5) manual and BUILTIN_FILTER_README) is done.

Yes, I ment something like xxx_end_of_data_restrictions. As I´m not sooo
familiar with the code, an idea must not be understood as a proposal for
a "nearly perfect" solution/implementation. Taking under attention that
the cleanup daemon already has the capabilities to perform
header_checks... I think it will be an interesting experience to write a
patch ;)

Post by /dev/rob0
Your idea would bloat smtpd, and while not running as a separate
process, it certainly would cause more overhead.

That´s an argument!

[Dominik Chilla]

Post by Wietse Venema
Presumably this would be done in the cleanup daemon (compare
rfc5321.from with rfc5322.from). I don't think that 'it can be done
in Postfix' means that doing so is necessarily a good idea.

Absolutely correct :)

Post by Wietse Venema
Wietse

Dominik

[A. Schulze]

Post by Wietse Venema
In Postfix: require that MAIL FROM matches SASL login
In Milter: require that MAIL FROM matches From: header.

I took that suggestion and had a deeper look in OpenDKIM today.
Parsing RFC5322.From /is/ complicated. But for my feeling OpenDKIM does that job very well.

OpenDKIM has the ability to do such checks in a very convenient way.
We may do lookup in static files, databases and even LDAP.

I would like to see it very similar to http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps
Lookup one RFC5322.From (Key) and check if one or more SASL Users (Values) are authorized.

But, what are the use-cases?

- RFC3522.From matches exact sasl_user
- RFC5322.From domain matches sasl users domain-part
- RFC5322.From is authorized by one ore more sasl users

...

Andreas

[Dominik Chilla]

Post by A. Schulze

Post by Wietse Venema
In Postfix: require that MAIL FROM matches SASL login
In Milter: require that MAIL FROM matches From: header.

I took that suggestion and had a deeper look in OpenDKIM today.
Parsing RFC5322.From /is/ complicated. But for my feeling OpenDKIM
does that job very well.
OpenDKIM has the ability to do such checks in a very convenient way.
We may do lookup in static files, databases and even LDAP.
I would like to see it very similar to
http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps

Besides "xxx_end_of_data_restrictions", "rfc5322_from_login_maps" was
one of the key aspects of my original question ;)

Post by A. Schulze
Lookup one RFC5322.From (Key) and check if one or more SASL Users
(Values) are authorized.
But, what are the use-cases?
- RFC3522.From matches exact sasl_user

Implies that your users authenticate with their email address only ->
bijective mapping, IMO this would be perfect for human senders with only
one email address. In this use cases, a person would not be able to use
additional/alias addresses as sender.

Post by A. Schulze
- RFC5322.From domain matches sasl users domain-part

Sounds useful if you want to "soften" a strict submission-policy.
Downside: within same domain, sender A will still be able to send as
sender B. But, the core statement of my original question was to prevent
this ;)

Post by A. Schulze
- RFC5322.From is authorized by one ore more sasl users

Could be used for automated application/script based senders like
***@example.org -> surjective mapping of sasl-user and sender-address.
Further this could be a solution for the flexibility problem of use-case
"RFC3522.From matches exact sasl_user".

Post by A. Schulze
...
Andreas

Thanx,
Dominik