Il 29. 10. 15 17:33, Wietse Venema ha scritto: > Marco: >> A Milter could be also an option in the future, with the target of >> "sanitizing" the mails by replacing the original header with a new one, >> ensuring no internal information leakage (i.e. including the >> bi-directional mapping of the internal message ID created by the > smtp_header_checks has a replace option. The issue I have is that smtp_header_checks is unable to distinguish between mail sent to internal destinations (the VMsrunning the services) and the Internet. I could implement more "precise" roles, however my objective is to avoid this type of header check rules that will have to be changed/updated depending on the internal setup and are prone to get wrong after some time.
> >> internal mail clients "public" message IDs). I'm aware that someone is >> flagging this type of protection as "security by obscurity". In my >> opinion this is partially false as this is not a direct security measure >> (where security by obscurity is for sure wrong) , instead just a prudent >> way to make attacks more difficult. I have seen this type of approach in >> some commercial products (E-mail gateways, etc) and I'm surprised I have >> never seen this applied to Postfix. > If you are concerned about leaking client details, then there are > other leaks besides the message ID header. Simple transformations > can be done with the smtp_header_checks "replace" action. For more > complex transformations, use the same interfaces as content filters. Yes, that's exactly what I'm currently doing, i.e. I'm already removing all headers containing information about the internal domains, user-agent and mailer types, virus checking, internal path of mails, etc etc This is solving most of the leakage risks, however this is still not perfect, i.e. the message ID header masking requires a mapping table that can be implemented only in a Milter. > > Wietse Marco
