Taco de Wolff via Postfix-users:
> Thanks Wietse and Steffen, I forgot to mention that I'm using Postfix
> 3.5.8, but it appears the bug is thus still present in the latest version.
> Looking forward to the fix :-)
Another solution is to adopt Postfix 3.9 (the development relea
Taco de Wolff via Postfix-users wrote in
:
|Thanks Wietse and Steffen, I forgot to mention that I'm using Postfix
|3.5.8, but it appears the bug is thus still present in the latest version.
|Looking forward to the fix :-)
|
|@Steffen, that is genius and hadn't thought of it. I can confirm
Thanks Wietse and Steffen, I forgot to mention that I'm using Postfix
3.5.8, but it appears the bug is thus still present in the latest version.
Looking forward to the fix :-)
@Steffen, that is genius and hadn't thought of it. I can confirm that
issuing two modifications works as expected
Taco de Wolff via Postfix-users wrote in
:
|While writing a milter for use with Postfix, I was unable to change the
|first header field and instead of changing it, Postfix appends it to the
|end of the header. Incidentally, as I believed this was a bug with the
insheader with index 0 worked
The Postfix Milter implementation is sometimes inconsistent about
the "first" header so that it can sometimes not be updated.
The fix below was in the queue for Postfix 3.5 - 3.8 a few days
before the SMTP smuggling shitshow happened. The last SMTP smuggling
patch was released on January 21. For
Hi,
While writing a milter for use with Postfix, I was unable to change the
first header field and instead of changing it, Postfix appends it to the
end of the header. Incidentally, as I believed this was a bug with the
milter library, I rewrote the milter server implementation from scratch
Rune Philosof via Postfix-users:
> Mismatching between compatibility_level in overview and explanations for
> http://www.postfix.org/COMPATIBILITY_README.html#relay_restrictions
> and
> http://www.postfix.org/COMPATIBILITY_README.html#smtputf8_enable
>
> The overview lists them as
Mismatching between compatibility_level in overview and explanations for
http://www.postfix.org/COMPATIBILITY_README.html#relay_restrictions
and
http://www.postfix.org/COMPATIBILITY_README.html#smtputf8_enable
The overview lists them as compatibility_level < 2 and the detailed explanation
says <
On Sun, Nov 05, 2023 at 12:13:17PM +, Matthias Nagel via Postfix-users
wrote:
> Viktor, you recommend to use proxymap in combination with LDAP,
Yes.
> especially if all LDAP lookups use the same connection.
Regardless of whether the connection settings are the same across all
tables. But
As Viktor mentions, best practice is to:
- Share the LDAP socket handle among the three tables that connect
to the same LDAP endpoint (i.e. delay the bind with bind=no in the
three *cf files).
- Open LDAP tables from outside the chroot, by configuring LDAP
tables as proxy:ldap:/path/to/file, and
Dear Viktor, dear Wietse,
Viktor, you recommend to use proxymap in combination with LDAP, especially if
all LDAP lookups use the same connection. Indeed, this is the case for my
setup. The LDAP server, the bind DN and bind passwd are the same. Only the
search base, the query filter and the
Viktor Dukhovni via Postfix-users:
> On Sat, Nov 04, 2023 at 09:48:32AM -0400, Wietse Venema via Postfix-users
> wrote:
>
> > To be precise: Postfix opens your LDAP configuration file and asks
> > the LDAP library to create an LDAP client instance, before entering
> > the chroot jail and before
On Sat, Nov 04, 2023 at 09:48:32AM -0400, Wietse Venema via Postfix-users wrote:
> To be precise: Postfix opens your LDAP configuration file and asks
> the LDAP library to create an LDAP client instance, before entering
> the chroot jail and before accepting any SMTP client commmands.
>
>
Matthias Nagel via Postfix-users:
> Hello all,
>
> I am using Postfix 3.8.1 on Ubuntu 23.10. Per distribution default,
> Postfix runs chrooted. I have setup LDAP lookups for most maps.
> OpenLDAP is only listening via UNIX socket on
> ldapi:///var/run/slapd/ldapi.
>
> For all but one LDAP lookup
rently than all other
configuration options which allow LDAP lookup?
- Is this an oversight? Is it an „bug“ in the Postfix software? All other LDAP
connections seem to opened by Postfix before chrooting.
- Did I miss something in the docs? If this is not a bug, but intended
behaviour, the
Stephan Bosch via Postfix-devel:
>
> Op 2-11-2023 om 15:22 schreef Wietse Venema:
> > Stephan Bosch via Postfix-devel:
> >> Looks like Postfix [...] somehow uses the data from the previous CONT auth
> >> service
> >> response as the reason.
> > Does this patch address the problem? It resets any
On Sun, Aug 27, 2023 at 04:06:18PM -0400, Viktor Dukhovni via Postfix-users
wrote:
> If the aliases(5) table has actually been rebuilt, and the message
> is now deliverable, the background refresh is supposed to happen:
>
> address_verify_negative_refresh_time (default: 3h)
>The
ob/v3.8.1/postfix/src/verify/verify.c#L512-L550
If you have detailed log evidence of refresh probes not happening,
please share.
> I have 100% default values. Ten hours after correcting the problem,
> it still failed. Perhaps a bug?
During those 10 hours, how many deliveries were a
On Fri, Aug 25, 2023 at 08:07:01PM -0600, Pete Holzmann via Postfix-users wrote:
> SUMMARY
>
> * Scenario/repeatability:
>- See www.postfix.org/ADDRESS_VERIFICATION_README.html#caching
>- Since Postfix 2.7, there's a persistent verification database.
Actually, there isn't, or, more
SUMMARY
* Scenario/repeatability:
- Typical default postfix configuration
- An alias is added, but with a typo.
- Incoming email is rejected as expected, "Recipient address
rejected: undeliverable address: unknown user: "address"
- Typo corrected. newaliases is used. Postfix can
ARC-Authentication-Results: i=1; list.sys4.de; dkim=fail;
arc=none (Message is not ARC signed);
dmarc=none
Authentication-Results: list.sys4.de; dkim=fail;
arc=none (Message is not ARC signed); dmarc=none
when originating mails is not dkim signed then i belive dkim=fail here
should be
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
On 17/10/21 8:00 pm, Viktor Dukhovni wrote:
The feature appears to have been released in an incomplete form.
I don't see any code in Postfix to actually use "known_tcp_ports"
to load the underlying hash table.
Hr, okay.
Also, while numeric service names work with getaddrinfo(3), I
don't
On Sun, Oct 17, 2021 at 06:40:47PM +1300, Peter wrote:
> Just had someone come into the IRC chat with this issue and I was able
> to reproduce it quite easily, this is with Postfix 3.6.2. If your
> /etc/services has smtps listed but not submissions (or vice-versa) and
> you uncomment or add
Just had someone come into the IRC chat with this issue and I was able
to reproduce it quite easily, this is with Postfix 3.6.2. If your
/etc/services has smtps listed but not submissions (or vice-versa) and
you uncomment or add the relevant section to master.cf then postfix
gives an error
On Mon, Jun 14, 2021 at 04:57:24PM -0400, Christopher Gurnee wrote:
> That was quick, thanks!
Welcome to Postfix, where we don't let bugs linger and have no (need for
a) bug tracking system, because there are no open bugs. Bugs are fixed
in near real time, and show up in snaphots and pa
Christopher Gurnee:
> That was quick, thanks!
Well you did the work by finding the missing code in postmap.c :-)
Wietse
That was quick, thanks!
Regards,
Chris
On 06/14/2021 4:22 pm, Wietse Venema wrote:
Wietse Venema:
Christopher Gurnee:
> Workaround
> --
>
> Use a hash table:
> tls_server_sni_maps = hash:/etc/postfix/tls_server_sni
> and create it with:
> sudo postmap -F
Wietse Venema:
> Christopher Gurnee:
> > Workaround
> > --
> >
> > Use a hash table:
> > tls_server_sni_maps = hash:/etc/postfix/tls_server_sni
> > and create it with:
> > sudo postmap -F /etc/postfix/tls_server_sni
>
> There is some code that was added to postmap/postmap.c but
Christopher Gurnee:
> Workaround
> --
>
> Use a hash table:
> tls_server_sni_maps = hash:/etc/postfix/tls_server_sni
> and create it with:
> sudo postmap -F /etc/postfix/tls_server_sni
There is some code that was added to postmap/postmap.c but not to
util/dict_thash.c. This is
Hi, all! My apologies if I've gotten anything wrong below.
Version
---
3.4.13-0ubuntu1 (from Ubuntu 20.04.2)
(although I suspect this affects all versions >= 3.4)
Configuration
-
/etc/postfix/main.cf:
smtpd_tls_security_level = may
tls_server_sni_maps =
It is just a warning, you can live with it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926331
On Mon, Oct 26, 2020 at 7:59 PM natan wrote:
> Hi
> Probably bug in debian 10 ...
> "warning: symlink leaves directory: /etc/postfix/./makedefs.out"
>
> ii postfix
Hi
Probably bug in debian 10 ...
"warning: symlink leaves directory: /etc/postfix/./makedefs.out"
ii postfix 3.4.14-0+deb10u1 amd64 High-performance mail
transport agent
Maybe another repo ? I don't want to install from source ... eh
I search in google and probably bug in
--
nutes where you expect month. It should be
> %Y%m%d-%H%M%S.
>
> And as I said, it?s technically not a bug because it works as documented but
> as documented and as works is not what one would reasonably expect.
>
> I?m running Postfix 3.5.1.
I fixed this in the pending stab
be
%Y%m%d-%H%M%S.
And as I said, it’s technically not a bug because it works as documented but as
documented and as works is not what one would reasonably expect.
I’m running Postfix 3.5.1.
--
Larry Stone
lston...@stonejongleux.com
> On May 9, 2020, at 10:31 AM, Larry Stone wr
On Wed, May 06, 2020 at 09:07:45AM -0400, Wietse Venema wrote:
> You need to collect logs over at least 5 minutes.
I was sitting this one out, but perhaps should make a few comments:
1. Postfix does not have bugs of the sort conjectured by the OP.
The problem is entirely a result of
natan maciej milaszewski:
Thenx for replay:
May? 5 06:00:51 smtp1 postfix/smtpd[5939]: warning: Illegal address
syntax from unknown[217.153.30.34] in RCPT command: <>
...
May? 5 06:00:54 smtp1 postfix/smtpd[6444]: warning:
unknown[111.72.195.23]: SASL LOGIN authentication failed:
natan maciej milaszewski:
> Thenx for replay:
>
> May? 5 06:00:51 smtp1 postfix/smtpd[5939]: warning: Illegal address
> syntax from unknown[217.153.30.34] in RCPT command: <>
...
> May? 5 06:00:54 smtp1 postfix/smtpd[6444]: warning:
> unknown[111.72.195.23]: SASL LOGIN authentication failed:
On 5/05/20 5:04 pm, natan maciej milaszewski wrote:
Hi
I have a centos 7 and postfix3-3.4.7-1.gf.el7.x86_64
I reload postfix via:
postfix reload
May 5 06:00:52 smtp1 postfix/master[22162]: reload -- version 3.4.7,
configuration /etc/postfix
And new mail was only added to queue active
They
Thenx for replay:
May 5 06:00:51 smtp1 postfix/smtpd[5939]: warning: Illegal address
syntax from unknown[217.153.30.34] in RCPT command: <>
May 5 06:00:51 smtp1 postfix/smtpd[6242]: warning: Illegal address
syntax from unknown[217.153.30.34] in RCPT command: <>
May 5 06:00:51 smtp1
natan maciej milaszewski:
> Hi
> I not found any errors:
RUN THE COMMAND DESCRIBED IN http://www.postfix.org/DEBUG_README.html#logging
$ egrep '(warning|error|fatal|panic):' /some/log/file | more
Wietse
Hi
I not found any errors:
May 5 06:00:52 smtp1 postfix/master[22162]: reload -- version 3.4.7,
configuration /etc/postfix
May 5 06:00:52 smtp1 postfix/cleanup[5718]: 49GQxc60ggz4D9D:
message-id=
May 5 06:00:52 smtp1 postfix/qmgr[5678]: 49GQxc60ggz4D9D:
from=, size=67939, nrcpt=1 (queue
Have a look at the error logs.
http://www.postfix.org/DEBUG_README.html#logging
Look for obvious signs of trouble
=
Postfix logs all failed and successful deliveries to a logfile.
* When Postfix uses syslog logging (the default), the file is usually
called
For second test i relod postfix via systemd (service postfix reload) -
works fine
Any idea ? maby bug ?
anyone can confirm ?
On 3/04/19 17:13, Viktor Dukhovni wrote:
>
>
> It seems you're in a sardonic mood, ... best to not go there.
If I gave that impression, I apologize.
All I was trying to say is that, because of the bug, you may be more
likely to run out of disk space by trying to send to bona fid
records.
No, because failing deliveries to domains with tens to hundreds of
unavailable MX host IPs would DoS the queue by tying up delivery
agents for an unreasonably long time.
It seems you're in a sardonic mood, ... best to not go there.
Your bug report has been noted, and the so
eir mail queues melt down.
>
... because of all the mail that will get stuck in the queue with
"server unavailable or unable to receive mail" for _any_ MX that has
_both_ A and records.
One of each is enough to trigger the bug, even if they would all respond
if Postfix bothered to
Luc Pardon:
> On the same topic: what if smtp_mx_address_limit was simply made to
> apply for each family separately? E.g. the default of 5 would mean: keep
> max 5 IPv6 addresses _and_ max 5 IPv4's ?
The purpose of these and other Postfix limits is not to frustrate
legitimate mail operators.
On 2/04/19 13:21, Wietse Venema wrote:
> Probably better to not allow a limit-less smtp_mx_address_limit,
> as it makes Postfix vulnerable to resource exhaustion attack.
>
> Wietse
>
Fair enough, but then the docs for smtp_mx_address_limit ought to be
changed to remove the "or zero (no
Probably better to not allow a limit-less smtp_mx_address_limit,
as it makes Postfix vulnerable to resource exhaustion attack.
Wietse
e is an easy workaround, and
that is: "don't RTFM", i.e. leave smtp_mx_address_limit at its default of 5.
And if you really want "no limit", you can set it to a ridiculously high
value, such as 100.
>From the changelog, this seems to have been introduced on 20170505, and
in
Ralf Hildebrandt:
> * Viktor Dukhovni :
> > > On Mar 28, 2019, at 12:03 PM, Wietse Venema wrote:
> > >
> > > And thank you for your thorough investigation that helped to narrow
> > > down the root cause: under high traffic conditions, LMTP connections
> > > are cached but never reused, therefore
* Viktor Dukhovni :
> > On Mar 28, 2019, at 12:03 PM, Wietse Venema wrote:
> >
> > And thank you for your thorough investigation that helped to narrow
> > down the root cause: under high traffic conditions, LMTP connections
> > are cached but never reused, therefore those idle cached connections
Juliana Rodrigueiro:
> On Friday, 29 March 2019 00:49:34 CET Wietse Venema wrote:
>
> >
> > This is a patch for LMTP connection reuse over UNIX-domain sockets.
> >
> > Bugfix (introduced: Postfix 3.0): LMTP connections over
> > UNIX-domain sockets were cached but not reused, due
On Friday, 29 March 2019 00:49:34 CET Wietse Venema wrote:
>
> This is a patch for LMTP connection reuse over UNIX-domain sockets.
>
> Bugfix (introduced: Postfix 3.0): LMTP connections over
> UNIX-domain sockets were cached but not reused, due to a
> cache lookup key
Wietse Venema:
> Juliana Rodrigueiro:
> > > To get rid of the 2s delays:
> > >
> > > /etc/postfix/main.cf:
> > > lmtp_connection_cache_on_demand = no
> > >
> > > Please let us know if that helps. Meanwhile we can develop a proper fix.
> >
> > And yes, it worked, that helped a lot. Although not
> On Mar 28, 2019, at 12:03 PM, Wietse Venema wrote:
>
> And thank you for your thorough investigation that helped to narrow
> down the root cause: under high traffic conditions, LMTP connections
> are cached but never reused, therefore those idle cached connections
> are exhausting server
Juliana Rodrigueiro:
> > To get rid of the 2s delays:
> >
> > /etc/postfix/main.cf:
> > lmtp_connection_cache_on_demand = no
> >
> > Please let us know if that helps. Meanwhile we can develop a proper fix.
>
> And yes, it worked, that helped a lot. Although not as fast as before, but now
> I
On Wednesday, 27 March 2019 20:01:49 CET Viktor Dukhovni wrote:
> On Wed, Mar 27, 2019 at 03:36:28PM +0100, Juliana Rodrigueiro wrote:
> > However, during a benchmark, we realized 3.3.2 was 5 times slower than the
> > version before.
>
> This is misleading. Postfix is not 5 times slower, your
Wietse Venema:
> Juliana Rodrigueiro:
> > Excerpt of maillog version > 2.11.1:
> > Mar 27 14:46:50 localdomain postfix/lmtp[24750]: 6CEFF61:
> > to=, orig_to=,
> > relay=localdomain.com[/var/
> > imap/socket/lmtp], delay=0.02, delays=0.01/0/0.01/0, dsn=2.1.5, status=sent
> > (250 2.1.5 Ok
> On Mar 27, 2019, at 3:01 PM, Viktor Dukhovni
> wrote:
>
> There's likely a bug. We should either simulate a synthetic nexthop
> ($myhostname?) for unix-domain destinations, and then do nexthop
> reuse (and perhaps do no caching by endpoint address for unix-domain
> dest
Juliana Rodrigueiro:
> Excerpt of maillog version > 2.11.1:
> Mar 27 14:46:50 localdomain postfix/lmtp[24750]: 6CEFF61:
> to=, orig_to=,
> relay=localdomain.com[/var/
> imap/socket/lmtp], delay=0.02, delays=0.01/0/0.01/0, dsn=2.1.5, status=sent
> (250 2.1.5 Ok SESSIONID=)
> Mar 27 14:46:50
addr(), so that
SASL authenticated connections might be re-used, but this looks
like a mistake, since we're therefore creating cached sessions that
will never be re-used, but that tie up LMTP server resources,
possibly leading to subsequent congestion under load.
> (2) Is this expected behavio
the configuration variables
regarding this have not changed.
The benchmark uses 3 emails, but generating 20 emails is sufficient to see
the bug.
After trials and errors and running out of ideas, I decided to bisect the code
to see what made this change.
It happens that version 2.11.1
A. Schulze:
>
> Viktor Dukhovni:
>
> > Your no-BDAT work-around is sufficient until the code is updated
> > along lines below
>
>
> Hello Viktor,
>
> Thanks for that patch. I confirm it works like expected
Did you test it in smtpd_end_of_data_restrictions?
Wietse
Viktor Dukhovni:
Your no-BDAT work-around is sufficient until the code is updated
along lines below
Hello Viktor,
Thanks for that patch. I confirm it works like expected
Andreas
A. Schulze:
> Hello,
>
> updated from 3.4.1 to 3.4.3 and at the same time dovecot-2.2 to dovecot-2.3 (
> + pigeonhole)
> I assume the changes behavior is dovecot/pigeonhole now using the advertised
> "CHUNKING" extension.
>
> Now an echo service (dovecot-2.3-pigeonhole) don't send messages
On Mon, Mar 11, 2019 at 11:48:56PM +0100, A. Schulze wrote:
> I assume the changes behavior is dovecot/pigeonhole now using the advertised
> "CHUNKING" extension.
Yes.
> Reason: "Data command rejected: Multi-recipient bounce" while there is
> clearly only one recipient.
>
> Mar 11 23:27:54
Hello,
updated from 3.4.1 to 3.4.3 and at the same time dovecot-2.2 to dovecot-2.3 ( +
pigeonhole)
I assume the changes behavior is dovecot/pigeonhole now using the advertised
"CHUNKING" extension.
Now an echo service (dovecot-2.3-pigeonhole) don't send messages anymore.
Reason: "Data command
On Sun, Mar 10, 2019 at 9:41 AM Scott Kitterman
wrote:
> My preference would be to press on with 3.4 (I don't mind packaging the
bug
> fixes if you don't mind releasing them), but if you are going to withdraw
3.4,
> please do it before next Sunday so I can keep it out of the next Debian
Daniele Nicolodi:
> On 10/03/2019 15:07, Wietse Venema wrote:
> > You are looking from the "we made improvements" angle. I am looking
> > from the "with hard work, we introduce 1 bug in 1000 lines of new
> > code" angle.
> >
> > In the TLS lib
On 10/03/2019 15:07, Wietse Venema wrote:
> You are looking from the "we made improvements" angle. I am looking
> from the "with hard work, we introduce 1 bug in 1000 lines of new
> code" angle.
>
> In the TLS library there were 1039 additions and 559 deletions
Viktor Dukhovni:
> On Sun, Mar 10, 2019 at 12:29:44PM -0400, Wietse Venema wrote:
>
> > > My preference would be to press on with 3.4 (I don't mind packaging the
> > > bug
> > > fixes if you don't mind releasing them), but if you are going to withdraw
> >
On Sun, Mar 10, 2019 at 12:29:44PM -0400, Wietse Venema wrote:
> > My preference would be to press on with 3.4 (I don't mind packaging the bug
> > fixes if you don't mind releasing them), but if you are going to withdraw
> > 3.4
> > please do it before next Sun
On Sun, Mar 10, 2019 at 02:34:02PM +, Scott Kitterman wrote:
> This worked just fine until 3.3.2-4 inclusive but since I've upgraded
> my sid system yesterday and Postfix was upgraded to 3.4.1-1 I see:
>
> postfix/smtp[15202]: warning: Trust anchor files not supported
>
Scott Kitterman:
> On Sunday, March 10, 2019 11:11:15 AM Wietse Venema wrote:
> > Scott Kitterman:
> > > I received the bug report/patch below from a Debian user. I'm somewhat
> > > busy this weekend/week, so I decided to forward it without evaluation
> > > ra
On Sun, 10 Mar 2019 11:41:01 -0400, Scott Kitterman stated:
>On Sunday, March 10, 2019 11:11:15 AM Wietse Venema wrote:
>> Scott Kitterman:
>> > I received the bug report/patch below from a Debian user. I'm
>> > somewhat busy this weekend/week, so I decided
To add a possible data point to the convo,
at least one distro, OpenSUSE, is already toying with apparently poorly
thought-thru patches (aka, not vetted/source here, from upstream) --
e,g, here,
On Sun, 10 Mar 2019 11:11:15 -0400 (EDT), Wietse Venema stated:
>Scott Kitterman:
>> I received the bug report/patch below from a Debian user. I'm
>> somewhat busy this weekend/week, so I decided to forward it without
>> evaluation rather than sit on it for a week u
On Sunday, March 10, 2019 11:11:15 AM Wietse Venema wrote:
> Scott Kitterman:
> > I received the bug report/patch below from a Debian user. I'm somewhat
> > busy this weekend/week, so I decided to forward it without evaluation
> > rather than sit on it for a week u
Scott Kitterman:
> I received the bug report/patch below from a Debian user. I'm somewhat busy
> this weekend/week, so I decided to forward it without evaluation rather than
> sit on it for a week until I could research it.
>
> I attempted to remove the distro specific noise
I received the bug report/patch below from a Debian user. I'm somewhat busy
this weekend/week, so I decided to forward it without evaluation rather than
sit on it for a week until I could research it.
I attempted to remove the distro specific noise from the report.
Scott K
Package: postfix
off".
Since this is about Postfix as shipped by Ubuntu and as packaged by Debian,
the bug tracker for one of those distributions is the appropriate place for
this discussion, not here. Apologies for not noticing which distro this was
about sooner.
Scott K
Marat Khalili:
> > Postfix from me installs with IPv6 turned off. Complain with your
> > distributor if they change that.
>
> Indeed default inet_protocols value in my distribution is "all", both in
> configuration created by install script and when corresponding line is
> commented out. Do you
On Thu, May 04, 2017 at 05:18:55PM +0300, Marat Khalili wrote:
> > Postfix from me installs with IPv6 turned off. Complain with your
> > distributor if they change that.
>
> Indeed default inet_protocols value in my distribution is "all", both in
> configuration created by install script and
Postfix from me installs with IPv6 turned off. Complain with your
distributor if they change that.
Indeed default inet_protocols value in my distribution is "all", both in
configuration created by install script and when corresponding line is
commented out. Do you mean, it is not supposed to
To disable outbound IPv6 in Postfix set "inet_protocols = ipv4". If you set
"inet_protocols" to some other value, then Postfix will do nexthop IPv6 lookups.
What will happen in my current setup if response suddenly becomes
non-empty? Will it fail to send the message?
--
With Best
sts both
> A and records of the relay from DNS, as I verified by tcpdump.
> Is it a bug or feature?
To disable outbound IPv6 in Postfix set "inet_protocols = ipv4". If you set
"inet_protocols" to some other value, then Postfix will do nexthop IPv6 lookups.
> (Y
s I verified by tcpdump. Is it
> a bug or feature? (Yes I know I can explicitly disable IPv6 in postfix
> configuration too, but that's not the point.)
Postfix from me installs with IPv6 turned off. Complain with your
distributor if they change that.
Wietse
> My investiga
Postfix is installed as forwarder to a fixed relay in a system with no
IPv6 addresses (disabled system-wide by net.ipv6.conf.*.disable_ipv6
lines in sysctl). Still, for each message it separately requests both A
and records of the relay from DNS, as I verified by tcpdump. Is it
a bug
Maurizio Caloro:
> Hello
>
> >From time to time I see on mail.log the following error message:
>
> Mar 22 23:29:43 mail postfix/verify[2206]: close database
> /var/lib/postfix/verify_cache.db: No such file or directory (possible
> Berkeley DB bug)
Indeed, the db-&g
Hello
>From time to time I see on mail.log the following error message:
Mar 22 23:29:43 mail postfix/verify[2206]: close database
/var/lib/postfix/verify_cache.db: No such file or directory (possible
Berkeley DB bug)
I have see found different answer, but I don't know which in furt
On 12/18/2016 09:38 PM, John Fawcett wrote:
> On 12/18/2016 02:09 AM, Wietse Venema wrote:
>> What if Postfix made an old-style query? I think it should just
>> report the old-style error here.
>>
>> Wietse
> I agree. It might be as simple as changing
>
> msg_warn("dict_mysql: stored
I have been working this code into Postfix, and have a comment
about error reporting for old-style queries.
> while ((host = dict_mysql_get_active(dict_mysql)) != NULL) {
> #if defined(MYSQL_VERSION_ID) && MYSQL_VERSION_ID >= 4
> @@ -536,9 +541,46 @@
> #endif
>
> if
On 11/27/2016 01:47 PM, John Fawcett wrote:
> On 11/23/2016 10:54 PM, j...@conductive.de wrote:
>> On 2016-11-23 21:57, John Fawcett wrote:
>>> On 11/22/2016 01:35 AM, Joel Linn wrote:
Hey Guys,
this issue has decayed a bit but I now finally found the time (and the
nerves) to
On 11/23/2016 10:54 PM, j...@conductive.de wrote:
> On 2016-11-23 21:57, John Fawcett wrote:
>> On 11/22/2016 01:35 AM, Joel Linn wrote:
>>> Hey Guys,
>>>
>>> this issue has decayed a bit but I now finally found the time (and the
>>> nerves) to integrate the fix in my system.
>>> I'm running
On 2016-11-23 21:57, John Fawcett wrote:
On 11/22/2016 01:35 AM, Joel Linn wrote:
Hey Guys,
this issue has decayed a bit but I now finally found the time (and the
nerves) to integrate the fix in my system.
I'm running Ubuntu 16.04 and trying not change to many things and be
able to have clean
On 11/22/2016 01:35 AM, Joel Linn wrote:
> Hey Guys,
>
> this issue has decayed a bit but I now finally found the time (and the
> nerves) to integrate the fix in my system.
> I'm running Ubuntu 16.04 and trying not change to many things and be
> able to have clean comparison I applied the patch to
Hey Guys,
this issue has decayed a bit but I now finally found the time (and the
nerves) to integrate the fix in my system.
I'm running Ubuntu 16.04 and trying not change to many things and be
able to have clean comparison I applied the patch to the apt sources and
only replaced the
John Fawcett:
> here is my proposed submission to add mysql stored procedure support to
> Postfix. As per Wietse's comments in the following thread
Thanks much. I'll examine it in the crumbs of available time.
Wietse
1 - 100 of 378 matches
Mail list logo
