>I also have seen ones where [EMAIL PROTECTED] was forged by >the source. All sorts of fun.
How would you test for that? Data portion isn't in the logs - did you find that with verbose logging turned on? My maillog is already 400+Meg/day, and this issue seems kinda sporatic. I DO have lots of disk space, but man is that a lot of log for an issue that might take a day or three to confirm. :-) >Did a little digging.... it is the start of cleanup, a call to rewrite to >standardize things and prevent problems. > >http://www.postfix.org/rewrite.html > >http://www.postfix.org/trivial-rewrite.8.html > >So certainly worth testing to see if it has any change on what you feel >should happen. Which is what led me to append_at_myorigin... I'm going to play with it and see what happens. http://www.postfix.org/cleanup.8.html says that trivial-rewrite is delegated the task of transforming all (envelope AND header) addresses to [EMAIL PROTECTED] form - so by design it would be monkeying with the data header - the issue at hand. I think in this application I want it to leave the data header alone (except for of course the required Received: additions, etc.), just like as I understand RFC2821 says it should - not that I claim to always fully understand the sometimes cryptic nuances of RFC specs... :-) If my main.cf has: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_recipient_domain, ... that should mean that I should always have fqdn envelope addresses (as smtpd is before cleanup) from any external sources, so I can't imagine this affecting any relayed delivery - only possibly locally generated notifications. Thanks for letting me bounce this off ya - sometimes the simple answers don't seem that simple at first. :-) -Tony >--Eric > > >
