[pfx] Re: Strengthen email system security
On 2024-05-23 at 20:12:09 UTC-0400 (Fri, 24 May 2024 12:12:09 +1200) Peter via Postfix-users is rumored to have said: On 24/05/24 01:42, Bill Cole via Postfix-users wrote: [...] It is also helpful as a matter of system design to decouple user email addresses from their login usernames. For example, all of the email addresses I give to companies are aliases, so none of them are at all useful if compromised in a breach. The username I use to authenticate to my mail server cannot be mailed from anywhere but the mail server itself. This assures that no matter how many systems get breached where I've got an account, none of those usernames and passwords are useful to the thieves. I set this up almost 30 years ago as a spam control measure, but the greatest benefit has been in basic account security. This is good advice for the email admin personally but increases the complexity for other users to a point where it's probably not worth it, imo. To elaborate aliases are great, but trying to reject email to the primary mailbox address, or trying to force users to pick a different username to their primary mailbox email address can be problematic. Right, it is difficult to retrofit a robust model with arcane aliasing kinks onto an existing userbase. It is much less hard to switch users from authenticating as cuten...@example.com to cuten...@mailauth.example.com even though they still get all their mail at the simpler, preferred address. The critical point is to make the session authentication identity for mail different from the mail delivery address, because they have definitely used that delivery address for authentication elsewhere. -- 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: Strengthen email system security
On 2024-05-23 at 02:31:05 UTC-0400 (Thu, 23 May 2024 08:31:05 +0200) Matus UHLAR - fantomas via Postfix-users is rumored to have said: Don't accept mail from home networks. For example, use "reject_dbl_client zen.spamhaus.org". For this you must use your own DNS resolver, not the DNSresolver from your ISP. On 23.05.24 07:00, Northwind via Postfix-users wrote: will this also stop the valid client's SMTP connection? thank you Wietse. not, unless they are listed in zen.spamhaus.org, which should not happen. Zen includes the "PBL" component, which consists largely of residential and mobile consumer IPs. -- 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: Strengthen email system security
On 2024-05-22 at 19:03:48 UTC-0400 (Thu, 23 May 2024 11:03:48 +1200) Peter via Postfix-users is rumored to have said: On 23/05/24 10:33, Northwind via Postfix-users wrote: [...] The attack continues at this time. My questions are: 1. what's the purpose of this kind of attack? Brute force password cracking, or DDoS? Likely brute force. Not exactly. "Brute force" password cracking is almost never seen today, as it has been replaced by a practice commonly called "credential stuffing" where the attacker has some large collection of known-good username+password combinations from another source (e.g. one of the many "breaches" of online systems) and is simply trying the same combinations on your system. This is a much more targeted attack and so can be slow enough to evade rate-limit based protections. This means that you need more prevention than was needed with classic brute force. An attacker may not be working from a list of random names and passwords or from common names and passwords, but from some smaller list of names and passwords specific to your domain and users, so the chances of a hit are based on whether your users use the same passwords everywhere. All the other suggestions are good, and I would add that in addition to using Geo-IP data for excluding by country or region, you can proactively exclude other large blocks at the packet level quite broadly. The Spamhaus DROP list of criminal-controlled ranges would be the first step, as you can rely on nothing you want coming from those ranges. Next, you can look at the IPs which are doing the authentication probes and find large blocks of cheap hosting from which none of your users will ever be logging in. For example, you can count on never seeing legitimate traffic on ports 465 or 587 (or any of the POP and IMAP ports) from AWS, GCP, Linode, Digital Ocean, OVH, Alibaba, or Azure network ranges. It is also helpful as a matter of system design to decouple user email addresses from their login usernames. For example, all of the email addresses I give to companies are aliases, so none of them are at all useful if compromised in a breach. The username I use to authenticate to my mail server cannot be mailed from anywhere but the mail server itself. This assures that no matter how many systems get breached where I've got an account, none of those usernames and passwords are useful to the thieves. I set this up almost 30 years ago as a spam control measure, but the greatest benefit has been in basic account security. -- 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: long header folding and DKIM fails
On 2024-05-02 at 07:53:15 UTC-0400 (Thu, 2 May 2024 12:53:15 +0100) Tim Coote via Postfix-users is rumored to have said: What would have helped - and I’ve no idea how feasible this is - would be some tooling to pull out different versions of the message as they flow through the queues. This can be done with a milter like MIMEDefang or MailMunge which let you do arbitrary things to messages at each step in the mail flow. I have used this to debug similar problems with signing and Sendmail's not-so-obvious mods to messages based on mailer flags. -- 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: reliable RBL
On 2024-04-11 at 05:10:45 UTC-0400 (Thu, 11 Apr 2024 11:10:45 +0200) Matus UHLAR - fantomas via Postfix-users is rumored to have said: >> Στις 11/4/24 10:59, ο/η Matus UHLAR - fantomas via Postfix-users έγραψε: >>> It still works, but you may need supplementary software as amavis, sagator, >>> spamass-milter or mimedefang because SpamAssassin only focuses on >>> classification, not about delivery. > > On 11.04.24 11:54, Dimitris via Postfix-users wrote: >> iirc, you also need a compiler installed (for SA rules). > > only if you want to compile them. They are written in perl and can be used > without compiler. ALSO: with a modern Perl, SA v4.0.1, and the current default rules with care taken to avoid runaways in local rules, the difference between running with precompiled vs. interpreted rules is minimal. There has been discussion in the SA community of deprecating sa-compile, although no concrete action has been taken to do so. -- 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
[pfx] Re: reliable RBL
On 2024-04-11 at 03:41:37 UTC-0400 (Thu, 11 Apr 2024 15:41:37 +0800) Mr. Peng via Postfix-users is rumored to have said: Thanks for all the help. BTW, is spamassassin still a popular option for antispam today? or should I use rspamd instead? SpamAssassin is still pretty popular and we just made a new bugfix release. I am biased as a member of the SpamAssassin PMC, but I think it is a very good choice for many sites and it has a large mature user base with a lot of support available. I have heard much good about rspamd from sources I trust, but I am not directly familiar with it. Were I to set up a new mail system today without legacy reliance on SA, I would probably try using rspamd just to learn about it. Regards. On Wed, Apr 10, 2024 at 10:23 PM Bill Cole via Postfix-users < postfix-users@postfix.org> wrote: On 2024-04-10 at 05:46:36 UTC-0400 (Wed, 10 Apr 2024 17:46:36 +0800) Mr. Peng via Postfix-users is rumored to have said: I have been using spamhaus, spamcop, sorbs as the RBL providers for antispam. But some of the customers speak to me about the FP issues caused by RBL. Do you think the three RBL above are reliable in a practical system? Those are three of the best, but you have to understand that they are complicated and may not fit YOUR needs. Spamhaus offers multiple DNSBLs which each has a vey specific definition, which they aggregate in the "Zen" list which uses reply value to indicate which component an address listing belongs to. Not all component lists of Zen are appropriate for all MTAs. Spamhaus is extremely careful about making each list reliably represent what they claim it represents. They act quickly on the rare occasions when they inadvertently list sources of legitimate email. SpamCop is based on actual feeds of spam from many sources, and when they list an IP, you can be certain that it recently sent spam. They do not exempt major mailbox providers who are also major spam emitters. If you use the SpamCop list as an absolute test, you will reject some legitimate mail which shares an outbound MTAQ with spam. Reliably. SORBS is also informed by multiple sources of spam, and like SpamCop they do not exempt mixed sources. Like Spamhaus, they have both independent DNSBLs and an aggregated list that uses distinct return values for each component list, so you need to take that into account when using it, to fit the different sorts of listings to different interfaces. Like SpamCop, some of the SORBS components intermittently list major mixed sources. You really need to look at your DNSBL choices carefully and with an understanding of your users and their needs. You may want to consider using them in a more complex filtering tool like SpamAssassin where it is possible to weight the impact of different DNSBLs to fit your needs and to make explicit direct exemptions if you like. -- 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 -- 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: reliable RBL
On 2024-04-10 at 05:46:36 UTC-0400 (Wed, 10 Apr 2024 17:46:36 +0800) Mr. Peng via Postfix-users is rumored to have said: > I have been using spamhaus, spamcop, sorbs as the RBL providers for > antispam. > But some of the customers speak to me about the FP issues caused by RBL. > Do you think the three RBL above are reliable in a practical system? Those are three of the best, but you have to understand that they are complicated and may not fit YOUR needs. Spamhaus offers multiple DNSBLs which each has a vey specific definition, which they aggregate in the "Zen" list which uses reply value to indicate which component an address listing belongs to. Not all component lists of Zen are appropriate for all MTAs. Spamhaus is extremely careful about making each list reliably represent what they claim it represents. They act quickly on the rare occasions when they inadvertently list sources of legitimate email. SpamCop is based on actual feeds of spam from many sources, and when they list an IP, you can be certain that it recently sent spam. They do not exempt major mailbox providers who are also major spam emitters. If you use the SpamCop list as an absolute test, you will reject some legitimate mail which shares an outbound MTAQ with spam. Reliably. SORBS is also informed by multiple sources of spam, and like SpamCop they do not exempt mixed sources. Like Spamhaus, they have both independent DNSBLs and an aggregated list that uses distinct return values for each component list, so you need to take that into account when using it, to fit the different sorts of listings to different interfaces. Like SpamCop, some of the SORBS components intermittently list major mixed sources. You really need to look at your DNSBL choices carefully and with an understanding of your users and their needs. You may want to consider using them in a more complex filtering tool like SpamAssassin where it is possible to weight the impact of different DNSBLs to fit your needs and to make explicit direct exemptions if you like. -- 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
[pfx] Re: sender_login_maps and dovecot and roundcube
On 2024-03-28 at 17:38:38 UTC-0400 (Thu, 28 Mar 2024 17:38:38 -0400)
Alex via Postfix-users
is rumored to have said:
HI,
I've set up a domain with a catch-all to deliver emails to any address
to a
single recipient address by specifying it in my virtual_alias_maps.
However, the user wants to be able to send mail as any user in that
domain.
The problem is that it's rejected with "sender address rejected"
because
the user isn't defined in the smtpd_sender_login_maps.
That last sentence provides such a specific and clear problem
description that it virtually provides the solution: Add a suitable
entry to the sender_login_maps file. Run postmap on the file.
That entry probably should look like:
@example.com alex
Mar 28 15:55:01 cipher roundcube: SMTP Error: Failed to add
recipient 're...@gmail.com': 5.7.1 : Sender
address
rejected: not owned by user alex (Code: 553) in
/usr/share/roundcubemail/program/lib/Roundcube/rcube.php on line 1794
(POST
/webmail/?_task=mail&_unlock=loading1711655700954&_framed=1&_action=send)
# postconf smtpd_sasl_security_options smtpd_sender_login_maps
smtpd_sender_restrictions
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sender_login_maps = ${indexed}sender_login_maps
smtpd_sender_restrictions = check_sasl_access ${indexed}sasl-access
sasl-access is just:
alexenforce_login
I know this is something I've done with different identities in
Thunderbird
before, just by changing the From address, but dovecot apparently
requests
auth from submission?
I also thought of using the recipient_delimiter, so sending something
like
user1+a...@mydomain.com might work, but it's not what was asked for.
Maybe this is a dovecot config option I'm missing?
Thanks for any ideas on what I'm missing here.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
--
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
[pfx] Re: collect emails in maildir folder without delivering them to user
On 2024-03-19 at 02:10:53 UTC-0400 (Tue, 19 Mar 2024 07:10:53 +0100) Fourhundred Thecat via Postfix-users <400the...@ik.me> is rumored to have said: Hello, I am running postfix server for my personal use. On the server, I have one unix user, and multiple aliases defined in /etc/aliases, so that I can use different email addresses for different purposes. All these aliases are delivered to the users home / maildir. Now I would like to have yet another alias/email address, but instead of having the emails delivered to my main user, I would like to just collect the emails in some maildir. You are describing (one variety of) normal email delivery (to a second user) which is trivial. I just need to collect these emails for archival purposes, separately from my main account. I could create a new unix user, and have them delivered to his home / maildir, but that seems quite convoluted. How so??? That seems to me like the obvious simplest solution. If you need to access that mail directly on the host, you can make that work with well-planned user and group permissions and/or ACLs. If you do this and want to see that maildir as part of a particular IMAP account, that would be something you could implement via the IMAP server. Any other mechanism requires more new configuration than a real new user. Is there some straightforward way to collect emails from given alias/emaiul address directly to some maildir folder ? If you are phobic about adding another user you could use a virtual mailbox but that's more convoluted than just adding another real user of the same delivery class that you are already using. Another option is delivery-time filtering. You could use something like procmail (an antique tool that was recently re-animated) or a sieve filter in the delivery path to deliver mail to different folders within an IMAP account (e.g. in the same user's maildir tree) based on arbitrary conditions. This is what I do for mailing lists: my .procmailrc has match lines for each list I subscribe to, delivering each one to its own maildir in my account. -- 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
[pfx] Re: postfix not working with squarespace domains
On 2024-03-17 at 10:38:27 UTC-0400 (Sun, 17 Mar 2024 09:38:27 -0500) Paxton Houston via Postfix-users is rumored to have said: i'm trying to set up a mail server using postfix. i currently have a squarespace domain and are using mailutils to send the email. do i need to set up some kinda dns record? thanks bye You will need a hosting/connectivity provider who can allocate you an IPv4 address with no reputation problems, multiple DNS records depending on how robust your sending needs to be, a solid understanding of SMTP, a basic understanding of Unix/Linux system administration, a local caching fully recursive, DNSSEC-validating DNS resolver. You will need to learn about mail authentication using SPF, DKIM, and DMARC and deploy tools on your server to support them. There are people who will tell you in all sincerity, hoping to save you from yourself, that it isn't feasible for an individual without a deep technical background to stand up a new mail server just for their own small domain. They are not wrong. I know excellent mail admins who have given up self-hosting in the past few years because of the ever-growing difficulty of delivering mail normally to the behemoth mailbox providers and other frustrations. I will not tell you to give up but you should understand that it is far more difficult to do this today than it was a decade or two ago. Most people can be better served by a good experienced mail provider than by their own efforts. -- 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
[pfx] Re: Ignoring postscreen DNSBL disposition by recipient address
On 2024-03-17 at 05:55:43 UTC-0400 (Sun, 17 Mar 2024 10:55:43 +0100) Matus UHLAR - fantomas via Postfix-users is rumored to have said: On 15.03.24 15:06, Noel Jones via Postfix-users wrote: Postscreen by design only looks at the IP, and has no mechanism to consider other envelope data. The solution is to not use a DNSBL that routinely blocks wanted mail in postscreen. Or, set postscreen_dnsbl_threshold high enough so it does not rely on listing in single list. You could e.g. set up: postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[0..255] dnsbl.sorbs.net=127.0.0.[0..255] bl.spamcop.net=127.0.0.2 list.dnswl.org=127.0.[0..255].[0..255]*-1 list.dnswl.org=127.0.[0..255].3*-1 postscreen_dnsbl_threshold=2 maybe if you trust spamhaus enough, append *2 to it It is not about "trusting spamhaus" but rather understanding what Spamhaus intends the Zen aggregate to be. It is unsuitable for postscreen *by design* if you treat any last octet as a hit. The same problem exists for SORBS and SpamCop. The unwanted hit you might get out of some of the Zen subcomponents stand a real chance of being hit for the same reasons by the others. They are not entirely independent factors. Concretely: that combination is likely to cause you to block individual random behemoth mailbox provider outputs and chunks of VPS hosting space including non-spammers for hours to days at a time. That risk may acceptable for some sites, but it goes well beyond postscreen's explicit design intent. -- 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
[pfx] Re: Ignoring postscreen DNSBL disposition by recipient address
On 2024-03-15 at 14:11:03 UTC-0400 (Fri, 15 Mar 2024 13:11:03 -0500) Matt Saladna via Postfix-users is rumored to have said: Hello, I'm seeking a workaround for Microsoft's litany of IPs landing on DNSBL. They'd like all mail irrespective of DNSBL status to be delivered, which requires a skip if the sender IP is blacklisted in postscreen. With separation between postscreen and smtpd, postscreen rejects the connection before handing off to smtpd so smtpd_recipient_restrictions isn't triggered. Is there an appropriate workaround that allows postscreen to report DUNNO after DNSBL checks if the recipient matches in a table? No, which is because of how postscreen is designed, as a fit to its intended purpose. See the man page and supplementary README file for details. If you need to make recipient exceptions to postscreen, you are simply using it for the wrong function. It is a *lightweight* tool to dispose of pure spam sources without loading and using all the logic of the smtpd daemon. By default, postscreen is no longer in control by the time the greeting banner is sent. If you wish to do anything complicated with deciding whether to accept a message, you need to do it later in the SMTP transaction. -- 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
[pfx] Re: A functional lightweight reverse alias?
On 2024-03-02 at 04:45:53 UTC-0500 (Sat, 2 Mar 2024 10:45:53 +0100) Gerben Wierda via Postfix-users is rumored to have said: Aliases are nice, to receive mail. But when you reply, the address behind the alias is exposed. To prevent that I need to create full mailboxes, which requires a lot of administration in dovecot, postfix. Suppose - I am m...@mydomain.tld - At evilcompany.com they know be by my alias meatevilcomp...@mydomain.tld - I am mailing with marketingt...@evilcompany.com Is there a way to create a lightweight 'reverse alias' for a specific target. E.g., suppose my alias is meatevilcompany:me then have a mail from m...@mydomain.tld to marketingt...@evilcompany.com turn into a reply from meatevilcomp...@mydomain.tld to marketingt...@evilcompany.com, but only for marketingt...@evilcompany.com or for @evilcompany.com? There is a commonly-used header that supports MUAs handling this: X-Original-To Postfix will add that to mail it is delivering locally by default. It also adds a Delivered-To header with the final result of aliasing. Some MUAs (I think this included TBird but I have not used it regularly in many years) can be configured to recognize those and compose replies as being "From: " the X-Original-To address, using the Delivered-To to figure out what account the reply should use for determining outbound server & auth. This seems like it is much more suited to the MUA rather than a MTA/MSA. I don't think I want something on the server responsible for rewriting headers to keep their original content confidential when the user's MUA could have just written the proper public address there in the first place. I've been working with mailing lists this way for years on Eudora, Mulberry, TBird, and now MailMate. I reply to a message with an X-Original-To header and the MUA uses that address to compose and send the message. -- 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
[pfx] Re: postfix check_sender_access and subdomain test
_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99], reject_rbl_client psbl.surriel.com, reject_rbl_client bl.spamcop.net, reject_rhsbl_sender fresh.spameatingmonkey.net, reject_rhsbl_client fresh.spameatingmonkey.net, reject_rhsbl_sender uribl.spameatingmonkey.net, reject_rhsbl_client uribl.spameatingmonkey.net, reject_rbl_client sip-sip24.metbpp3hnheh.invaluement.com, check_policy_service unix:postgrey/socket, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $host1 smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile = /etc/postfix/certs/cacert.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/certs/postfix_public_cert.pem smtpd_tls_key_file = /etc/postfix/certs/postfix_private_key.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = no soft_bounce = no tls_random_source = dev:/dev/urandom transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_domains = hash:/etc/postfix/virtual_domains virtual_alias_maps = hash:/etc/postfix/virtual_users ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org -- 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
[pfx] Re: Postfix gmail relay SASL authentication failed invalid parameter supplied
On 2024-02-28 at 10:04:05 UTC-0500 (Wed, 28 Feb 2024 15:04:05 +) Nuno Catarino via Postfix-users is rumored to have said: > Hi there, i'm using leap 15.5, trying to send emails thru gmail relay and > getting crazy. > Send my configuration for someone to help me > when i'm trying to send the email the error is: > > postfix/pickup[30145]: CFC982C034E: uid=0 from= > postfix/cleanup[30149]: CFC982C034E: > message-id=<20240228100831.CFC982C034E@localhost> > postfix/qmgr[30144]: CFC982C034E: from=, size=428, nrcpt=1 > (queue active) > postfix/smtp[31278]: CFC982C034E: to=, > relay=smtp.gmail.com[64.233.167.109]:587, > delay=5.5, delays=0.05/0/5.4/0, dsn=4.7.0, status=deferred (SASL > authentication failed; cannot authenticate to server > smtp.gmail.com[64.233.167.109]: > invalid parameter supplied) > > *In the gmail account i have created a apps password* > > *In the file /etc/postfix/sasl_passwd* > [smtp.gmail.com]:587 nuno.catar...@.pt: The error indicates that the password and/or username were incorrect. I believe you need to remove any spaces in the GMail app password. -- 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
[pfx] Re: rbl bounces email that has both rbl_override and client_checks whitelisting
On 2024-02-27 at 16:39:54 UTC-0500 (Tue, 27 Feb 2024 13:39:54 -0800 (PST)) lists--- via Postfix-users is rumored to have said: I have a sender_checks file but I don't see that on the postfix.org website. Is that a deprecated parameter? The names of Postfix map files are up to you. Their usage is determined by the specific restriction directive referencing them. So you could have 'check_sender_access hash:/etc/postfix/any_name_you_like' and Postfix will use that file, as long as you populate it with access entries and 'postmap' it to create the .db file. -- 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
[pfx] Re: rbl override doesn't work perhaps due to sender using relay
On 2024-02-24 at 10:43:36 UTC-0500 (Sat, 24 Feb 2024 07:43:36 -0800 (PST)) lists--- via Postfix-users is rumored to have said: https://www.dnswl.org/?page_id=15 I get your point but this is for a different blocking list. That is spamcop and spamassassin have different blocking lists. What I really need is a way to make the rbl_override work for the domain name that has been related. You're using that file check_client_access, which only checks IPs and verified (PTR/A consistent) client hostnames. If you want to exempt based on the envelope sender address (generally lame, but sometime needed) you need to use check_sender_access. -- 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
[pfx] Re: postfix alternating between mail.example.com and real hostname?
On 2024-02-12 at 07:07:03 UTC-0500 (Mon, 12 Feb 2024 13:07:03 +0100) Joachim Lindenberg via Postfix-users is rumored to have said: I haven´t seen this before, but at present my mail server is kind of alternating between mail.example.com and the real hostname (or someone is spoofing my IP-address which I doubt). It is not at all clear what you actually mean by that. Any MTA has a potentially complicated collection of different "identities" used in different context. E.g. in Postfix you've got origin domain names, destination domain names, hostnames used in MX records, and a hostname used in HELO/EHLO greetings. Or is the 'alternating' happening in DNS? We cannot know... All configuration files I checked indicate the correct setting and postconf myhostname returns the correct name. Thus I am wondering whether this might be caused by a recent change of postfix, which happens tob e 3.5.23 – the mail server is a mailcow-dockerized instance which still uses images based on debian-bullseye. Any idea for the cause and a fix? My guess: Gremlins. You might get more useful answers by including the illuminating information described at https://www.postfix.org/DEBUG_README.html#mail in the section titled "Reporting problems to postfix-users@postfix.org" -- 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
[pfx] Re: Understanding log entries
On 2024-02-10 at 18:33:29 UTC-0500 (Sat, 10 Feb 2024 15:33:29 -0800) Doug Hardie via Postfix-users is rumored to have said: > 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 No, it is sending a 554 without an extended code instead of a connect greeting, which Postfix (reasonably) treats as a temporary failure in the scope of the specific message being tried. > 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? It's a quirk of Telekom. They reject with 554 at connect when they dislike your IP. In my experience, the email address in the rejection message is responsive. -- 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
[pfx] Re: ARC or DKIM or SRS?
On 2024-02-08 at 16:05:16 UTC-0500 (Thu, 8 Feb 2024 13:05:16 -0800) Doug Hardie via Postfix-users is rumored to have said: 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. If you enable the tests in postscreen(8) which are described in the "AFTER 220 GREETING TESTS" section of its man page, it must send a 4xx reply to passing clients and hope that they come back within the positive cache timeout. -- 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
[pfx] Re: Is there a way to reject an internal domain on our border MXes
On 2024-02-03 at 08:52:17 UTC-0500 (Sat, 3 Feb 2024 05:52:17 -0800) Dan Mahoney via Postfix-users is rumored to have said: > All, > > Pretty simple question: > > We have an internal domain, zimbra.example.org, but it's only used for > internal routing of our corporate mail (there's a master delivery map that > controls what addresses at example.org route to zimbra.example.org). We have > other domains under example.org such as list servers, ticket systems, and the > like, many of which have example.org addresses pointing at them. > > In no case should anything on the outside be directing mail directly to > zimbra.example.org, and it is firewalled so only our border MXes can talk to > it. > > Is there a way to reject mail destined to an internal domain (like > zimbra.example.org) such that only our internal machines can deliver to it, > but that any host on the outside gets an immediate reject notice from our > border MXes? There are ways to do almost anything... One way to implement this is to use restriction classes. I do this for some of my list-specific addresses that get scraped for spam, but it would work just as well for a domain e.g.: main.cf: smtpd_restriction_classes = privdom smtpd_recipient_restrictions = ...,check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,... privdom = check_client_access hash:/etc/postfix/privdom-allow, reject recipient_checks.pcre: [...] /^.*@zimbra.example.org$/ privdom [...] privdom-allow: .example.orgDUNNO 192.0.2 DUNNO Where 192.0.2.0/24 is your privileged network and you want to allow anyone on that network or any client with a verified hostname under example.org. -- 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
[pfx] Re: Problems with round-robin outbound emails
On 2024-01-31 at 10:12:06 UTC-0500 (Wed, 31 Jan 2024 16:12:06 +0100) Matus UHLAR - fantomas via Postfix-users is rumored to have said: On 30.01.24 20:20, Israel britto via Postfix-users wrote: hello, I'm having a problem with spamhaus that I don't know how to solve. Today I have 1 domain that uses 2 exclusive IPs 1.1.1.1 and 2.2.2.2 The PTR and rDNS entries are correctly configured: 1.1.1.1 > a1.domain.com 2.2.2.2 > a2.domain.com a1.domain.com -> 1.1.1.1 a2.domain.com -> 2.2.2.2 My Postfix is behind a load balance, which performs round-robin balancing between these 2 IPs, however, my server is configured with the helo -> xpto.com.br That's almost certainly wrong. The HELO argument should be the resolvable primary name associated with the actual client IP as it connects to the server. In this case, that would be the outward-facing IP of the load balancer. # host xpto.com.br xpto.com.br has address 186.202.157.79 xpto.com.br mail is handled by 20 mx.jk.locaweb.com.br. xpto.com.br mail is handled by 10 mx.core.locaweb.com.br. xpto.com.br mail is handled by 20 mx.a.locaweb.com.br. xpto.com.br mail is handled by 20 mx.b.locaweb.com.br. # host 186.202.157.79 Host 79.157.202.186.in-addr.arpa. not found: 3(NXDOMAIN) On 31.01.24 09:43, Bill Cole via Postfix-users wrote: So if your load balancer isn't at 186.202.157.79, the hosts behind it should not be announcing themselves as xpto.com.br. how did you get to this? xpto.com.br exists and has addres, so there's no reason why it could not be used in HELO. The purpose of HELO is identification of the client system to receiving systems. A HELO name that authoritatively resolves to an IP unrelated to the client IP is a confusion and confounding of that purpose. It should not be done. (I use 'should' here in the secular sense, not its tight RFC meaning) -- 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
[pfx] Re: Are multiple white spaces allowed in a date in headers?
On 2024-01-30 at 17:56:16 UTC-0500 (Tue, 30 Jan 2024 23:56:16 +0100) Jonas Vautherin via Postfix-users is rumored to have said: My understanding of a "folding white space" from (amongst others) RFC2822 [3] is that it implies a carriage return (CRLF), and it is *not* the same thing as a white space character: That is incorrect. Read the aBNF definitions more carefully. Specifically the items related to folding white space. More generally, parsing of dates in Unix-like environments should always be prepared for other programs using %e where %d would be more code-friendly. E.g. syslog-generated log files do that. -- 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
[pfx] Re: Problems with round-robin outbound emails
On 2024-01-31 at 03:32:20 UTC-0500 (Wed, 31 Jan 2024 09:32:20 +0100) Matus UHLAR - fantomas via Postfix-users is rumored to have said: On 30.01.24 20:20, Israel britto via Postfix-users wrote: hello, I'm having a problem with spamhaus that I don't know how to solve. Today I have 1 domain that uses 2 exclusive IPs 1.1.1.1 and 2.2.2.2 The PTR and rDNS entries are correctly configured: 1.1.1.1 > a1.domain.com 2.2.2.2 > a2.domain.com a1.domain.com -> 1.1.1.1 a2.domain.com -> 2.2.2.2 My Postfix is behind a load balance, which performs round-robin balancing between these 2 IPs, however, my server is configured with the helo -> xpto.com.br That's almost certainly wrong. The HELO argument should be the resolvable primary name associated with the actual client IP as it connects to the server. In this case, that would be the outward-facing IP of the load balancer. # host xpto.com.br xpto.com.br has address 186.202.157.79 xpto.com.br mail is handled by 20 mx.jk.locaweb.com.br. xpto.com.br mail is handled by 10 mx.core.locaweb.com.br. xpto.com.br mail is handled by 20 mx.a.locaweb.com.br. xpto.com.br mail is handled by 20 mx.b.locaweb.com.br. # host 186.202.157.79 Host 79.157.202.186.in-addr.arpa. not found: 3(NXDOMAIN) So if your load balancer isn't at 186.202.157.79, the hosts behind it should not be announcing themselves as xpto.com.br. If that is your load balancer, you should fix its reverse DNS (i.e. a PTR record at 79.157.202.186.in-addr.arpa.) Spamhaus is listing my IPs because it says that my HELO address is not aligned with the rDNS of my IPs. Has anyone had this type of problem and could help me with how to resolve it? I have never seen anyone having this problem, also I have never see spamhaus list IP address because of this. Neither have I, having used Spamhaus for their whole existence. However, I am fairly sure that some of the signals that feed XBL (former CBL) listings include signature HELO behaviors. It's not implausible that using a HELO which looks like an intentional impersonation effort will generate a XBL listing. I have no special knowledge of precisely how that could happen, but I do see pure spam sources playing fraudulent games with HELO. In fact, refusing mail because of HELO inconsistence is against all SMTP RFCs issued so far. That's a very narrow prohibition, technically only against simplistic requirement that HELO must use a name that resolves to the client IP with a matching PTR resolving the IP to the HELO name. It does not prohibit blocking mail because of a HELO name which is formally invalid (e.g. illegal name or authoritatively resolving otherwise) or a HELO name that identifies a known bad actor. Beyond that formal language issue, it is a simple fact that essentially all systems doing effective spam control 'violate' RFCs in some ways. Spam control is in conflict with the fundamental RFC purpose of maximal interoperability. However, if your HELO string is invalid or not existing, it's somehow common for some servers to refuse mail from you. Right. If you say "HELO ylmf-pc" or "EHLO USER" or various other signature introductions to arbitrary MXs, your mail will not be delivered in many places. Since you did not provide us with your real address nor the error message spamhaus provides when you check for your IPs, it's really hard to help you. Spamhaus doesn't control error messages... I assume that anyone obfuscating IPs when seeking support on issues directly related to specific IPs being blocklisted is trying to get their spambots working. There's absolutely no excuse for it in 99% of cases and it leads to random pointless speculation. -- 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
[pfx] Re: [postfix] 3.4.23: virtual, pipe and ${original_recipient} vs. ${recipient}
On 2024-01-25 at 11:58:56 UTC-0500 (Thu, 25 Jan 2024 11:58:56 -0500) Viktor Dukhovni via Postfix-users is rumored to have said: - Are you expected exactly one recipient per-invocation of the spamassassin filter? I'm not sure how spamc handles multiple recipients after "-u". It doesn't. The argument to '-u' is a key to identify a user-specific ruleset. The spamc too (and SA generally) has no mechanism to split envelopes or to provide multiple responses to a single submission. -- 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
[pfx] Re: Enabling TLS1.3 and allow sending over SMTPS/465
On 2024-01-22 at 14:16:31 UTC-0500 (Mon, 22 Jan 2024 16:16:31 -0300) Taco de Wolff via Postfix-users is rumored to have said: Regarding MTA-MTA connections, it seems I didn't fully understand it. I was surprised that port 25 (unencrypted) was used for all mail traffic, but surely (and hopefully) most connections upgrade with STARTTLS. This happens on port 25 though, unlike MUA-MTA connections which happen (regularly) on port 587 (and perhaps on port 25 as well?). I was under the impression that implicit TLS is (slightly) more secure since the TLS negotiation happens right at the start and not somewhere down along the connection. Implicit TLS has been assigned to port 465, which is the port that the original Netscape SSLv3 draft had proposed for 'smtps' analogous to https. That assignment did not survive to the TLSv1 specification which was derived from that draft. And yet, many MUAs adopted port 465 for implicit TLS before it failed to make it to an RFC. More recently, the fact that implicit TLS for the "submission" (MUA-MTA) protocol was de facto broadly deployed and slightly more secure led to RFC8314. The reason implicit TLS isn't useful for SMTP (MTA-MTA) use is that port 25 must always be backwards-compatible and so MUST start with a plaintext server greeting, NOT a TLS handshake. Establishing a new secure port would mean either every MTA trying to connect twice to sites that have yet to upgrade or we'd have to finally switch to SRV records for SMTPS, forcing every MTA to replace its whole DNS logic. Also, the info disclosure of MTA-MTA STARTTLS vs implicit TLS is less meaningful than it is for MUA-MTA, where it exposes end user info. -- 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
[pfx] Re: Enabling TLS1.3 and allow sending over SMTPS/465
On 2024-01-22 at 12:42:08 UTC-0500 (Mon, 22 Jan 2024 12:42:08 -0500) Viktor Dukhovni via Postfix-users is rumored to have said: On Mon, Jan 22, 2024 at 11:44:40AM -0300, Taco de Wolff via Postfix-users wrote: [...] Has this something to do with FIPS mode? I don't think so because the ciphers show up in OpenSSL. Why is TLS1.3 not getting enabled? Ask RedHat. With the caveat that I am absolutely NOT RedHat... Circa 2019 I ran into a similar problem: The RHEL OpenSSL 1.1.1-FIPS can't do TLS 1.3. I don't have any hard reference for that readily available but I have a vague recollection that the root cause was a remarkably stupid issue involving the formal certification. Also worth noting: OpenSSL 1.1.1 is obsolete and has no upstream support. -- 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
[pfx] Re: improper command pipelining
On 2024-01-15 at 04:15:53 UTC-0500 (Mon, 15 Jan 2024 10:15:53 +0100)
Admin Beckspaced via Postfix-users
is rumored to have said:
somoene is trying to use your postfix as http proxy server.
Looks like security scanner.
do you know the type of encoding?
The encoding for the log is octal: characters are either literal or in
\### format for unprintables.
I would like to decode and see the actual commands.
The underlying data looks (by eyeball) to probably be an attempted HTTPS
handshake. That's consistent with the test apparently being done for an
open proxy. Shodan and Censys are nominally legitimate operations that
scan the Internet for possibly vulnerable machines and sell access to
the resulting data. There are others who can be identified by the names
"stretchoid" and "binaryedge.ninja" who are less public about their
scans.
The IPs performing the scans can safely be blocked at the packet level,
if you're into such things. They will never do anything but test your
system.
Jan 14 01:57:15 cx20 postfix/submission/smtpd[25120]: improper
command pipelining after CONNECT from
battery.census.shodan.io[93.174.95.106]:
\026\003\003\001\244\001\000\001\240\003\003'>\232\037\250\226/zan\025\307\023\350_\373\253\021W\212\3262\246\223\3378\314/\312\200>\200
\343p5J\020\265q@\355\241\371b\377\236\375\227;\352\202wL\303\204\003\305O\255\273\2319\322\330\000\212\000\026\0003\000g\300\236\300\242\000\236\0009\000k\300\237\300\243\000\237
Jan 14 01:57:15 cx20 postfix/submission/smtpd[25120]: improper
command pipelining after CONNECT from
battery.census.shodan.io[93.174.95.106]:
\026\003\003\001\244\001\000\001\240\003\003pP\244\201Y\346\233\272\340=\365\222\201\333\ba\354\v1V
\356\277\200\370\023\264zR\360\243\307
\270T\336w\204\177\213\220D\317\234\210\220w\2446\b\302\206\376\202\365\317\312\340\353\177\016\370~\032\306\000\212\000\005\000\004\000\a\000\300\000\204\000\272\000A\000\235\300\241\300\235\000=
Jan 14 01:57:15 cx20 postfix/submission/smtpd[25120]: improper
command pipelining after CONNECT from
battery.census.shodan.io[93.174.95.106]:
\026\003\003\001U\001\000\001Q\003\003V\021\240\231\032m\243\224\002A\fL-\017n\315\f1g\037k\021\357\245\302EG\317\a\226
\331
\006^\005V[#\265\001\255t\246\340\364\357\020g\247F\301\317\203\253\201U[\324(\221\247\221R9\000F\300\022\300\a\314\024\023\001\023\002\314\251\300s\300r\300,\300\257\300\255
Jan 14 01:57:15 cx20 postfix/submission/smtpd[25122]: improper
command pipelining after CONNECT from
battery.census.shodan.io[93.174.95.106]:
\026\003\002\001\231\001\000\001\225\003\002\003\201\335\374\201\271\a\022!\224@\272z]\362\006\371\001\313\371\233(\245\ne\200\fm\370\270\335{
\366S\224\365\370\220\355\033\237\3706\033\347\237P\312\236\247\274\232a^_\361\227\257,\275\nu\276D\000\212\000\026\0003\000g\300\236\300\242\000\236\0009\000k\300\237\300\243\000\237
Jan 14 05:05:41 cx20 postfix/submission/smtpd[31071]: improper
command pipelining after CONNECT from
scanner-29.ch1.censys-scanner.com[167.248.133.186]:
\026\003\003\001\244\001\000\001\240\003\003\316@\257\332\b\000\n\337\205^\377\260D\331\344\364\222\250\030\215\234\220\032\341\352\313`\2470K+\306
\265~P\206\337O\364Q\310\236xi\277\017\266\244\020\205\006i\a\273\317\220\006]t0x\216\221\311\000\212\000\026\0003\000g\300\236\300\242\000\236\0009\000k\300\237\300\243\000\237
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
--
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
[pfx] Re: Incoming mail server blocks outlook / microsoft servers
On 2024-01-10 at 10:12:26 UTC-0500 (Wed, 10 Jan 2024 17:12:26 +0200) Nikolaos Milas via Postfix-users is rumored to have said: [...] and this causes legitimate mail to be discarded (actual mail addresses modified above). My question in this case: If I understand right, it seems that postscreen allows the client connection even though it is listed because it uses a cache which serves as a useful buffer; however the client is subsequently blocked by reject_rbl_client restrictions. So, it seems I should I entirely remove the reject_rbl_client filters (from smtpd_recipient_restrictions) as they are already listed with postscreen. No, that's the wrong lesson. You should be more selective about your long lists of DNSBLs. They are not all the same thing, and so are not all suitable for use at postscreen time. It seems like you are ignoring the fact that the underlying cause of this rejection is your decision to trust the Spamcop 'bl' list as an absolute blocker, which for most people who value their email is not a good idea. If you want to consistently receive mail from the giant mailbox providers, you need to use more nuanced mechanisms. It appears to me that using rbl services both with postscreen and smtpd_recipient_restrictions is actually pointless and causes double lookups which in the end make things worse. Postscreen is sufficient and better in filtering with rbl services. Am I right? Not sufficient and not better. Different. Postscreen is intended and designed to catch "bots": automated senders of nothing but garbage. It exists to spare systems from running full smtpd processes for what are ultimately no-op sessions. Unless you enable its extended checks, postscreen is very lightweight and fast. That's partly because it has no time-consuming exemption mechanisms (only fast ones.) Using reject_rbl_client with DNSBLs which occasionally list IPs which send a mix of spam and ham can be made feasible by putting the reject_rbl_client restriction late in the restriction list and having exemption mechanisms ahead of it. For example, I use reject_rbl_client extensively, but with check_*_access maps ahead of those directives. If you like everything about the Spamcop DNSBL except for it listing Microsoft outbounds, you could have a check_client_access directive with a map that permits *.outbound.protection.outlook.com clients before any DNSBL checks (in the same restriction list.) -- 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
[pfx] Re: SMTP Smuggling, workarounds and fix
On 2024-01-04 at 11:15:17 UTC-0500 (Thu, 4 Jan 2024 17:15:17 +0100) Geert Hendrickx via Postfix-users is rumored to have said: My point was not about SMTP smuggling, but about potentially revealing DISCARD rules to the outside world (since they cause later rules to be skipped entirely). Eg. a discarded sender receives OK on any RCPT TO, whereas an allowed sender sees usual recipient/relay restrictions. This has always been the case with DISCARD tactics and is part of the canonical argument against using DISCARD: it gives senders false indications of success, such that innocent (false positive) bystanders get no clue of any trouble. -- 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
[pfx] Re: How to configure lmtp delivery
On 2023-12-31 at 05:56:49 UTC-0500 (Sun, 31 Dec 2023 11:56:49 +0100) Togan Muftuoglu via Postfix-users is rumored to have said: But then reading man lmtp(8) it says lmtp is expected to be configured in master.cf. What am I configuring and how do I do is as there is no lmtp server running on the machine running postfix. Everything will be sent to the dovecot machine. The Postfix "lmtp" transport defined in master.cf runs the Postfix "lmtp" binary (typically a hardlink to "smtp") in LMTP mode, so that it operates as a LMTP client. You need the lmtp transport defined in master.cf so that you can use it in *_transport directive in main.cf. The Dovecot "lmtp" is the LMTP server side. -- 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
[pfx] Re: omitting the X-Google-Original-From header
On 2023-12-18 at 17:15:16 UTC-0500 (Mon, 18 Dec 2023 23:15:16 +0100) Steffen Nurpmeso via Postfix-users is rumored to have said: Bill Cole via Postfix-users wrote in <6039ed61-2c8f-4a12-b736-994d32632...@billmail.scconsult.com>: |On 2023-12-17 at 09:27:36 UTC-0500 (Sun, 17 Dec 2023 06:27:36 -0800 |(PST)) |saunders.nicholas--- via Postfix-users |is rumored to have said: | |> How is this header populated? |> |> X-Google-Original-From: nicho...@mordor.saundersconsulting.tech | |By Google. Exactly what their algorithm is for it is not known. The "X-" |prefix is the clue: it's an experimental or local-use header. Note that the X- prefix is deprecated by RFC 6648 from 2012: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols Yes, but that does not mean that one can expect to find a sound specification for what a random X-* header means and despite the deprecation you can actually be fairly sure that any X-* header has no reliable public spec. -- 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
[pfx] Re: Postfix authenticated sender and From: header verification
On 2023-12-18 at 11:31:47 UTC-0500 (Mon, 18 Dec 2023 16:31:47 +) Vijay S Sarvepalli via Postfix-users is rumored to have said: Hello Viktor, Wietse, (I am copying the Postfix community as the report is out in the public now) First of all thank you for your help and response to highlight your approach to this issue. This may not be the first time you have observed types of abuse that relate to spoofing. This research work has now been published by Sec Consult company, see link below . It is interesting that they seem to be unaware of some SMTP basics, such as the fact that message bodies, message headers, and the SMTP protocol have different format rules, defined in different RFCs that are clearly marked as such. They seem to think that the problem is grounded in legitimate misunderstanding of imprecise RFCs, when it seems clear to me that there's one right interpretation. That very much ruins my ability to take what they are saying seriously. I believe they tested against the proprietary systems cited and found the issue, I find it extremely suspect that they show no examples for Semndmail or Postfix, merely an assertion. The Postfix issues the researcher mentions, we were not able to actually reproduce This is unsuprising. -- 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
[pfx] Re: omitting the X-Google-Original-From header
On 2023-12-17 at 09:27:36 UTC-0500 (Sun, 17 Dec 2023 06:27:36 -0800 (PST)) saunders.nicholas--- via Postfix-users is rumored to have said: How is this header populated? X-Google-Original-From: nicho...@mordor.saundersconsulting.tech By Google. Exactly what their algorithm is for it is not known. The "X-" prefix is the clue: it's an experimental or local-use header. So this is a guess: it is the message's envelope sender when it arrived at Google. Maybe (unlikely) the original From: header address. What's interesting about this value is that the user name on localhost is nicholas. The FQDN is as above. There's no such e-mail address. Well, I suppose mail on localhost to that e-mail will make its way to the user mail. So Postfix when it gets local mail submitted without a domain part, it fixes that by appending @$myorigin and uses that for sending it along via SMTP. By default, myorigin=$myhostname but if your hostname isn't resolvable, you should change that. My preference is to set $myhostname to a name that relevant public MX records use, so that you get no confusion externally. Can this value be explicitly set? Or, preferably, even configured so that gmail doesn't generate and populate this header. Is there a work-around to this header, so that it's never generated? Those seem like Google questions... My GUESS is that if your EHLO name is sensible and your envelope sender has a resolvable domain, they MIGHT not generate that header. -- 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
[pfx] Re: PATCH: using Milter to change a PREPENDed header
On 2023-12-13 at 13:06:36 UTC-0500 (Wed, 13 Dec 2023 19:06:36 +0100) Jiri Bourek via Postfix-users is rumored to have said: > On 11. 12. 23 1:04, Wietse Venema via Postfix-users wrote: >> >> Confirmed. A premiminary fix is below. This will prepend the >> Received-SPF from the policy service after the Postfix-generated >> Received: header and before the received message. >> >> With this fix, a Milter can replace a PREMENDed Received-SPF: header >> as one would expect. >> >> This change is a bit invasive as it changes the message layout, >> which is not needed if a configuration does not use Milters. >> > > Will this not cause breakages in other programs though? With the current > behaviour, you can easily determine that a header was added by some local > (own) program and consider it trustworthy. Any header below own Received: is > controlled by the sender and can contain fake information. > > SpamAssasin comes to mind as an example. I would need to re-check but I think > it only considers Received-SPF to be trustworthy, if it's above own Received > header (trusted/internal network relays come into play here but let's stick > with the simple case) [dons SA contributor hat...] Generally speaking, correct. Technically it needs to be above/before the last trusted Received header. It should be possible to construct rules to identify one's own authentication headers and score appropriately, if you feel that necessary. In my opinion that's not worthwhile because SA will do its own SPF check and if something else has just done the needed DNS queries, they'll still be in cache. Very fast. -- 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
[pfx] Re: printer ip SMTP AUTH / mynetworks question
using STARTTLS, it hung up. That's bad. It should have used STARTTLS to get a useful session. shiny:~ root# telnet geko.sbt.net.au 25 Trying 103.106.168.106... Connected to geko.sbt.net.au. Escape character is '^]'. 220-geko.sbt.net.au ESMTP Postfix 220 geko.sbt.net.au ESMTP Postfix EHLO dynnat.scconsult.com 250-geko.sbt.net.au 250-PIPELINING 250-SIZE 30971520 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING quit 221 2.0.0 Bye Connection closed by foreign host. There's why port 25 worked: you have AUTH enabled on port 25 without encryption. Even worse, you only advertise plaintext SASL mechanisms, so your printer's password was sent in the clear to authenticate. So my GUESS at PART of your fix is to remove smtpd_sasl_auth_enable=yes from your main.cf, add it as an override in master.cf for submission (as above,) and tell your printer to use TLS. If you cannot use TLS, you should either get a modern printer or don't ask your printer to email you. You certainly COULD work around that by compromising the security of your MTA, but why? -- 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
[pfx] Re: Milter own Postfix-prepended Received
On 2023-12-11 at 09:37:39 UTC-0500 (Mon, 11 Dec 2023 15:37:39 +0100) Carlos Velasco via Postfix-users is rumored to have said: Bill Cole via Postfix-users escribió el 11/12/2023 a las 15:31: On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100) Carlos Velasco via Postfix-users is rumored to have said: [...] And doing the same work in 2 different places can be called software efficiency? No, but the "fix" here would be a divergence from how Milter has worked since it was created and semi-documented by Sendmail Inc. It is de facto controlled by the current developers of Sendmail, but I don't believe anyone is working to make Milter better, at least not in ways that would break compatibility. No one is talking here about breaking any compatibility, re-read the messages. What did I miss? Are you not asking for Postfix to support providing milters with a header that none of them expect and which no other Milter implementation supports? That seems to me like a compatibility break. Or you could call it a unique extension to a protocol which lacks a defined extension mechanism or even a formal standardization. Postfix would be doing something with a shared (if not exactly open...) de facto standard that is effectively controlled by the Sendmail project. What could go wrong? Beyond that, I don't think that your justifications for such an addition have made any sense. Milters can ask for any available macros needed explicitly, avoiding the need to parse a Received header in the milter itself. The only reason SpamAssassin requires a synthetic header is that it has no interface for passing the known untainted values of the parameters it wants to use. SA knows nothing about the milter API or "Sendmail Macros" or which MTA+milter layer you are using, so if it needs that it can only look in a header built in the milter e.g, as logged by the MD instance here (which logs excessively...): Dec 11 09:31:59 shiny mimedefang.pl[13203]: 4Spkhs2mXtzXcP2f: Macros are mail_mailer mail_addr daemon_port client_port mail_host auth_authen auth_type j cipher _ client_connections daemon_name tls_version cipher_bits From those macros, MD constructed this Received header for handoff to SpamAssassin: Received: from skinnyclam.scconsult.com (skinnyclam.scconsult.com [192.168.254.125]) by shiny.scconsult.com (envelope-sender ) (MIMEDefang) with ESMTPSA id 4Spkhs2mXtzXcP2f for ; Mon, 11 Dec 2023 09:31:59 -0500 SpamAssassin can reliably and usefully parse out of that header the fact that the message arrived with authentication over an encrypted session. If one had a particular need for some other defined macro one could request it in the milter and stuff it into a header as appropriate. -- 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
[pfx] Re: Milter own Postfix-prepended Received
On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100) Carlos Velasco via Postfix-users is rumored to have said: [...] And doing the same work in 2 different places can be called software efficiency? No, but the "fix" here would be a divergence from how Milter has worked since it was created and semi-documented by Sendmail Inc. It is de facto controlled by the current developers of Sendmail, but I don't believe anyone is working to make Milter better, at least not in ways that would break compatibility. -- 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
[pfx] Re: Milter own Postfix-prepended Received
On 2023-12-10 at 16:16:27 UTC-0500 (Sun, 10 Dec 2023 22:16:27 +0100) Carlos Velasco via Postfix-users is rumored to have said: Wietse Venema via Postfix-users escribió el 10/12/2023 a las 21:53: 2. the "own Received" header not being passed to milter. I understand it works as expected, but could be great to be able to decide this with a configuration parameter. That is because every Milter in the real world gets the client info from the smfi_connect() callback function and from Milter macros, instead of parsing Received: headers. That statement is absolutely false. Quite a bold choice there... Many milters, like amavisd, use other filters for mail content inspection, like SpamAssassin. Spamassassin uses the "Received" headers for some tasks, like this: https://cwiki.apache.org/confluence/display/spamassassin/TrustPath# As a contributor & PMC member for both SpamAssassin (definitely not a milter) and MIMEDefang (definitely a milter, which uses SpamAssassin) I assure you that the Received header which notionally reflects the current transaction DOES NOT exist when the milter gets the message data, and for SA to do its "trust path" audit of Received headers, the MIMEDefang milter MUST construct one for SA to use. Amavis is slightly different because it can be used as a SMTP proxy (between 2 Postfix smtpd processes) or a milter. When used as a proxy, it sees the whole message with the locally-added Received headers. When used as a milter, it works with what Postfix provides it (the relevant macros) to construct a Received header for SA. All of this is documented accurately. -- 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
[pfx] Re: postsrsd
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
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
On 2023-11-30 at 08:03:09 UTC-0500 (Thu, 30 Nov 2023 14:03:09 +0100) Alexander Leidinger via Postfix-users is rumored to have said: Hi, There is something strange with delivering mail from my mailserver to github, it complains about the github server certificate not verified on an outgoing TLS connection. Maybe requiring verified hostnames on outbound SMTP via TLS will be feasible some time after London and Miami are underwater. Not this decade. My main.cf contains the same certs-path for smtp and smtpd TLS connections: ---snip--- # grep CApath main.cf smtp_tls_CApath = /etc/ssl/certs smtpd_tls_CApath = /etc/ssl/certs ---snip--- What I see in the failure case is: ---snip--- Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: CONNECT to [140.82.112.31]:25 Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: server certificate verification failed for in-9.smtp.github.com[140.82.112.31]:25: num=62:hostname mismatch That is the error. The hostname your TLS configuration is probably expecting for that connection is reply.github.com, but that's apparently just a mail domain, not a hostname, and the machines acting as MXs for it don't use a certificate with that name. You can probably make it work for this case with suitable special-casing in your configuration, but your configuration is a total mystery to us... Also, I wouldn't consider it a worthwhile effort for most systems, but that's your call for your environment. -- 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
[pfx] Re: [ext] gmail failing SPF/DKIM
On 2023-11-28 at 06:21:14 UTC-0500 (Tue, 28 Nov 2023 11:21:14 +) Linkcheck via Postfix-users is rumored to have said: If it's only "largely redundant" I would expect G to possibly ignore it but not fail on it. The expectations of others are known to be poor predictors of GMail behavior. -- 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
[pfx] Re: gmail failing SPF/DKIM
On 2023-11-28 at 06:15:47 UTC-0500 (Tue, 28 Nov 2023 11:15:47 +) Linkcheck via Postfix-users is rumored to have said: The dmarc results are ambiguous: r That's not a result, that's part of the DMARC policy pass although dkim fails both tests. So, DKIM signatures are failing. That should not be enough to reject the mail if its SPF is passing and aligns with the From header. = google.com noreply-dmarc-supp...@google.com https://support.google.com/a/answer/2466580 10845692433607357330 1701043200 1701129599 bristolweb.net r r reject reject 100 reject 185.35.151.121 1 none fail pass mail.bristolweb.net mail.bristolweb.net pass = ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org -- 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
[pfx] Re: Postfix authenticated sender and From: header verification
On 2023-11-27 at 17:55:32 UTC-0500 (Mon, 27 Nov 2023 22:55:32 +) Vijay S Sarvepalli via Postfix-users is rumored to have said: Hello Postfix community, This may be a feature request. As far as I can tell it is currently not possible to verify if an authenticated user has sent email that uses a From: header (After DATA command) that does not match his/her credentials. The features https://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch allows for SMTP MAIL FROM: address to be verified with the authenticated user. However if a user spoofs From: header inside an email and leave the SMTP MAIL FROM: to be matching, it cannot be inspected or verified using any Postfix configuration parameters. Correct. As Dr. Venema said, this is a design choice. An important and correct one, in my opinion. The only way I found is using some third party software https://github.com/magcks/milterfrom/ Actually there are MANY ways to attack this issue with add-ons for Postfix. For example, if you use any of the mechanisms for integrating Apache SpamAssassin, it has a suite of rules related to the coherence of various sender-related values. So you could just use SpamAssassin with Amavis, MIMEDefang, MailMunge, spamass-milter, or in a simple content_filter to get those rules applied at whatever weights you like. There are also other anti-spam tools that can be integrated with Postfix by its various interfaces. Is it possible to include this as a feature so it is possible for large scale ISP’s to prevent any one user using another user hosted on the same server. This type of spoofing of the From: header inside the email could go unnoticed, potentially get a SPF verified delivery and/or even get a DKIM signature due to the lack of native capability to inspect and reject such misuse. Something like reject_authenticated_from_login_mismatch could be used to distinguish this configuration parameter. Sophisticated analysis of the contents of a message (which may or may not be in a standard format and may even be designed to thwart analysis) is a complicated and potentially dangerous task. As a transport agent, Postfix should not be spending the resources or taking the risk of such analysis. It is much safer to delegate that analysis to specialized external software. -- 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
[pfx] Re: www.postfix.org outage
On 2023-11-22 at 09:40:48 UTC-0500 (Wed, 22 Nov 2023 15:40:48 +0100) Ralph Seichter via Postfix-users is rumored to have said: * Jaroslaw Rafa via Postfix-users: Maybe it wasn't rebooted until now? (as PXE is a boot-related feature) :) I am positive that I personally rebooted this server a number of times following Kernel updates, the last of which happened not long ago. ;-) If there's a virtualization layer, they are likely to be referring to the real physical host rather than the VM running the Postfix site. I know from managing that sort of environment that PXE (netboooting) makes sense for physical hosts AND they may go a very long time between upgrades & reboots. -- 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
[pfx] Re: Odd error
On 2023-11-21 at 09:38:35 UTC-0500 (Tue, 21 Nov 2023 14:38:35 +) Paul Enlund via Postfix-users is rumored to have said: Hi I have an odd error in yesterdays mail.log. This is a one off and cannot be replicated Nov 20 15:48:03 kanuka postfix/smtpd[3566272]: connect from host.verypinktiger.c om[89.34.18.125] Nov 20 15:48:03 kanuka postfix/smtpd[3566272]: Anonymous TLS connection establis hed from host.verypinktiger.com[89.34.18.125]: TLSv1.2 with cipher ECDHE-RSA-AES 256-GCM-SHA384 (256/256 bits) Nov 20 15:48:03 kanuka postfix/smtpd[3566272]: warning: unknown smtpd restrictio n: "OK" Nov 20 15:48:03 kanuka postfix/smtpd[3566272]: NOQUEUE: reject: RCPT from host.v erypinktiger.com[89.34.18.125]: 451 4.3.5 Server configuration error; from=ir...@tigerspecs.co.uk> to= proto=ESMTP helo= ger.com> Nov 20 15:48:03 kanuka postfix/smtpd[3566272]: disconnect from host.verypinktige r.com[89.34.18.125] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7 Where/what to start looking for something that caused this. 'OK' Somewhere in your smtpd_*_restrictions lists there's an error. Most likely a typo in an access map of some sort. Impossible for anyone here to even guess which one without the debugging info suggested here: http://www.postfix.org/DEBUG_README.html#mail -- 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
[pfx] Re: Spamc no such file or directory
On 2023-11-20 at 13:04:06 UTC-0500 (Mon, 20 Nov 2023 19:04:06 +0100)
Joseph Castry via Postfix-users
is rumored to have said:
Hi,
I’m trying to activate spamassassin over postix.
My firewall is deactivated
My master.cf file :
smtp inet n - - - - smtpd
-o content_filter=spamassassin
spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -f -e /usr/bin/sendmail
-oi -f ${sender} ${recipient}
I already have the following error and no mail delivery :
spamc : exec failed: No such file or directory
What’s wrong with ?
You probably need to change /usr/bin/sendmail to /usr/sbin/sendmail.
(Unless Debian has done something crazy with their mail packages...)
--
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
[pfx] Re: Why does Postfix evaluate relay restrictions despite an early permit in recipient restriction?
On 2023-11-11 at 12:58:04 UTC-0500 (Sat, 11 Nov 2023 17:58:04 +) Matthias Nagel via Postfix-users is rumored to have said: Am Samstag, 11. November 2023, 18:51:04 CET schrieb Bill Cole via Postfix-users: Nope. Review the restriction list docs. PERMIT only short-circuits the current restriction list. Later restriction in the same list are skipped, but later lists are still run. DENY or DEFER acts immediately. Thanks for clarification. What happens if Postfix find a PERMIT in an earlier restriction list (which shortcuts that list), but then finds a DENY in a later restriction list? What takes precedence? The earlier PERMIT or the later DENY? PERMIT causes Postfix to skip the rest of the specific list that it is part of. DENY acts immediately. DEFER acts immediately The documentation is perfectly clear on this. -- 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
[pfx] Re: Why does Postfix evaluate relay restrictions despite an early permit in recipient restriction?
On 2023-11-11 at 12:26:18 UTC-0500 (Sat, 11 Nov 2023 17:26:18 +) Matthias Nagel via Postfix-users is rumored to have said: Hello all, I am running Postfix 3.8.1. Postfix serves port 25 for incoming mail from other MTAs and port 587 for authenticated MUAs. Postfix is supposed to check SPF for mails from other MTAs on port 25, but not for mails from authenticated MUAs on port 587. To this end, there is a SPF check inside „recipient_restrictions“, but authenticated clients are already permitted by an early „permit_sasl_authenticated“ inside „relay_restrictions“. According to my understanding, Postfix should stop evaluation of the access rules as soon as a final decision has been made. I thought, Postfix evaluates 1. client restrictions 2. helo restrictions 3. sender restrictions 4. recipient restrictions 5. relay restrictions 6. data restrictions 7. end-of-data restrictions in that order until either a final PERMIT, DENY or DEFER is found. Nope. Review the restriction list docs. PERMIT only short-circuits the current restriction list. Later restriction in the same list are skipped, but later lists are still run. DENY or DEFER acts immediately. -- 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
[pfx] Re: Virtual mailbox config
On 2023-11-09 at 20:25:44 UTC-0500 (Thu, 9 Nov 2023 20:25:44 -0500) Phil Stracchino via Postfix-users is rumored to have said: Agh. I've been looking at mail.log on the wrong machine ALL ALONG . Isn't that what I said ? kill me now Nah, just a little told-ya-so. -- 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
[pfx] Re: Virtual mailbox config
On 2023-11-09 at 17:50:20 UTC-0500 (Thu, 9 Nov 2023 17:50:20 -0500) Phil Stracchino via Postfix-users is rumored to have said: Hey folks, I'm trying (for the first time) to add two virtual domains for publishing to my long-time-stable postfix-3.8.2 installation. [...] If I: babylon5:alaric:~:1 $ echo test | mutt sean.fen...@seanfenian.com I get: Nov 9 17:36:54 babylon5 postfix/pickup[1545]: 4B6BA1145E89B: uid=1000 from= Nov 9 17:36:54 babylon5 postfix/cleanup[3227]: 4B6BA1145E89B: message-id= Nov 9 17:36:54 babylon5 postfix/qmgr[4905]: 4B6BA1145E89B: from=, size=742, nrcpt=1 (queue active) Nov 9 17:36:54 babylon5 postfix/smtp[3231]: Untrusted TLS connection established to smtp.caerllewys.net[10.24.32.15]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 Nov 9 17:36:54 babylon5 postfix/smtp[3231]: 4B6BA1145E89B: to=, relay=smtp.caerllewys.net[10.24.32.15]:25, delay=0.28, delays=0.02/0/0.06/0.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 6256522656D01) Nov 9 17:36:54 babylon5 postfix/qmgr[4905]: 4B6BA1145E89B: removed OK. So the Postfix SMTP *client* on the babylon5 machine successfully passed a message to smtp.caerllewys.net. Mutt and the Postfix client on babylon5 work. The Postfix SMTP *server* on smtp.caerllewys.net helpfully included in its 250 reply that its queue ID for that message is 6256522656D01. But no mailbox is created and the test message never appears anywhere. For that, look into the logs from smtp.caerllewys.net, which do not seem to appear above. Search for queue ID 6256522656D01. What probably-should-be-obvious thing am I missing? Do I need to manually create /var/spool/mail/fenianhouse.com/ ? Do I need to manually create /var/spool/mail/fenianhouse.com/seanfenian/ ? I believe so. When I've used virtual mailboxes I have done so (actually via a script, so: semi-manually) but I don't know if it is actually necessary. Again: logs from smtp.caerllewys.net are where you need to look. Search for queue ID 6256522656D01. Something else I've missed? Looking at the wrong log? Filtering out the relevant lines? -- 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
[pfx] Re: Question about postscreen
On 2023-11-02 at 04:49:37 UTC-0400 (Thu, 02 Nov 2023 10:49:37 +0200) Ivan Ionut via Postfix-users is rumored to have said: Hi, it's possible that postscreen does not block the email when postscreen_dnsbl_threshold is reached but to pass that email to spamassassin(with a score and a tag). No, postscreen is designed to be extremely lightweight and has no mechanism to 'pass' anything other than the active connection to a real smtpd process. It is intended to only catch the sorts of spambots that can be positively identified by bad behavior or *targeted* DNSBLs. If you have postscreen configured in a way that catches legitimate mail systems, you are misusing it. With that said, it is possible to set postscreen_blacklist_action to 'ignore' and have other tools like SA work with the same DNSBLs later in the transaction with more subtlety. Note that if you are running a local recursive caching DNS resolver (AS ANY MTA SHOULD) it is essentially free to "re-check" DNSBLs that postscreen has queried earlier, as the answers will be cached. This would effectively front-load the inherent delay of making DNSBL checks. -- 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
[pfx] Re: No Permissions To TLS Certificates
On 2023-10-12 at 08:26:40 UTC-0400 (Thu, 12 Oct 2023 23:26:40 +1100) Matthew J Black via Postfix-users is rumored to have said: On 12/10/2023 23:19, Wietse Venema via Postfix-users wrote: If the 'find' command cannot enumerate mode 755 directories, then this is no longer a problem that receives Postfix support. Turning off SeLinux is easy. Wietse Thanks for getting back to me. Yes, turning off SELinux is easy - however, as it is only a thought that that may be the cause (I'll test it tomorrow when I get to work), is there any doco/thoughts/etc on Postfix interacting with SELinux? I mean, surely, people have been running Postfix on RHEL before, right? These helpfully informative and demonstrative files exist on a CentOS 8Stream machine, so should be available on a RHEL 8 box if the relevant packages are installed: /usr/share/doc/selinux-policy/html/contrib_postfix.html /usr/share/doc/selinux-policy/html/contrib_postfixpolicyd.html /usr/share/man/man8/postfix_bounce_selinux.8.gz /usr/share/man/man8/postfix_cleanup_selinux.8.gz /usr/share/man/man8/postfix_local_selinux.8.gz /usr/share/man/man8/postfix_map_selinux.8.gz /usr/share/man/man8/postfix_master_selinux.8.gz /usr/share/man/man8/postfix_pickup_selinux.8.gz /usr/share/man/man8/postfix_pipe_selinux.8.gz /usr/share/man/man8/postfix_postdrop_selinux.8.gz /usr/share/man/man8/postfix_postqueue_selinux.8.gz /usr/share/man/man8/postfix_qmgr_selinux.8.gz /usr/share/man/man8/postfix_showq_selinux.8.gz /usr/share/man/man8/postfix_smtp_selinux.8.gz /usr/share/man/man8/postfix_smtpd_selinux.8.gz /usr/share/man/man8/postfix_virtual_selinux.8.gz /usr/share/selinux/targeted/default/active/modules/100/postfix /usr/share/selinux/targeted/default/active/modules/100/postfix/cil /usr/share/selinux/targeted/default/active/modules/100/postfix/lang_ext As I said, I'll experiment tomorrow, and (apart from waiting for any further SELinux/Postfix feedback) get back with the results that I generate. -- This email has been checked for viruses by Avast antivirus software. www.avast.com I see exactly that claim in a lot of malware spam... -- 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
[pfx] Re: Can postfix/spamassassin save blocked messages ?
On 2023-10-06 at 08:11:13 UTC-0400 (Fri, 6 Oct 2023 12:11:13 +) White, Daniel E. (GSFC-770.0)[AEGIS] via Postfix-users is rumored to have said: We have mail coming from one of our servers that gets a spam score of 8 and gets blocked. Is it possible to tweak the configuration of postfix and/or spamassassin to save the blocked messages for debugging/troubleshooting purpuses ? How messages are handled is out of scope for SpamAssassin. It ONLY a classifier. Conditional handling may be implemented in whatever 'glue' layer you are using between the MTA and SA. For example: I use the MIMEDefang milter and on one test system I have it save all messages, whether SA says they are spam or ham. It is also possible to use a script as a content_filter which stashes messages. If your glue layer implements a quarantine mechanism, you may be able to use it to retain messages. -- 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
[pfx] Re: pipelining issue
On 2023-09-20 at 11:07:07 UTC-0400 (Wed, 20 Sep 2023 11:07:07 -0400) Joey J via Postfix-users is rumored to have said: > Hello All, > > I have been getting a ton of pipelining errors over the past few weeks and > I can't figure out why. > It keeps saying queue write error, but disk & cpu performance is good, disk > space is good. > > I also have noticed at times it's when there are multiple recipients on the > message. > Running: mail_version = 3.7.6 > > I have a couple of samples below. Which, as Ralf said, indicate nothing about any pipelining issue. SMTP chat transcripts are not terribly useful for diagnosing problems with Postfix because the error messages sent by Postfix are intentionally not useful for discerning confidential and potentially sensitive details like configuration. http://www.postfix.org/DEBUG_README.html#mail explains what information is needed to effectively get assistance here. > Any ideas/suggestions appreciated! > > _ > Out: 220 mgw.server.net mgw.server.net > In: EHLO sender.com > Out: 250-mgw.server.net > Out: 250-PIPELINING > Out: 250-SIZE 7680 > Out: 250-ETRN > Out: 250-STARTTLS > Out: 250-ENHANCEDSTATUSCODES > Out: 250-8BITMIME > Out: 250-SMTPUTF8 > Out: 250 CHUNKING > In: STARTTLS > Out: 220 2.0.0 Ready to start TLS > In: EHLO sender.com > Out: 250-mgw.server.net > Out: 250-PIPELINING > Out: 250-SIZE 7680 > Out: 250-ETRN > Out: 250-ENHANCEDSTATUSCODES > Out: 250-8BITMIME > Out: 250-SMTPUTF8 > Out: 250 CHUNKING > In: MAIL FROM: SIZE=36318 > Out: 250 2.1.0 Ok > In: RCPT TO: > Out: 250 2.1.5 Ok > In: DATA > Out: 354 End data with . > Out: 451 4.3.0 Error: queue file write error > In: QUIT > Out: 221 2.0.0 Bye > > _ > > Out: 220 mgw.server.net mgw.server.net > In: EHLO mail-oi1-f198.google.com > Out: 250-mgw.server.net > Out: 250-PIPELINING > Out: 250-SIZE 7680 > Out: 250-ETRN > Out: 250-STARTTLS > Out: 250-ENHANCEDSTATUSCODES > Out: 250-8BITMIME > Out: 250-SMTPUTF8 > Out: 250 CHUNKING > In: STARTTLS > Out: 220 2.0.0 Ready to start TLS > In: EHLO mail-oi1-f198.google.com > Out: 250-mgw.server.net > Out: 250-PIPELINING > Out: 250-SIZE 7680 > Out: 250-ETRN > Out: 250-ENHANCEDSTATUSCODES > Out: 250-8BITMIME > Out: 250-SMTPUTF8 > Out: 250 CHUNKING > In: MAIL > FROM:< > 3yzajzrukbnydggc6j-klm5ag-fgj6hdq8gg8d6.4ge2d6p2f5j6mk@data-studio.bounces.google.com >> > SIZE=8188944 > Out: 250 2.1.0 Ok > In: RCPT TO: > Out: 250 2.1.5 Ok > In: BDAT 65536 > Out: 250 2.0.0 Ok: 65536 bytes > In: BDAT 8123408 LAST > Out: 451 4.3.0 Error: queue file write error > In: QUIT > Out: 221 2.0.0 Bye > _ > > Out: 220 mgw.server.net mgw.server.net > In: EHLO JPN01-OS0-obe.outbound.protection.outlook.com > Out: 250-mgw.server.net > Out: 250-PIPELINING > Out: 250-SIZE 7680 > Out: 250-ETRN > Out: 250-STARTTLS > Out: 250-ENHANCEDSTATUSCODES > Out: 250-8BITMIME > Out: 250-SMTPUTF8 > Out: 250 CHUNKING > In: STARTTLS > Out: 220 2.0.0 Ready to start TLS > In: EHLO JPN01-OS0-obe.outbound.protection.outlook.com > Out: 250-mgw.server.net > Out: 250-PIPELINING > Out: 250-SIZE 7680 > Out: 250-ETRN > Out: 250-ENHANCEDSTATUSCODES > Out: 250-8BITMIME > Out: 250-SMTPUTF8 > Out: 250 CHUNKING > In: MAIL FROM: SIZE=9132359 > Out: 250 2.1.0 Ok > In: RCPT TO: > Out: 250 2.1.5 Ok > In: RCPT TO: > Out: 250 2.1.5 Ok > In: BDAT 9104042 LAST > Out: 451 4.3.0 Error: queue file write error > In: QUIT > Out: 221 2.0.0 Bye > > > -- > Thanks! > Joey > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org -- 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
[pfx] Re: Stupid questions
On 2023-09-18 at 12:33:31 UTC-0400 (Mon, 18 Sep 2023 12:33:31 -0400) Phil Stracchino via Postfix-users is rumored to have said: Any lookup by rspamd happens *after* Postfix has accepted the message and passed it to milters. That is not how milters work. Postfix passes the message data to the milters after the terminating . at end-of-DATA but BEFORE it has responded to the client. The milters can then tell Postfix whether or not to accept the message and what changes to make to the message, such as adding headers. -- 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
[pfx] Re: mask "mail from: " for Microsoft
On 2023-09-14 at 10:08:42 UTC-0400 (Thu, 14 Sep 2023 10:08:42 -0400 (EDT)) Wietse Venema via Postfix-users is rumored to have said: That appears to be a different use case: you are not originating a message for some recipient on the Internet, instead you appear to be using Postfix to forward a message from the Internet to a Microsoft email service. For this, your best bet is to forward the message as an attachment, instead of inline. That is, create a new email message, from your email address, and attach the forwarded message as message/rfc822. I do this sporadically, using the 'forward' feature of a mail reader program. If you want to do this in some automated manner, perhaps Bill Cole has some tooling suggestions. Do I? Oh, I guess I've earned that by repeatedly suggesting MIMEDefang (or its sibling MailMunge) for doing things in a milter that no MTA should be doing. If one wished to do this, MIMEDefang could handle it and there may even be an example of the basic encapsulation technique in the documentation. -- 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
[pfx] Re: Postfix mails accepted for delivery, but never received
On 2023-09-11 at 12:15:10 UTC-0400 (Mon, 11 Sep 2023 09:15:10 -0700 (PDT)) Fred Morris via Postfix-users is rumored to have said: Looks like you've got the general idea. On Mon, 11 Sep 2023, Jesper Hansen via Postfix-users wrote: [...] All the non port 25 tests, took about 15-27 hops. But the port 25 ones only took 7 or 8, and have a look at the IP at the next-to-last hop of the route. 192.168.20.20?? What? Anyone can put any packet onto any network they have an interface for, even ones with RFC1918 source addresses. For years, Sprint's internal routers all used NET10 source addresses so if you traced across Sprint, you got many lines of * or a bunch of 10.* replies, depending on the egress/ingress filtering of the networks in-between. I suspect that most "empty" hops in a traceroute these days indicate routers with RFC1918 addresses and proper egress filtering. 5 165.217.24.125.in-addr.arpa (125.24.217.165) 9.645 ms 9.548 ms 9.473 ms 6 203.113.59.128 (203.113.59.128) 13.410 ms 7.639 ms 7.460 ms 7 192.168.20.20 (192.168.20.20) 9.929 ms 89.206.23.94.in-addr.arpa (94.23.206.89) 7.406 ms 192.168.20.20 (192.168.20.20) 9.611 ms user@wopr4:/etc/postfix$ sudo traceroute -T -p 25 smtp.univie.ac.at traceroute to smtp.univie.ac.at (131.130.3.111), 30 hops max, 60 byte packets 1 192.168.0.1 (192.168.0.1) 1.084 ms 1.277 ms 1.432 ms 2 * * * 3 node-16rl.pool-125-24.dynamic.totinternet.net (125.24.216.129) 7.886 ms 7.710 ms 7.526 ms 4 * * * 5 node-16zp.pool-125-24.dynamic.totinternet.net (125.24.217.165) 10.211 ms 10.037 ms node-16zl.pool-125-24.dynamic.totinternet.net (125.24.217.161) 9.846 ms 6 203.113.59.130 (203.113.59.130) 9.668 ms 7.902 ms 203.113.59.128 (203.113.59.128) 7.783 ms 7 192.168.20.20 (192.168.20.20) 9.091 ms 8.829 ms 11.607 ms 8 justin.univie.ac.at (131.130.3.111) 10.002 ms 8.949 ms 8.725 ms I also find it very impressive that it reaches univie.ac.at in 9 ms, considering the tracetime when NOT using port 25, is 260 ms. I'm surprised it reaches it at all. Yeah, because it did not. Anyone can send a packet claiming to be from 131.130.3.111. That's precisely how the port 25 intercept works: a middlebox sees packets on port 25 and replies to them with packets supposedly from the target IP. -- 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
[pfx] Re: Postfix mails accepted for delivery, but never received
On 2023-09-10 at 04:28:38 UTC-0400 (Sun, 10 Sep 2023 15:28:38 +0700) Jesper Hansen via Postfix-users is rumored to have said: [...] Then, about an hour later, I got this message to postaster@mydomain: - Transcript of session follows - ... Deferred: Connection timed out with reception.mail-tester.com. Message could not be delivered for 1 hour Message will be deleted from queue Reporting-MTA: dns; spamfilter-02.totbroadband.com Arrival-Date: Sat, 9 Sep 2023 18:06:26 +0700 Original-Recipient: rfc822;test-6y2o9s...@srv1.mail-tester.com Final-Recipient: RFC822; test-6y2o9s...@srv1.mail-tester.com Action: failed Status: 4.4.7 Remote-MTA: DNS; reception.mail-tester.com Last-Attempt-Date: Sat, 9 Sep 2023 19:17:35 +0700 I have sent 3-4 mails to mail-tester, but this is the ONLY time, I have and any response. Actually the ONLY response at all to my 20-30 mails to various recipients. What’s suspicious here is the "Reporting-MTA: dns; spamfilter-02.totbroadband.com” line. TOT is my ISP here, and I cannot fathom how THEY are in some way involved with my mail, neither sending or receiving. They are capturing and redirecting port 25 traffic from your system to their MTA, which has severe deliverability problems. If most of the traffic through that poor machine is hijacked mail like yours, it is also almost certainly mostly spam, so it is understandable that most other places won't take their connections. I simply sit on their fiber and does not relaying anything through them. Yes, but your packets traverse their routers and can be hijacked. Can someone help me shed light on what’s going on and why my emails are “blocked” somewhere down the line. I hope this helps... Your only fix for this is to get your ISP to stop hijacking your port 25 traffic. They are doing that to prevent spam coming from their network, which is good. They may also be doing that to provide incentive to individuals like yourself to buy a more expensive grade of service that allows mail to flow unmolested. Incidentally, this was also a trick used by AOL for years, back around the turn of the millennium. That example was followed by many smaller operations who didn't have any of AOLs mitigating attributes. -- 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
[pfx] Re: PDS_OTHER_BAD_TLD
On 2023-09-05 at 13:31:06 UTC-0400 (Tue, 05 Sep 2023 13:31:06 -0400) Bill Cole via Postfix-users is rumored to have said: > 6. Many years of BAD operation has sent a steady trickle of poor innocents > here and to the SA Bugzilla making false assertions like yours above and > wasting everyone's time. CORRECTION: s/here/to the SA-Users mailing list/ (I'm apparently old enough that I'm forgetting where I am, in addition to being cranky...) -- 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
[pfx] Re: PDS_OTHER_BAD_TLD
On 2023-09-03 at 19:05:41 UTC-0400 (Mon, 4 Sep 2023 01:05:41 +0200) roughnecks via Postfix-users is rumored to have said: > Il 03/09/2023 22:34, mailmary--- via Postfix-users ha scritto: > > > > maybe spamassassin is reading your vCard (.vcf) which has the following > string: > > > > URL:https://woodpeckersnest.space/ > > Bingo! Thanks > https://www.mail-tester.com/test-65luqzkci > > > btw, yes .space is considered a "bad domain" frequently abused for spam. > But I think it was recently removed from spamassassin bad domains. > > I get this from google: > > Remote-MTA: dns; gmail-smtp-in.l.google.com (66.102.1.27) > Diagnostic-Code: smtp; 550 5.7.1 Our system has > detected that this message is likely suspicious due to the very low > reputation > of the sending domain. To best protect our users from spam, the message has > been blocked. Please visit https://support.google.com/mail/answer/188131 for > more information. i39-20020a05600c4b2700b003fe19c9081dsi3181476wmp.150 - > gsmtp > (in reply to EOD command) READ CAREFULLY! The "sending domain" cited there is most likely to be the one in your SMTP envelope sender address, although it COULD be from the Sender or From header of the message, since Google is using this reply at end-of-data (EOD) and it has presumably done some basic content analysis. They would NOT use this message in reference to a domain found at arbitrary places within the message's unstructured content. More directly: If that was sent as you've described – using the .eu domain – that domain is the problem, NOT the .space domain in the body. -- 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
[pfx] Re: PDS_OTHER_BAD_TLD
On 2023-09-03 at 16:03:02 UTC-0400 (Sun, 3 Sep 2023 22:03:02 +0200) roughnecks via Postfix-users is rumored to have said: > Hello, first time here. > > I'm struggling with an issue for a .space domain which gets triggered by > Spamassassin as PDS_OTHER_BAD_TLD (Unthrustworty TLDs). Gmail is rejecting > all of my emails for that reason. FALSE. To the best of the my knowledge (and as far as I know, the other members of the SpamAssassin PMC's knowledge,) GMail does not use SpamAssassin. I have never seen solid evidence of ANY of the top 10 mailbox providers using SA, and I would be surprised if any were using it. Employees and ex-employees of MS, Google, pre- and post-merger AOL/Yahoo/Oath, and GMX have at various points over the past decade denied using SA in public, and I believe them. > I recently bought this new .eu domain That's a fun idea, but it may not help you. It has been claimed here and on the MailOp list based on anecdotal evidence that GMail disfavors the .eu TLD. No definitive public evidence of this exists, but there are anecdotes and conjectural rationales... > and trying to fix the issue I set up a virtual alias domain in postfix. > > Now I can send my mails (changing sender address from space to eu) using the > same users I had (have) for the .space domain without issues, even to google > but if I perform an online test for the .eu domain, it still references my > .space domain and I don't know where that is coming from.. > > Here's my latest test: https://www.mail-tester.com/test-w8p3e18tf That site has many problems: 1. It has been chronically out-of-date on SA code, rules, and scores. 2. It inexplicably reverses the sign on SA scores, causing needless confusion. 3. It SOLELY reflects the spam filtering choices of whoever is running it. 4. It fails to make clear that it does not and cannot provide insights into anyone else's spam filtering. 5. It implies a FALSE and BAD impression that all mail which is not spam can be "improved." 6. Many years of BAD operation has sent a steady trickle of poor innocents here and to the SA Bugzilla making false assertions like yours above and wasting everyone's time. > For that test I also tried changing my server's hostname and PTR to make it > point to the new eu domain, to no avail. > > Can anyone help me solve this issue? Google *could* but they don't really do that for senders. They do not seem to consider their misclassification of email to be a problem worth solving for free. There are professional "Deliverability Consultants" who may be able to aid you with delivery to the behemoth mailbox providers, but I have no specific knowledge of the quality or affordability of any particular firm. -- 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
[pfx] Re: Spam mails seen in logfiles question
On 2023-08-23 at 14:38:18 UTC-0400 (Wed, 23 Aug 2023 12:38:18 -0600) IUL Support via Postfix-users is rumored to have said: I must be missing something in what you're saying. If the server receives a message for myu...@mydomain.com and myuser's mailbox is full... by default the server generates a bounce, I don't see any way around that. In most modern configurations of Postfix, a full mailbox will result in a rejection code in SMTP. The incoming message is never queued. If the sender uses the ESMTP SIZE extension, the receiving server may reject an oversize message without seeing the message data at all. It tries to send the bounce back to the sender from whence it came, lets say that is "enlarge_your_part-myuser=mydomain@theirdomain.com" and then their server throws a 4xx and defers accepting the bounce, repeatedly, for a week, until retries finally times out.If their server is deferring inbound mail that doesn't sound like any sort of successful bounce management strategy to me. Yes, you will only notice when bounces fail. Most happen almost immediately and just work. Depending on why you are bouncing messages, you may only be bouncing messages sent by reckless spammers who use VERP only because that's what their tools do, and their spamming gets their accounts killed or filled before their giant piles of spam have fully delivered. -Original Message----- From: Bill Cole via Postfix-users Sent: Wednesday, August 23, 2023 9:17 AM To: IUL Support via Postfix-users Subject: [pfx] Re: Spam mails seen in logfiles question On 2023-08-23 at 05:22:21 UTC-0400 (Wed, 23 Aug 2023 03:22:21 -0600) IUL Support via Postfix-users is rumored to have said: Hi All, Have a legacy server that I've just taken over maintaining. It's set up with postfix that handles a small handful of email users. In looking through the logfile I'll frequently see emails bouncing (and the bounce messages being deferred so they just sit in the queue wasting retries). You should fix that. It is a dangerous practice to accept mail and then attempt to bounce it on a machine accepting mail from the Internet. This generates a "backscatter" of bounces to forged addresses, often with embedded spam and malware in the bounce messages. The email will be from some_spammy_text-myuser=mydomain@notmydomain.com and addressed to myu...@mydomain.com. The LHS always seems to have the same basic format ie. the underscores and the equal sign so it seems obvious that they're trying to accomplish something specific. Is it supposed to help them get past spam filtering, or get around some sort of bug? It is called "variable envelope return path" or more often just VERP. It is a common practice used in modern mailing list management that sends each message with one recipient and a unique envelope sender to assure that any delayed bounces (which are sent to the envelope sender, a.k.a. 'return path') can be positively matched to a user, so that the user can be removed or suspended from a list if there are problems delivering to them that can be understood from the bounce as likely to be repaired. There are related variants on VERP that are used to encode an earlier return path into a new one on forwarded messages (SRS) and as a trick to give every message a unique return path and hence eliminate fake bounces (BATV.) Can anyone enlighten me as to what they're trying to accomplish and if I should be doing anything configuration wise to block them from accomplishing it?? Don't block based solely on VERP use. VERP is almost universally used in business-to-consumer bulk and transactional email, including messages which are very much wanted and valuable. SRS and BATV, which look very similar, are used to make other spam mitigation tactics possible. Is it supposed to help them get past spam filtering, or get around some sort of bug? It's all about spam, like everything these days in email... But it is NOT about getting around filters. It is about enabling rigorous bounce handling (GOOD!) so that bulk mail senders can avoid sending de facto spam and keep their lists clean. The similar-looking BATV and SRS are tactics developed to allow other anti-spam techniques to work with fewer errors. -- 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 -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire _
[pfx] Re: Spam mails seen in logfiles question
On 2023-08-23 at 05:22:21 UTC-0400 (Wed, 23 Aug 2023 03:22:21 -0600) IUL Support via Postfix-users is rumored to have said: Hi All, Have a legacy server that I've just taken over maintaining. It's set up with postfix that handles a small handful of email users. In looking through the logfile I'll frequently see emails bouncing (and the bounce messages being deferred so they just sit in the queue wasting retries). You should fix that. It is a dangerous practice to accept mail and then attempt to bounce it on a machine accepting mail from the Internet. This generates a "backscatter" of bounces to forged addresses, often with embedded spam and malware in the bounce messages. The email will be from some_spammy_text-myuser=mydomain@notmydomain.com and addressed to myu...@mydomain.com. The LHS always seems to have the same basic format ie. the underscores and the equal sign so it seems obvious that they're trying to accomplish something specific. Is it supposed to help them get past spam filtering, or get around some sort of bug? It is called "variable envelope return path" or more often just VERP. It is a common practice used in modern mailing list management that sends each message with one recipient and a unique envelope sender to assure that any delayed bounces (which are sent to the envelope sender, a.k.a. 'return path') can be positively matched to a user, so that the user can be removed or suspended from a list if there are problems delivering to them that can be understood from the bounce as likely to be repaired. There are related variants on VERP that are used to encode an earlier return path into a new one on forwarded messages (SRS) and as a trick to give every message a unique return path and hence eliminate fake bounces (BATV.) Can anyone enlighten me as to what they're trying to accomplish and if I should be doing anything configuration wise to block them from accomplishing it?? Don't block based solely on VERP use. VERP is almost universally used in business-to-consumer bulk and transactional email, including messages which are very much wanted and valuable. SRS and BATV, which look very similar, are used to make other spam mitigation tactics possible. Is it supposed to help them get past spam filtering, or get around some sort of bug? It's all about spam, like everything these days in email... But it is NOT about getting around filters. It is about enabling rigorous bounce handling (GOOD!) so that bulk mail senders can avoid sending de facto spam and keep their lists clean. The similar-looking BATV and SRS are tactics developed to allow other anti-spam techniques to work with fewer errors. -- 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
[pfx] Re: reverse DNS question for HELO hostname
On 2023-08-22 at 09:32:11 UTC-0400 (Tue, 22 Aug 2023 15:32:11 +0200) Matus UHLAR - fantomas via Postfix-users is rumored to have said: so far all SMTP RFCs have specified that hostname specified in HELO needs NOT to match the result of client IP's hostname lookup. I think there's a problem with this statement, likely an error in translation. All SMTP RFCs have specified that the hostname in HELO must not be required to match the result of client IP's hostname lookup, but they all agree that it should match. Or, more tersely, in regexp: s/needs NOT/does NOT need/ -- 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
[pfx] Re: Troubleshooting mail loop issue
On 2023-08-15 at 21:52:52 UTC-0400 (Tue, 15 Aug 2023 21:52:52 -0400) Alex via Postfix-users is rumored to have said: [...] Yes, it is a loop. The loop occurs inside MS365. Apparently Microsoft does not understand how to get mail from CompanyA to CompanyB internally, so they follow the DNS. but it should then send it to another tenant, correct? You are asking a MS365 question on a Postfix mailing list. "Should" they? Of course. They didn't. Whatever is broken in this case is broken inside Microsoft. -- 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
[pfx] Re: Block based on subject and rcpt to
On 2023-08-14 at 15:13:54 UTC-0400 (Mon, 14 Aug 2023 16:13:54 -0300) SysAdmin EM via Postfix-users is rumored to have said: Hi, Is it possible to discard an email based on the Subject and the destination email address? I try this and not work: /^Subject:.*Test email subject .*To:.*m...@me.com/ DISCARD Any helps? You cannot do this within Postfix proper. You need a content filter, SMTP proxy filter, or milter to examine multiple headers together. You could also deliver to a program like procmail (e.g. via ~/.forward) or a Sieve filter (e.g. via Dovecot with it's Sieve plugin) and handle disposition of such messages there. -- 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
[pfx] Re: Troubleshooting mail loop issue
On 2023-08-14 at 17:23:34 UTC-0400 (Mon, 14 Aug 2023 17:23:34 -0400) Alex via Postfix-users is rumored to have said: Hi, I have what appears to be a complicated mail loop problem that I can't figure out. I suspect that their receiving system (M365) is somehow reinjecting the message back to our mail server after it's been successfully delivered to them. For loose values of "success"... We are acting as MX for two small companies, and occasionally, when companyA emails companyB, it is first received by raven.example.com, 209.216.111.115, which is the MX we have created for them, processed by amavisd, then routed to the destination through our postfix-out instance xavier.example.com, 209.216.111.114. The companyB server accepts the message, but then somehow companyA appears to connect to our server again and send the same message again. Yes, it is a loop. The loop occurs inside MS365. Apparently Microsoft does not understand how to get mail from CompanyA to CompanyB internally, so they follow the DNS. It's very difficult to trace what's happening, Not really, just strip out everything but the Received headers and unfold them. The path is clear. so I hoped someone could help. I think the sending server is somehow reconnecting to our server and resending the same message, but it eventually dies with the sending server saying "Error: too many hops". Our server never sees that message. They have forwarded the bounce to me and I've pasted it here: https://pastebin.com/ChcnDwjK It appears like it delivers five different copies, but each version has all the received headers of the previous version. It is odd to call these "copies" since the Received headers clearly prove that the message has gone around the loop 4 times. I'm sorry if this is confusing. I've spent probably six hours or more reading through this one email trying to trace the problem and correlate it with the postfix/amavis logs. I believe it's only happened a few times - I don't quite understand all the circumstances under which it happens. We also don't always see the reject/too many hops message. Here is a recent one: Aug 4 09:01:13 xavier postfix-115/smtp[125455]: 88D5F246: to=, relay=127.0.0.1[127.0.0.1]:11024, delay=0.67, delays=0.21/0/0/0.45, dsn=5.4.0, status=bounced (host 127.0.0.1[127.0.0.1] said: 554 5.4.0 id=136757-17 - Rejected by next-hop MTA on relaying, from MTA(smtp:[127.0.0.1]:11025): 554 5.4.0 Error: too many hops (in reply to end of DATA command)) Any ideas for either what's going on with this email or what I can do to troubleshoot this further would really be appreciated. Your task is to fix Microsoft's mishandling of email. (giggles insanely...) But seriously, you cannot fix this problem by reconfiguring Postfix or DNS, the changes must be done in MS365 mail routing. -- 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
[pfx] Re: identifying sender failing ssl/tls cipher ?
lem, not being offered/found, etc. currently / so far, this server's config is postconf -n | grep -i tls | grep -i cipher smtp_tls_ciphers = medium smtp_tls_exclude_ciphers = EXP, LOW, MEDIUM, aNULL, eNULL, SRP, PSK, kDH, DH, kRSA, DHE, DSS, RC4, DES, IDEA, SEED, ARIA, CAMELLIA, AESCCM8, 3DES, ECDHE-ECDSA-AES256-SHA384, ECDHE-ECDSA-AES128-SHA256, ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES128-SHA256, MD5, SHA smtp_tls_mandatory_ciphers = medium smtpd_tls_ciphers = medium smtpd_tls_exclude_ciphers = smtpd_tls_mandatory_ciphers = medium tls_preempt_cipherlist = yes tlsproxy_tls_mandatory_exclude_ciphers = $smtpd_tls_mandatory_exclude_ciphers Why? Can you explain how each of these is better than the Postfix defaults? i'm not seeing the cause of the problem :-/ am i looking in the wrong place? or is that^ config already a cause? I expect that Viktor will respond with a detailed coherent explanation of why your bespoke config is breaking your system. He will be correct about every word. I will just say that you should remove all non-default TLS-related settings for which you cannot give a detailed technical justification, beyond "some random web page told me to do it." -- 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
[pfx] Re: email being flagged a spam for using localhost [127.0.0.1] as first hop
On 2023-08-09 at 03:40:20 UTC-0400 (Wed, 9 Aug 2023 09:40:20 +0200) Fourhundred Thecat via Postfix-users <400the...@gmx.ch> is rumored to have said: On 2023-08-09 07:58, Viktor Dukhovni via Postfix-users wrote: On Wed, Aug 09, 2023 at 07:34:48AM +0200, Fourhundred Thecat via Postfix-users wrote: So that the first hop looks like this: Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.xxx.yyy (Postfix) with ESMTPSA id 7E011B0 for ; Wed, 9 Aug 2023 07:04:42 +0200 (CEST) Try a small change: Received: from localhost.local (localhost.local [127.0.0.1]) by mail.xxx.yyy (Postfix) with ESMTPSA id 7E011B0 for ; Wed, 9 Aug 2023 07:04:42 +0200 (CEST) That is, use a hostname as the recorded "HELO" name, rather than address-literal, and make that name be an FQDN while you're at it. This might be enough. thank you. thinking about it now, could I remove the host and the IP entirely? You CAN do just about anything with the Received headers, as it has a long history of wildly divergent contents. How MS reacts is the more relevant question and the answer is only known to Cortana, or whatever MS calls their quasi-sentient spam filter... I have looked at what the header looks like when I send an email locally (from mutt as user on the postfix server). And there is no hostname or IP or localhost entry at all: Received: by mail.xxx.yyy (Postfix, from userid 1000) id A73CFD6; Wed, 9 Aug 2023 08:36:22 +0200 (CEST) do you think this would be OK, or does the hostname and IP (be it localhost.local) have to be there ? It is probably a good idea (if you are committed to an audit trail going nowhere and being obviously intentionally deceptive) to mimic mail that works. So the answer is testing. If sending with mutt works, fake that. A Received header that seems to record a SMTP session on the loopback by Postfix is not common, so maybe the local submission pattern will be less suspect. Test. One thing that seems to work is to not attempt to craft Received headers at all. You have to evaluate your own threat model, but the marginal value of the information in a Received header is rarely significant. On the other side, it is usually possible to detect obfuscated Received headers and it is entirely reasonable for receiving sites to see that in a message and deem it suspect on that basis. -- 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
[pfx] Re: Maildir filename format
On 2023-07-31 at 09:34:47 UTC-0400 (Mon, 31 Jul 2023 15:34:47 +0200) Fourhundred Thecat via Postfix-users <400the...@gmx.ch> is rumored to have said: On 2023-07-31 15:09, Bill Cole via Postfix-users wrote: On 2023-07-31 at 02:43:28 UTC-0400 (Mon, 31 Jul 2023 08:43:28 +0200) 1690633510.M94611123819.mail,S=11706,W=12202:2,S That message was delivered at Sat Jul 29 12:25:10 2023 UTC. It is 11706 bytes on disk and the "RFC822Size" (a.k.a. "wire size") is 12202 bytes, implying that it has 496 lines of text. It has been marked as seen by an IMAP client, and has no other IMAP flags set. The delivery agent believes that its hostname is simply "mail". how did you decode it ? 1690633510 is the timestamp in "Unix Epoch Seconds." "date -j -f %s 1690633510" will do the conversion. M94611123819 is a locally unique token chosen by the delivery agent. I believe that for Dovecot on most platforms there's an inode number hidden in there. mail is the hostname S= and W= fields are (compatible) Dovecot extensions to the naming format that spares reading the file or even stat()ing it to get the raw size. : is the delimiter between the base name and the flags 2 is the version number for the format. S is an indicator that the IMAP "\Seen" flag is set for the message. -- 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
[pfx] Re: Maildir filename format
On 2023-07-31 at 02:43:28 UTC-0400 (Mon, 31 Jul 2023 08:43:28 +0200) Fourhundred Thecat via Postfix-users <400the...@gmx.ch> is rumored to have said: Hello, I am using Maildir format on my server (Postfix + Dovecot). The individual filenames have this format: 1690633510.M94611123819.mail,S=11706,W=12202:2,S That message was delivered at Sat Jul 29 12:25:10 2023 UTC. It is 11706 bytes on disk and the "RFC822Size" (a.k.a. "wire size") is 12202 bytes, implying that it has 496 lines of text. It has been marked as seen by an IMAP client, and has no other IMAP flags set. The delivery agent believes that its hostname is simply "mail". Now, I have another, unrelated email account (not my mail server), and I have set up Thunderbird with local Maildir support. Which is not compliant with any Maildir spec that I am aware of. When I look inside the folder, the emails have this nice and clear format: for received: ----x...@sender.com.eml for sent: ----x...@recipient.com.eml how could I have such nice filenames on my server, with useful information in the filename, instead of those ugly containing special characters like '=' and ':' ? You cannot. The names on the server are structured as defined in the Maildir spec and specifically constructed by the delivery agents (Postfix and/or Dovecot.) They include extended semantics specific to Dovecot that embeds metadata in the names. Do the nioe filenames come from Thunderbird, or from the mailserver ? TBird. -- 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
[pfx] Re: which main.cf and postconf
On 2023-07-10 at 12:42:24 UTC-0400 (Mon, 10 Jul 2023 17:42:24 +0100) Ken Gillett via Postfix-users is rumored to have said: From where is postconf getting its information? Does it have a config directory hard coded? Yes. Note: # strings /Applications/Server.app/Contents/ServerRoot/usr/sbin/postconf |grep -i '[a-z]/[a-z]' /dev/null open /dev/null: %m /Library/Server/Mail/Config/postfix/usr/sbin /Library/Server/Mail/Config/postfix/usr/bin/newaliases /Library/Server/Mail/Data/spool btree:$data_directory/postscreen_cache /Applications/Server.app/Contents/ServerRoot/usr/local/man /Library/Server/Mail/Config/postfix dev:/dev/urandom /Library/Server/Mail/Config/postfix/usr/bin/mailq /var/mail /Library/Server/Mail/Config/postfix/usr/sbin/sendmail hash:/Library/Server/Mail/Config/postfix/aliases /Library/Server/Mail/Data/mta [...] # strings /usr/sbin/postconf |grep -i '[a-z]/[a-z]' /dev/null open /dev/null: %m /var/mail btree:$data_directory/postscreen_cache /usr/sbin /usr/sbin/sendmail /usr/bin/newaliases /usr/local/man /usr/libexec/postfix hash:/etc/aliases /var/lib/postfix /usr/bin/mailq /etc/postfix /var/spool/postfix [...] Postfix is built with a set of defaults which are embedded in the executables. These are subject to configuration at build time. You need to use Postfix binaries like postconf which were built with the same configuration as the running service. The basis of the confusion here is that Apple has shipped all versions of MacOS X with a customized Postfix using "core system" defaults (/etc, /var, /usr) since ~10.4. That version is built to be used as a local 'null client' and is launched on demand when mail is submitted locally (e.g. using /usr/sbin/sendmail, which is actually a Postfix interface) They also have the "Server" package which puts a differently-customized version in an "add-on software" tree under /Library/ (which is the "right" choice per Apple/NeXT filesystem layout norms.) If you intend to stick with Server a while longer, you might want to edit your .profile (or .login if you use csh) to add the useful paths to binaries under /Applications/Server.app/Contents/ServerRoot/ to the start of your PATH so that you use the Server versions by default. Certainly it does not seem to follow the directory as applied to the running master process. How can 2 different postconf executables produce different results and which is correct? They produce different results because they were built with different configurations, such that they have different embedded default parameters, including the default location of config files. Each 'postconf' will provide the configuration truth about the Postfix installation of which it is a part. -- 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
[pfx] Re: which main.cf and postconf
On 2023-07-10 at 05:34:44 UTC-0400 (Mon, 10 Jul 2023 10:34:44 +0100) Ken Gillett via Postfix-users is rumored to have said: It is many years since I set up postfix on my Mac server and it's use is now purely for local email, i.e. users on home network. However I have some issues with this and could really do with some help. First of all, changes I have made in main.cf are not being used. AFAICT I am editing the main.cf that is used:- ps ax | grep master => master -c /Library/Server/Mail/Config/postfix So main.cf in that directory is the one being used, but changes to that file are ignored. I'm kinda stuck trying to figure out what appropriate changes to make when I don't know how to actually make any changes to the config being used. That's apparently an installation done by Apple's "Server" product, which has been abandonware for some years. Changing it through the Server.app administrative tool is one strong possibility for something that will work for you. As for why your changes did not take, I have 2 theories: 1. You didn't restart Postfix after the changes (easiest fix!) 2. When you restarted Postfix, the Apple tools rebuilt main.cf and master.cf from its (hidden in a plist somewhere?) configuration and the *.cf.proto files in that same directory. I have not touched Server in quite a while, but if I recall correctly, (2) is always going to happen if you use Server (or launchctl) to restart Postfix. The actual .cf files are just for runtime use, not direct editing. What does 'postconf -d' show? I know it is supposed to be the 'defaults', but from where is it getting those defaults? Hard coded into the executable? As I understand it, yes. If so, how come myhostname, mydomain and mynetworks all contain data specific to my network. All of those have programmatic defaults, and they are expanded at postconf run time to give operating defaults that are likely to be right for you. You may notice that 'postconf -n' gives different values if you've explicitly set any of those attributes. Reading the comments in main.cf and/or the man pages for postconf(1) and postconf(5) may help clarify. It is almost as if the configuration being used is an amalgam of main.cf in the above directory and also from /etc/postfix, but I don't believe postfix does that sort of thing. Correct. It does not. OTOH, the MacOS X Server software that manages Postfix does undocumented things under the hood that thwart direct editing of its runtime config files. As I said, many years since I last played with postfix and could do with some assistance. As someone who has run Postfix on MacOS for 17 years, my most vehement advice is to get off the old unpatched Apple-customized and abandoned FOSS components in the old Server package and update to current versions NOT managed by Server. You can build everything on your own and I expect that you can use Homebrew to build them if you prefer, but my personal preference is using the MacPorts versions. Postfix, Dovecot, BIND, and all their dependencies have working ports. If you were "all in" committed to the Server environment, with its integrated calendar, directory, push notification, and other tools, it is extremely painful to reconstruct that all by yourself with the underlying FOSS tools, but that's the best choice at this point. -- 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
[pfx] Re: How to configure minimal POP3/IMAP server with postfix?
On 2023-07-10 at 04:10:32 UTC-0400 (Mon, 10 Jul 2023 09:10:32 +0100) Chris Green via Postfix-users is rumored to have said: I run simple Postfix setups on a number of systems, these are all systems which only have a very few users, two or three at the most. I want to add IMAP/POP3 access to one of the systems (it's a VPS but that's probably irrelevant). This will again be for only two or three users. What's the simplest way to do this? I looked in the "Postfix Howtos and FAQs" page but there didn't seem to be any 'minimal' sort of setups there. They also seemed rather old. So, can I just install and configure Dovecot with Postifx delivering mail to /var/mail? Yes. You might find ~/Maildir more convenient in the long run, but you can do the traditional mbox in /var/mail/ thing. ... and is Dovecot the way to go? Yes. -- 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
[pfx] Re: SPF questions
On 2023-06-12 at 04:19:12 UTC-0400 (Mon, 12 Jun 2023 20:19:12 +1200) Peter via Postfix-users is rumored to have said: > Technically it's an invalid MX record because MX records must point to a > hostname, not an IP address. > > They are probably trying (but failing) to implement a null MX record: > > https://www.rfc-editor.org/rfc/rfc7505 Also, it may be an artifact of discussions ~2 decades ago about how best to express the mail-nonexistence of a domain. I am certain I saw it proposed at least twice as a way to make misuse of such a domain noisy and painful. > > > Peter > > > On 12/06/23 19:50, wesley--- via Postfix-users wrote: >>> >>> Note there is also RFC 7505 "Null MX" where you simply add "IN MX 0 ." to >>> any DNS name you wish not to send or accept e-mail. (this is designed to >>> work around implicie MX records when A record is present). >>> >>>> >> >> I saw some domains have MX pointing to 127.0.0.1. what does this mean? >> >> Thanks. >> ___ >> 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 -- 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
[pfx] Re: No Postfix novice, but need novice-like advice (was Postfix or Dovecot cracked?!)
Postfix configuration. Does Postfix EVER read a password file? I think it does not, Correct. and so I say it has to be Dovecot, but some clearing up of that would be nice... It is quite simple to misconfigure Postfix as a de facto open relay, so that no authentication is needed. It is possible to misconfigure Dovecot such that it does not actually check anything (but it is NOT easy...) It is possible for users to lose control of their passwords to malware, persistently and repeatedly. And, now that I think of it could this be a way to prove which is guilty of letting the spammers in? Unless you have specifically configured submission via Dovecot, Postfix is what "let them in" because Postfix is what handles submission on port 587 (and possibly on 465 also) and general SMTP on port 25, which can also be misconfigured with regards to authentication and/or relaying. I MUST get Dovecot's use of the ports 587 / 993 working again to allow my outside users to get email again, but HOW THE HELL DO I DO THIS and NOT let the spammers in?! My top suspicion based on your rather vague description of this as being reduced to 'just the Russians' is that the problem is not with your system at all, but with one user's machine. If you had a simple config problem or some compromising bug in Postfix or Dovecot, it would be open to all sorts of miscreants. A user who has spyware owning their machine leaks their credentials to only one criminal spam operation. Repeatedly. But that's very much a guess. -- 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
[pfx] Re: Detect/extract attachments in broken messages composed by Apple Mail
On 2023-05-26 at 07:05:09 UTC-0400 (Fri, 26 May 2023 13:05:09 +0200) Paul Menzel via Postfix-users is rumored to have said: Dear Postfix folks, Apple Mail violates the standard [1], That's no "standard" that's a Mozilla Inc. bug report. There is no violation of standards here, there is only an *uncommon* MIME structure. resulting in attachments only being shown in the HTML view. How your MUA presents a particular MIME structure is implementation dependent. E.g. my MUA shows me a message with attachments as having attachments, whether it is rendering HTML or not, no matter which part of a multipart/alternative message it is presenting. That's a MUA design choice. This behaviour is to be expected given the incorrect MIME structure of the message. It is: multipart/alternative text/plain multipart/mixed text/html attachment So when selecting the plain part, you don't see the attachment associated with the alternative part. As Viktor noted, this CAN be a legitimate choice. If the "attachments" are images that only exist to be displayed inline in rendered HTML, there's no point in trying to present them in a MNUA that only displays the text/plain part. The message structure should be: multipart/mixed multipart/alternative text/plain text/html attachment If we wanted to detect such messages, and add a notification or extract the attachment, what component would be the right part for such message alteration? A milter? A milter would be the best choice. Both MIMEDefang and MailMunge (a descendant of MIMEDefang) could do this, if you can work with the Perl MIME::Tools module. (I am aware, that this will break with end-to-end encryption (GPG or S/MIME).) It will also break DKIM. Therefore it would be unsuccessful if you were to do this with mail that you want to relay or forward elsewhere. -- 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
[pfx] Re: Mx has ip6 only
On 2023-05-24 at 09:50:08 UTC-0400 (Wed, 24 May 2023 13:50:08 +) Ken Peng via Postfix-users is rumored to have said: If the MX hostname has only IPv6 resolved, does it have problems in mail functions? Yes. Not all sending systems have IPv6 addresses or connectivity. If your inbound mail system doesn't have an IPv4 address, it cannot receive mail from other machines that only have IPv4 addresses. -- 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
[pfx] Re: delivery loop?
On 2023-05-22 at 19:53:11 UTC-0400 (Tue, 23 May 2023 07:53:11 +0800) Tom Reed via Postfix-users is rumored to have said: PS: Why do you (think you) need a backup MX? Hello I am not sure why I need a backup mx indeed, If you don't know why you want the added complexity, you do not want the added complexity. (See Also: "Cargo Cult") but if you make a simple dig, you find gmail, fastmail, protonmail, comcast, free.fr those big providers do have backup MXs. And they handle thousands of simultaneous SMTP sessions 24x7x365. Do you need that sort of scale? Though yahoo, outlook don't have backup MX as a comparison. Right, because multiple MXs are really NOT made necessary by scale, that's just a feature of some possible scaling architectures. The historical justification for the complexity of MX records was the Internet of the 1980s. That complexity (or robustness, if you prefer) turned out to be useful in the scaling of mail to hundreds of millions of users in thousands of domains in essentially unified systems with very high availability to 100% of the open Internet. If you do not have connectivity like the 1980s or scale like Google or GMX, you should have some *architectural* justification for a backup MX. -- 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
[pfx] Re: delivery loop?
On 2023-05-22 at 08:36:49 UTC-0400 (Mon, 22 May 2023 14:36:49 +0200
(CEST))
Bernardo Reino via Postfix-users
is rumored to have said:
My world is only a very small subset of the real world :), but in that
world, if I say that a given server is the MX for a domain, then
that's that, it should not relay further.
No.
Historically, domains would be configured with multiple MX records
pointing to diverse machines because one could not rely on perfect
connectivity and in some cases it was actually more or less expensive
(in resources or actual money) to route mail via one or another path.
This is why MX records have a "cost" field, and it is expected that
whichever MX host one relays to, it will end up in the same mailbox.
Usually this means that higher-cost MX hosts relay messages with SMTP to
the lowest-cost MX host, but not always.
In the modern world, connectivity and individual host availability have
become good enough for most cases that it is more trouble than it is
worth to have diverse MX hosts with varied cost metrics. The use of
multiple MX records has evolved into a mechanism for load balancing and
availability in very large systems and playing standard-compliance games
with spammers ("no-listing") for smaller systems.
--
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
[pfx] Re: A strange DMARC failure
On 2023-05-16 at 21:09:35 UTC-0400 (Wed, 17 May 2023 09:09:35 +0800) Tom Reed via Postfix-users is rumored to have said: [...] Since the message was sent to mailing list which rewrites envelope address and adds list signature, so: 1) SPF for header From: address won't get pass due to SRS. 2) DKIM won't get pass due to list signature. So the DMARC failed totally and the message was rejected. How to improve this? Do not reject mail solely based on DMARC failure. DMARC is fragile and unreliable. It has WELL-KNOWN incompatibilities with traditional mailing list practices. The fact that DMARC exists does not imply that it is entirely usable as deployed. -- 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
[pfx] Re: logging strangeness
On 2023-05-16 at 12:19:03 UTC-0400 (Tue, 16 May 2023 18:19:03 +0200) Víctor Rubiella Monfort via Postfix-users is rumored to have said: For example for imap/pop login failures dovecot log email account that produces the failure. If you are using Dovecot for SASL and have auth_verbose enabled in Dovecot, it will log failures. For failed Postfix authentications, you will see lines logged by auth-worker in the info log with the username, remote IP, and failure type. -- 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
[pfx] Re: per-domain sender_checks?
On 2023-05-16 at 11:27:52 UTC-0400 (Tue, 16 May 2023 11:27:52 -0400) Alex via Postfix-users is rumored to have said: > Is there a way to control smtpd_recipient_restrictions on a per-domain > basis so I can relax some of these restrictions for cases like this, > instead of a more reactive approach where I'm always adding > sender_checks.pcre entries? Have you looked into using restriction classes? -- 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
[pfx] Re: DKIM and DMARC
On 2023-05-16 at 10:11:39 UTC-0400 (Tue, 16 May 2023 22:11:39 +0800) Tom Reed via Postfix-users is rumored to have said: For OpenDMARC this setting: SPFSelfValidate true Can it handle the case when incoming message has rewritten envelope address by SRS then no SPF found for header From address? I have no idea what the answer to that is, as I don't use OpenDMARC. You may want to figure out where, if anywhere, OpenDMARC support is available. If opendmarc can implement SPF checks for header From address , That would be much better. Thanks On 2023-05-16 at 08:16:21 UTC-0400 (Tue, 16 May 2023 20:16:21 +0800) Tom Reed via Postfix-users is rumored to have said: Hello list, Should we reject failed message on DKIM validation stage, or DMARC validation stage, or both? Generally, neither. IF (and ONLY IF) the "From: " header address domain aligns with the DKIM-signing domain AND that domain also has a DMARC record in DNS which specifies "p=reject" you may choose to reject a failed message. So, obviously, you cannot know whether rejection is reasonable before doing the full DKIM/DMARC analysis. NOTE WELL: DKIM signatures are notoriously fragile, and are broken by MTA behaviors which have been commonplace for the lifetime of the Internet. If you reject messages based on an existing DKIM signature not verifying, you will reject some entirely legitimate mail for no good reason. -- 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 -- sent from https://dkinbox.com/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org -- 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
[pfx] Re: DKIM and DMARC
On 2023-05-16 at 08:16:21 UTC-0400 (Tue, 16 May 2023 20:16:21 +0800) Tom Reed via Postfix-users is rumored to have said: Hello list, Should we reject failed message on DKIM validation stage, or DMARC validation stage, or both? Generally, neither. IF (and ONLY IF) the "From: " header address domain aligns with the DKIM-signing domain AND that domain also has a DMARC record in DNS which specifies "p=reject" you may choose to reject a failed message. So, obviously, you cannot know whether rejection is reasonable before doing the full DKIM/DMARC analysis. NOTE WELL: DKIM signatures are notoriously fragile, and are broken by MTA behaviors which have been commonplace for the lifetime of the Internet. If you reject messages based on an existing DKIM signature not verifying, you will reject some entirely legitimate mail for no good reason. -- 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
[pfx] Re: domain based vhosts
On 2023-05-04 at 08:21:31 UTC-0400 (Thu, 04 May 2023 14:21:31 +0200) Corey Hickman via Postfix-users is rumored to have said: Hello list, another more question, does postfix support domain based vhosts? It depends on what you mean by that... There is no mechanism in SMTP for a server to determine what host and/or domain names a client has used to choose where to make the connection. HTTP has the Host header and very little flexibility until that header is available, where an analogous header for email would be unavailable until the DATA phase, after at least one recipient has been explicitly accepted. such as different vhost has different policies, routes, milters etc. See the MULTI_INSTANCE_README file in the Postfix documentation for what Postfix *does* support in regards to having multiple instances running on a single machine. Note that instances are differentiated by IP address and TCP port number. -- 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
[pfx] Re: Future Date:
On 2023-05-02 at 11:47:03 UTC-0400 (Tue, 02 May 2023 17:47:03 +0200) Benny Pedersen via Postfix-users is rumored to have said: Viktor provided a milter that test it before queue, while spamassassin is after queue ? SpamAssassin is NOT inherently after-queue. There are at least 4 open source milters that can call SA. -- 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
[pfx] Re: tls_high_cipherlist parameter
On 2023-05-01 at 04:45:37 UTC-0400 (Mon, 1 May 2023 10:45:37 +0200) Kolusion K via Postfix-users is rumored to have said: Hello Postfix's documentation for the tls_high_cipherlist parameter states to see the output of the command 'postconf -d' to see the default setting. Sadly, the documentation lacks specificness, and the output spit out about 500 lines, so I am not sure what I am suppose to be looking at. The man page for postconf(8) very clearly and fully explains how to display a single parameter. The man page for postconf(5) explains what tls_high_cipherlist is, and there is also an in-depth README in the Postfix documentation for TLS configuration. -- 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
[pfx] Re: postscreen question
On 2023-04-29 at 06:43:01 UTC-0400 (Sat, 29 Apr 2023 10:43:01 +) Ken Peng via Postfix-users is rumored to have said: Nope. I found that if I enabled protocol test, every provider including gmail/orange/vodafone sending messages to me will get response code 450. After I disabled those protocol test, everything goes fine. So what's the correct way to deal with postscreen protocol tests? Do not enable any of the Postscreen "After 220" tests. They are not worth their cost in delays. This was discussed earlier in this thread... I mean the following stuff. postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce Thanks. On Sat, 29 Apr 2023, Ken Peng via Postfix-users wrote: Hello When I enabled postscreen, why even gmail's sender IP was greylisted? Did you expect or configure to deal with gmail differently? The log says: Apr 29 15:35:35 mxin postfix/postscreen[59408]: NOQUEUE: reject: RCPT from [209.85.160.53]:50219: 450 4.3.2 Service currently unavailable; from=, to=, proto=ESMTP, helo= And this is my configuration for postscreen: # postscreen postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_access.cidr postscreen_blacklist_action = drop postscreen_greet_action = enforce postscreen_dnsbl_threshold = 2 postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org*2 postscreen_dnsbl_whitelist_threshold = -2 # postscreen protocol test postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce There doesn't seem to be anything specific to gmail, so if you enable greylisting, it will apply to everyone. Cheers. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org -- https://kenpeng.pages.dev/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org -- 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
[pfx] Re: Deny any sender address with subdomain
On 2023-04-28 at 09:59:53 UTC-0400 (Fri, 28 Apr 2023 15:59:53 +0200) Gerd Hoerst via Postfix-users is rumored to have said: Hi ! question 1st : is it a good idea to reject any email which is not sent from a domain (means sen...@domain.tld) any other like sen...@sub.domain.tld or sub.sub.domain.tld is rejected ? No. It would be a deeply unwise idea for most mail systems, and a fundamental misunderstanding of how Internet email is designed to work. OF COURSE, there's no law in most places that would forbid you from doing something deeply unwise, and your own mail stream may never see non-spam "From" anyone with a 3-level domain part to their address. This is possible for subscribers to this list only because it has recently switched to replacing the "From" header on posts. at least i tried with header checks in pcre /^From:\.*@.*\.*\.*/ DISCARD NO SUBDOMAINS but this seemd not to work.. Yes, it wouldn't. It seems to want a local-part consisting of a single literal '.' and a redundantly-specified repeating series of literal '.' characters at the end of the domain name. That would be a whole different class of bogosity... i have several anti spam feature enabled but i get still some messages which are coming from subdomains or sub sub domains Yes, indeed you do... Or you would, if I CC'd a copy of this to you directly. -- 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
[pfx] Re: postscreen question
On 2023-04-26 at 11:56:01 UTC-0400 (Wed, 26 Apr 2023 17:56:01 +0200) Mihaly Zachar via Postfix-users is rumored to have said: Dear All, I am building a new server where I would like to build the best spam filter possible :) I am checking postscreen these days. I am planning to turn on the "deep tests" as well, but it seems to be really scary to me :) Don't. They are not worth it. What is the best practice here ? I am curious for your opinions. Only use Postscreen's before-greeting tests. The "deep" tests add very little marginal value. -- 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
[pfx] Re: Subject modification based on recipient
On 2023-04-26 at 10:07:09 UTC-0400 (Wed, 26 Apr 2023 16:07:09 +0200) Andreas Cieslak via Postfix-users is rumored to have said: Hi list, i want to achieve that my postfix relay will modify the subject based on the recipients. The postfiy relay is receiving email from other internal systems and forwards all mail to a mail group (testgroup) on another internal mail system. I have already configured the following in the header_checks file if !/^To: email@company$/ /^Subject: (.+)$/i REPLACE Subject: [email@company] $1 endif For this one case it works fine. Now i want to modify the subject for more emails in the header_checks like if !/^To: email@company$/ /^Subject: (.+)$/i REPLACE Subject: [email@company] $1 endif if !/^To: email@company2$/ /^Subject: (.+)$/i REPLACE Subject: [email@company2] $1 endif I have read that there is a header_checks limitation for the first line check, so my example does not work. Correct. The header_checks facility checks exactly one header at a time, so there is NO WAY to make the above logic work using header_checks. When header_checks is examining the To header, it is ONLY able to operate on the To header. The 'if/endif' structure is primarily useful to make sure some rules are only ever applied to specific headers and skipped for others. Does anybody know if its possible with regex within header_checks? Or is there another possibility to solve this? You would need to use a milter or a content_filter for this. For example, MIMEDefang (or its descendant MailMunge) could do this in a filter_end() subroutine. -- 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
[pfx] Re: Sender address rejected, but domain is found?
On 2023-04-25 at 12:24:04 UTC-0400 (Tue, 25 Apr 2023 12:24:04 -0400) Alex via Postfix-users is rumored to have said: Hi, I realize this is probably one of the most frequently asked questions, but I really can't figure out why this was rejected. Apr 25 12:06:01 petra postfix-226/smtpd[592344]: NOQUEUE: reject: RCPT from mail.email.eurobank.rs[195.242.76.237]: 450 4.1.8 : Sender address rejected: Domain not found; from=< obaveste...@eurobank-direktna.rs> to= proto=ESMTP helo=< mail.email.eurobank-direktna.rs> What am I missing? eurobank-direktna.rs and mail.email.eurobank-direktna.rs both have forward and reverse DNS entries. I thought maybe it just didn't resolve properly at the time the email was received, but it's been happening for hours. The 450 error code implies a transient failure, e.g. a SERVFAIL reply or a timeout. One of the authoritative nameservers for eurobank-direktna.rs (the domain part of the sender address) times out for me at the moment, which may be related to what you're seeing. -- 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
[pfx] Re: Use of PTR record
On 2023-04-25 at 09:14:18 UTC-0400 (Tue, 25 Apr 2023 15:14:18 +0200) Jos Chrispijn via Postfix-users is rumored to have said: Running mailservice with Postfix PTR record is set to myserver.mydomain.com (1.2.3.4) Every time I receive external e-mail, my logfile shows: Apr 25 15:01:39 terra postfix/smtpd[12479]: 073416D2: client=unknown[1.2.3.4], sasl_method=LOGIN, sasl_username=me How can I configure that client=unknown[1.2.3.4] will be replaced with the PTR record text instead? Make the name in the PTR record resolve back to the same client IP. I could force that by puting 'myserver.mydomain.com 1.2.3.4' in my hosts file, but I am not quite convinced that is the only solution. Actual DNS is also an option, and a better one usually. As you've chosen to pose this as a hypothetical with bogus details, there may be complications we can't see. -- 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
[pfx] Re: postfix does not add Return-Path if mail is missing it
On 2023-04-23 at 14:29:31 UTC-0400 (Sun, 23 Apr 2023 20:29:31 +0200) Benny Pedersen via Postfix-users is rumored to have said: Matus UHLAR - fantomas via Postfix-users skrev den 2023-04-23 16:43: On 23.04.23 11:19, Benny Pedersen via Postfix-users wrote: Subject: [pfx] postfix does not add Return-Path if mail is missing it imho a bug it's added in local if delivering to mbox or maildir: http://www.postfix.org/local.8.html its not in my case a local problem, its seen from remote mta (exim), i reported here in belive that this is a bug, i know envelope-from can be in received header aswell Return-Path should only be added by the final delivery agent. If the mail is being sent out to another MTA, it should NOT have a Return-Path on it. what will postfix do if both missing ?, I'm sure Viktor and/or Wietse with correct me if I'm wrong, but I'm fairly sure Postfix never cares about the presence of a Return-Path header *UNLESS* it is configured to strip an existing one out. It does not interpret existing Received headers. what will spf test do in spamassassin ? SA has multiple ways of figuring out the RFC5321MailFrom (a.k.a. envelope sender or return-path) value, which the MTA should provide to whatever glue you use to integrate SA. Some glue layers (e.g. MIMEDefang, MailMunge, and I expect any other milter) construct synthetic final delivery headers (Received, Delivered-To, Return-Path, etc.) to pass to SA. See the SA docs (and your glue docs, I guess...) for details. -- 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
[pfx] Re: Reject mail by language
On 2023-04-18 at 14:54:22 UTC-0400 (Wed, 19 Apr 2023 02:54:22 +0800) tom--- via Postfix-users is rumored to have said: How to reject messages by languages? For example, only English, Germany and Chinese messages will be accepted. All others should be rejected. For that sort of filtering, you need to use an external tool such as ASF SpamAssassin or rspamd, usually integrated with Postfix via a milter interface. Note that detection of specific languages in email is intrinsically imperfect. -- 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
[pfx] Re: SPF: HELO does not publish an SPF Record
On 2023-04-12 at 06:41:02 UTC-0400 (Wed, 12 Apr 2023 12:41:02 +0200) Fourhundred Thecat via Postfix-users <400the...@gmx.ch> is rumored to have said: Hello, I have domain mydomain.com, with mx record: $ host -t mx mydomain.com mail.mydomain.com and I have SPF record on my domain: host -t txt mydomain.com which is the ip address of mail.mydomain.com I have no SPF record on mail.mydomain.com itself. Now, when I check my email score on mail-tester.com, A site that no one should trust, as they actively misrepresent SpamAssassin's usage and scores. it says: SPF_HELO_NONE SPF: HELO does not publish an SPF Record A fact that in fact carries no value judgment. SpamAssassin currently hard-scores that rules at +0.001, meaning that while *in theory* it adds to the "spamminess" metric, it is effectively meaningless in the overall score of almost any particular message. A non-zero score (or usage in a non-zero-score meta-rule) is required for SA to check any rule, so we score some things that users have asked for as possibly informative at -0.001 or +0.001 to assure that they are always checked, even when our QA shows no indication of the rule being in any way useful for determining whether a message is spam or not. One reason for that is the recognition that every site sees a different mail stream. There may be sites where SPF_HELO_NONE could be a helpful discriminant between spam and ham. If we don't peg the score, that possibility is invisible. and lastly, I have smtp_helo_name = mail.mydomain.com Does it mean that I should either: 1) create SPF record for mail.mydomain.com or 2) change smtp_helo_name to smtp_helo_name = $mydomain Neither. You do not have any problem that is worth solving. Believing that every SpamAssassin hit is a "problem" that can or should be "solved" is simply not true. -- 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
[pfx] Re: Different set of milters for one domain?
On 2023-03-28 at 06:10:27 UTC-0400 (Tue, 28 Mar 2023 03:10:27 -0700 (PDT)) Dan Mahoney (Gushi) via Postfix-users is rumored to have said: Hey there all, Dayjob sometimes receives mail for one domain that we'd like to have bypass certain milters (specifically, we want to exempt them from some filtering/scanning mitlers since the domain is pretty much entirely passthrough) -- Is there an easy way to do this in postfix without completely splitting the config up? Short answer: No. The question has come up here multiple times and always gets the same assortment of alternative ideas for how to do what people want... Fortunately, many milters provide the tools to be selective about how to handle different target domains. -- 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
[pfx] Re: Allow TLSv1 only for internal senders
On 2023-03-18 at 09:54:15 UTC-0400 (Sat, 18 Mar 2023 14:54:15 +0100) Gerd Hoerst via Postfix-users is rumored to have said: Hi ! I setup my postfix for the clients to use only protocols > TLSv1 with smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1 smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1 in main.cf Why? but unfortunately i have a sender (its a printer) which is not capable for TLSv1.1 and up.. How can i manage to use TLSv1.1 and up from outside but allow TLSv1 from inside my network What do you believe to be the risk of allowing TLSv1.0 for SMTP? My understanding is that the marginal risks of TLSv1.0 are not relevant to SMTP. It is also inherently counter-productive to prohibit TLSv1.0 if you allow unencrypted SMTP as a fallback. -- 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
