Hello list,
sorry for the silly question.
does virtual domains (such as virtual_alias_domains) support wildcast?
such as putting this one in the file:
*.foo.com
so that one.foo.com, two.foo.com... will be a recipient domain.
Thanks.
--
sent from https://dkinbox.com/
On Mon, May 22, 2023 at 02:34:41PM +0200, Joachim Lindenberg via Postfix-users
wrote:
> reusing the private key for too long (say a year or more) is
> considered a bad security practice. Imho it is easier to monitor
> changes of the issuing CA (I do) or just mark your calendar to update
> in
On Mon, May 22, 2023 at 06:06:00PM -0400, Alex wrote:
> Yes, I wasn't aware that's how it worked. I've now explicitly defined the
> bcc-user to use the same transport, but the problem is that there is one
> bcc-user but multiple transports, each with their own policy.
This is where
On 2023-05-22 at 19:53:11 UTC-0400 (Tue, 23 May 2023 07:53:11 +0800)
Tom Reed via Postfix-users
is rumored to have said:
PS: Why do you (think you) need a backup MX?
Hello
I am not sure why I need a backup mx indeed,
If you don't know why you want the added complexity, you do not want
Hello.
It really depends on your mail volume and the reliability of your
primary MX hostname. Typically the RFC permits mail to be delayed for up
to 5 days at which mail will bounce back as undeliverable. For most
low-volume sites, a primary only MX configuration is fine.
Both of those
Tom Reed via Postfix-users skrev den 2023-05-23 01:53:
I am not sure why I need a backup mx indeed, but if you make a simple
dig,
you find gmail, fastmail, protonmail, comcast, free.fr those big
providers
do have backup MXs.
Though yahoo, outlook don't have backup MX as a comparison.
one
>
> PS: Why do you (think you) need a backup MX?
Hello
I am not sure why I need a backup mx indeed, but if you make a simple dig,
you find gmail, fastmail, protonmail, comcast, free.fr those big providers
do have backup MXs.
Though yahoo, outlook don't have backup MX as a comparison.
Hi,
>
> The BCC recipient is processed in much the same way as any other message
> recipient. The only special handling that comes to mind is DSN, where
> this recipient is treated as if NOTIFY=NEVER were specified.
>
> > local_transport = error:5.1.1 Mailbox unavailable
> > default_transport =
Thank you Victor, you are the embodiment of truth.
> On Mon, May 22, 2023 at 08:26:19PM +0800, Tom Reed via Postfix-users
> wrote:
>
>> 1. postfix is a backup MX for foo.com
>> 2. this postfix uses other MTA as relay_host
>
> This would be a misconfiguration. A backup MX host MUST NOT be an
>
Tom Reed via Postfix-users:
> Hello list,
>
> Given the case that:
>
> 1. postfix is a backup MX for foo.com
> 2. this postfix uses other MTA as relay_host
Please don't do that. By design a Postfix backup MX host will deliver
to an MX host with a 'better' MX preference. You are frustrating that
On 22.05.23 20:26, Tom Reed via Postfix-users wrote:
Given the case that:
1. postfix is a backup MX for foo.com
2. this postfix uses other MTA as relay_host
When the primary MX for foo.com is down, messages to u...@foo.com will be
delivered into backup MX. And, backup MX delivers the message
On Mon, May 22, 2023 at 08:26:19PM +0800, Tom Reed via Postfix-users wrote:
> 1. postfix is a backup MX for foo.com
> 2. this postfix uses other MTA as relay_host
This would be a misconfiguration. A backup MX host MUST NOT be an
effective null client that relays *all* non-local mail to a
On 2023-05-22 at 08:36:49 UTC-0400 (Mon, 22 May 2023 14:36:49 +0200
(CEST))
Bernardo Reino via Postfix-users
is rumored to have said:
My world is only a very small subset of the real world :), but in that
world, if I say that a given server is the MX for a domain, then
that's that, it should
Joachim Lindenberg via Postfix-users writes:
> (...) just mark your calendar to update in September 2025 ...
Hellow Joachim! Thanks for remarkble tip ^^^
Sincerely, Byung-Hee
___
Postfix-users mailing list -- postfix-users@postfix.org
To
On Mon, 22 May 2023, Tom Reed via Postfix-users wrote:
Given the case that:
1. postfix is a backup MX for foo.com
2. this postfix uses other MTA as relay_host
When the primary MX for foo.com is down, messages to u...@foo.com will be
delivered into backup MX. And, backup MX delivers the
reusing the private key for too long (say a year or more) is considered a bad
security practice. Imho it is easier to monitor changes of the issuing CA (I
do) or just mark your calendar to update in September 2025 than to pin 3 1 1.
Don´t want to be fundamental, just opinionated. Everyone has to
Hello list,
Given the case that:
1. postfix is a backup MX for foo.com
2. this postfix uses other MTA as relay_host
When the primary MX for foo.com is down, messages to u...@foo.com will be
delivered into backup MX. And, backup MX delivers the message to
relay_host, which find that primary MX
17 matches
Mail list logo
