Recent content by trichardson

@Stoiko Ivanov I removed all my hacks and applied this update and things are working fine. Thank you!

Stoiko, I reviewed your patches and largely agree with the approach. I might have added a configuration option to enable/disable SMTPUTF8 which could be used to retain PMG's original behavior w.r.t. locally-generated mails, but I also appreciate not wanting to complicate things. People with...

I was seeing the exact same thing. I assume you haven't yet disabled SMTPUTF8 in postfix. The first rejection you see is postfix being unhappy that your downstream Exch2016 server doesn't support SMTPUTF8. The second is because postfix tries to use SMTPUTF8 when sending the bounce message to the...

Not sure if you consider this "nondestructive", but this worked for me: I commented out line 267 of /usr/share/perl5/PMG/Utils.pm to disable the new check which was enabling SMTPUTF8. #disabled this: $mail_opts .= " SMTPUTF8" if mail_needs_smtputf8($entity, $sender, $targets); I also have...

Turns out the X-DFrom and X-DSubject headers contain UTF-8. I believe this is in contradiction to the third paragraph of 3.2 of SMTPUTF8

Stoiko, The timeline, from my point of view is this: 1. We have been successfully receiving mails with UTF8 in the envelope addresses for years, through PMG, into an Exchange 2010 server 2. An update applied on January 5 broke mail flow. That update bumped pmg-api to 7.2-3. Emails were being...

The modification to Utils.pm in pmg-api v7.2-3 will turn on SMTPUTF8 when it sees non-ASCII characters in the To/From addresses. This is problematic when emails are received with non-ASCII in the To/From fields and either 1) smptutf8_enable=no is configured in Postfix locally; or 2) the...

The ability to use a logical AND for items in a rule's What and Who object would be very useful since the rule list is first-matching-wins and rules cannot be chained in any way.