On Mon, Nov 20, 2023 at 11:02:15AM -0500, postfix--- via Postfix-users wrote:

> > You'd need to apply "body checks" to internally generated mail, which is
> > generally not recommended, and would apply regardless of context, not
> > just to bounced header-only content.
> > 
> >      main.cf:
> >          internal_mail_filter_classes = bounce
> >          bounce_body_checks = pcre:{ {~^(Content-Type:\s*multipart/)~ 
> > X-$${1}} }
> > 
> >      master.cf:
> >          bounce     unix  -       -       n       -       0       bounce
> >              -o { cleanup_service_name = bounce-cleanup }
> >          bounce-cleanup unix n    -       n       -       0       cleanup
> >              -o { receive_override_options = no_milters }
> >              -o { disable_mime_input_processing = no }
> >              -o { body_checks = $bounce_body_checks }
> >              -o { header_checks = }
> >              -o { nested_header_checks = }
> > 
> 
> Thank you! This might work for us (and does for this specific test case).
> But do I read you right that the danger is that if the full message is
> returned in the third part of the report then this setup would alter those
> headers as well (which would then presumably break the message, since it's
> not meant to be headers-only)?

No. This will not break actual MIME headers in the returned message, but
may interfere with message content where the string:

Content-Type: multipart/mumble

occurs at the beginning of a message body line in contexts other than
returned headers.  Note that the configuraion is narrowly targetting
just the "bounce" service, and enables only "body_checks".  It is
as safe as I know how to make it...

The caveat is there to let you know that the rule is less surgically
precise than say a tailored Postfix feature to explicitly censor or
modify the headers to be included in a header-text-only bounce.

Given infinite cycles, Postfix would support some sort of
"header-checks" like syntax for deciding how to tweak the returned
headers.  But the cost here should be borne by the guilty party (Amazon)
and not Postfix.

Barring more compelling use-cases, We should not go out of our way to 
help their broken MTA work.

-- 
    Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to