On 5/10/2016 11:07 AM, Viktor Dukhovni wrote:
On Tue, May 10, 2016 at 01:15:59AM -0500, deoren wrote:
# sender_dependent_default_transport_maps.conf
#
# This entry is matching against gmail.com because Google Calendar
# delivers notifications to your associated Gmail account. To
# receive them on your outside email account you have to configure
# Gmail to forward email. When it does, the Calendar notification
# appears to end up with an envelope sender address of your
# Gmail account. For testing purposes, I am attempting to just
# match on ALL Gmail accounts.
@gmail.com autosieve
I would not expect the messages generated by Sieve to be sent from
"gmail.com". These auto-generated messages are created on your
machine, and should be sent by some user on your machine (envelope
sender, not rfc822 "From:" header). Figure out which user sends
Sieve-generated mail.
The incoming Google Calendar notifications from Google's servers are
what I'm attempting to match against. Once I get that working I would
enable the local Sieve script.
For my testing I used a Gmail account and sent an email directly from it
to my primary account on the system. My expectation was that I would see
the new autosieve transport use logged in the mail log to prove that the
matching was at least occurring. I didn't see any clues which suggested
that the transport was being used though.
autosieve unix - - - - - smtp
-o syslog_name=postfix/autosieve
-o smtp_header_checks=$autosieve_header_checks
This is chrooted, which is OK if that works for you, but can be
a source of some problems (though not related to this thread).
Thanks for the heads up. I don't really know what I'm doing there, I
just copied the existing line from master.cf (Postfix 2.11.x, Ubuntu
14.04 LTS) and modified the name in an attempt to reflect your example.
As I got ready to do send this I turned to Google and looked for others
who ran into the same problem:
"postfix sender_dependent_default_transport_maps not working"
and ended up on a conversation you had with Russell Jones about four
years ago:
http://postfix.1071664.n5.nabble.com/sender-dependent-default-transport-maps-difficulties-td3402.html#a3409
Your comment here got me thinking:
> The sender_dependent_default_transport_maps is a mechanism
in Postfix, that overrides the default transport:nexthop for outbound
mail based on the sender address.
If the delivery is local (via LMTP), would
sender_dependent_default_transport_maps or even transport_maps even apply?
My goal is to match on the incoming notifications from a remote server,
strip out the Auto-Submitted header so a local Sieve rule will agree to
match against those emails and then generate a new custom notification
email (not using any of the existing text, headers, etc). That custom
email notification would then be delivered through an email-to-text
message gateway that the cellular phone service provider allows others
to use (ex: Verizon's vtext.com).
In other words, the notification that will be generated by the Sieve
rule will not be coming back to the system unless the remote
email-to-text gateway server bounces it. If it does, my goal is to have
the Postfix setup not match on those. This should allow Pigeonhole to
see the Auto-Submitted header and then refuse to process it, hopefully
preventing a loop from occurring.
