[pfx] Re: Mails ending up in spam when sending to gmail address

[Peter via Postfix-users]

On 16/05/24 23:40, Jaroslaw Rafa via Postfix-users wrote:

Dnia 16.05.2024 o godz. 12:05:52 Peter via Postfix-users pisze:

On my side the email is accepted from here, and relayed, Rspamd
does sign it, and Postfix's last message in the log is a message
sent delivered, and removed from my queue. I check my test Gmail
account, and the message is indeed there, but Gmail has placed it
in the spam folder. I check the headers of said message, an SPF
and DKIM both pass.

I am open to suggestions.


It's probably just IP reputation and you need to let it build up
with google, but see:

https://support.google.com/mail/answer/81126


Not necessarily, it may be as well related to domain reputation. And
sometimes no "build up" can help, Google just "dislikes" you and thinks
you're a spammer.


...


I described the whole story on my blog and was contacted by several people
who said they have the same problem. Also, on the "mailop" mailing list for
mail server operators, similar problems were reported multiple times (I also
of course reported mine there). So neither you nor I are the only one with
this issue...

Now, since maybe a half year, I don't have this problem anymore - so maybe
it is gone for good. But nobody can guarantee that.

We can only say that it's just "Google doing Google things"...


Indeed, at the end of the day google is a black box, they don't tell you 
how their anti-spam system works and it often times doesn't work.


None of this changes the correct approach to take initially.  The above 
link I gave has lots of information directly from google about what they 
say you need to be doing and how to troubleshoot issues and how to 
contact them if need be.  I do realize that there are many many 
instances of people who have jumped through those hoops and have nothing 
to show for it, but unfortunately those hoops is the best answer I can 
give to someone who is having issues.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Mails ending up in spam when sending to gmail address

[Peter via Postfix-users]

On 16/05/24 11:54, David Mehler via Postfix-users wrote:

Hello,

I'm not sure if this is a Postfix or an Rspamd problem or a Gmail 
problem, the first two I can do something about the third one not so sure.


I'm running a personal E-mail server running on a VPS via a2hosting. I'm 
using Cloudflare for my DNS. I've got Postfix 3.7.11 and Rspamd 3.8.4 
going. All appears well on my end, I've got dns MX, a PTR, SPF, DKIM, 
and DMARC with what I thought was abiding by Google's new email sending 
policy so I could get a message through.


On my side the email is accepted from here, and relayed, Rspamd does 
sign it, and Postfix's last message in the log is a message sent 
delivered, and removed from my queue. I check my test Gmail account, and 
the message is indeed there, but Gmail has placed it in the spam folder. 
I check the headers of said message, an SPF and DKIM both pass.


I am open to suggestions.


It's probably just IP reputation and you need to let it build up with 
google, but see:


https://support.google.com/mail/answer/81126


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Different SMTP access/relay control for ipv4 vs ipv6?

[Peter via Postfix-users]

Greetings,

I've been running an ipv4-only postfix system for years, and have dialed 
in a set of SMTP access/relay controls that work well for my use case.


I've avoided enabling ipv6 because its lack had yet to cause an issue, 
and due to what I'm given to understand has been the wild-west nature of 
v6 when it comes to SMTP.


However, it's becoming more desirable to enable v6. The ideal end goal 
would be to use the same general set of controls as v4, but to start off 
I would like to use a more permissive/less restrictive set of controls, 
and initially only enable v6 for receiving (as that's where I anticipate 
the majority of the issues).


I'm not entirely sure how to do this, so I am seeking recommendations & 
guidance.


I looked to see whether the various smtpd__restrictions statements 
could take different actions depending on the address-family of the 
connecting client (within the context of one main.cf file), but so far 
have not found that this is possible.


My reading indicates that I could make an additional smtpd entry for v6 
in master.cf with a different set of -o options than that used by v4 in 
main.cf (inet_protocols = ipv6, inet_interfaces = a:b:c::d, mynetworks, 
smtpd__restrictions, etc).


Am I on the right track with the previous paragraph, or is/are there 
better way(s) to accomplish this?


Sincerely,
Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: hmm spf is missing :)

[Peter via Postfix-users]

On 25/04/24 19:42, Benny Pedersen via Postfix-users wrote:

Peter via Postfix-users skrev den 2024-04-25 09:19:

On 15/04/24 10:14, Benny Pedersen via Postfix-users wrote:
Authentication-Results    list.sys4.de; dkim=pass 
header.d=porcupine.org; arc=none (Message is not ARC signed); 
dmarc=pass (Used From Domain Record) header.from=porcupine.org 
policy.dmarc=none


What does this have to to with Postfix, or even the Postfix mailing 
list?  You're posting headers coming from Wietse's personal email, not 
the list itself.


No, score=-3.3 tagged_above=-999 required=5 tests=[AUTHRES_ARC_NONE=0.5, 
AUTHRES_DKIM_PASS=-0.5, AUTHRES_DMARC_PASS=-0.5, DKIM_SIGNED=0.1, 
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 
MAILING_LIST_MULTI=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.1, 
SPF_PASS=-0.1] autolearn=unavailable autolearn_force=no


I see here a bunch of tests passing (and lowering the SPAM score as a 
result) with the exception of ARC which this says is missing alltogether 
which is puzzling because the list certainly adds ARC headers.  I fail 
to see how this has anything to do with your above claims and only adds 
to the confusion of, "what the heck are you talking about?".


from authres perspective maillists can not be dmarc aligned, we all have 
to live with unalined maillist members


postfix.org appears to be missing a _dmarc record.  This is the only 
reason why it's not DMARC aligned and is not actually a failure.  Both 
SPF and DKIM pass with alignment to the From: header of every message on 
this mailing list, so with the exception of the missing DNS record it is 
certainly DMARC aligned.



dmarc can't be aligned with this missing,
This is just plain wrong.  DMARC will align just fine with SPF missing 
if DKIM is correct and signed by the From: header domain.


i am not sure with this, maybe you will enligtment me on this case ?


https://datatracker.ietf.org/doc/html/rfc7489#page-13

"A message satisfies the DMARC checks if at least one of the supported 
authentication mechanisms:..."


"One of" means that either SPF *or* DKIM has to pass and be in 
alignment, not both of them.  If you have have some app that is 
reporting DMARC failure because SPF is missing even though DKIM passes 
and is in alignment then that app is wrong.


not specifik anyone here, its imho just a fail that does not exits on 
dovecot maillist if you note the diffrent ?


I'm not going to go comparing the two lists.  I don't have problems with 
any messages from this list failing, and my analysis shows me that they 
are all correct.


The list software re-signs the message from postfix.org and the 
envelope sender and From: header are all changed to postfix.org so 
it's all in alignment.


resigns is a workaround on maillist that breaks dkim on purpose, if 
maillist or plain forwarders did not break dkim we won't need arc to fix 
any problems


Re-signing doesn't break DKIM, the DKIM is broken because certain 
headers and the body are changed.  Neither is it a workaround, it's 
simply taking ownership of the message as if the list server is the 
originator and as such the reputation of the list server becomes 
attached to the message instead of the original sender.


Just to be clear, both porcupine.org and postfix.org have SPF and DKIM 
policies and Wietse's messages pass both when passing through the list.


this is fine, but arc sign, arc seal does not care on direkt mails


The list ARC signs messages as well.  There is no reason for a message 
that is direct from the original sender to be ARC signed as


spamassassin DKIM_VALID_EF is maybe just a hack to track dmarc aligment 
without dmarc at all ? :=)


DKIM_VALID_EF tracks the *envelope* From alignment, which is different 
to the From: header alignment.  The envelope From alignment does not 
affect DMARC.


i just hope postfix.org and sys4 does as best as dovecot maillist do 
with spf


*Sigh*  ...and yet you cannot even show an actual problem.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Which DKIM application for postfix 3.9.0

[Peter via Postfix-users]

On 25/04/24 14:34, Benny Pedersen via dovecot wrote:

+1, thanks for dovecot maillist do it right, postfix maillist fails on spf


You make a confusing, factually incomplete post with claims that are 
incorrect and then complain about a lack of clear response on a 
different list?  If you're going to run down the postfix list for your 
own failure at least have the decency to do it *on* the postfix list.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: hmm spf is missing :)

[Peter via Postfix-users]

On 15/04/24 10:14, Benny Pedersen via Postfix-users wrote:
Authentication-Results    list.sys4.de; dkim=pass 
header.d=porcupine.org; arc=none (Message is not ARC signed); dmarc=pass 
(Used From Domain Record) header.from=porcupine.org policy.dmarc=none


What does this have to to with Postfix, or even the Postfix mailing 
list?  You're posting headers coming from Wietse's personal email, not 
the list itself.



dmarc can't be aligned with this missing,


This is just plain wrong.  DMARC will align just fine with SPF missing 
if DKIM is correct and signed by the From: header domain.


i just complain for the 
authres in spamassassin can't see this detail


Unless you're referring to a message that Wietse sent you directly then 
these headers don't even apply to the mailing list.  The list software 
re-signs the message from postfix.org and the envelope sender and From: 
header are all changed to postfix.org so it's all in alignment.


Just to be clear, both porcupine.org and postfix.org have SPF and DKIM 
policies and Wietse's messages pass both when passing through the list.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Update: What features to deprecate

[Peter via Postfix-users]

On 21/02/24 12:40, Wietse Venema via Postfix-users wrote:

Peter via Postfix-users:

A quick status update.

First, several features have been logging warnings that they would
be removed for 10 years or more, so we could delete them in good
conscience (perhaps keeping the warning with the suggested alternative).
This change has not yet been made.


Note that this IS a breaking change: features are removed. But
there have been warnings for 10+ years that this was coming.


Right, this is the main reason why I think that releasing as 4.0 would 
be appropriate.  I do realize that these features have been deprecated 
for a long time but still they are, as you say, breaking changes and so 
releasing as 4.0 will help a lot to distinguish that.



Next, I have added new warnings for the following features, so that
they can be removed some 5 years down the road.

...

The present state is in postfix-3.9-20240218. I have slienced the
noisy warnings for deprecated and unused configuration parameters
so that they are not logged while upgrading or installing Postfix.
The warnings are still logged, once, with postfix start, start-fg,
check, reload, or status.


Just a quick thought here.  I think it would make sense to release this
as Postfix 4.0 since removing and deprecating a large number of features
should probably be considered quite a major change.


I'm not sure that I follow. This is not a breaking change. it just logs
a reminder that there will be a breaking change a few years from now.


I didn't mean to imply that these are breaking changes.  Simply taking 
the whole of these changes into account along with the breaking changes 
above seems to lend support to releasing as 4.0.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Update: What features to deprecate

[Peter via Postfix-users]

On 19/02/24 14:00, Wietse Venema via Postfix-users wrote:

Viktor Dukhovni via Postfix-users:

On Tue, Feb 13, 2024 at 12:23:32PM -0500, Wietse Venema via Postfix-users wrote:


Over 25 years, Postfix has accumulated some features that
are essentially obsolete.


A quick status update.

First, several features have been logging warnings that they would
be removed for 10 years or more, so we could delete them in good
conscience (perhaps keeping the warning with the suggested alternative).
This change has not yet been made.

...

Next, I have added new warnings for the following features, so that
they can be removed some 5 years down the road.

...

The present state is in postfix-3.9-20240218. I have slienced the
noisy warnings for deprecated and unused configuration parameters
so that they are not logged while upgrading or installing Postfix.
The warnings are still logged, once, with postfix start, start-fg,
check, reload, or status.


Just a quick thought here.  I think it would make sense to release this 
as Postfix 4.0 since removing and deprecating a large number of features 
should probably be considered quite a major change.



Peter
___
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?

[Peter via Postfix-users]

On 12/02/24 11:47, Alex via Postfix-users wrote:
My concern would be with multiple MX records for the same domain - is it 
possible it would come back to try again with another MX and be delayed 
yet again?


Unless you're referring to your own MX records these are not relevant. 
That said, many providers do use multiple different servers and IPs for 
MX connections and this can be an issue.  This is the primary reason why 
after-220 tests in postscreen are rather controversial.  There are some 
ways to help mitigate this issue but no golden bullet.


If you're referring to your own MX servers you can share the internal 
whitelist cache (see postscreen_cache_map).


The sqlgrey perl script has the ability to consult a database to see if 
enough time has elapsed as well as cluster servers to see if the client 
has attempted a connection to one of the other MX servers. I'm not sure 
I ever managed to set it up successfully, however.


Right, postscreen has similar functionality to greylisting, but since it 
has a different goal there are some features of postgrey that aren't 
present in postscreen.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Understanding log entries

[Peter via Postfix-users]

On 11/02/24 13:51, Doug Hardie via Postfix-users wrote:

If I am understanding correctly, that means that if I set smtp_skip_5xx_greeting to 
"no", then postfix would stop after the first 5xx and terminate the email.  
That seems like it might open up some issues where a provider with multiple MTAs might 
have one in problem state, but the others working fine.  If postfix tried the problem MTA 
first, the email would never get delivered.


Right, and further to that a 554 response at connection time is a 
rejection of the *connection*.  No attempt was ever made to send the 
*message*, so in a manner of speaking the message is still valid and a 
different connection might accept it (e.g. by attempting a different 
MX).  An MTA that wants to reject the message should should wait until 
after the RCPT TO command to reject the actual message.



Peter
___
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?

[Peter via Postfix-users]

On 10/02/24 02:50, Matus UHLAR - fantomas via Postfix-users wrote:

On 08.02.24 13:05, Doug Hardie via Postfix-users wrote:
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. 


It does not introduce _this_ kind of delay, because it was the main 
reason for noticeable delays of incoming mail I mentioned in my last 
e-mail.


Yes it does, just not by default.


It has multiple benefits against bots, like:
- few seconds delay for refusing clients that send helo/ehlo before 
esmtp greeting (I have used this for years with sendmail)

- dnwsl/dnsbl scoring system.

These are pretty safe to use.


These are the tests that are enabled by default.  If you also enable the 
other after-220 tests then postscreen will, after whitelisting the 
connecting IP, give a 450 response which tells the sending server to 
defer (disconnect and try again later).  This is very similar to how 
greylisting works.



Peter
___
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?

[Peter via Postfix-users]

On 8/02/24 21:38, Kees van Vloten via Postfix-users wrote:
A little addition that also helps a bit: move the content of the From: 
header to the Reply-To: header and replace From: with the local account 
that is forwarding the message. All mail then originates from your 
domain and a reply to a forwarded message will go to the original sender.


This is what many mailing lists (including this one) do nowadays, but 
unfortunately it has a downside, it will almost certainly break the DKIM 
signature, meaning that if you do this you will probably need to also 
remove the original DKIM signature then re-sign the message yourself. 
At the point you are legitimately telling other server that the message 
does indeed originate from you and it makes the consequences of 
forwarding SPAM even worse than they already were.


For general forwarding of mail I really wouldn't recommend this approach.


Peter
___
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?

[Peter via Postfix-users]

On 8/02/24 14:23, Alex via Postfix-users wrote:
I'm hoping I could ask for some advice. We have a pretty 
large percentage of users who forward mail through our systems to 
personal Gmail accounts. Sometimes it is mail from bulk senders like 
mailgun and lanyon/cvent.


Before answering your actual questions I'll give a quick note of 
caution.  When you forward mail that means you will also forward SPAM. 
To at least some servers this makes it at least appear as if SPAM is 
originating from your server and could result in your servers' IP 
address(es) being added to DNSRBLs.  That said...



Would ARC help here,


It won't hurt, and Google seems to be advising to use it for forwarding. 
 ARC is basically telling the recipient's MTA that your MTA 
legitimately received the message and indicating whether it passed or 
failed SPF, DKIM and DMARC to your server.  Do note that ARC requires 
that the recipient server somehow trusts your server so it does mean 
that you're taking some amount of responsibility for the messages you're 
forwarding and the quality of those messages could determine how much 
other servers will accept your ARC results.


or is DKIM enough for DMARC alignment with 
forwarded messages?


It can be, but this depends entirely on the message being properly DKIM 
signed by the original sender, something which is entirely out of your 
control, so it's safe to say that not all messages will pass DMARC 
because of DKIM because not all senders will have DKIM properly 
configured, or configured at all.  Also DKIM relies on you not altering 
any of the message headers or body used for the signature, so your own 
server could potentially invalidate the DKIM signature even if it is 
initially valid.  You can sign the messages yourself but that won't help 
for DMARC alignment because DMARC requires a DKIM signature that is 
signed by the From: header domain in order to accept it.


Perhaps ARC will help in those cases where DKIM 
fails with forwarded messages?


Again, it might, it depends on the recipient MTA.

Is it used on the sending server or on 
the relay?


DKIM has to be signed by the original sender, ARC is signed by the relay 
(you).


Is it installed using a milter alongside openSPF/DKIM 
using openarc?


It can be, yes.

I've also thought about implementing SRS over the years, but it has its 
own problems, so I wondered if people were still implementing that?


SRS is simply changing the envelope sender so it aligns with one that 
you control.  It allows SPF to pass but won't help with DMARC because 
your domain will not align with the From: header in the message.


My recommendations are as follows (other people's recommendations will 
vary):


1.  Don't forward mail.

2.  If you must forward mail then relay it using a different IP address 
to mail that originates from you, that way if the IP gets added to a 
DNSRBL it at least should hopefully not affect the mail that you originate.


3.  SPAM-filter mail before you forward it, be aggressive with this as 
you really don't want to be forwarding SPAM.  Note that some SPAM will 
still get through.


4.  ARC sign your forwarded mail.

5.  Use SRS on forwarded mail.

This is in addition to all the other things you do for mail that you 
originate (SPF, DKIM, DMARC, etc).


Good luck,


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Documentation on upgrade 2.10 to 3.5

[Peter via Postfix-users]

On 25/01/24 04:38, Bill Gee via Postfix-users wrote:

Oops!  I just realized that I sent this instead of saving it.  Dang!


I've re-organized the quoted section to put your questions in their 
intended order.


The time is finally coming when I have to do something with my Postfix 
server.  I have several questions for the group.


Background - Currently I have Postfix 2.10.1 running on CentOS7.  It 
is rock-solid.  If not for the coming EOL on CentOS7 I would leave it 
alone.


Indeed CentOS 7 is very near to EOL.  If you want you can upgrade CentOS 
7 to the latest version of Postfix using the packages available from the 
GhettoForge repositories, but I would not recommend it at this stage.


 The upgrade target I have chosen is AlmaLinux 9 which packages 
PostFix 3.5.9.  This will be an in-place upgrade using ELevate and leapp.


Be careful with Elevate (and leapp) they are the best tool available to 
do an in place upgrade, but there will almost certainly be issues with 
the new system just due to the many many changes between major RHEL 
releases.  I've seen issues crop up from Elevate-upgraded systems years 
after the upgrade.  I tend to recommend doing a new install instead.


I should also note that if you're interested in features beyond postfix 
3.5 (which is almost EOL itself) then you can get current postfix 
packages which install on all RHEL-derived distributions (including Alma 
Linux) from the GhettoForge repos.


1) Is there any documentation about moving from Postfix 2 to 3?  I 
looked on the web site but saw nothing obvious.


Viktor already covered the release notes.  The main thing I would 
recommend that you be aware of is that Postfix versions greater than 3 
have support for dynamic maps.  This means that packages (including Red 
Hat) now require that you install separate packages for certain map 
types, e.g. postfix-mysql if you want mysql support.  The real upside of 
this approach is that you don't end up having to install all the libs 
and other deps for all the map types that you *don't* want.


2) The leapp output mentions a compatibility option.  I think I need 
to use that.  Is there documentation on it?


This has already been well covered by Viktor.

3) Would it be useful to set up a test machine (of which I have 
several) and try the configuration files on it?  I think there is no 
good way to actually run messages through it, but I can at least see 
if the Postfix service starts.


Postfix backwards-compatibility is very good.  If you change nothing in 
the config odds are quite good that Postfix will still start up and run 
(see the note about dynamic maps above, though).  That said, it's never 
a bad idea to do some testing.


> 4) Probably not a PostFix question, but it is related.  One big reason
> for doing an in-place upgrade is because I do not know how to move my
> mailbox from the old server to something new.  Is that just a matter of
> copying a $HOME directory?

Indeed this is more of a Dovecot question.  I would recommend setting up 
dovecot on the new server and copying over your mailboxes, then see if 
you can log in and retrieve the mail.  You may also want to take the 
opportunity to convert to a new mailbox format, or locate the mailboxes 
differently, which would best be done through the tools provided by 
dovecot as well.


> I hate to mess with a working system.  The current setup is not broken.
> The server has almost 300 days of uptime on it

The day is long gone where bragging about long uptimes is a good thing. 
You should be running regular updates and rebooting after each.  I 
personally update servers once a month unless I deem a particular 
vulnerability bad enough to do an upgrade right away.


> and has been running for
> most of ten years.  Looking forward, though, I see in a year or two
> CentOS7 might become less and less usable, in much the same way that
> Windows XP is pretty much unusable now.  I want to get ahead of that 
curve.


Sooner than that, CentOS 7 will go EOL on 30 June of this year, so just 
a few months away.  CentOS 7 will not be receiving any updates after 
that date.


> It is probably worth noting that I have now converted all of my CentOS
> systems except the email server to AlmaLinux 9 using ELevate.  There
> were a few glitches along the way, but it did work.  The converted
> systems were a mix of CentSO7, 8 Stream and 9 Stream.  Only one of them
> has any significant workload (VirtualBox host).  The others are all test
> beds.

Glad to hear you've upgraded nearly all of your machines, though I would 
have recommended a different approach to Elevate (as stated above).



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postfix repo

[Peter via Postfix-users]

On 16/01/24 17:26, Scott Kitterman via Postfix-users wrote:

As many are aware Ghettoforge builds these for EL.  To me the simplest way for 
Debian and other distros is for a community member to take up the mantle and 
build Postfix in a similar way.  It's not that difficult to do and it puts the 
responsibility on someone who is genuinely interested in that particular 
platform instead of putting the responsibility on Wietse to try to build binary 
rpms for every distro under the sun.


You can actually install RPMs on Debian systems, but it would be a pretty 
unusual way to go about things.


The reverse is also possible (installing debian packages on an RPM-based 
distro) but I really don't recommend it (in either direction) as it 
fails to take into account differences in the distributions themselves. 
Dependencies are named differently, and postfix will be built with 
different library versions or different libraries entirely (e.g. you may 
be trying to install a postfix built against openssl 3.0 on a system 
that has openssl 1.1 and it would likely fail spectacularly).  In fact 
you would see this exact issue if you tried to install the postfix built 
for EL9 onto EL7.



 I think for almost every one, the Debian stable updates that we provide should 
be sufficient.  For those that actually need the latest release, it's trivial 
to grab the Debianized source from a later release and build it for an earlier 
release.


Coming from the Red Hat side of things I doubt it's any more difficult 
to build for Debian than it is for Red Hat based systems, but even so I 
would argue that if one person is going to go to the work to do that why 
not share it with everyone else so that multiple people don't have to 
re-produce the same work?  At any rate, it's really up to someone in the 
Debian community to step up and do that, and I'm not trying to volunteer 
you for the job, it could be anyone, even someone who doesn't know much 
about packaging could take it as a good learning opportunity and Postfix 
is one of the easier programs to build in my experience.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postfix repo

[Peter via Postfix-users]

On 12/01/24 04:08, Wietse Venema via Postfix-users wrote:

Viktor Dukhovni via Postfix-users:

On Thu, Jan 11, 2024 at 03:53:35PM +0100, natan via Postfix-users wrote:

Hi Wietse Have you thought about postfix repo for Debian, just like dovecot
has for his relase ?



What is a "Postfix repo for Debian"?  Do you mean binary release
packages?  What's wrong with the packages from the Debian maintainers?


If he means Postfix distributing BINARY packages for Debian, RedHat,
*BSD, and so on, then I do not expect that to happen.


As many are aware Ghettoforge builds these for EL.  To me the simplest 
way for Debian and other distros is for a community member to take up 
the mantle and build Postfix in a similar way.  It's not that difficult 
to do and it puts the responsibility on someone who is genuinely 
interested in that particular platform instead of putting the 
responsibility on Wietse to try to build binary rpms for every distro 
under the sun.



Peter
___
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

[Peter via Postfix-users]

On 3/01/24 01:27, Peter via Postfix-users wrote:
There is a link at the bottom to the postfix-specific lmtp configuration 
page which is broken, it means that page was not properly ported. Please 
post to the dovecot mailing list and let them know as this is something 
they need to fix.


In the meantime...

https://web.archive.org/web/20221231043420/https://wiki.dovecot.org/HowTo/PostfixDovecotLMTP


Peter
___
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

[Peter via Postfix-users]

On 1/01/24 07:52, Togan Muftuoglu via Postfix-users wrote:

The good old Dovecot Wiki is gone.


The pages have been ported over to doc.dovecot.org:

https://doc.dovecot.org/configuration_manual/protocols/lmtp_server/

There is a link at the bottom to the postfix-specific lmtp configuration 
page which is broken, it means that page was not properly ported. 
Please post to the dovecot mailing list and let them know as this is 
something they need to fix.



Peter
___
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

[Peter via Postfix-users]

On 1/01/24 06:25, toganm--- via Postfix-users wrote:

The master.cf has already the following so what am I adding?

lmtp  unix  -   -   n   -   -   lmtp


Nothing, that is all that is required.  The docs simply mean that entry 
is required but you don't have to change or add to it.



Peter
___
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

[Peter via Postfix-users]

This doesn't help much, except to show that things look good for protonmail.

Protonmail doesn't appear to have IPv6 support while google does.  It is 
entirely possible that you're trying to send to google via IPv6 and you 
don't have an  record for mail.bristolweb.net.  This would result in 
SPF failing when an IPv6 connection is established.


This, of course, is just a WAG.  If you want someone to review the 
issues with google then you'll need to show headers and/or logs from the 
connection to google.  Protonmail headers doesn't really help for this.



Peter


On 28/11/23 05:50, Linkcheck via Postfix-users wrote:
I know that comment was not aimed at me but: I meant to include the 
protonmail header at the outset but forgot. Sorry. Below is all the 
header except protonmail's anti-spam section; I hope it helps.


==
Return-Path: 
X-Original-To: linkch...@protonmail.com
Delivered-To: linkch...@protonmail.com
Authentication-Results: mail.protonmail.ch; dkim=pass (Good 2048 bit
     rsa-sha256 signature) header.d=linkcheck.co.uk header.a=rsa-sha256
Authentication-Results: mail.protonmail.ch; dmarc=pass (p=reject
     dis=none) header.from=linkcheck.co.uk
Authentication-Results: mail.protonmail.ch; spf=pass
     smtp.mailfrom=linkcheck.co.uk
Authentication-Results: mail.protonmail.ch; arc=none
     smtp.remote-ip=185.35.151.121
Authentication-Results: mail.protonmail.ch; dkim=pass (2048-bit key)
  header.d=linkcheck.co.uk header.i=@linkcheck.co.uk header.b="aME9BZCV"
Received: from mail.bristolweb.net (mail.bristolweb.net 
[185.35.151.121]) (using TLSv1.2
  with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client 
certificate
  requested) by mailin029.protonmail.ch (Postfix) with ESMTPS id 
4Sf5mk3JF0z9vNQc for

  ; Mon, 27 Nov 2023 13:20:22 + (UTC)
Received: from bristolweb.net (unknown [185.35.148.202]) (using TLSv1.2 
with cipher
  ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate 
requested) by

  mail.bristolweb.net (Postfix) with ESMTPSA id 3C22E320306 for
  ; Mon, 27 Nov 2023 13:20:13 + (GMT)
Dkim-Filter: OpenDKIM Filter v2.10.3 mail.bristolweb.net 3C22E320306
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkcheck.co.uk; 
s=mail;

  t=1701091213; bh=S5/3sqlIYmgIYOvNb2ssVfXYaWT2GE56yHcXn92FzLc=;
  h=Date:To:From:Reply-To:Subject:From;
  b=aME9BZCVwQl1Dqp2qfjODGJpk6O40QkJVPwTd8lYpx2RJIbCgQxga0bDZQPeP/HQv
   t7TcyAC3spO0qI0STwEqgDTdv26WsLMNtKNP2Bwjy/WtKqA0PAKIQ3ccQo8pWE1OvL
   0DgCcd+vvGea8x+xej8E4lxVNOcLRapqgIW9Rosocjo5MlQ0pRiREbL4Bbth9gIXTr
   dL1VCSHA9ihF/aiRI+zIhehL+sA0tqoZOH1j+LNOjSVnMuaO6Mnph/gyR9de8aGZtc
   h/YgRaT2MVLNf6ntsk6qRKzuTJ2/9XKr71uotxbKAHLn6HzzB9nXoPPRvxGMn2obRR
   Fif83WWl/CJ7w==
Date: Mon, 27 Nov 2023 13:20:13 +
To: Dave Stiles 
From: EnquiryForm 
Reply-To: EnquiryForm 
Subject: Linkcheck Enquiry: Ref LK_XK27131943E
Message-Id: 
X-Mailer: BW-4
X-Originating-Ip: 46.33.129.43
X-Form-Host: www.linkcheck.co.uk
X-Complaints-To: abuse (at) bristolweb.net
Mime-Version: 1.0
Content-Type: text/plain
==

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: [off-topic] aarch inclusion in Linux distros (was: IPv6 and Cloud server CPU)

[Peter via Postfix-users]

On 24/11/23 19:52, Peter via Postfix-users wrote:
It's not the distro.  It's common for Linux distros to fully support 
ARM, but that does not put any obligation on 3rd-party distros, just 
like if someone were to create a 3rd-party distro for BSD it would be up 
to them to decide which arches they want to support and that does not 
reflect on the support by the distro itself.


That was meant to say "3rd party repos", not distros.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] [off-topic] aarch inclusion in Linux distros (was: IPv6 and Cloud server CPU)

[Peter via Postfix-users]

On 23/11/23 21:08, Charles Sprickman via Postfix-users wrote:

This ^.  Specifically if you want to run an EL distro there are good 
choices that offer ARM support and come with stock postfix and dovecot 
packages, but if you want to run the GhettoForge packages (which have newer 
versions of Postfix and Dovecot than that offered by the stock distros) then 
I'm afraid you're stuck with x86_64 for now.  Similarily you might have issues 
with other supporting software that is only available from 3rd-party repos or 
where 3rd-party repos have newer versions taht you want to use, but not for ARM.


Is this a common thing with Linux distros? I've not dabbled there in ages, but on the 
various *BSDs they tend to have a designation for each architecture, for example FreeBSD 
at some point moved most ARM variants to "Tier 1" which generally means there's 
parity with x86 for the average user.


It's not the distro.  It's common for Linux distros to fully support 
ARM, but that does not put any obligation on 3rd-party distros, just 
like if someone were to create a 3rd-party distro for BSD it would be up 
to them to decide which arches they want to support and that does not 
reflect on the support by the distro itself.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: IPv6 and Cloud server CPU

[Peter via Postfix-users]

On 23/11/23 14:22, Gerald Galster via Postfix-users wrote:

Q2:
given the minuscule work-load, is there any preference/preclusion 
between employing the 'usual' x86 processor or 2 Arm Ampere 
processors? Both offer Linux. Cost is effectively same.


You should check if the software you want to use is available
for the desired platform. Distributions might provide dovecot
packages for ARM while the official dovecot repository might
not. Then you would have to compile the sources yourself.


This ^.  Specifically if you want to run an EL distro there are good 
choices that offer ARM support and come with stock postfix and dovecot 
packages, but if you want to run the GhettoForge packages (which have 
newer versions of Postfix and Dovecot than that offered by the stock 
distros) then I'm afraid you're stuck with x86_64 for now.  Similarily 
you might have issues with other supporting software that is only 
available from 3rd-party repos or where 3rd-party repos have newer 
versions taht you want to use, but not for ARM.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: GMail is rejecting mail I forward

[Peter via Postfix-users]

On 30/10/23 05:43, Robert Inder via Postfix-users wrote:
For 10 years now I've been running a Linux (CentOS 7) server, using 
Postfix to handle mail for a handful of users.
Specifically, I'm running Postfix 2.2, because that is the most recent 
version yum will fetch

from the current/default set of repositories.


CentOS 7 comes with Postfix 2.10.1.  If you want to update to the latest 
postfix in CentOS 7 you can get it from the ghettoforge repositories 
(see: http://ghettoforge.org/index.php/Postfix3) which currently has 
Postfix 3.8.1 for CentOS 7.


If you're really running 2.2 as you say, you would have to be running an 
EOL operating system to be running such an old version of postfix. 
CentOS 4 is the most recent version of CentOS which shipped with Postfix 
2.2 and it went EOL in February of 2012. If you're running CentOS 4 then 
you haven't gotten any updates for well over ten years and it will be 
very full of several major security vulnerabilities, not just in postfix 
but throughout your operating system.


Some users want to use GMail, so I have used an alias (in an aliases 
file) to forward their mail to their GMail account, making

        person at my.domain
an alias for
   same_person at gmail.com 

Recently, users have told me they have discovered that mail has not 
reached them because it was rejected by GMail.


The rejection mail I have seen says GMail rejected the message because 
the IP address of my server did not pass

DKIM or SPF for the source of the email.


You have discovered one of the primary issues with forwarding mail.  The 
other one is that any SPAM that you inadvertently forward will be 
attributed to your server and it can get blocklisted as a source of SPAM.


I have set up SPF for my domain, but I don't think that is relevant to 
FORWARDING mail (is it?).


No, since you're forwarding mail with an envelope sender from other domains.


So I'm not sure what to do next.


My best recommendation is to allow POP3 retrieval of messages (dovecot, 
courier, as well as several other agents offer POP3 services).  Then 
gmail has a setting where it can be configured to fetch messages via 
POP3 from the connection.  This should bypass all of the google SPAM 
filters and allow retrieval into the user's mailbox directly without 
having to forward.



Do I have to set up DKIM?


No, but it's now recommended to help with deliverability, as well as 
several other things.



Can I do that with Postfix 2.2?


Milter support, which is generally what is used for DKIM signing, was 
first introduced in Postfix 2.3, so probably not.  If you're running 
Postfix 2.10 then you'll be fine, although updating to 3.8.1 from 
Ghettoforge would not be a bad idea.  Also keep in mind that CentOS 7 is 
very close to EOL as well (CentOS 7 is due to go EOL on 30 June of next 
year), you should plan to migrate to a new OS now.  If you want to stay 
on the EL track I recommend Rocky Linux or Alma Linux as CentOS no 
longer provides a stable Linux platform beyond CentOS 7.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: UGFzc3dvcmQ6

[Peter via Postfix-users]

On 13/09/23 12:54, DL Neil via Postfix-users wrote:

Have been updating the .cf files (mostly ciphers, but also...)

Our old friend "UGFzc3dvcmQ6" is back.


This is simply base64 for "Password", all it indicates is an invalid 
login attempt using the LOGIN mech.


What is the setting to get rid of these dozens of false-attempts from 
diverse IPaddresses, please?


Disable the LOGIN mech?


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: configure a relayhost

[Peter via Postfix-users]

On 11/09/23 19:59, François Patte via Postfix-users wrote:

And updated the security level to "secure".


If I turn this to "secure", I get in maillog file:

server certificate verification failed for
smtp.gmx.com[212.227.17.174]:465: num=62:hostname mismatch


The cert is signed for mail.gmx.com, either change the relayhost setting 
to reflect this or create a new cert that also includes smtp.gmx.com.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How can I set up a very simple postfix server

[Peter via Postfix-users]

On 23/08/23 11:58, Steffen Nurpmeso via Postfix-users wrote:

"The problem" (i have given up and did not try it for long) is the
configuration directory.  Does this work without configuration
directory?  I had to try again.

So last i tried.
If you do not compile custom, but still want a custom
configuration (directory), you need command line options.


Or you can set the MAIL_CONFIG environment variable, which should be 
easy enough to do system-wide.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How can I set up a very simple postfix server

[Peter via Postfix-users]

On 22/08/23 22:59, Peter via Postfix-users wrote:

You forgot:

smtpd_tls_auth_only = no


Sorry, scratch this last bit, it's only if you need to do AUTH without 
TLS, and I don't think you're trying to do AUTH here.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: How can I set up a very simple postfix server

[Peter via Postfix-users]

On 22/08/23 15:42, Bruce Dubbs via Postfix-users wrote:
I have built postfix-3.8.1 from source and want to use it only on the 
local system. That is, I really only want it to receive messages from 
applications like sudo, cron, or some simple scripts using mailx and 
post it to the local user's mailbox.


You've already over-complicated it.  For starters building from source, 
while admirable, is almost certainly not going to be required for the 
simple use-case you have.  I would just install the postfix that your 
distro packages for you, it may be an older version but nothing you are 
doing requires the latest bleeding-edge version of postfix, or anything 
near to it.



My problem is that postfix keeps rejecting the messages.  For instance:

bdubbs@pippin120$ mail -s test root
smtp-server: 530 5.7.0 Must issue a STARTTLS command first
"/home/bdubbs/dead.letter" 11/293
. . . message not sent.


This means that mailx has been reconfigured from it's default to attempt 
to use either submission or smtp.  If you want to keep it simple then 
you don't need to do this, just let mailx use the sendmail binary which 
in postfix uses the postdrop command and mail gets picked up by the 
pickup service, all of which are enabled and properly configured by default.



I have tried several options, but nothing seems to avoid this situation.

I've changed the default master.cl to have:

smtp  inet  n   -   n   -   -   smtpd
   -o smtpd_tls_security_level=none
   -o smtp_tls_security_level=none
   -o smtpd_sasl_auth_enable=no


I would comment this section out entirely, you do not need nor should 
you be using port 25 smtp unless your postfix instance is going to 
receive mail from other servers on the internet.



127.0.0.1:submission inet n -   n   -   -   smtpd
   -o smtpd_tls_security_level=none
   -o smtp_tls_security_level=none
   -o smtpd_sasl_auth_enable=no


Disabling tls is not a great idea here, but is okay since you're 
limiting it to localhost.  Do keep in mind that you do not need this at 
all if you go by my suggestion above to use the sendmail binary (which 
is properly configured by default).



and main.cf changes:

# myhostname is not a valid internet name, but is in /etc/hosts
myhostname = pippin120.gdc.com
mydomain = gdc.com


These are fine, although not really required or relevant if you're only 
doing delivery to local mailboxes.



inet_interfaces = 127.0.0.1


This is fine, although it's redundant with the specified 127.0.0.1 for 
the submission service above.  It also won't matter if you end up just 
using the sendmail binary as suggested.  That said, you can set this to 
loopback_only or localhost for a bit more flexibility.



mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 192.168.0.0/24, 127.0.0.0/8


If you use the sendmail binary then you can set this to blank (mynetworks=)


# Try to avoid TLS
smtpd_tls_security_level = none
smtp_tls_security_level = none
smtp_sasl_auth_enable = no
smtp_use_tls = no


You forgot:

smtpd_tls_auth_only = no


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: smtp auth on port 25

[Peter via Postfix-users]

On 15/08/23 21:08, Benny Pedersen via Postfix-users wrote:

Peter via Postfix-users skrev den 2023-08-15 10:44:


This is a bad idea for several reasons.  If you want submission use
ports 465 and/or 587 as they are intended.  Don't try to use a service
that is meant for a different purpose for this.


mta to mta can use port 465 or 587 aswell for intended purpose :)


This is incorrect, MTAs should not and will not connect to any port 
other than port 25 for MX traffic.


so its valid if both client and server is maintained from same admin, 
but not if its another maintainer, ihmo this is the diffrent


If you're running both servers and relaying via a non-standard port then 
it's not MX traffic, it's a form of submission or relaying but not MX.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: smtp auth on port 25

[Peter via Postfix-users]

On 15/08/23 12:15, Jon Smart via Postfix-users wrote:

I have disabled port 587/465 to be accessed publicly.


These are the submission and submissions ports, for user submission of mail.


but port 25 must be open to internet for MTA communications.


Port 25 is for MX to MX communication, for a submission host, or some 
other type of relay to push mail to your MTA on teh public internet.



My question is, can external users access port 25 for smtp auth and send
mail then?


This is a bad idea for several reasons.  If you want submission use 
ports 465 and/or 587 as they are intended.  Don't try to use a service 
that is meant for a different purpose for this.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: IP/CIDR based exception in smtpd_sender_restrictions?

[Peter via Postfix-users]

On 14/07/23 16:26, Aban Dokht via Postfix-users wrote:

https://www.postfix.org/postconf.5.html#smtpd_sender_restrictions

check_sender_access type:table


...

Any hints how smtpd_sender_restrictions can be overridden with an IP 
based  hash or cidr table?


/etc/postfix/sender_override.cidr:
1.2.3.0/24 OK
5.6.7.128/25 OK

main.cf:
smtpd_sender_restrictions =
  check_client_access cidr:/etc/postfix/sender_override.cidr
  check_sender_access type:table


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix: running a script on authentication failure

[Peter via Postfix-users]

On 23/06/23 07:05, André Rodier via Postfix-users wrote:
Is there any way, with postfix, to run a script on authentication 
failure, with information like the IP address and the

username passed, for instance.


You can write your script up as a policy daemon and have it listen on an 
inet or unix socket (you can use the spawn daemon for this), then do 
something like this:


smtpd_recipient_restrictions = permit_sasl_authenticated,
 check_policy_service unix:private/policy, reject

The policy service will only be called if sasl auth fails, make sure 
that the policy service returns a response of either REJECT or DUNNO and 
it should be called with all of the relevant info you want.


See SMTPD_POLICY_README, access(5) and spawn(8).


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: SPF questions

[Peter via Postfix-users]

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


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

[pfx] Re: logging strangeness

[Peter via Postfix-users]

On 17/05/23 00:14, mailmary--- via Postfix-users wrote:


I am talking about the authentication email, not MAIL FROM or RCPT TO.


There is no "authentication email".  There is a login username which can 
be just about anything and in your case likely just happens to match the 
user's email address.



hmm, when using the -v parameter, just above the "SASL LOGIN authentication failed: 
UGFzc3dvcmQ6" log entry, I can clearly see the email/password


What you are seeing is the direct SASL data being passed between the MUA 
and Dovecot server via Postfix.  Postfix is not actually aware of what 
this content is, it just blindly passes it back and forth.



thus postfix knows the email address being authenticated BEFORE the error 
message


No it does not (see above).


so why not report the email, instead of a base64 string?


Postfix doesn't actually know what the login username is until after the 
login completes and is reported back to Postfix by the Dovecot server.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: postscreen sends 450 without deep tests

[Peter via Postfix-users]

On 8/05/23 00:27, Wietse Venema via Postfix-users wrote:

After multiple such connnections, postscreen could theoretically
decide that the client is unlikely to ever connect to the primary
MX, but by then the client will likely already have given up, and
postscreen has done no harm.

Postscreen does not have such a counting system.


This could (in theory) be done with a fail2ban (or similar tool) entry 
that monitors the mail log and maintains a table with the IP addresses 
to reject based on the criteria you determine.  The value of this (as 
you already pointed out) is questionable, though.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: inet_interfaces documentation

[Peter via Postfix-users]

On 5/05/23 11:33, Wietse Venema via Postfix-users wrote:

An empty inet_interfaces means that there is no constraint for the
SMTP client source IP address. I am adding some text for that.


I think the question is, what effect does it have on the server 
listening address.  This is from inet_listen.c:


/* .IP addr
/*  The communication endpoint to listen on. The syntax is "host:port".
/*  Host and port may be specified in symbolic form or numerically.
/*  A null host field means listen on all network interfaces.

So I would assume from that setting inet_interfaces to empty has the 
same effect as setting it to all (it will listen on all interfaces)?



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: inet_interfaces documentation

[Peter via Postfix-users]

On 4/05/23 08:31, Wietse Venema via Postfix-users wrote:

Peter via Postfix-users:

Is this behavior of inet_interfaces overridden by smtp_bind_address?
  From the way it's worded it looks to me like the inet_interfaces
setting overrides smtp_bind_address but this isn't clear to me.  Can
that be clarified (one way or the other)?


In the mean time I the text further. It should address that
question.

Wietse

When smtp_bind_address and/or smtp_bind_address6 are not specified,
the inet_interfaces setting may constrain the source IP address for
an outbound SMTP or LMTP connection.


Actually I brain-farted and didn't see that you already specified that. 
Sorry for the noise.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: inet_interfaces documentation

[Peter via Postfix-users]

On 4/05/23 08:31, Wietse Venema via Postfix-users wrote:

Peter via Postfix-users:

Is this behavior of inet_interfaces overridden by smtp_bind_address?
  From the way it's worded it looks to me like the inet_interfaces
setting overrides smtp_bind_address but this isn't clear to me.  Can
that be clarified (one way or the other)?


In the mean time I the text further. It should address that
question.

Wietse

When smtp_bind_address and/or smtp_bind_address6 are not specified,
the inet_interfaces setting may constrain the source IP address for
an outbound SMTP or LMTP connection.


Thanks, that looks perfect.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: inet_interfaces documentation

[Peter via Postfix-users]

Is this behavior of inet_interfaces overridden by smtp_bind_address? 
From the way it's worded it looks to me like the inet_interfaces 
setting overrides smtp_bind_address but this isn't clear to me.  Can 
that be clarified (one way or the other)?



Peter


On 4/05/23 04:48, Wietse Venema via Postfix-users wrote:

I updated the inet_interfaces documentation anmd clarified its
relationship with smtp_bind*_address and system-chosen source IP
addresses.

Wietse

When smtp_bind_address and/or smtp_bind_address6 are not specified, the
inet_interfaces setting may constrain the source IP  address  for  out-
bound  connections over IPv4 and/or IPv6. Support for IPv6 is available
in Postfix version 2.2 and later.

o  When inet_interfaces specifies one IPv4 address, and that is not
   a  loopback  address,  the  Postfix SMTP client uses that as the
   source address for outbound IPv4 connections.

o  Otherwise, the Postfix SMTP client does not constrain the source
   IPv4  address,  and  connects  using a system-chosen source IPv4
   address. This includes the cases where inet_interfaces specifies
   all,  or no IPv4 address, or one IPv4 address that is a loopback
   address, or multiple IPv4 addresses.

o  The same reasoning as above applies to IPv6.

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: body_checks not catching all backscatter

[Peter via Postfix-users]

On 3/05/23 17:51, Ken Peng via Postfix-users wrote:

But anybody can use our (even setup correctly) mailserver as backscatter source?


Not if you configure postfix properly.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: body_checks not catching all backscatter

[Peter via Postfix-users]

On 28/04/23 03:59, Sebastian Wiesinger via Postfix-users wrote:

Hi everyone,

I'm not sure if I'm missing something but I can't find out why my
body_checks doesn't catch all the backscatter I'm getting right now.


Oh yuck.

I've found that the best way to block backscatter is by using the 
backscatter DNSRBL.  Make sure you follow the instructions for setting 
it up properly:


https://www.backscatterer.org/?target=usage

If used correctly it will only block DSNs from known backscatter sources.


Peter
___
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

[Peter via Postfix-users]

On 28/04/23 21:19, Andreas Cieslak via Postfix-users wrote:

Why are To and From replaced in the header but not the subject?
Am I perhaps missing the right expression here and could someone give me 
some advice?

Or is there really no way around Mailmunge or MimeDefang etc.?
Any hints would be appreciated.


Others have already answered this.  header_checks operates on only ONE 
HEADER AT A TIME.  If you match the To: header then the REPLACE 
operation replaces the To: header with whatever you put in the 
replacement text, so when you are trying to replace the Subject header 
you are literally replacing the To: header in the message with a second 
Subject: line thereby resulting in a message with no To: header and two 
Subject: headers.  The way that this is treated in the email client is 
very much undefined.


The only way to accomplish what you want is with either a milter or a 
content filter.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: www.postfix.org certificate expired

[Peter via Postfix-users]

On 22/04/23 22:18, Ralph Seichter via Postfix-users wrote:

* Peter Ajamian via Postfix-users:


Verify return code: 10 (certificate has expired)


Thanks. For some reason, the web server had not been restarted after the
last certificate update, which normally happens automatically. I just
restarted the server process manually.


Fixed now.

You should set a POST_HOOK in certbot renew (assuming you're using 
certbot, that is) that restarts or reloads the web server.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question to reject_rbl_client zen.spamhaus.org

[Peter via Postfix-users]

On 10/04/23 16:52, tom--- via Postfix-users wrote:
The default_action here actually defines what action postfix will take 
if the policyd errors out (e.g. not running).  By default this is "451 
4.3.5 Server configuration problem" which results in a deferral, so it 
would not cause the message to pass by default but rather to defer. 
That said, there is nothing wrong with this setting if that's what you 
actually want to happen if the policyd isn't working.




I was thinking the python version configuration for policyd-spf maybe 
have bugs.


If that's the case this won't solve it.  If policyd-spf was returning 
something invalid that caused postfix to use this setting then as I 
stated before the default would be a 451 deferral, not a 2xx or OK 
response as you indicated is happening.  The fact that you haven't been 
getting lots of mail deferred shows that this isn't the case.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question to reject_rbl_client zen.spamhaus.org

[Peter via Postfix-users]

On 10/04/23 14:21, tom--- via Postfix-users wrote:

I have resolved the issue by:

1. install unbound as dns resolver locally


This is good.


2. change this statement:
    check_policy_service unix:private/policyd-spf,
   to this one:
    check_policy_service { unix:private/policyd-spf, 
default_action=DUNNO },


The default_action here actually defines what action postfix will take 
if the policyd errors out (e.g. not running).  By default this is "451 
4.3.5 Server configuration problem" which results in a deferral, so it 
would not cause the message to pass by default but rather to defer. 
That said, there is nothing wrong with this setting if that's what you 
actually want to happen if the policyd isn't working.



now it works perfectly.


Excellent, glad you were able to work it out.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question to reject_rbl_client zen.spamhaus.org

[Peter via Postfix-users]

On 9/04/23 23:02, Peter via Postfix-users wrote:

On 9/04/23 21:23, tom--- via Postfix-users wrote:
I am using the policyd-spf by default configuration (never changed a 
line), and this is the doc:

https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html

But the doc says noting about "OK" and "DUNNO". so how?


Not sure, but since you identified that you are using Google DNS chasing 
this is likely going to be a red herring, it probably already returns 
DUNNO anyways.


Pretty sure it's not going to be policyd:

peter@linux:~/postfix/postfix-policyd-spf-perl$ grep DUNNO 
postfix-policyd-spf-perl

my $DEFAULT_RESPONSE = 'DUNNO';
# Pick whatever response is not 'DUNNO'
if ($response and $response !~ /^DUNNO/i) {
return 'DUNNO' if ( ( ! defined( $domain ) ) or ( $domain eq '' ) );
return 'DUNNO';
return 'DUNNO';
return 'DUNNO';
peter@linux:~/postfix/postfix-policyd-spf-perl$ grep OK 
postfix-policyd-spf-perl



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question to reject_rbl_client zen.spamhaus.org

[Peter via Postfix-users]

On 9/04/23 21:23, tom--- via Postfix-users wrote:
I am using the policyd-spf by default configuration (never changed a 
line), and this is the doc:

https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html

But the doc says noting about "OK" and "DUNNO". so how?


Not sure, but since you identified that you are using Google DNS chasing 
this is likely going to be a red herring, it probably already returns 
DUNNO anyways.


If fixing your DNS doesn't solve the issue then temporarily remove the 
line for policyd as I stated earlier and that will tell you if policyd 
is the issue or not.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question to reject_rbl_client zen.spamhaus.org

[Peter via Postfix-users]

On 9/04/23 19:51, tom--- via Postfix-users wrote:
First off make sure that policyd isn't somehow returning an OK (or 
equivalent) response, if you're not sure temporarily remove 
"check_policy_service unix:private/policyd-spf," from your 
restrictions above and see if it makes a difference.


what action code policyd should return for passing the request to next 
check?


"DUNNO", see access(5).


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question to reject_rbl_client zen.spamhaus.org

[Peter via Postfix-users]

On 9/04/23 18:18, tom--- via Postfix-users wrote:
Secondly, and this is *very* important, make certain you are not using 
your ISP's or another public DNS resolver (such as 8.8.8.8).  You 
*must* run your own DNS resolver for DNSRBLs to work properly.


I was exactly using google DNS. Do u mean Google will block queries for 
RBL?


No, as someone else already mentioned, Spamhaus blocks queries from 
public DNS servers such as Google DNS.  Also Spamhaus limits the number 
of queries that can be performed from a given DNS server so even if they 
don't explicitly block it you are sharing that limit with everyone else 
who uses that resolver and will not get reliable results that way.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Question to reject_rbl_client zen.spamhaus.org

[Peter via Postfix-users]

On 9/04/23 14:02, tom--- via Postfix-users wrote:

I have this setting in main.cf:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service unix:private/policyd-spf,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net

When I sent message from a Spamhaus Zen listed IP (this IP not in my 
whitelist), the message still came into system.

it seems    reject_rbl_client zen.spamhaus.org has no effect.
Where should i debug it?


First off make sure that policyd isn't somehow returning an OK (or 
equivalent) response, if you're not sure temporarily remove 
"check_policy_service unix:private/policyd-spf," from your restrictions 
above and see if it makes a difference.


Secondly, and this is *very* important, make certain you are not using 
your ISP's or another public DNS resolver (such as 8.8.8.8).  You *must* 
run your own DNS resolver for DNSRBLs to work properly.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: secondary MX server

[Peter via Postfix-users]

On 2/04/23 09:03, Jaroslaw Rafa via Postfix-users wrote:

Dnia  1.04.2023 o godz. 13:04:30 Peter via Postfix-users pisze:


Secondary, or backup MXes are almost never recommended in the modern
internet and tend to be a relic of the 1990s dialup internet.

[...]

None of this is what you are considering.  If you still want to
implement a secondary MX then it must have all of the same anti-spam
measures as the primary server, be just as well maintained, and
requires a lot of work to get right, all of this for a server which
will likely see little or no legitimate email traffic.  My opinion
is you are better served spending your time and efforts on the
primary server.


If I remember correctly, someone mentioned NoListing recently on that list.
For this, you *need* a secondary MX, and it is actually your main mail
server - the primary MX never accepts mail...


This is actually something that postscreen can do as well, given two IP 
addresses on the same server, after-220 tests, and mail exchanger policy 
tests as described in postscreen(8) the first connection would run the 
littany of postscreen tests then return a deferral (450) status. 
Assuming that the tests have passed the server will be whitelisted for 
the second connection which will then work to either MX, so basically:


* A connection must be made to the primary MX first, which is then deferred.

* A connection can then be made to any MX provided that the postscreen 
tests have passed in the first connection.


* Any attempt to connect to the secondary MX before the primary is 
discarded.


This allows the best of all worlds without actually configuring a second 
server, and postfix has this capability out of the box.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: secondary MX server

[Peter via Postfix-users]

On 1/04/23 00:36, Corey Hickman via Postfix-users wrote:
Since almost every sending MTA has the queues, do I need a secondary MX 
for my domain email?


Secondary, or backup MXes are almost never recommended in the modern 
internet and tend to be a relic of the 1990s dialup internet.  What is 
often times done for very high traffic situations is load balancing, 
which can be implemented similar to a secondary MX (but having the same 
MX priority for two or more servers instead of different priorities).


Secondary MX entries can also be used for a type of spam trap since 
spammers will often times try to abuse them and send directly to the 
secondary MX instead of trying the primary first as they should do, see 
"MAIL EXCHANGER POLICY TESTS" in postscreen(8) for an implementation of 
this.


None of this is what you are considering.  If you still want to 
implement a secondary MX then it must have all of the same anti-spam 
measures as the primary server, be just as well maintained, and requires 
a lot of work to get right, all of this for a server which will likely 
see little or no legitimate email traffic.  My opinion is you are better 
served spending your time and efforts on the primary server.



I am afraid the secondary MX was abused by spammers.


Indeed, it often is.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: New List Host and Reply-to Header

[Peter via Postfix-users]

On 26/03/23 18:37, Benny Pedersen via Postfix-users wrote:

Peter via Postfix-users skrev den 2023-03-26 06:15:


DKIM and ARC signatures need to be checked right after the message is
received,


not really, all that is needed is to frezze stata of dkim, arc, dmarc at 
recieve state,


which involves ... checking the validity at that stage.  It's rather 
obvious taht if you change the message it can break DKIM and ARC, so if 
you are going to check the signatures they have to be checked before you 
make those changes.  Call it what you want it's still checking it.



new signatures need to be generated right before the message
is sent,


not really, this stage would be waste of resources


If you're going to generate new signatures then it does no good to 
generate them and *then* make changes which could potentially break the 
signature.  That said I was not intending to make a statement about 
whether or not it's worthwhile to re-sign the message or not.


majordomo did not break dkim, dovecot maillist still dont, and are still 
using mailman, thumps up, it works


I'm well aware of how majordomo worked.  We've moved on from majordomo 
and now the mailing list works differently. It's pointless arguing about 
the way things used to be, that system is not likely going to return.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: New List Host and Reply-to Header

[Peter via Postfix-users]

On 26/03/23 13:55, Benny Pedersen via Postfix-users wrote:

Peter via Postfix-users skrev den 2023-03-26 01:05:


Mailman has a setting that addresses this, reply_goes_to_list.
According to mm docs, this adds the original From: address as a CC


there will be a day when mailman dont sink ships, so titanik survived 
it, if just mailman was called AFTER rspamd have ARC sign/seal it, then 
mailman can do there changes of origin mail as needed, where ARC do 
still pass for the origin sender, dkim sign forwarders makes more fails 
then solves


the dkim signer even signs headers that is not in recpients mail as 
recivers, hmm


DKIM and ARC signatures need to be checked right after the message is 
received, new signatures need to be generated right before the message 
is sent, any changes to the message need to be done in-between, all of 
this regardless of however else you set up the system.  I would think 
that this would be obvious.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: [P-U] Re: New List Host and Reply-to Header

[Peter via Postfix-users]

On 25/03/23 11:50, raf via Postfix-users wrote:

On Fri, Mar 10, 2023 at 09:11:58AM +1300, Peter via Postfix-users 
 wrote:


* Don't add a Reply-To:.  I actually question if this is really needed as we
likely want replies to go to the list the vast majority of time anyways.  I
have seen other lists explicitly exclude this step and it works well.

Peter


Removing Reply-To would remove functionality that is
important, even if it is only occasionally required.
Off-list replies would become impossible. That is a
loss of functionality. Just because something is wanted
the vast majority of the time, it doesn't mean that
it's OK to enforce it 100% of the time.


Mailman has a setting that addresses this, reply_goes_to_list. 
According to mm docs, this adds the original From: address as a CC 
instead of Reply-To.  This means that an ordinary reply should go to the 
list (as it's listed in From:) and Reply All will include the original 
sender.  An off-list reply could easily be done by Reply All then 
removing the list address.  considering that off list replies are much 
less common than list replies the additional action of removing the list 
address should not be of great concern.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Fwd: Re: Re: Allow TLSv1 only for internal senders

[Peter via Postfix-users]

On 19/03/23 12:13, Steffen Nurpmeso via Postfix-users wrote:

  |>smtpd_tls_protocols = $smtpd_tls_mandatory_protocols
  |
  |This will simply result in clients that can't support at least TLSv1.2
  |connecting in plain text instead.  So rather than having (arguably not
  |so) poor encryption for those client you would rather have no encryption
  |at all?  This does not make any sense.

There is none.  I have looked, there is only a single server of
value, and it does not even try starttls.  (And he won the USENIX
Flame award.)


Assuming you are correct then you still gain nothing with this setting, 
and if you are not correct then it will cause you to downgrade potential 
encrypted connections to plain text.  I know someone will likely argue 
with me, but I can really think of no valid reason to set this.



Peter
___
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

[Peter via Postfix-users]

On 19/03/23 07:44, Matus UHLAR - fantomas via Postfix-users wrote:

I would generally allow the printer to use port 25.


Port 25 is not a submission port and should not be used as such.  Keep 
your submission separate from your MX traffic and you will avoid a whole 
heap of issues down the road.


If you want a separate port for the printer then just create one in 
master.cf:


10465 inet n   -   n   -   -   smtpd
-o syslog_name=postfix/10465
-o smtpd_tls_wrappermode=yes
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_recipient_restrictions=$mua_recipient_restrictions
-o milter_macro_daemon_name=ORIGINATING

...or similar for a submission (non-wrappermode) port.


Peter
___
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

[Peter via Postfix-users]

On 19/03/23 02:54, Gerd Hoerst via Postfix-users wrote:

I setup my postfix for the clients to use only  protocols > TLSv1 with

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1


A better way to do this is:
smtpd_tls_protocols = >=TLSv1.1


smtpd_tls_protocols   = !SSLv2,!SSLv3,!TLSv1


Don't do this!  All you will accomplish is to force clients that don't 
support at least TLSv1.1 to connect in plain text instead.  No 
encryption is never better than (arguably not very) weak encryption.



in main.cf

but unfortunately i have a sender (its a printer) which is not capable 
for TLSv1.1 and up..


As others have pointed out, TLSv1.0 is not that bad for smtp.  Others 
have posted a solution for this, but honestly I would just allow >=TLSv1 
and not worry about it.



Peter
___
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

[Peter via Postfix-users]

On 19/03/23 09:08, Steffen Nurpmeso via Postfix-users wrote:

I still have no problems with

   smtpd_tls_mandatory_protocols = >=TLSv1.2


This is fine, so long as you don't have a user that can't support at 
least TLSv1.2 that needs to use submission.



   smtpd_tls_protocols = $smtpd_tls_mandatory_protocols


This will simply result in clients that can't support at least TLSv1.2 
connecting in plain text instead.  So rather than having (arguably not 
so) poor encryption for those client you would rather have no encryption 
at all?  This does not make any sense.



   # super modern, forward secrecy TLSv1.2 / TLSv1.3 selection..
   tls_high_cipherlist = EECDH+AESGCM:EECDH+AES256:EDH+AESGCM:CHACHA20


I would avoid messing with this setting unless you really understand 
what you are doing, and even then it's not a very good idea.  You could 
end up causing some clients to be unable to establish a connection or on 
the flip side you could inadvertently be enabling a cipher that ends up 
becoming vulnerable in the future unless you stay on top of this setting 
and remove it from the list.  Note that the default for this setting is 
taken from openssl so when a vulnerability does get found in a cipher 
you will get an update to openssl from your OS vendor which will remove 
that cipher from the list, unless you do something like override it like 
you are doing above.



   smtpd_tls_mandatory_ciphers = high


This is fine.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: The joke writes itself.

[Peter via Postfix-users]

On 10/03/23 11:09, Wietse Venema via Postfix-users wrote:

I am subscribed to several mailing lists that have [uppercase
abbreviation] as their tag, and that works well. None of those tags
are more than 5 characters long.


I have the opposite experience.  most of the lists I'm subscribed to 
have relatively longer, more descriptive tags.  Some examples:


[CentOS]
[CentOS-devel]
[CentOS-announce]
[CIRCLE]
[Fail2ban-users]
[SDLU List]
[rocky]
[rocky-announce]
[rocky-devel]

I also have some examples of shorter tags.  At the end of the day the 
current [P-U] rubs me the wrong way because of the childish reference it 
invokes.  I don't want to see postfix associated with that reference in 
any way.


I think that [postfix] or [postfix-users] and [postfix-devel] 
[postfix-announce] are just fine, but if you want shortened versions, 
might I suggest:


[pf] [pf-dev] [pf-ann]


Peter



If I'd change anything I would
delete the '-' in the middle of the current tag.

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: The joke writes itself.

[Peter via Postfix-users]

On 10/03/23 10:04, Dan Mahoney via Postfix-users wrote:

I know that P-U stands for postfix users.  I get it that a short subject tag 
was desired, but would [postfix] have been that much more distracting, without 
adding the obvious third-grader label that might better be held by qmail?


Indeed, please consider changing it.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: New List Host and Reply-to Header

[Peter via Postfix-users]

On 10/03/23 09:22, Wietse Venema via Postfix-users wrote:

This list uses Mailman configuration settings, not handcrafted code.
If people believe that it is worthwhile to change the Mailman
implementation or the DMARC spec, then I suggest that they work
with the people responsible for that.


How about this setting?

reply_goes_to_list

If this is set to other than no-munging of Reply-To:, the original 
From: goes in Cc: rather than Reply-To:. This is intended to make MUA 
functions of reply and reply-all have the same effect with messages to 
which mitigations have been applied as they do with other messages.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: New List Host and Reply-to Header

[Peter via Postfix-users]

On 10/03/23 09:12, Gerald Galster via Postfix-users wrote:

Many email clients have a "Reply List" option which goes to the address in the List-Post: header.  
Thunderbird has a "Smart Reply" button that when displaying a message with List-Post: defaults to 
"Reply List". I've found that hiding the normal reply button in TB and enabling the smart reply 
button has made my world way easier when dealing with mailing lists.


Apple Mail doesn't seem to have that feature.
A standard reply goes to the original sender via reply-to, "reply all" goes to 
original sender and list.
This requires manually correcting email addresses, but I'm not complaining.


Indeed, it's a suggestion to help people who use an MUA that does have 
the feature.  I wouldn't consider it a proper fix for the issue from the 
perspective of the list itself.  I find the feature works well in 
Thunderbird and can't speak for other MUAs.



Regarding DKIM: I don't see any benefits with ARC-signing for this list, but 
I'll accept whatever the list admin decides.


I tend to agree, ARC is not well implemented (except for google) and it 
doesn't really say much of anything except that you should trust the 
middle man (who's trust is already in question).  That said, it doesn't 
really hurt to have it and can help for gmail recipients.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: New List Host and Reply-to Header

[Peter via Postfix-users]

On 10/03/23 09:07, Matthew McGehrin via Postfix-users wrote:

Hi Peter.

The Reply-To has always been the original poster for 10+ years. No sense 
changing it now. :)


On the contrary, this is the perfect time to change it, if we're going 
to change it.  We've already made a number of changes to where the 
argument of "it's always been like that" is pretty well invalidated at 
this point, imo.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: New List Host and Reply-to Header

[Peter via Postfix-users]

On 10/03/23 08:50, Steffen Nurpmeso via Postfix-users wrote:

Wietse Venema via Postfix-users wrote in
  <4pxdmb1f8fzj...@spike.porcupine.org>:
  |postfix--- via Postfix-users:
  |> Is it the best idea to add a reply-to header to the author on mailing \
  |> list emails?
  |> The problem I see is many people will hit reply in their email client \
  |> which will create an email from them to the author, bypassing the \
  |> mailing list.
  |> Unless they remember to manually alter the To: field to keep the \
  |> conversation on the list, it wont be.
  |>
  |> Was that the intent?
  |
  |This (same-domain From: header and DKIM signature) is  DMARC damage \
  |control.

The very much worth reading RFC 9057 of Dave Crocker defines an
Author: field which can at least be used to fixate the original
From: (or Sender:).  It is (hmm,well) a shame that those who do
invent and push things that brake things, at least, do not use it.


Maybe:

* Mung the From: as we do now (we can perhaps do this selectively based 
on the DMARC policy of the sender instead of doing it across the board?)


* Add an Author: header reflecting the original From: header (if one 
does not already exist).


* Add an Original-From: header reflecting the original From:.  This is 
also supported by some MUAs.


* Don't add a Reply-To:.  I actually question if this is really needed 
as we likely want replies to go to the list the vast majority of time 
anyways.  I have seen other lists explicitly exclude this step and it 
works well.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: New List Host and Reply-to Header

[Peter via Postfix-users]

On 10/03/23 07:34, postfix--- via Postfix-users wrote:
Is it the best idea to add a reply-to header to the author on mailing 
list emails?
The problem I see is many people will hit reply in their email client 
which will create an email from them to the author, bypassing the 
mailing list.
Unless they remember to manually alter the To: field to keep the 
conversation on the list, it wont be.


Many email clients have a "Reply List" option which goes to the address 
in the List-Post: header.  Thunderbird has a "Smart Reply" button that 
when displaying a message with List-Post: defaults to "Reply List". 
I've found that hiding the normal reply button in TB and enabling the 
smart reply button has made my world way easier when dealing with 
mailing lists.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: Postfix lists are migrating to a new list server

[Peter via Postfix-users]

On 8/03/23 10:40, postfix--- via Postfix-users wrote:
I am using RHEL8 and after checking for updates I was able to update 
opendmarc to 1.4.2 (from 1.4.1) however it still has the error, only 
with mail from this list.
In the mean time as suggested, I added "list.sys4.de" to the ignorelist 
to be able to accept list mail again. However i would like to solve the 
problem and not rest on a band-aid.


Another workaround would be to set milter_default_action=accept so that 
when the milter crashes postfix will still accept the message.  I would 
also suggest this:


# systemctl edit opendmarc

[Service]
Restart=on-failure

...so that opendmarc will restart when it does crash for this or any 
other reason.



Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: Postfix lists are migrating to a new list server

[Peter via Postfix-users]

On 8/03/23 15:46, Scott Kitterman via Postfix-users wrote:

For Debian, if someone can find/test patches, I can get them into Debian's 
package.  I assume other distributors are similar.  Feel free to update the 
Debian bug with information.  It's unfortunate we don't have a better 
maintained solution.


The patch appears to be committed in github:

https://github.com/andreasschulze/OpenDMARC/commit/e8e7b41fef40032398d35650489a717108ac70de.patch


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[P-U] Re: Postfix lists are migrating to a new list server

[Peter via Postfix-users]

On 8/03/23 10:54, postfix--- via Postfix-users wrote:

No solution so far, I think there are 2-3 open bug reports on
github, but since the project is very dead, nobody has bothered to
fix the problem.


So what's the option for a more upto date version of DKIM milter for 
debian?


And what would be a dmarc replacement or solution for RHEL systems?


Looks like there's a COPR available with the patch for this issue:

https://copr.fedorainfracloud.org/coprs/abo/opendmarc/

I can't vouch for how trustworthy it is.


Peter
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org