On 9/27/20 2:07 PM, PGNet Dev wrote:
> so the problem appears not to be the result of a general sieve-processing
> fail,
> but rather tied to the the redirect action/transaction
For anyone interested, having dovecot sieve submit to its own submission proxy
appears to be causal.
Specifically, setting
submission_host = internal.mx.example.com:60025
to submit to @ an UNencrypted port, or
submission_host = internal.mx.example.com:60465
to submit @ an ENcrypted port results in the errors I've seen.
direct submission to the dovecot submission proxy certainly works, an in the
non-sieve-triggering tests above^.
also,
in brief mention here,
Sieve and SMTP submission
https://doc.dovecot.org/configuration_manual/sieve/sieve_and_smtp_submission/
an alternative is to set sendmail_path, using the sendmail binary.
in this setup, that's postfix's sendmail; so, here, that's
sendmail_path = "/usr/sbin/sendmail.postfix"
once changed, the sieve filter redirection works.
notably, using
submission_host = internal.mx.example.com:465
, submitting to postfix's listener _also_ fails.
that _suggests_ that the problem's in dovecot's submission code, as used by
sieve
