Thanks Viktor,
it works as expected for test messages, bare CR is replaced, your Perl makes it
nicely visible when the feature is turned off. Looking at the feature source
code, there is really nothing to go wrong...
Shows nothing for the original message, so moved the queue file to the testing
system which I can point to the same destination and where turning off TLS is
not a problem, made a tcpdump on my side and was unable to find any CR not
followed by a LF...
Looks like either something happens on the way or directly on the downstream
Sendmail... Do not know at what stage this check takes place in Sendmail
message processing, but there surely are some milters and custom rulesets that
might be interfering with this specific message -- as mentioned, these are some
newsletters coming from the same specific domain and probably have some common
attributes triggering "bare CR not allowed" response.
Anyway, sorry for the noise and thank you for your help.
Tomas
On Thu, Aug 22, 2024 at 10:18:59PM +1000, Viktor Dukhovni via Postfix-users
wrote:
> On Thu, Aug 22, 2024 at 12:32:31PM +0200, Tomas Habarta via Postfix-users
> wrote:
>
> > As the stray CR/LF replacement is implemented in cleanup server, I
> > assume that the corresponding queue file is already modified
>
> Correct, the replacement takes place as part of writing the queue file.
>
> Of course you have not posted evidence of your configuration, so hard to
> know whether it matches your intent. Post the output of at least:
>
> $ postconf -d cleanup_replace_stray_cr_lf
> $ postconf cleanup_replace_stray_cr_lf
>
> The former to make sure the parameter is actually supported in your
> build.
>
> > I can actually see a couple of CRs in body (raw hexdump of the queue
> > file and search for x0d)
>
> That's not the right way. Instead, use "poscat -hb", and look for a bare CR.
>
> # postcat -qbh $qid |
> perl -ne '
> next unless m{\r[^\n]};
> s/([\x00-\x1f\xff\\])/sprintf qq(\\x{%02x}), ord($1)/eg;
> print qq($_\n)
> '
>
> > but not quite sure whether this is a valid approach...
>
> Sadly, not.
>
> > Need to wait a month to try to catch and hold a sample with the
> > replace option set to "no" to get an idea how the source looks like
> > originally, but in the meantime, anyone noticed any similar behaviour
> > or better, any idea if (and if yes why) this might be possible to
> > happen within Postfix?
>
> Waiting is not necessary, just try to send a dedicated recipient whose
> messages are always kept in the hold queue (HOLD access(5) action) a
> message with a stray CR and see what happens.
>
> --
> Viktor.
> _______________________________________________
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
