On 11/10/2016 6:00 PM, b...@bitrate.net wrote: > On Nov 10, 2016, at 17.17, Noel Jones <njo...@megan.vbhcs.org> wrote: >> >> On 11/10/2016 4:05 PM, btb wrote: >>> hi- >>> >>> i have an "appliance" which submits mail. it's inflexible, >>> unfortunately, and uses crappy values for the envelope sender and the >>> from: header. i have communicated with the vendor in an attempt to >>> rectify this, but as might be expected, the outcome has been less than >>> successful. >>> >>> hopefully some day, this changes, but in the interim, i'd like to >>> rewrite the envelope sender and the from: header [ala >>> sender_canonical_maps] for all mail from this client. >>> >>> how should i do this? is the best method to set up an additional >>> cleanup(8) instance with its own sender_canonical_maps for just this >>> client? somehow connect the client to its own smtp(8) service to use >>> smtp_generic_maps? are there other/better methods? >>> >>> thanks >>> -ben >>> >> >> depending on "how" the addresses are broken, you can probably just >> use canonical_maps to always rewrite the offending address to >> something valid. There shouldn't be any need for additional cleanup >> service unless you're fighting some common misspelling. >> >> Send specifics of what you're trying to rewrite for further help. > > in particular, this client impersonates our users, which we don't want. it > is aware of users and their email addresses [it's part of a voicemail system > which sends voicemail messages as email attachments, and "helpfully" claims > the email message was sent by the caller]. for us, this is undesirable. > > when a user submits a message with a sender of u...@example.com, we of course > don't want to change that. however, when this client does it, we do. the > localpart is dynamic. for example, i would like to rewrite a sender of > /^.*@example.com$/, but only when the message came from this client. many > other messages with a sender which matches /^.*@example.com$/ are submitted > from many other clients, but those don't need to be changed. >
I see. This might be a good use of smtpd_command_filter. Add another smtpd service on a different port and arrange for the wonky client to connect there or use a firewall redirect to send the client to the alternate port. A separate cleanup service can use header_checks to remove the false From: header, don't bother trying to rewrite it. The extra master.cf service entries will look something like: localip:2525 inet n - n - - smtpd -o smtpd_command_filter=regexp:/path/to/filter.regexp -o smtpd_client_restrictions=hash:/etc/postfix/voicemail,reject -o cleanup_service_name=cleanup_voicemail cleanup_voicemail unix n - n - 0 cleanup -o header_checks=header_checks_voicemail.regexp # The command filter something like (untested, but the general idea is correct): if /^MAIL FROM:\s.*example\.com/ /^MAIL FROM:\s*<(.*)@example\.com/ MAIL FROM: <voicemail+$1...@example.com> fi # the the voicemail client map ip.of.voicemail.system OK # and the header_checks_voicemail: /^From: .*@example\.com/ IGNORE Good luck! -- Noel Jones
