[pfx] Re: GMail is rejecting mail I forward
> On Oct 31, 2023, at 03:37, Matus UHLAR - fantomas via Postfix-users > wrote: > >>> On Oct 29, 2023, at 10:59, Matus UHLAR - fantomas via Postfix-users >>> wrote: >>> I did SRS by using postsrs, see https://github.com/roehling/postsrsd >>> >>> This way, even forwarding using ~user/.forward will get SRS'ed. >>> >>> However, any mail from foreign domains without DKIM may still get rejected. > > On 29.10.23 11:57, Doug Hardie via Postfix-users wrote: >> I run a similar mail server. I use SRS and it "works" - well sort of. Most >> of the mail gets eventually accepted although it is delayed many hours. The >> delay range is about 1.5 to 27 hours. > > Delayed how? Is the destination mailserver refusing the mail with temporary > error? > Yes. >> I am pretty sure that much of the long delayed mail is actually spam. I >> created a log scanner to find the sources for the messages that are delayed >> to see if there is any conistency but there are no significant differences >> in the number of delayed mail baed on source IP. > -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: GMail is rejecting mail I forward
-- Doug > On Oct 29, 2023, at 10:59, Matus UHLAR - fantomas via Postfix-users > wrote: > > On 29.10.23 16:43, Robert Inder via Postfix-users wrote: >> For 10 years now I've been running a Linux (CentOS 7) server, using >> Postfix to handle mail for a handful of users. >> Specifically, I'm running Postfix 2.2, because that is the most recent >> version yum will fetch >> from the current/default set of repositories. >> >> Some users want to use GMail, so I have used an alias (in an aliases file) >> to forward their mail to their GMail account, making >> person at my.domain >> an alias for >> same_person at gmail.com >> >> Recently, users have told me they have discovered that mail has not reached >> them because it was rejected by GMail. >> >> The rejection mail I have seen says GMail rejected the message because the >> IP address of my server did not pass >> DKIM or SPF for the source of the email. > >> Can I do that with Postfix 2.2? > > not with postfix itself. > I did SRS by using postsrs, see https://github.com/roehling/postsrsd > > This way, even forwarding using ~user/.forward will get SRS'ed. > > However, any mail from foreign domains without DKIM may still get rejected. I run a similar mail server. I use SRS and it "works" - well sort of. Most of the mail gets eventually accepted although it is delayed many hours. The delay range is about 1.5 to 27 hours. I am pretty sure that much of the long delayed mail is actually spam. I created a log scanner to find the sources for the messages that are delayed to see if there is any conistency but there are no significant differences in the number of delayed mail baed on source IP. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Debugging options
Is there a debug setting that will show which tables are searched when an incoming email is received and delivered to a mailbox? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Blocked Sender
I have a specific email sender that is getting the error "Sender addresses rejected: Domain not found". Sure enough DNS provides no response for that domain. If I drop off the first part of the domain name, then DNS returns a response. However, the organization is using the complete name which means the emails are dropped. I know the proper solution is to have the originator fix their DNS, but that is not going to happen in the near term. I have tried various ways for a temporary fix, but none have worked so far. I don't want to remove the "reject_unknown_sender_domain" function as it gets used properly a lot. Is there some way I can get postfix to accept these for local delivery? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Blocked Sender
> On Mar 26, 2023, at 14:27, Viktor Dukhovni via Postfix-users
> wrote:
>
> On Sun, Mar 26, 2023 at 02:15:27PM -0700, Doug Hardie via Postfix-users wrote:
>
>> Thanks Viktor. I went with the first approach and am getting errors:
>>
>> warning: inline:{DigitalInsight.firefightersfirstcreditunion.org =
>> permit_auth_destination} is unavailable. missing '=' after attribute name:
>> "inline:{DigitalInsight.firefightersfirstcreditunion.org =
>> permit_auth_destination}"; need "inline:{name=value...}
>>
>> and others like:
>>
>> warning: inline:{DigitalInsight.firefightersfirstcreditunion.org =
>> permit_auth_destination} lookup error for "file...@crytech.il"
>>
>> I think that message is saying the : after inline should be an =. I'll give
>> that a try.
>
> No, the syntax should instead be:
>
>inline:{{digitalinsight.firefightersfirstcreditunion.org =
> permit_auth_destination}}
> or
>
> inline:{digitalinsight.firefightersfirstcreditunion.org=permit_auth_destination}
>
> Per the documentation:
>
>http://www.postfix.org/DATABASE_README.html
>
>"inline:{ key=value, { key = text with whitespace or comma }}
I found the = didn't work. So I tried the example in the access(5) man page.
That doesn't give any errors, but the domain is still rejected.
Here is the master.cf extract for smtpd:
smtpd pass - - n - 50 smtpd
-o smtpd_recipient_restrictions=$incoming_smtpd_restrictions
Here is the main.cf extract:
incoming_smtpd_restrictions =
check_policy_service inet:127.0.0.1:10040,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
check_sender_access hash:/usr/local/etc/postfix/access
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
check_recipient_access hash:/usr/local/etc/postfix/tempfail,
reject_unauth_destination,
reject_unlisted_recipient
reject_rbl_client bl.spamcop.net,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client zen.spamhaus.org,
permit
the contents of access:
# Firefighters CU has missing DNS
156.55.193.213 OK
-- Doug
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Blocked Sender
> On Mar 26, 2023, at 13:28, Viktor Dukhovni via Postfix-users
> wrote:
>
> On Sun, Mar 26, 2023 at 12:52:01PM -0700, Doug Hardie via Postfix-users wrote:
>
>> I don't want to remove the "reject_unknown_sender_domain" function as
>> it gets used properly a lot. Is there some way I can get postfix to
>> accept these for local delivery?
>
>smtpd_sender_restrictions =
>check_sender_access inline:{bogus.example.org =
> permit_auth_destination},
>reject_unknown_sender_domain
>
> Alternatively, if you prefer RE tables:
>
>main.cf:
>smtpd_mumble_restrictions =
>... prior restrictions ...
>check_sender_access pcre:${config_directory}/sender-access.pcre
>... later restrictions ...
>
>sender-access.pcre:
># Single "node.example.org" domain
>/@node\.example\.org$/ DUNNO
># The "tree.example.org" domain or any subdomain
>/(?:@|\.)tree\.example\.org$/ DUNNO
># ... more exceptions here ...
># Everyone else'd better be valid
>/^/ reject_unknown_sender_domain
>
> This has the advantage that the verdict for "bogus.example.com" is not
> final, later restrictions in the same restriction list are still
> evaluated. The downside is that most users are sloppy with regular
> expressions, when using regular expressions you are quite likely to make
> mistakes. For example,
Thanks Viktor. I went with the first approach and am getting errors:
warning: inline:{DigitalInsight.firefightersfirstcreditunion.org =
permit_auth_destination} is unavailable. missing '=' after attribute name:
"inline:{DigitalInsight.firefightersfirstcreditunion.org =
permit_auth_destination}"; need "inline:{name=value...}
and others like:
warning: inline:{DigitalInsight.firefightersfirstcreditunion.org =
permit_auth_destination} lookup error for "file...@crytech.il"
I think that message is saying the : after inline should be an =. I'll give
that a try.
-- Doug
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Blocked Sender
-- Doug
> On Mar 26, 2023, at 15:04, Viktor Dukhovni via Postfix-users
> wrote:
>
> On Sun, Mar 26, 2023 at 02:53:42PM -0700, Doug Hardie wrote:
>
>>> inline:{{digitalinsight.firefightersfirstcreditunion.org =
>>> permit_auth_destination}}
>>> or
>>>
>>> inline:{digitalinsight.firefightersfirstcreditunion.org=permit_auth_destination}
>>>
>>> Per the documentation:
>>>
>>> http://www.postfix.org/DATABASE_README.html
>>>
>>> "inline:{ key=value, { key = text with whitespace or comma }}
>>
>>
>> I found the = didn't work.
>
> This is sadly without any configuration or error message details. So not
> actionable. The suggested inline:{{key = value}} replacement will work
> if implemented correctly.
Mar 26 15:42:30 mail postfix/smtpd[15243]: NOQUEUE: reject: RCPT from
mx4.messageprovider.com[156.55.193.213]: 450 4.1.8
: Sender address
rejected: Domain not found;
from=
to= proto=ESMTP helo=
mail# postconf -n
alias_maps = hash:/usr/local/etc/postfix/aliases
bounce_queue_lifetime = 1d
command_directory = /usr/local/sbin
compatibility_level = 3.7
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 1
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
default_privs = mailnull
dovecot_destination_recipient_limit = 1
enable_long_queue_ids = yes
header_checks = pcre:/usr/local/etc/postfix/header_checks.pcre
home_mailbox = Maildir/
html_directory = /usr/local/share/doc/postfix
incoming_smtpd_restrictions = check_policy_service inet:127.0.0.1:10040,
reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient,
check_sender_access hash:/usr/local/etc/postfix/access
reject_unknown_sender_domain, reject_unknown_recipient_domain,
reject_unauth_pipelining, permit_mynetworks, check_recipient_access
hash:/usr/local/etc/postfix/tempfail, reject_unauth_destination,
reject_unlisted_recipient reject_rbl_client bl.spamcop.net, reject_rbl_client
b.barracudacentral.org, reject_rbl_client zen.spamhaus.org, permit
inet_protocols = ipv4
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mail_spool_directory = /var/spool/mail
mailbox_size_limit = 0
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
max_use = 5
message_size_limit = 102400
mydestination = localhost.$mydomain, localhost
mydomain = sermon-archive.info
mynetworks = 10.0.1.0/24, 127.0.0.0/8
mynetworks_style = host
newaliases_path = /usr/local/bin/newaliases
postscreen_access_list = permit_mynetworks,
cidr:/usr/local/etc/postfix/access.cidr
postscreen_greet_action = enforce
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
recipient_canonical_classes = envelope_recipient,header_recipient
recipient_canonical_maps = tcp:localhost:10002
relocated_maps = hash:/usr/local/etc/postfix/relocated
sample_directory = /usr/local/etc/postfix
sender_canonical_classes = envelope_sender
sender_canonical_maps = tcp:localhost:10001
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtp_destination_concurrency_limit = 2
smtp_destination_recipient_limit = 25
smtp_generic_maps = hash:/usr/local/etc/postfix/generic
smtpd_authorized_xclient_hosts = 10.0.1.0/24
smtpd_client_auth_rate_limit = 10
smtpd_client_connection_rate_limit = 10
smtpd_command_filter = pcre:/usr/local/etc/postfix/quote
smtpd_error_sleep_time = 10
smtpd_hard_error_limit = 10
smtpd_milters = unix:/var/run/clamav/clmilter.sock
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_soft_error_limit = 1
smtpd_tls_cert_file = /etc/ssl/certs/mail.pem
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/usr/local/etc/postfix/vmail_aliases,
hash:/usr/local/etc/postfix/vcsc_aliases,
hash:/usr/local/etc/postfix/lafn_aliases, hash:/usr/local/mailman/data/aliases
virtual_gid_maps = static:
virtual_mailbox_base = /var/mail/
virtual_mailbox_domains = hash:/usr/local/etc/postfix/vmail_domains
virtual_mailbox_limit = 102400
virtual_mailbox_maps = hash:/usr/local/etc/postfix/vmail_mailbox
virtual_minimum_uid =
virtual_transport = dovecot
virtual_uid_maps = static:
>
># Best to rename to "incoimg_recipient_restrictions", here, and in
> master.cf.
Good suggestion.
>incoming_smtpd_restrictions =
>check_policy_service inet:127.0.0.1:10040,
>reject_invalid_hostname,
>reject_non_fqdn_sender,
>reject_non_fqdn_recipient,
>check_sender_access inline:{
>{digitalinsight.firefightersfirstcreditunion.org =
> permit_auth_destination}
>},
>reject_unknown_sender_domain,
>reject_unknown_recipient_domain,
>reject_unauth_pipelining,
>permit_mynetworks,
>
[pfx] Re: Debugging options
> On Mar 19, 2023, at 18:26, Viktor Dukhovni via Postfix-users > wrote: > > On Sun, Mar 19, 2023 at 03:48:07PM -0700, Doug Hardie via Postfix-users wrote: > >> Is there a debug setting that will show which tables are searched when >> an incoming email is received and delivered to a mailbox? > > The best answer to that is the documentation: > >http://www.postfix.org/ADDRESS_REWRITING_README.html > > You could run Postfix in verbose mode, but learning how the various > tables are used from verbose logging is challenging. Thanks Viktor. I tried the debug approach before posting. That's why I made the request. The web page requires a lot of parsing too though. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Reply To header
I have an app that sends SMTP to post fix to deliver an email. The first line it sends after the DATA command is a Reply To line. However, that causes postfix to terminate the headers and puts the Reply To line after the blank line at the end of theheaders. As a result, none of the following header lines are in the header and only show up in the text. Is this normal, or have I done something wrong? If I leave out the Reply To line, then everything works fine. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Reply To header
> On Apr 29, 2023, at 00:06, Roger Klorese via Postfix-users > wrote: > > Reply-To, not Reply To. > What a bone-head mistake. Thanks. Now it works just fine. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Reply To header
> On Apr 28, 2023, at 23:13, Noel Jones via Postfix-users > wrote: > > > >> On Apr 29, 2023, at 12:43 AM, Doug Hardie via Postfix-users >> wrote: >> >> I have an app that sends SMTP to post fix to deliver an email. The first >> line it sends after the DATA command is a Reply To line. However, that >> causes postfix to terminate the headers and puts the Reply To line after the >> blank line at the end of theheaders. As a result, none of the following >> header lines are in the header and only show up in the text. Is this >> normal, or have I done something wrong? >> > > Sounds like your app is inserting a blank line where it shouldn’t. A tcp > capture will show what’s actually being sent. > That's what I thought also. I checked and can't find one Here is the tcpdump output from the DATA through the Reply to line which is the first line sent after the DATA. 23:42:59.591170 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 58, bad cksum 0 (->3cbc)!) localhost.24534 > localhost.smtp: Flags [P.], cksum 0xfe2e (incorrect -> 0x49b2), seq 69:75, ack 103, win 1277, options [nop,nop,TS val 2735927841 ecr 2347198655], length 6: SMTP, length: 6 DATA 0x: 4500 003a 4000 4006 7f00 0001 E..:..@.@... 0x0010: 7f00 0001 5fd6 0019 1d84 3332 0c8e 3d62 _.32..=b 0x0020: 8018 04fd fe2e 0101 080a a312 f221 ...! 0x0030: 8be7 68bf 4441 5441 0d0a ..h.DATA.. 23:42:59.591781 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 89, bad cksum 0 (->3c9d)!) localhost.smtp > localhost.24534: Flags [P.], cksum 0xfe4d (incorrect -> 0xbe3b), seq 103:140, ack 75, win 1277, options [nop,nop,TS val 2347198656 ecr 2735927841], length 37: SMTP, length: 37 354 End data with . 0x: 4500 0059 4000 4006 7f00 0001 E..Y..@.@... 0x0010: 7f00 0001 0019 5fd6 0c8e 3d62 1d84 3338 .._...=b..38 0x0020: 8018 04fd fe4d 0101 080a 8be7 68c0 .Mh. 0x0030: a312 f221 3335 3420 456e 6420 6461 7461 ...!354.End.data 0x0040: 2077 6974 6820 3c43 523e 3c4c 463e 2e3c .with..< 0x0050: 4352 3e3c 4c46 3e0d 0a CR>.. 23:42:59.592129 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 94, bad cksum 0 (->3c98)!) localhost.24534 > localhost.smtp: Flags [P.], cksum 0xfe52 (incorrect -> 0x1809), seq 75:117, ack 140, win 1277, options [nop,nop,TS val 2735927842 ecr 2347198656], length 42: SMTP, length: 42 Reply To: t...@vintagecorvettessocal.com 0x: 4500 005e 4000 4006 7f00 0001 E..^..@.@... 0x0010: 7f00 0001 5fd6 0019 1d84 3338 0c8e 3d87 _.38..=. 0x0020: 8018 04fd fe52 0101 080a a312 f222 .R." 0x0030: 8be7 68c0 5265 706c 7920 546f 3a20 7465 ..h.Reply.To:.te 0x0040: 7374 4076 696e 7461 6765 636f 7276 6574 st@vintagecorvet 0x0050: 7465 7373 6f63 616c 2e63 6f6d 0d0a tessocal.com.. There is nothing between the DATA and Reply to except for the CRLF at the end of the DATA. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Blocked Sender
> On Mar 26, 2023, at 16:23, Viktor Dukhovni via Postfix-users
> wrote:
>
>> ...
>
> Well, this does not have the "inline:{{...}}" guard.
>
>>> incoming_smtpd_restrictions =
>>> check_policy_service inet:127.0.0.1:10040,
>>> reject_invalid_hostname,
>>> reject_non_fqdn_sender,
>>> reject_non_fqdn_recipient,
>>> check_sender_access inline:{
>>> {digitalinsight.firefightersfirstcreditunion.org =
>>> permit_auth_destination}
>>> },
>>> reject_unknown_sender_domain,
>
>>
>
> You can now either whitelist the client IP, or the exclude the domain
> name from tests of DNS existence. Use whatever you think is most
> manageable (I'd go with exempting the name).
I decided to go with exempting the name as shown above. It works. However, I
have been studying the recommended:
http://www.postfix.org/ADDRESS_REWRITING_README.html
I am beginning to understand how the tables are used now. I made a list in the
order shown in that page and came to the initial conclusion that all I needed
was the virtual aliasing tables. I don't need any of the canonical,
masquerading, or bcc functions. That should be all I need to get a received
email into the queue properly. To test this, I started up ktrace on the master
process and all it's siblings, and then sent in an email. Grabbing the NAMI
entries from the output, removing the non-postfix entries and the duplicates
yields a small list:
18128 postscreen NAMI "/var/db/postfix"
18128 postscreen NAMI "/var/db/postfix/postscreen_cache.db"
18129 smtpdNAMI "/usr/local/etc/postfix/aliases.db"
18129 smtpdNAMI "/usr/local/etc/postfix/vmail_aliases.db"
18129 smtpdNAMI "/usr/local/etc/postfix/vcsc_aliases.db"
18129 smtpdNAMI "/usr/local/etc/postfix/lafn_aliases.db"
18129 smtpdNAMI "/usr/local/mailman/data/aliases.db"
18129 smtpdNAMI "/usr/local/etc/postfix/vmail_mailbox.db"
18129 smtpdNAMI "/usr/local/etc/postfix/tempfail.db"
18131 trivial-rewrite NAMI "/usr/local/etc/postfix/vmail_aliases.db"
18131 trivial-rewrite NAMI "/usr/local/etc/postfix/vcsc_aliases.db"
18131 trivial-rewrite NAMI "/usr/local/etc/postfix/lafn_aliases.db"
18131 trivial-rewrite NAMI "/usr/local/mailman/data/aliases.db"
18131 trivial-rewrite NAMI "/usr/local/etc/postfix/vmail_domains.db"
18131 trivial-rewrite NAMI "/usr/local/etc/postfix/relocated.db"
18132 cleanup NAMI "/usr/local/etc/postfix/vmail_aliases.db"
18132 cleanup NAMI "/usr/local/etc/postfix/vcsc_aliases.db"
18132 cleanup NAMI "/usr/local/etc/postfix/lafn_aliases.db"
18132 cleanup NAMI "/usr/local/mailman/data/aliases.db"
18133 localNAMI "/usr/local/etc/postfix/aliases.db"
18133 localNAMI "/usr/local/etc/postfix/aliases.db"
The first thing I noticed is that smtpd accesses some of the tables. That I
didn't expect based on the README. I don't think it is using those tables to
rewrite addresses, but it is not obvious why it accesses them. The aliases,
vmail_aliases, lafn_alises,and mailman/data/aliases are all in the
virtual_address_maps. I have them split into multiple files to make
maintenance easier. smtpd accesses the vmail_mailbox table
(virtual_mailbox_maps) also. It would appear that is required, but I don't see
why. trivial-rewrite appears to be what I expected. I don't use relocated
entries at this time, but I can see why it would use them. The rest of the
entries seem obvious.
-- Doug
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Headers and Forwarding
> On Apr 8, 2023, at 11:59, Viktor Dukhovni via Postfix-users > wrote: > > On Sat, Apr 08, 2023 at 11:51:06AM -0700, Doug Hardie via Postfix-users wrote: > >> A couple of questions. Looking in the postfix generated Received: >> header, the SMTP id often has a few other letters included: ESMTPA >> etc. I am guessing that the extra letters mean: >> >> E - EHLO used rather the HELO >> S - SSL was used in the connection >> A - the originator was authenticated >> >> Are there any others and how close am I? > > > https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-7 Wow, I never would have guessed there would be that many. Thanks. > >> When the alias file pipes an email to a program, does it expect any >> response from that program, > > Only a 0 exit status code, in which case the program should not generate > any output. > >> or would it do anything with a response? > > If an error occurs some of the output might be included in the bounce. Now that sounds like a useful feature. I'll have to try it out. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Headers and Forwarding
> On Apr 8, 2023, at 13:15, Viktor Dukhovni via Postfix-users > wrote: > > On Sat, Apr 08, 2023 at 12:16:30PM -0700, Doug Hardie via Postfix-users wrote: > >>>> Are there any others and how close am I? >>> >>> >>> https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-7 >> >> Wow, I never would have guessed there would be that many. Thanks. > > For SMTP (as opposed to LMTP), you were only off by a factor of ~2, > there's a second "base" value of "UTF8SMTP". The full set for SMTP is: > >SMTP Simple Mail Transfer Protocol [RFC5321] >ESMTP SMTP with Service Extensions [RFC5321] >ESMTPA ESMTP with AUTH [RFC3848] >ESMTPS ESMTP with STARTTLS [RFC3848] >ESMTPSA ESMTP with both STARTTLS and AUTH [RFC3848] >UTF8SMTP ESMTP with SMTPUTF8 [RFC6531] >UTF8SMTPA ESMTP with SMTPUTF8 and AUTH [RFC4954][RFC6531] >UTF8SMTPS ESMTP with SMTPUTF8 and STARTTLS [RFC3207][RFC6531] >UTF8SMTPSA ESMTP with SMTPUTF8 and both STARTTLS and AUTH > [RFC3207][RFC4954][RFC6531] > > These are correctly used in Postfix and a few other MTAs, and then > there's Microsoft, where even the basic atom syntax is violated: > >with Microsoft SMTP Server > > or MessageLabs: > >with AES128-GCM-SHA256 encrypted SMTP > > c.f. > >https://www.rfc-editor.org/rfc/rfc5321#section-4.4 > > Protocol = "ESMTP" / "SMTP" / Attdl-Protocol > Attdl-Protocol = Atom > ; Additional standard names for protocols are > ; registered with the Internet Assigned Numbers > ; Authority (IANA) in the "mail parameters" > ; registry [9]. SMTP servers SHOULD NOT > ; use unregistered names. > > other violations are less severe: > >with HTTP >with mapi >with bizsmtp >with ngmta Thanks for that info. I don't think that will affect me as the first Received header in the message (last in time) will always be from postfix . I only need postfix's queue id so I can trace what happened if required. >... > > Apparently, reading RFC5321 and RFC5322 is too tedious. Reading is not tedious. You can't force everyone to use your software if you follow the standards. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Headers and Forwarding
A couple of questions. Looking in the postfix generated Received: header, the SMTP id often has a few other letters included: ESMTPA etc. I am guessing that the extra letters mean: E - EHLO used rather the HELO S - SSL was used in the connection A - the originator was authenticated Are there any others and how close am I? When the alias file pipes an email to a program, does it expect any response from that program, or would it do anything with a response? Thanks, -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Behaviour change between 3.2.2 and 3.7.4?
> On May 2, 2023, at 16:14, kwoody--- via Postfix-users > wrote: > >>> Log for the nightly cron job run: >>> >>> 03:01:09 mail sendmail[10703]: 342A19Wv010703: from=root, >> size=14672, >>> class=0, nrcpts=1, >>> msgid=<202305021001.342a19wv010...@mail.citytel.net>, >>> relay=root@localhost >> >> This is sent by Sendmail(TM), not Postfix. You need to run whatever system >> utility FreeBSD uses to switch the default mailer. Note the mail already > is >> addressed to @mail.citytel.net, so that's happening before postfix ever > sees >> the mail. > > I caught that too and was unsure of why it was showing sendmail there or if > it was relevant. But it is so will go down that path. > > Always just do a pkg install of postfix on new systems, but in this case it > didn't > replace sendmail like I thought it did. > > Thanks. The FreeBSD handbook has a section that shows how to replace sendmail with postfix, Section 30.4 Changes are needed to /etc/rc.conf and /etc/mail/mailer.conf -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: ARC or DKIM or SRS?
> On Feb 8, 2024, at 01:56, Matus UHLAR - fantomas via Postfix-users > wrote: > > On 07.02.24 21:51, Christophe Kalt via Postfix-users wrote: >> +1 on setting up SRS, it helps with Gmail and I believe ARC does too >> (although I don't have hard data on this). Interesting note about postgrey, >> I didn't think that was effective any longer but maybe it is. > > I have removed postgrey from servers I manage a few years ago. > - without good exemption lists, you'll run into hours long waiting for email > from various mail services that attempt multiple times from multiple IP > addresses, e.g. microsoft or google. > > I implemented postscreen instead that has similar functionality but is a bit > more safe to use. I implemented postscreen quite a while ago. I don't see where or how it introduces a delay to force the originating MTA to queue and try later. That seems to be what is benefiting me. So far, there have not been any complaints of desired mail not being delivered. There were only 6 defers yesterday. Normally there are a couple hundred. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Understanding log entries
I used Viktor's collate to trace a specific email handling. There were a number of these entries. However, I am only showing 2 of them: Feb 10 03:15:40 mail postfix/smtp[60428]: 4TWjVT5qz7z2gF8w: to=, orig_to=, relay=mx01.t-online.de[194.25.134.72]:25, delay=59371, delays=59369/0.02/1.5/0, dsn=4.0.0, status=deferred (host mx01.t-online.de[194.25.134.72] refused to talk to me: 554 IP=47.181.130.121 - None/bad reputation. Ask your postmaster for help or to contact t...@rx.t-online.de for reset. (NOWL)) Feb 10 03:20:21 mail postfix/smtp[60525]: 4TWjVT5qz7z2gF8w: to=, orig_to=, relay=mx03.t-online.de[194.25.134.73]:25, delay=59652, delays=59651/0/1.4/0, dsn=4.0.0, status=deferred (host mx03.t-online.de[194.25.134.73] refused to talk to me: 554 IP=47.181.130.121 - None/bad reputation. Ask your postmaster for help or to contact t...@rx.t-online.de for reset. (NOWL)) I am a bit confused as it appears that the receiving MTA is returning a 554 and a 4.0.0 which appears inconsistent. Obviously postfix is using the temp failure as it continues to retry periodically. From the text, it appears that this should be a permanent failure, not temporary. Is the receiving MTA confused or am I? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Understanding log entries
> On Feb 10, 2024, at 15:55, Wietse Venema via Postfix-users > wrote: > > Doug Hardie via Postfix-users: >> I used Viktor's collate to trace a specific email handling. There were a >> number of these entries. However, I am only showing 2 of them: >> > > This is host mx01.t-online.de[194.25.134.72]: > >> Feb 10 03:15:40 mail postfix/smtp[60428]: 4TWjVT5qz7z2gF8w: >> to=, >> orig_to=, >> relay=mx01.t-online.de[194.25.134.72]:25, delay=59371, >> delays=59369/0.02/1.5/0, dsn=4.0.0, status=deferred (host >> mx01.t-online.de[194.25.134.72] refused to talk to me: 554 >> IP=47.181.130.121 - None/bad reputation. Ask your postmaster for >> help or to contact t...@rx.t-online.de for reset. (NOWL)) > > With "smtp_skip_5xx_greeting = yes" (the default) Postfix > will skip to an alternate MX address. > > And this is mx03.t-online.de[194.25.134.73]: > >> Feb 10 03:20:21 mail postfix/smtp[60525]: 4TWjVT5qz7z2gF8w: >> to=, >> orig_to=, >> relay=mx03.t-online.de[194.25.134.73]:25, delay=59652, >> delays=59651/0/1.4/0, dsn=4.0.0, status=deferred (host >> mx03.t-online.de[194.25.134.73] refused to talk to me: 554 >> IP=47.181.130.121 - None/bad reputation. Ask your postmaster for >> help or to contact t...@rx.t-online.de for reset. (NOWL)) >> >> I am a bit confused as it appears that the receiving MTA is returning >> a 554 and a 4.0.0 which appears inconsistent. Obviously postfix >> is using the temp failure as it continues to retry periodically. >> From the text, it appears that this should be a permanent failure, >> not temporary. Is the receiving MTA confused or am I? > > You can configure this to be permanent. But, as you see, even > different MTAs of the same provider differ in their responses. If I am understanding correctly, that means that if I set smtp_skip_5xx_greeting to "no", then postfix would stop after the first 5xx and terminate the email. That seems like it might open up some issues where a provider with multiple MTAs might have one in problem state, but the others working fine. If postfix tried the problem MTA first, the email would never get delivered. Is there a way to configure postfix to drop the email if all the providers MTAs return a 5xx response? -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: ARC or DKIM or SRS?
> On Feb 7, 2024, at 17:23, Alex via Postfix-users > wrote: > > Hi, > > I'm hoping I could ask for some advice. We have a pretty large percentage of > users who forward mail through our systems to personal Gmail accounts. > Sometimes it is mail from bulk senders like mailgun and lanyon/cvent. > > Would ARC help here, or is DKIM enough for DMARC alignment with forwarded > messages? Perhaps ARC will help in those cases where DKIM fails with > forwarded messages? Is it used on the sending server or on the relay? Is it > installed using a milter alongside openSPF/DKIM using openarc? > https://github.com/trusteddomainproject/OpenARC/issues/139 > > I've also thought about implementing SRS over the years, but it has its own > problems, so I wondered if people were still implementing that? > > This has become particularly important with the recent news about Google > requiring senders (or forwarders, in my case) to do more to ensure delivery. > https://support.google.com/a/answer/81126?visit_id=638429520681370280-1110640002=1#zippy=%2Crequirements-for-all-senders I won't claim to be an expert on this, but I have the same situation except I am forwarding mail to dozens of different MTAs. GMail is the most popular destination. I ran into numerous problems with forwarding to Google until I implemented SRS. postsrsd works fine. However, even after that, I still had long delays in forwarding mail. Recently I added postgrey into the mix. I didn't expect it to do much. Back in the early 2000s, it eliminated about 90% of received mail and really helped the spam problem. However, as storage space became cheaper and larger, its effectiveness went way down. Five years ago or so, I no longer saw and improvement from greylisting and removed it. I just added it back a few days ago, and the number of delayed emails dropped to almost zero. mailq shows only 2 emails waiting. That is very unusual as usually it was around 100. I have never tried ARC, DKIM, or DMARC. I suppose that somewhere down the road I will need to start down those paths. -- Doug___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Logging received from address
I am using postfix with postsrsd. Is there a way for postfix to log the from address as originally received? The only addresses I find in postfix's log are the converted addresses from postsrsd. Both addresses are logged by postsrsd, but there is no way to tie it back to the postfix logs for that email. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] postsrsd
I just upgraded FreeBSD from 13.2 to 14.0. Postfix just picked up and ran fine. However postsrsd is causing me a few issues. I get the impression that postsrsd got updated, but I can't tell for sure. At the moment, the version is 2.0.8. The config files (conf and conf.sample) all had dates of 14 Nov so I suspect they were replaced. I don't know what the original files contained anymore. main.conf included: sender_canonical_maps = tcp:localhost:10001 sender_canonical_classes = envelope_sender recipient_canonical_maps = tcp:localhost:10002 recipient_canonical_classes= envelope_recipient,header_recipient I got errors that postfix couldn't connect to 10001. There was nothing listening to either port. I changed postsrsd.conf: chroot-dir = "" That got rid of the port errors. But now postfix gave an error about the tcp mapping. I changed main.conf to: sender_canonical_maps = socketmap:unix:srs:forward sender_canonical_classes = envelope_sender recipient_canonical_maps = socketmap:unix:srs:reverse recipient_canonical_classes = envelope_recipient, header_recipient and now postifx logs: Dec 6 00:02:44 test postfix/cleanup[2365]: warning: socketmap:unix:srs:forward lookup error for "wa6...@arrl.net". Postfix returns: 451 4.3.0 Error: queue file write error. Turning debug on in postsrsd.conf does not generate any additional information. I believe something is not configured properly for postsrd, but have not been able to locate the problem. I added my local domain to domains, and mail to those addresses get delivered locally. So it appears that postfix is talking to postsrsd properly. It's just not working for non-local addresses. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postsrsd
Not that I can find > On Dec 6, 2023, at 02:49, Jaroslaw Rafa via Postfix-users > wrote: > > Dnia 6.12.2023 o godz. 01:00:21 Doug Hardie via Postfix-users pisze: >> The config files (conf and conf.sample) all had dates >> of 14 Nov so I suspect they were replaced. I don't know what the original >> files contained anymore. > > Does the upgrade save the previous config files anywhere as backups? It > should. > -- > Regards, > Jaroslaw Rafa > r...@rafa.eu.org > -- > "In a million years, when kids go to school, they're gonna know: once there > was a Hushpuppy, and she lived with her daddy in the Bathtub." > ___ > 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: postsrsd
> On Dec 6, 2023, at 23:48, patpro--- via Postfix-users > wrote: > > December 6, 2023 10:00 AM, "Doug Hardie via Postfix-users" > wrote: > >> I just upgraded FreeBSD from 13.2 to 14.0. Postfix just picked up and ran >> fine. However postsrsd is >> causing me a few issues. I get the impression that postsrsd got updated, but >> I can't tell for sure. > > FreeBSD does not work like this. Ah, but it does if you follow all the instructions. > > postsrsd is not part of the «base system» so it’s not upgraded automatically > when you upgrade from FreeBSD 13.2 to 14.0. It’s standard procedure, though, > to reinstall every ports/pkg after a system upgrade but that particular step > is explicit and up to you. All of that is correct and that is exactly what I did. The instructions said to do that and I did. I'ts part of the upgrade process even though it's a separate step. > > You might find in your /var/log/messages the log of `pkg` actions. Indeed: postsrsd upgraded: 1.10 -> 2.0.8_1,1 That explains why there were issues. It was a major revision. > > Any way, a pkg upgrade SHOULD NOT replace your config file. > And you SHOULD use ZFS snapshots (install zfsnap, setup periodic.conf.local > and forget about it) AND backups. I can't say if there was a config file before or not. But both config and config.sample have exactly the same dates as reported by stat (1). They were also identical. Diff showed no differences. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postsrsd
> On Dec 7, 2023, at 00:27, patpro--- via Postfix-users > wrote: > > December 7, 2023 9:12 AM, "Doug Hardie via Postfix-users" > wrote: > >> Indeed: postsrsd upgraded: 1.10 -> 2.0.8_1,1 > > OK. I’m still running 1.10 : it does not use a config file. Configuration is > only in /etc/rc.conf. > It’s normal that config files for 2.0.8 are new and not tunned. That is useful information. Thanks. I'll have to read the Upgrading document again. There were 70 some ports upgraded and I missed this change. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postsrsd
No backups for that file that I can find. Although there probably are on one of the other systems. Have to check. There is over 400 GB of space available on the disk. Now for the interesting part. At 1 am this morning, postsrsd was not working so i removed it from main.cf. At noon today, I reenabled it again on the test system and it just worked. I then enabled it on the production system and it worked. All I did was to enable syslog logging, add a couple local domains, and disabled chroot. None of those should have changed anything, but it did - or it just needed more time to think about what it should be doing ;-) -- Doug > On Dec 6, 2023, at 09:07, Bill Cole via Postfix-users > wrote: > > On 2023-12-06 at 04:00:21 UTC-0500 (Wed, 6 Dec 2023 01:00:21 -0800) > Doug Hardie via Postfix-users > is rumored to have said: > >> I just upgraded FreeBSD from 13.2 to 14.0. Postfix just picked up and ran >> fine. However postsrsd is causing me a few issues. I get the impression >> that postsrsd got updated, but I can't tell for sure. At the moment, the >> version is 2.0.8. The config files (conf and conf.sample) all had dates of >> 14 Nov so I suspect they were replaced. I don't know what the original files >> contained anymore. > > And you have no backups? > > This is actually my most common reason for needing backups: when I've whacked > a config file and need to get back to a last working config. It's not exactly > common, but it is more frequent than catastrophic disk death... > >> main.conf included: >> >> sender_canonical_maps = tcp:localhost:10001 >> sender_canonical_classes = envelope_sender >> recipient_canonical_maps = tcp:localhost:10002 >> recipient_canonical_classes= envelope_recipient,header_recipient >> >> I got errors that postfix couldn't connect to 10001. There was nothing >> listening to either port. >> >> I changed postsrsd.conf: >> >> chroot-dir = "" >> >> That got rid of the port errors. But now postfix gave an error about the >> tcp mapping. >> >> >> I changed main.conf to: >> >> sender_canonical_maps = socketmap:unix:srs:forward >> sender_canonical_classes = envelope_sender >> recipient_canonical_maps = socketmap:unix:srs:reverse >> recipient_canonical_classes = envelope_recipient, header_recipient >> >> and now postifx logs: Dec 6 00:02:44 test postfix/cleanup[2365]: warning: >> socketmap:unix:srs:forward lookup error for "wa6...@arrl.net". Postfix >> returns: 451 4.3.0 Error: queue file write error. > > I have no positive suggestions of a solution but that error does not seem > like something a socketmap error should be able to generate from the service > side, as opposed to Postfix itself. How is your disk space doing? > > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire > ___ > 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] 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] Re: Mail text wrapping
> On Apr 22, 2024, at 23:31, Matus UHLAR - fantomas via Postfix-users > wrote: > > On 22.04.24 22:55, Doug Hardie via Postfix-users wrote: >> 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? > > this is quoted-printable MIME formatting which wraps lines to <80 characters > per line and uses = at the end of line as continuation character. > > see RFC 2045 section 6.7 for its definnition > > > I also recommend to look at the "format=flowed" option which is nicer > approach. > > RFC 3676 addresses this. > That was an amazing and helpful response. RFC 2045 showed exactly what caused the problem. When the message was delivered to a file, the CRLFs were replaced by \n. An = followed by a \n is not a valid soft return. I am going to have to parse the text and fix that. Thanks, -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Mail text wrapping
> On Apr 23, 2024, at 12:08, Viktor Dukhovni via Postfix-users > wrote: > > On Tue, Apr 23, 2024 at 11:46:22AM -0700, Doug Hardie via Postfix-users wrote: > >>> RFC 3676 addresses this. >> >> That was an amazing and helpful response. RFC 2045 showed exactly >> what caused the problem. When the message was delivered to a file, >> the CRLFs were replaced by \n. An = followed by a \n is not a valid >> soft return. I am going to have to parse the text and fix that. > > In a quoted-printable MIME body that is stored in a UNIX mailbox file, > "=" *is* a soft line break. Your MIME parser should treat it as > such, accepting not only "=", but also "=". > I must be interpreting this wrong because it appears postfix is not accepting that. Here is the complete process. A message arrives at my MTA addressed to a specific address. Postfix delivers that message to a pipe to my process which reads the pipe and stores everything in a file. Portions of the text of that message are extracted and then sent using SMTP to port 25 on my MTA with new recipients. The > Content-Type: text/plain; > charset=us-ascii > Content-Transfer-Encoding: quoted-printable > are forwarded exactly as received. The resulting message is delivered to multiple recipients including me. There I see the =LF in the message text. If I edit the file before it is sent and replace the =LF with 2 spaces, then it works properly. I'm confident the issue is not in postfix. However, I can't find where it is. -- Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Fun with line endings, was Re: Mail text wrapping
-- Doug > On Apr 24, 2024, at 09:05, John Levine via Postfix-users > wrote: > > It appears that Viktor Dukhovni via Postfix-users > said: >> On Wed, Apr 24, 2024 at 01:01:46AM -, John Levine via Postfix-users >> wrote: >> I must be interpreting this wrong because it appears postfix is not accepting that. Here is the complete process. A message arrives at my MTA addressed to a specific address. Postfix delivers that message to a pipe to my process which reads the pipe and stores everything in a file. Portions of the text of that message are extracted and then sent using SMTP to port 25 on my MTA with new recipients. ... >>> >>> Oh, there's your problem. If you are talking directly to an SMTP >>> server, you have to use SMTP line endings \r\n rather than the \n used >>> in files on Unix systems. >> >> Maybe, but perhaps this is too literal a reading of the OP's anecdotal >> description of the message handling. One might equally expect that the >> problem is with some parser of the message content not expecting to decode >> quoted-printable MIME bodies. > > I suppose, but sending bare LF in SMTP is definitely wrong, so he needs to > fix that first. > Well, the header lines are properly terminated by CRLF. However, the text lines are whatever I get from postfix. Generally that is just a LF. I copied the text and inserted the CRs and sent it to see what happens. I get the same result: = signs at each fold point. The solution was to replace all the =LFs with a couple spaces. Postfix/receiving MUA wraps the text of long lines properly (e.g., without and =). There was one other = occurance that I found a replaced with spaces. This solution was easy to accomplish since the text of the message is accessed via mmap. I expected to see some extraneous spaces in the message, but something is optimizing them out. — Doug ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
