[pfx] Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
When sending a mail with a folded message-id header according to [ https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.2%29 | https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.2 ] and [ https://www.postfix.org/postconf.5.html#enable_threaded_bounces | https://www.postfix.org/postconf.5.html#enable_threaded_bounces ] is enabled, then the message-id is ignored with the log message: "ignoring malformed Message-ID". It seems that the issue is located in the bounce_notify_util.c "Extract Message-ID for threaded bounces" else if block. Especially it seems that the if (*cp == '<' && vstring_end(bounce_info->buf)[-1] == '>') can never be true if provided a folded header. Further it seems that the smtp smuggling fixes that replace the \r \n with spaces did not change anything on that behavior. This means that message-ids that are exceeding the 78 lines + crlf and are therefore folded (as in [ https://datatracker.ietf.org/doc/html/rfc5322#section-2.2.3 | https://datatracker.ietf.org/doc/html/rfc5322#section-2.2.3 ] ) will not generate any In-Reply-To Header in DSNs. Is this a bug or is this an intended behavior to only allow single-line message-ids? Kind regards, Thomas. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
Thomas M?rbauer via Postfix-users: > When sending a mail with a folded message-id header according to [ > https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.2%29 | > https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.2 ] and > [ https://www.postfix.org/postconf.5.html#enable_threaded_bounces | > https://www.postfix.org/postconf.5.html#enable_threaded_bounces ] is enabled, > then the message-id is ignored with the log message: > "ignoring malformed Message-ID". > > It seems that the issue is located in the bounce_notify_util.c "Extract > Message-ID for threaded bounces" else if block. > Especially it seems that the if (*cp == '<' && > vstring_end(bounce_info->buf)[-1] == '>') can never be true if provided a > folded header. > > Further it seems that the smtp smuggling fixes that replace the \r \n with > spaces did not change anything on that behavior. > This means that message-ids that are exceeding the 78 lines + crlf and are > therefore folded (as in [ > https://datatracker.ietf.org/doc/html/rfc5322#section-2.2.3 | > https://datatracker.ietf.org/doc/html/rfc5322#section-2.2.3 ] ) > will not generate any In-Reply-To Header in DSNs. > Is this a bug or is this an intended behavior to only allow single-line > message-ids? Which folding whitespace space in "Message-ID: " did you have in mind? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
For example Message-ID: would not be written into the In-Reply-To. So a simple crlf with space. Thomas - Original Message - From: "Wietse Venema via Postfix-users" To: "Postfix users" Sent: Thursday, 5 September, 2024 14:12:32 Subject: [pfx] Re: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used Thomas M?rbauer via Postfix-users: > When sending a mail with a folded message-id header according to [ > https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.2%29 | > https://datatracker.ietf.org/doc/html/rfc5322#section-3.2.2 ] and > [ https://www.postfix.org/postconf.5.html#enable_threaded_bounces | > https://www.postfix.org/postconf.5.html#enable_threaded_bounces ] is enabled, > then the message-id is ignored with the log message: > "ignoring malformed Message-ID". > > It seems that the issue is located in the bounce_notify_util.c "Extract > Message-ID for threaded bounces" else if block. > Especially it seems that the if (*cp == '<' && > vstring_end(bounce_info->buf)[-1] == '>') can never be true if provided a > folded header. > > Further it seems that the smtp smuggling fixes that replace the \r \n with > spaces did not change anything on that behavior. > This means that message-ids that are exceeding the 78 lines + crlf and are > therefore folded (as in [ > https://datatracker.ietf.org/doc/html/rfc5322#section-2.2.3 | > https://datatracker.ietf.org/doc/html/rfc5322#section-2.2.3 ] ) > will not generate any In-Reply-To Header in DSNs. > Is this a bug or is this an intended behavior to only allow single-line > message-ids? Which folding whitespace space in "Message-ID: " did you have in mind? Wietse ___ 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: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
On Thu, Sep 05, 2024 at 01:56:51PM +0200, Thomas Mörbauer via Postfix-users wrote: > When sending a mail with a folded message-id header ... then the > message-id is ignored with the log message: "ignoring malformed > Message-ID". There really SHOULD NOT be any folding whitespace in the middle of a Message-ID. https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.4 I hope you're not basing your argument on the obsolete forms. message-id = "Message-ID:" msg-id CRLF in-reply-to = "In-Reply-To:" 1*msg-id CRLF references = "References:" 1*msg-id CRLF msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] id-left = dot-atom-text / obs-id-left id-right= dot-atom-text / no-fold-literal / obs-id-right no-fold-literal = "[" *dtext "]" > Further it seems that the smtp smuggling fixes that replace the \r \n > with spaces did not change anything on that behavior. This has nothing to do with bare CR or bare LF handling. > This means that message-ids that are exceeding the 78 lines + crlf and > are therefore folded [...] There is no hard requirement to fold at 78 characters, the limit is 998 bytes. And Message-Id SHOULD not be folded, even if over 78 bytes long. I think it is fine for Postfix to treat folded Message-IDs as malformed. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
On Thu, Sep 05, 2024 at 02:21:13PM +0200, Thomas Mörbauer via Postfix-users wrote: > For example > Message-ID: > > would not be written into the In-Reply-To. > So a simple crlf with space. That's rather different than what you appeared to say. Here there's folding whitespace *before* (not in the middle of) the Message-ID. This should ideally be accepted as well-formed, but this requires the code that extracts the message-id to be willing to "unfold" such headers, which isn't currently the case. Perhaps a special case could be made for folds immediately after the header label, because no actual unfolding is required, just need to remember to treat the next line as the entire header payload... There are no clear cut rules on what to do with folding in the middle of the Message-ID payload, and it has long been obsolete, so just tolerating whitespace after the header label should be sufficient. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
>That's rather different than what you appeared to say. Here there's >folding whitespace *before* (not in the middle of) the Message-ID. Sorry, could have been more clear about that. The folding can only occur after the header label according to the non obsolete RFCs. >There are no clear cut rules on what to do with folding in the >middle of the Message-ID payload, and it has long been obsolete, >so just tolerating whitespace after the header label should >be sufficient. I agree on that. Is there any fix for this special case in sight or would you accept patches if provided? Thomas. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Rejecting by top level domain?
Howdy, all!
I am using Postfix for a small business/family e-mail domain. It's
pretty low volume, and I am really doing it as much to keep current on
Postfix as anything. We're getting positively hammered by spam. I used
to use Spamassassin when I was a Sendmail guy, but I have not had time
to set it up for Postfix. It's definitely on my list, just... life.
For spam abatement, I am using Spamhaus, and it's helping a lot, but
we're still getting a ton of spam.
So I have set up a rule:
check_sender_access regexp:/etc/postfix/sender_access
The sender_access file rejects everything from the "*.onmicrosoft.com"
domain, as we've never received a single non-spam email from those domains.
I've also started rejecting everything from all emails from these domains:
.pro
.date
.science
.top
.download
.work
.click
.link
.diet
.review
.party
.zip
.xyz
.stream
.bid
.shop
.best
.world
It has TREMENDOUSLY lowered our spam load, but, naturally, I'm worried
about the rare case where someone actually needs to receive email from
someone dumb enough to use one of those domains.
Here is my main.cf, with some basic obfuscations:
compatibility_level = 2
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
inet_interfaces = all
inet_protocols = ipv4
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix/samples
readme_directory = /usr/share/doc/postfix/README_FILES
smtpd_tls_cert_file = /etc/letsencrypt/live/mydomain/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mydomain/privkey.pem
smtpd_tls_security_level = may
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_security_level = may
meta_directory = /etc/postfix
shlib_directory = /usr/lib64/postfix
myhostname = [obfuscated].camerontech.com
mydomain = camerontech.com
myorigin = $mydomain
mynetworks = 127.0.0.0/8, [obfuscated]/19
home_mailbox = Maildir/
smtpd_banner = $myhostname ESMTP
disable_vrfy_command = yes
smtpd_helo_required = yes
message_size_limit = 20971520
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
rbl_reply_maps = hash:$config_directory/dnsbl-reply-map
smtpd_recipient_restrictions =
check_sender_access regexp:/etc/postfix/sender_access
permit_mynetworks
permit_auth_destination
permit_sasl_authenticated
reject_rbl_client [obfuscated].zen.dq.spamhaus.net=127.0.0.[2..11]
reject_rhsbl_sender [obfuscated].dbl.dq.spamhaus.net=127.0.1.[2..99]
reject_rhsbl_helo [obfuscated].dbl.dq.spamhaus.net=127.0.1.[2..99]
reject_rhsbl_reverse_client
[obfuscated].dbl.dq.spamhaus.net=127.0.1.[2..99]
reject_rhsbl_sender [obfuscated].zrd.dq.spamhaus.net=127.0.2.[2..24]
reject_rhsbl_helo [obfuscated].zrd.dq.spamhaus.net=127.0.2.[2..24]
reject_rhsbl_reverse_client
[obfuscated].zrd.dq.spamhaus.net=127.0.2.[2..24]
reject
smtpd_client_restrictions = permit_mynetworks,
reject_unknown_client_hostname, permit
smtpd_sender_restrictions = permit_mynetworks,
reject_unknown_sender_domain, reject_non_fqdn_sender
smtpd_helo_restrictions = permit_mynetworks, reject_unknown_hostname,
reject_non_fqdn_hostname, reject_invalid_hostname, permit
mynetworks_style = host
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
virtual_alias_domains = [obfuscated list]
virtual_alias_maps = hash:/etc/postfix/virtual
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept
So my overarching question is, am I being dense by rejecting these
spammy domains? My sender_access file looks like this:
/@*.onmicrosoft\.com/ REJECT
/\.pro$/ REJECT We reject all .pro domains. Contact thomas dot cameron
at camerontech dot com from a trusted email service if you need assistance.
/\.date$/ REJECT We reject all .date domains. Contact thomas dot cameron
at camerontech dot com from a trusted email service if you need assistance.
/\.science$/ REJECT We reject all .science domains. Contact thomas dot
cameron at camerontech dot com from a trusted email service if you need
assistance.
/\.top$/ REJECT We reject all .top domains. Contact thomas dot cameron
at camerontech dot com from a trusted email service if you need assistance.
/\.download$/ REJECT We reject all .download domains.
[pfx] Re: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
Thomas M?rbauer via Postfix-users: > >That's rather different than what you appeared to say. Here there's > >folding whitespace *before* (not in the middle of) the Message-ID. > Sorry, could have been more clear about that. The folding can only > occur after the header label according to the non obsolete RFCs. > > >There are no clear cut rules on what to do with folding in the > >middle of the Message-ID payload, and it has long been obsolete, > >so just tolerating whitespace after the header label should > >be sufficient. > I agree on that. > > Is there any fix for this special case in sight or would you accept > patches if provided? You're welcome to try. There is no promise it will be adopted. Folding a Message-ID: header after the ":" will keep the line length under 78, only if the message ID *value* is shorter than 78. Folding will merely make the problem happen 12 bytes later. If you're thinking about writing a patch to extract multiline header info in bounce_notify_util.c, then that patch must not accumulate more content than $header_size_limit (messages that are still in the maildrop queue can have headers that exceed this limit). A more "technically correct" fix is to update the cleanup server, which already inspects multiline header values and stores findings based on header/body content, as named attribute records in the "extracted" queue file segment. Examples of such extracted information are content type, content encoding, header/body FILTER action, REDIRECT action, etc. An extracted message-id record could go there. The code in bounce_notify_util.c already anticipates on the possibility of records in the extracted segment. More correct does not mean that it would make sense. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
On 2024-09-05 12:27, Viktor Dukhovni via Postfix-users wrote: There is no hard requirement to fold at 78 characters, the limit is 998 bytes. And Message-Id SHOULD not be folded, even if over 78 bytes long. I think it is fine for Postfix to treat folded Message-IDs as malformed. Interesting. I can see the following from certain microsoft noreply mail ids breaking line > 998 bytes with SPACE What is this? It doesn’t happen with outlook personal mails. Chandan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix ignores message id when threaded bounces are enabled if RFC-5322 header folding is used
chandan via Postfix-users: > On 2024-09-05 12:27, Viktor Dukhovni via Postfix-users wrote: > > > > There is no hard requirement to fold at 78 characters, the limit is 998 > > bytes. And Message-Id SHOULD not be folded, even if over 78 bytes > > long. > > > > I think it is fine for Postfix to treat folded Message-IDs as > > malformed. > > Interesting. I can see the following from certain microsoft noreply mail > ids > > breaking line > 998 bytes with SPACE > > What is this? https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.3.1.6 Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Rejecting by top level domain?
2024-09-05T14:07:05Z Thomas Cameron via Postfix-users : > Am I smoking crack? Or is this pretty reasonable? Or should I just knuckle > down and set up Spamassassin or some other anti-spam tool (I'm totally open > to suggestions, I just have experience with SA from a past life) No, you are not. First of all, Spamassasin (and other antispam solutions, as well as paid services) have similar TLD blacklists or slam scoring metrics. Also, given that you are willing to manually whitelist legitimate senders, you should be fine to go. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
On 9/5/24 10:20 AM, Serhii via Postfix-users wrote: 2024-09-05T14:07:05Z Thomas Cameron via Postfix-users : Am I smoking crack? Or is this pretty reasonable? Or should I just knuckle down and set up Spamassassin or some other anti-spam tool (I'm totally open to suggestions, I just have experience with SA from a past life) No, you are not. First of all, Spamassasin (and other antispam solutions, as well as paid services) have similar TLD blacklists or slam scoring metrics. Also, given that you are willing to manually whitelist legitimate senders, you should be fine to go. Thanks so much for the confirmation, Serhii! I figured it was the least evil way of doing this, thanks for letting me know I'm not being a *total* moron (just *mostly* a moron). :-) -- Thanks! Thomas Cameron, RHCE, AWS SA-Pro ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
Hi > My sender_access file looks like this: > /@*.onmicrosoft\.com/ REJECT > /\.pro$/ REJECT We reject all .pro domains. Contact thomas dot cameron at > camerontech dot com from a trusted email service if you need assistance. You could do that without regular expressions. Depending on your parent_domain_matches_subdomains, you need to list ".pro" or "pro" as key. Bastian -- There's coffee in that nebula! -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud" ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
On 9/5/2024 9:05 AM, Thomas Cameron via Postfix-users wrote: smtpd_recipient_restrictions = check_sender_access regexp:/etc/postfix/sender_access permit_mynetworks permit_auth_destination Note permit_auth_destination allows any mail addressed to you. This effectively bypasses all your nice rbl rules below. permit_sasl_authenticated reject_rbl_client [obfuscated].zen.dq.spamhaus.net=127.0.0.[2..11] ... reject_rhsbl_reverse_client [obfuscated].zrd.dq.spamhaus.net=127.0.2.[2..24] reject This final reject on smtpd_recipient_restrictions is unneeded. I guess that's why you put the permit_auth_destination above. Just remove both of those. This is not an exhaustive review of your restrictions, just something that jumped out at me. So my overarching question is, am I being dense by rejecting these spammy domains? My sender_access file looks like this: It's totally reasonable to reject whole TLDs that you don't expect to get legit mail from. Same with check_client_access and whole network blocks. Especially if you're prepared to make exceptions. -- Noel Jones ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
On 9/5/2024 12:45 PM, Noel Jones via Postfix-users wrote: On 9/5/2024 9:05 AM, Thomas Cameron via Postfix-users wrote: smtpd_recipient_restrictions = check_sender_access regexp:/etc/postfix/sender_access permit_mynetworks permit_auth_destination Note permit_auth_destination allows any mail addressed to you. This effectively bypasses all your nice rbl rules below. permit_sasl_authenticated You should probably put reject_unauth_destination here. reject_rbl_client [obfuscated].zen.dq.spamhaus.net=127.0.0. [2..11] ... reject_rhsbl_reverse_client [obfuscated].zrd.dq.spamhaus.net=127.0.2.[2..24] reject This final reject on smtpd_recipient_restrictions is unneeded. I guess that's why you put the permit_auth_destination above. Just remove both of those. This is not an exhaustive review of your restrictions, just something that jumped out at me. So my overarching question is, am I being dense by rejecting these spammy domains? My sender_access file looks like this: It's totally reasonable to reject whole TLDs that you don't expect to get legit mail from. Same with check_client_access and whole network blocks. Especially if you're prepared to make exceptions. -- Noel Jones ___ 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: Rejecting by top level domain?
On 9/5/24 12:19 PM, Bastian Blank via Postfix-users wrote: Hi My sender_access file looks like this: /@*.onmicrosoft\.com/ REJECT /\.pro$/ REJECT We reject all .pro domains. Contact thomas dot cameron at camerontech dot com from a trusted email service if you need assistance. You could do that without regular expressions. Depending on your parent_domain_matches_subdomains, you need to list ".pro" or "pro" as key. Absolutely fair point, but I like the $ to make it *exactly* the domain I want to block. -- Thanks! Thomas Cameron, RHCE, AWS SA-Pro ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
On 2024-09-05 at 11:20:52 UTC-0400 (Thu, 5 Sep 2024 15:20:52 + (UTC)) Serhii via Postfix-users is rumored to have said: 2024-09-05T14:07:05Z Thomas Cameron via Postfix-users : Am I smoking crack? Or is this pretty reasonable? Or should I just knuckle down and set up Spamassassin or some other anti-spam tool (I'm totally open to suggestions, I just have experience with SA from a past life) No, you are not. First of all, Spamassasin (and other antispam solutions, as well as paid services) have similar TLD blacklists or slam scoring metrics. Also, given that you are willing to manually whitelist legitimate senders, you should be fine to go. [Puts on ASF SpamAssassin Contributor hat] There is a complex mechanism for this in SpamAssassin which (using the default rules & scores) is NOT an outright ban on any TLD in any particular role in a message but which has a significant positive (spam) score. It is possible for any site using SA to remove any of the affected TLDs from the list or to specifically add domains or addresses to a local welcomelist. We act on bug reports that a listed TLD merits removal by testing to confirm substantial non-spam hitting our contributor mailstreams. I don't believe we list any country code TLDs on principle. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social 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
[pfx] Re: Rejecting by top level domain?
2024-09-05T20:37:33Z Bill Cole via Postfix-users : > [Puts on ASF SpamAssassin Contributor hat] > > There is a complex mechanism for this in SpamAssassin which (using the > default rules & scores) is NOT an outright ban on any TLD in any particular > role in a message but which has a significant positive (spam) score. It is > possible for any site using SA to remove any of the affected TLDs from the > list or to specifically add domains or addresses to a local welcomelist. We > act on bug reports that a listed TLD merits removal by testing to confirm > substantial non-spam hitting our contributor mailstreams. I don't believe we > list any country code TLDs on principle. I didn't meant outright ban by SA specifically, but I've had .xyz domain and I got too much pain trying to prove that it is legitimate to the diversity of ESPs/spam filters and just moved to .ch ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
Bill Cole via Postfix-users skrev den 2024-09-05 22:35: [Puts on ASF SpamAssassin Contributor hat] not yet for sale :) There is a complex mechanism for this in SpamAssassin which (using the default rules & scores) is NOT an outright ban on any TLD in any particular role in a message but which has a significant positive (spam) score. relaycountry plugin It is possible for any site using SA to remove any of the affected TLDs from the list or to specifically add domains or addresses to a local welcomelist. without dependign on dkim/spf/dmarc also possibel with wlbl plugin, with enlist data We act on bug reports that a listed TLD merits removal by testing to confirm substantial non-spam hitting our contributor mailstreams. good as it is, but i think spamassassin basicly have a problem, it contains data from to few contributeres, to be effitive spammers must not know scores to rule there spam under this scores, also why i do not just revael my own local rules :) I don't believe we list any country code TLDs on principle. unless ralaycontry counts as so, but this data is impossible to delist, so fine ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
On 9/5/24 16:35, Bill Cole via Postfix-users wrote: We act on bug reports that a listed TLD merits removal by testing to confirm substantial non-spam hitting our contributor mailstreams. I don't believe we list any country code TLDs on principle. There are a few ccTLDs that I block completely (looks like four), all of them problematic ccTLDs from which I have only ever seen clearly malicious mail. I *do* however block a list of about thirty or so junk "new" TLDs that were consistent spam sources, but with occasional whitelisting of legitimate domains within even those. (For instance I currently block .shop *except for* wandering.shop, which is widely used by other writers.) -- Phil Stracchino Fenian House Publishing ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
On 9/5/24 12:53 PM, Noel Jones via Postfix-users wrote: On 9/5/2024 12:45 PM, Noel Jones via Postfix-users wrote: On 9/5/2024 9:05 AM, Thomas Cameron via Postfix-users wrote: smtpd_recipient_restrictions = check_sender_access regexp:/etc/postfix/sender_access permit_mynetworks permit_auth_destination Note permit_auth_destination allows any mail addressed to you. This effectively bypasses all your nice rbl rules below. permit_sasl_authenticated You should probably put reject_unauth_destination here. That makes sense. Thank you, Noel! -- Thanks! Thomas Cameron, RHCE, AWS SA-Pro ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
how about setup a whitelist domains list? for instance, only allow .com, .net, .org, .de, .ca and some coutries TLD to be passed through. Phil Stracchino via Postfix-users: There are a few ccTLDs that I block completely (looks like four), all of them problematic ccTLDs from which I have only ever seen clearly malicious mail. I *do* however block a list of about thirty or so junk "new" TLDs that were consistent spam sources, but with occasional whitelisting of legitimate domains within even those. (For instance I currently block .shop *except for* wandering.shop, which is widely used by other writers.) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Rejecting by top level domain?
On 9/5/24 5:56 PM, LinuxMail.cc via Postfix-users wrote: how about setup a whitelist domains list? for instance, only allow .com, .net, .org, .de, .ca and some coutries TLD to be passed through. That's not a bad idea. Unfortunately we DO get a decent amount of international email, so it's not practical for our use. But I like the idea a lot. -- Thanks! Thomas Cameron, RHCE, AWS SA-Pro ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
