On Wed, Jul 20, 2016 at 10:05:38PM +0200, Dominik Chilla wrote: > On 20.07.2016 18:03, Wietse Venema wrote: > >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. > 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. > 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. > 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. > 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. > 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. > >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. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
