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 161
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. https://en.wikipedia.org/wiki/Internationa
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 a
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
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,
reje
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
"reject_non
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 s
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 machine
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 certifica
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 m
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 "inet_int
all-ipv6". 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 s
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
ank 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 IP
a
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 reader
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 o
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
docu
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 cl
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
[ 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 confusio
21 matches
Mail list logo
