[pfx] Re: OT: VPS w/FDE suggestions?
On 2024-02-21 MRob via Postfix-users wrote: [ off-topic ] It never ceases to amaze me how people *know* that what they're posting is off-topic, yet decide it's okay for them to post it anyway if they just label it as off-topic. Hint: it's not. Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky ___ 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. It's three (permit_naked_ip_address, reject_maps_rbl, check_relay_domains) that have been logging warnings since 2005 or earlier). I find it hard to justify a major version change for their removal. > >>> 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. There is a lot more work that needs to be done, that could result in 5.x in just a few years. It's not impossible to have major versions a few yearts apart, but I'd like keep a major version for the time that were removing those 17 obsolete TLS parameters (_use_tls, _enforce_tls, _per_site, and some otther ones). Wietse ___ 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
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: removing Authentication-Results, how?
On Tue, Feb 20, 2024 at 06:02:22PM -0500, Wietse Venema via Postfix-users wrote:
> - You'd better add $$ at the end of the pattern, to anchor the regular
> expression.
Actually, that hostname is typically followed by additional data
separated by whitespace or a ';'.
> header_checks = pcre:{ {/^Authentication-Results: \Q$myhostname\E$$/
> IGNORE} }
>
> Note that pcre, not regexp.
Indeed PCRE is best here:
header_checks = pcre:{ {/^Authentication-Results: \Q$myhostname\E[\s;]/
IGNORE} }
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] OT: VPS w/FDE suggestions?
Hello- Im looking for <= $6/mo VPS suggestions for general mail/web hosting server. Some super-cheap hosts pre-install O/S and give root but I want to install O/S myself so can put in FDE. Hard to see which hosts can do this. I tried Linode before and yes, could get FDE ($5 1GB, 1CPU, 25GB, 1TB) Is IONOS any good? Can I get FDE there?? ($2 1GB, 1CPU, 10GB, ?TB) ($3 2GB, 2CPU, 80GB, ?TB) ($6 4GB, 2CPU, 160GB, ?TB) Others caught my eye: hudsonvalleyhost ($3.95 1GB, 1CPU, 25GB, 20TB) ($6.95 2GB, 2CPU, 50GB, 20TB) liquidweb ($5 1GB, 1CPU, 30GB, 1TB) digitalocean ($6 1GB, 1CPU, 25GB, 20TB) ovhcloud ($4.20 2GB, 1CPU, 20GB, 100Mbps unmetered) ($5.50 2GB, 2CPU, 40GB, 500Mbps unmetered) brownrice ($5.95 3GB, 1CPU, 10GB, unlimited) ___ 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: > > 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. > > 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. Wietse ___ 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
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: removing Authentication-Results, how?
Matus UHLAR - fantomas via Postfix-users:
> I guess the inline code available since 3.7 supports this:
>
> header_checks = regexp:{ {/^Authentication-Results: $myhostname/ IGNORE} }
>
> This would only remove problem headers and exempt MX backups.
>
> >If it helps, header_checks happen before Milters see the message,
> >while milter_header_checks happen when a Milter adds a header.
>
> I am very glad it works this way.
It works with some limitations:
- You'd better add $$ at the end of the pattern, to anchor the regular
expression.
- Youe example will not escape '.' in the $myhostname value. Perhaps
you can disable special chatacters with \Q and \E, as in:
header_checks = pcre:{ {/^Authentication-Results: \Q$myhostname\E$$/ IGNORE} }
Note that pcre, not regexp.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: removing Authentication-Results, how?
Reviving my a bit old question.
Matus UHLAR - fantomas via Postfix-users:
RFC 8601 section 5. requires deleting Authentication-Results headers from
incoming messages. This should be done at trusted border, so when receiving
message via SMTP from clients or the world, except MX gateways or possibly
backup MX srevers.
On 16.01.24 11:55, Wietse Venema via Postfix-users wrote:
Indeed, the idea is to delete any Authentication-Results instance
that claims [...] to have been added within [this MTA's] trust
boundary but that did not come directly from another trusted MTA."
I don't want to rely on milters stripping those headers so I'll try
header_checks.
I guess I could remove all Authentication-Results: headers by using
regexp_table:
/^Authentication-Results: / IGNORE
but is it possible to put environment or postfix variable there?
/^Authentication-Results: $myhostname/ IGNORE
I guess the inline code available since 3.7 supports this:
header_checks = regexp:{ {/^Authentication-Results: $myhostname/ IGNORE} }
This would only remove problem headers and exempt MX backups.
If it helps, header_checks happen before Milters see the message,
while milter_header_checks happen when a Milter adds a header.
I am very glad it works this way.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Microsoft dick is soft to do no harm
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] reject_unverified_recipient triggers Recipient address rejected
> postfix/submission/smtpd[23263]: NOQUEUE: reject: RCPT from > unknown[21.193.143.55]: 450 4.1.1 : Recipient address rejected: > unverified address: unknown mail transport error; from= > to= proto=ESMTP helo= The verification fails with a "unknown mail transport error" Check the logs (on both sides, sending and receiving): egrep "(error|fatal):" /var/log/mail.log (or wherever your logs are) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] reject_unverified_recipient triggers Recipient address rejected
Hello,
i am running 3.4.14 smoothly. However, after adding a virtual ip and
some mailrouting (migration from an old sendmail host) i have the
problem, that if i add "reject_unverified_recipient":
smtpd_recipient_restrictions = permit_mynetworks
reject_unknown_recipient_domain reject_unverified_recipient
then i fail to deliver those mails:
postfix/submission/smtpd[23263]: NOQUEUE: reject: RCPT from
unknown[21.193.143.55]: 450 4.1.1 : Recipient address rejected:
unverified address: unknown mail transport error; from=
to= proto=ESMTP helo=
The reject_unverified_recipient flag worked fine before i did that migration.
The mails get delivered just fine (!) after removing the
reject_unverified_recipient flag. We already deleted the cache files
which temporarily fixed the problem.
I can also deliver the mail with a manual telnet.
Any hints on this verify problem? It looks like a local problem to me.
Here is my config:
-
address_verify_negative_cache = yes
address_verify_negative_expire_time = 24h
address_verify_negative_refresh_time = 15m
alias_database = hash:/etc/aliases hash:/etc/postfix/aliases
alias_maps = hash:/etc/aliases hash:/etc/postfix/aliases
allow_mail_to_commands = alias,forward,include
append_dot_mydomain = no
biff = no
compatibility_level = 2
debug_peer_list = 123.123.131.199
default_process_limit = 150
inet_interfaces = all
inet_protocols = all
local_recipient_maps =
local_transport = lmtp:unix:/run/cyrus/socket/lmtp
mailbox_size_limit = 9000
mailbox_transport = lmtp:unix:/run/cyrus/socket/lmtp
message_size_limit = 9000
mydestination = $myhostname, localhost, foo2.example.net, bar-1.example.net
myhostname = foo.example.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
123.123.172.75/32 123.123.130.86/32 123.123.150.195/32
123.123.152.74/32 123.123.160.114/32 123.123.152.105/32
123.123.128.219/32 123.123.131.247/32 123.123.66.12/32
123.123.128.227/32 123.123.150.17/32 123.123.149.243/32
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relay_domains = hash:/etc/postfix/mailertable
relayhost = mailout.example.net
smtp_tls_CApath = /etc/ssl/certs/
smtp_tls_cert_file = /etc/ssl/certs/wildcard.example.net-fullchain.pem
smtp_tls_key_file = /etc/ssl/private/wildcard.example.net-key.pem
smtp_tls_loglevel = 1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_count_limit = 20
smtpd_client_event_limit_exceptions =
smtpd_recipient_restrictions = permit_mynetworks reject_unknown_recipient_domain
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain = foo.example.net
smtpd_sasl_path = smtpd
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = cyrus
smtpd_tls_CApath = /etc/ssl/certs/
smtpd_tls_cert_file = /etc/ssl/certs/wildcard.example.net-fullchain.pem
smtpd_tls_key_file = /etc/ssl/private/wildcard.example.net-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/mailertable
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550
virtual_alias_domains = /etc/postfix/local-host-names
virtual_alias_maps = hash:/etc/postfix/virtusertable hash:/etc/postfix/aliases
virtual_transport = lmtp:unix:/run/cyrus/socket/lmtp
Cheers,
Michael
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: transport_maps : fatal: garbage after "]" in server description...
> i am running Postfix 3.4.14 and try to set up mailrouting to multiple > smtp hosts. > transport_maps = hash:/etc/postfix/mailertable > > example.com smtp:[mx1.foobar.com],smtp:[mx2.foobar.com] > > However i get: > fatal: garbage after "]" in server description: > [mx1.foobar.com],smtp:[mx2.foobar.com] > > Whats the correct syntax? I cant find a hint in the docs :-/ example.com smtp:[mx1.foobar.com],[mx2.foobar.com] -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
