I have been trying to understand why check_ccert_access does not work
with an inline:{} table and I believe I have uncovered a subtle bug.
My investigation has focused on
https://github.com/vdukhovni/postfix/blob/master/postfix/src/global/map_search.c
To cut to the chase, I believe line
map in virtual_alias_maps file:
u...@foo.com u...@gmail.com
(then postmap this file). The message sent to u...@foo.com won't
reach into mailbox, but just forwarded to gmail.
How can I setup it to both reach local mailbox and forwarding?
This is a bad idea. Don't do this. Forwarding
from smtp.c: debug_peer_check(request->nexthop, "noaddr");
The string being compared to debug_peer_list is the nexthop.
have you tried debug_peer_list = example.com
This single match should cover all servers, however many, for that domian.
I don't think the IP address of the actual peer
The question is wrong. One is not "more-stringent" than the other, they
just check for different things.
As TLS is not mandatory for SMTP over the general internet, it's
availability is patchy at best. For the servers that do provide STARTTLS
and a certificate, what's actually on the
On 8/04/2023 10:31 am, raf via Postfix-users wrote:
On Thu, Apr 06, 2023 at 11:28:07AM +1000, Sean Gallagher
wrote:
On 6/04/2023 10:39 am, raf via Postfix-users wrote:
On Thu, Apr 06, 2023 at 07:33:28AM +0800, Corey Hickman via Postfix-users
wrote:
Hello
for these two statements,
HUGE RETRACTION: I've really messed this up...
At the time of the HELO/EHLO command, SMTPD_FLAG_SMTPUTF8 should always
be false, that feature may be negotiated after HELO/EHLO.
As such, the UTF8 handling code of reject_non_fqdn_hostname is ALWAYS
DISABLED during HELO/EHLO and so
On 7/04/2023 12:32 am, Viktor Dukhovni via Postfix-users wrote:
On Thu, Apr 06, 2023 at 04:57:51PM +1000, Sean Gallagher via Postfix-users
wrote:
What a can of worms..
IDNA2003 allowed UTF8 in domain names
IDNA specified an encoding system for mapping UTF8 labels to
ACE-prefixed LDH labels
From reading the code, these two restrictions seem equivalent except
when SMTPUTF8 extension is used.
when the SMTPUTF8 is in play, reject_non_fqdn_helo_hostname will convert
a hostname containing UTF to an internationalized domain name
before checking.
What a can of worms..
IDNA2003 allowed UTF8 in domain names
IDNA2008 subsequently forbid non-ASCII characters in domain names.
RFC6531 (which defines the SMTPUTF8 extension) Allows internationalized
domain names in headers and the "envelope" - taken to mean the RCPT (to
address) and MAIL (from
I am just not sure, for this domain SpaceMail.com, who has a CNAME to CDN for
the root domain, every query to this domain will get a CNAME. for instance,
This is a requirement of CNAME. If a domain has a CNAME, it can't have
anything else. See RFC1034 3.6.2. There is a minor exception, the
how is "inet_interfaces = all" different to "inet_interfaces = " (i.e.
blank)?
By supplying an IP4 address and not an IPv6 address, you are effectively
leaving the IPv6 setting blank. What happens with a blank field needs to
be specified.
how is "inet_interfaces = all" different to
pv6". Just a thought bubble...
On 4/05/2023 6:58 am, Sean Gallagher via Postfix-users wrote:
how is "inet_interfaces = all" different to "inet_interfaces = " (i.e.
blank)?
By supplying an IP4 address and not an IPv6 address, you are
effectively leaving the IPv6 settin
ADDRESS_CLASS_README:
The most misleading place for me was the ADDRESS_CLASS_README
For "The virtual alias domain class" it says:
"Valid recipient addresses are listed with the virtual_alias_maps
parameter"
which is of course true, but there is nothing special about the virtual
alias domain
On 8/05/2023 10:19 am, Wietse Venema via Postfix-users wrote:
Sean Gallagher via Postfix-users:
ADDRESS_CLASS_README:
The most misleading place for me was the ADDRESS_CLASS_README
For "The virtual alias domain class" it says:
"Valid recipient addresses are listed with the vir
I am no fanboy of Postfix and have had more than my share of problems
wading through the documentation and often fining it quite thin - but on
this issue, I have no problem with Postfix's behavior. It is normal and
I think desirable for programs to choose sensible defaults when
possible. This
While Wietse has his word processor open, I'd like to share a few of my
greatest misdirects in my evolving understanding of Postfix.
To quote a like minded individual
I simply want to help others avoid my points of confusion, in the belief I
am not a uniquirely incapable or unintelligent
blank is NOT obvious to the uninitiated.
On 4/05/2023 11:10 pm, Wietse Venema via Postfix-users wrote:
Sean Gallagher via Postfix-users:
how is "inet_interfaces = all" different to "inet_interfaces = " (i.e.
blank)?
One says that Postfix will provide network service on all I
This is rarely what you want. I'd be inclined to require that the
"inet_interfaces" parameter be non-empty (though it could still be
effectively empty as a list by setting it to be a mixture of spaces and
at least one comma).
You need to be careful what "empty" means. If inet_interfaces has
That's a non-issue. With that, Postfix will only listen on IPv4 as
specified, when the "inet" endpoint only specifies the port.
That makes sense, and is exactly what I would expect, but it still needs
to be documented.
But it does raise another question in my mind. Many places in the
[ Yes, one could also craft "classless" access(5) tables, ... and rely
only on explicit transport(5) table entries, opting out of all the
taxonomy that makes it easier to reason about Postfix mail routing,
but this is not a good idea, and users advanced enough to do that
aren't the
On 5/05/2023 11:52 am, Sean Gallagher via Postfix-users wrote:
While Wietse has his word processor open, I'd like to share a few of
my greatest misdirects in my evolving understanding of Postfix.
To quote a like minded individual
I simply want to help others avoid my points of confusion
21 matches
Mail list logo
