[pfx] Mail text wrapping
This is probably not the right place to be asking this as it is not directly Postfix related, but I don't know a better group to ask. For years I have sent text messages and just let the lines run on. Only inserting a \n for the start of a new paragraph. I never exceed the 988 line length limit. My mail client does it's magic to make it smaller line lengths and the recipient's puts it back together again so that it fills whatever window size they are using. However, in the last couple days, something has changed. Looking at the raw sent text of the message, the lines are less than 80 bytes with an "=" at the end of each line that is not a line end. Going back through some of my email history, I see that occurring for years. It was never visible to me or any of my recipients. I have a process that takes a portion of a received email and distributes it to a small recipient list. I am one of the recipients and It arrived with no cleanup. The = was at the end of every line. There was no reassembly of the original lines. The outgoing email had the following headers: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I have searched the internet for some discussion of this and find nothing. The RFCs don't seem to address it either. Given the normal thoroughness of the RFCs I believe that just means I haven't found the right one. What controls this behavior and what is needed to get the reassembly to work again? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] IMPORTANT, drop "resolve [!UNAVAIL=return]" from Linux nsswitch.conf files
The isi.edu DNS nameservers were apparently being DoSed today, and reverse and forward lookups (from my MX host) were failing. I was however surprised to then see: postfix/smtpd[2530673]: NOQUEUE: reject: RCPT from unknown[128.9.29.254]: 550 5.7.1 Client host rejected: cannot find your reverse hostname, [128.9.29.254]; from= to= proto=ESMTP helo= This should have been a soft error, but with recent-enough Fedora (I have 39), the default nsswitch.conf has: hosts: files myhostname resolve [!UNAVAIL=return] dns and this (specifically, !UNAVAIL=return) turns soft DNS failures into hard errors. The solution, on any production mail server, is to remove (with prejudice) resolve [!UNAVAIL=return] from the "hosts" nsswitch.conf entry. If you don't want to randomly reject mail when there's a brief network glitch, your MUST simplify nsswitch.conf to: hosts: files myhostname dns or even just: hosts: files dns -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: status=deferred (bounce or trace service failure)
Viktor Dukhovni via Postfix-users: > On Mon, Apr 22, 2024 at 12:21:01AM -0400, 785 243 via Postfix-users wrote: > > > Recently i'm seeing a few messages deferred with status=deferred > > (bounce or trace service failure) > > > > instead of status=deferred (host .. said: 450 ...) > > > > from the logs: > > > > postfix/smtp[272605]: warning: unexpected protocol > > delivery_request_protocol from private/bounce socket (expected: > > delivery_status_protocol) > > Your master.cf file has bad settings. Post the verbatim (no rewrapping > of whitespace of line breaks) output of "postconf -Mf". > > The "bounce" service entries should be: > > # Possibly chrooted, if Debian prefers that. > # > bounce unix - - n - 0 bounce > defer unix - - n - 0 bounce > trace unix - - n - 0 bounce > > Or perhaps the "bounce" service executable has been replaced with a link > to a delivery agent? The "real" bounce service supports the expected > protocol. Replacing the 'bounce' service with the 'discard' delivery agent has never been a supported configuration. It just happened to "work" because of sloppy protocol checks. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: status=deferred (bounce or trace service failure)
I discovered I had bounce set to discard I don't recall why, it's been that way for years. Maybe to suppress backscatter. After i set it back to bounce' i got the expected 550 reject On Mon, Apr 22, 2024 at 2:09 AM Viktor Dukhovni via Postfix-users wrote: > > On Mon, Apr 22, 2024 at 12:21:01AM -0400, 785 243 via Postfix-users wrote: > > > Recently i'm seeing a few messages deferred with status=deferred > > (bounce or trace service failure) > > > > instead of status=deferred (host .. said: 450 ...) > > > > from the logs: > > > > postfix/smtp[272605]: warning: unexpected protocol > > delivery_request_protocol from private/bounce socket (expected: > > delivery_status_protocol) > > Your master.cf file has bad settings. Post the verbatim (no rewrapping > of whitespace of line breaks) output of "postconf -Mf". > > The "bounce" service entries should be: > > # Possibly chrooted, if Debian prefers that. > # > bounce unix - - n - 0 bounce > defer unix - - n - 0 bounce > trace unix - - n - 0 bounce > > Or perhaps the "bounce" service executable has been replaced with a link > to a delivery agent? The "real" bounce service supports the expected > protocol. > > -- > 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
[pfx] Re: status=deferred (bounce or trace service failure)
On Mon, Apr 22, 2024 at 12:21:01AM -0400, 785 243 via Postfix-users wrote: > Recently i'm seeing a few messages deferred with status=deferred > (bounce or trace service failure) > > instead of status=deferred (host .. said: 450 ...) > > from the logs: > > postfix/smtp[272605]: warning: unexpected protocol > delivery_request_protocol from private/bounce socket (expected: > delivery_status_protocol) Your master.cf file has bad settings. Post the verbatim (no rewrapping of whitespace of line breaks) output of "postconf -Mf". The "bounce" service entries should be: # Possibly chrooted, if Debian prefers that. # bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce Or perhaps the "bounce" service executable has been replaced with a link to a delivery agent? The "real" bounce service supports the expected protocol. -- Viktor ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
