On Thu, May 14, 2020 at 02:01:31AM -0500, Thomas Strike wrote:
> > So I would not expect virtual alias tables to be appropriate as alias
> > tables. What problem are you actually trying to solve?
>
> I'm hosting multiple domains and I'm using virtual host tables. I am
> not sure that I have a
On Thu, May 14, 2020 at 07:48:27AM +0200, Matus UHLAR - fantomas wrote:
> Can't that be kind of sender verification where the SMTP client doesn't
> cleanly close TLS connection?
>
> shouldn't we focus on failed client connections? [No we should not]
Would I be wasting my time and the OP's
On Thu, May 14, 2020 at 08:53:42AM +0200, Tobi wrote:
> using your suggestion with valgrind I found that the main-stacksize
> seems to be the problem. By using --main-stacksize with different values
> I found that the last working value is 59449345, changing to ...344 let
> postmap segfault:
But
Hi Wietse
using your suggestion with valgrind I found that the main-stacksize
seems to be the problem. By using --main-stacksize with different values
I found that the last working value is 59449345, changing to ...344 let
postmap segfault:
> valgrind -s --main-stacksize=59449344 --tool=memcheck
On 5/13/20 4:29 PM, Viktor Dukhovni wrote:
On Wed, May 13, 2020 at 03:42:47PM -0500, Thomas Strike wrote:
Postfix is trying to access the aliases table in the postfix db with a
wrong file name and directory. I thought I had this fixed yesterday but
it is showing up again today.
I changed the
I am a novice to Postfix and only have to deal with setting up a new
mail server every couple of years or so. This is only my 3rd time
setting Postfix up in the past 10 years. Over time things change and
every time I do this I have to learn it all over again. With all the
extensive
On Thu, May 14, 2020 at 02:38:09PM -0400, Wietse Venema wrote:
> Viktor Dukhovni:
> > Alternatively, we could siglongjmp() out of a segfault handler, enabled
> > around PCRE lookups, leaking whatever heap space libpcre may have
> > allocated along the way, and log a more informative message, and
On Thu, May 14, 2020 at 06:20:17PM -0700, Alexander Vasarab wrote:
> The plot thickens.
>
> In a nutshell, the problem is "solved" by changing the virtual(8) hosts
[ That's virtual(5) by the way, but not important. ]
> to use UNIX domain sockets (rather than e.g. 127.0.0.1). In both cases,
>
I think it is a fundamental question on what your goal is: To
send/receive mail under any circumstance or force a minimum security
level.
With that it is important to distinguish between receiving mail and
sending. The issue with leaving every old option available is, that
broken tls versions or
Thomas Strike:
> The following cryptic line is given as the reason;
>
> .
>
> .
>
> .
>
> .
>
> BOUNCE postfix-users@postfix.org: Admin request of type /^\s*config\b/i
> at line 3
>
>
> How do I correct this?
Look at line 3 of the rejected email message.
Wietse
On 5/14/20 2:51 PM, Wietse Venema wrote:
Thomas Strike:
The following cryptic line is given as the reason;
.
.
.
.
BOUNCE postfix-users@postfix.org: Admin request of type /^\s*config\b/i
at line 3
How do I correct this?
Look at line 3 of the rejected email message.
Wietse Venema:
> Thomas Strike:
> > Thought: I am assuming that Postfix is only reading from the main.cf and
> > master.cf files. Could it be possible that Postfix is trying to use
> > main.cf* and master.cf*?
>
> On 5/14/20 12:28 PM, Wietse Venema wrote:
> > Type "postfix reload" and report the
On Thu, May 14, 2020 at 09:07:29AM -0300, SysAdmin EM wrote:
> postfix-out/smtp[12931]: E30639204ED: to=,
> relay=hotmail-com.olc.protection.outlook.com[104.47.124.33]:25,
> delay=1.4, delays=0.08/0/1.4/0, dsn=5.5.4, status=bounced
> (host hotmail-com.olc.protection.outlook.com[104.47.124.33]
>
* Thomas Strike:
> The following cryptic line is given as the reason
Not quite cryptic, just a regular expression. ;-) Make sure your subject
line does not match this expression (the first case-insensitive word of
the subject, after 0-n optional consecutive spaces, must not be "config").
-Ralph
On 5/14/20 2:33 PM, Ralph Seichter wrote:
* Thomas Strike:
The following cryptic line is given as the reason
Not quite cryptic, just a regular expression. ;-) Make sure your subject
line does not match this expression (the first case-insensitive word of
the subject, after 0-n optional
Which logs are you talking about. After setting up Postfix and Dovcot,
everything reports to var/log/maillog. Postfix doesn't report it's conf
files that it loaded from there, only that it reloaded. Is there other
logs hidden somewhere?
On 5/14/20 12:28 PM, Wietse Venema wrote:
Thomas
Thomas Strike:
> Thought: I am assuming that Postfix is only reading from the main.cf and
> master.cf files. Could it be possible that Postfix is trying to use
> main.cf* and master.cf*?
On 5/14/20 12:28 PM, Wietse Venema wrote:
> Type "postfix reload" and report the main.cf filename in the logs.
Viktor Dukhovni:
> Alternatively, we could siglongjmp() out of a segfault handler, enabled
> around PCRE lookups, leaking whatever heap space libpcre may have
> allocated along the way, and log a more informative message, and thereby
> perhaps even avoid occasional service throttling in master
The following cryptic line is given as the reason;
.
.
.
.
BOUNCE postfix-users@postfix.org: Admin request of type /^\s*config\b/i
at line 3
How do I correct this?
On 13/05/20 21:58 -0400, Viktor Dukhovni wrote:
Please rebuild, and post another similar set of logs.
Thanks. Attached.
Alexander
May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: connect from []
May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio:
hsfunc=0x7f310ef3a780,
Tobi:
> Hi Wietse
>
> using your suggestion with valgrind I found that the main-stacksize
> seems to be the problem. By using --main-stacksize with different values
> I found that the last working value is 59449345, changing to ...344 let
> postmap segfault:
>
> > valgrind -s
I posted the note below Saturday but having seen no acknowledgement from
Wietse, wanted to make sure it wasn’t overlooked although it’s very minor.
To summarize what’s below, the default value of maillog_file_rotate_suffix is
%Y%M%d-%H%M%S which puts minutes where you expect month. It should be
Wietse, Viktor
It seems that this is the problematic part of the pcre pattern
>
/^Content-(Disposition|Type).*name\s*=\s*("(?:[^"]|\\")*|[^();:,\/<>\@\"?=<>\[\]\
]*)
I tested by replacing star by star with explicit limits and found that
limits avoid the segfault. I replaced the last two stars
14.05.20, 03:32 CEST, Viktor Dukhovni:
> Are any other Debian users seeing similar issues?
I did grep for "TLS library problem"[1] an 2 Debian 10 servers (low
volume, though) and didn't find anything that seemed related.
[1] The following came up empty:
$ zgrep -i "TLS library problem"
On 14/05/20 01:40 -0400, Viktor Dukhovni wrote:
I'f you're comfortable with gdb, and willing to build both Postfix and
OpenSSL from source with debugging symbols, then you could add a "-D"
flag to the "smtpd" entry in the /opt/postfix/etc/master.cf file, and
attach to a "screen" running a
On Mon, May 11, 2020 at 11:43:41AM -0700, Alexander Vasarab wrote:
> May 11 11:23:54 vasaconsulting postfix/smtpd[21870]: warning: TLS
> library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown
> while in init:../ssl/ssl_lib.c:2086:
The patch below avoids spurious SSL_ERROR_SSL
Larry Stone:
> I posted the note below Saturday but having seen no acknowledgement from
> Wietse, wanted to make sure it wasn?t overlooked although it?s very minor.
>
> To summarize what?s below, the default value of maillog_file_rotate_suffix is
> %Y%M%d-%H%M%S which puts minutes where you
Tobi:
> So the problem is definitely our pattern in combination with a VERY big
> mime part header. We're on introducing limits where we can in our patterns.
> Anyway I think that this should not end in such an ugly error where
> postfix cleanup goes south because of such header/pattern
Matus UHLAR - fantomas:
> >> On 07.05.20 12:26, Matus UHLAR - fantomas wrote:
> >> >I ust received mail where user specified destination address:
> >> >@example@example.com
> >> >
> >> >the mail was accepted and forwarded to "empty_address_recipient",
> >> >
> >> >which docs' say:
> >> >
> >>
Hello,
I have two servers running on Postfix, one of which runs version 2.10.1 and
the other server runs version 3.4.7.
On the server where I am running verion 3.4.7, I receive "501 5.5.4 Invalid
domain name" errors in emails sent to different servers. Rhe mail is sent
to postfix through exim
On Thursday, May 14, 2020 1:40:38 AM EDT Viktor Dukhovni wrote:
> On Wed, May 13, 2020 at 10:01:24PM -0700, Alexander Vasarab wrote:
> > May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio:
> > hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(36) = 0
> > May 13 21:56:38
As some test suite recommendations might be harsher than what is practical
I thought I'd check with the people who actually work on Postfix.
1) some test sites say TLS 1.0 should be disabled for NIST compliance. Is
that recommended? What about 1.1?
2) is there a page that has up-to-date
On 5/14/20 2:18 AM, Viktor Dukhovni wrote:
Have you looked in master.cf? Are you looking at the right main.cf
file?
Look in the output of "postconf -n" and "postconf -M".
Yes. and postconf doesn't list this path/file in any -n, -m, -M, -p, or
-d. I have only one main.cf and one master.cf
> As some test suite recommendations might be harsher than what is practical I
> thought I'd check with the people who actually work on Postfix.
>
> 1) some test sites say TLS 1.0 should be disabled for NIST compliance. Is
> that recommended? What about 1.1?
The devices will negotiate the best
Thomas Strike:
> Thought: I am assuming that Postfix is only reading from the main.cf and
> master.cf files. Could it be possible that Postfix is trying to use
> main.cf* and master.cf*?
Type "postfix reload" and report the main.cf filename in the logs.
Wietse
On Thu, May 14, 2020 at 10:04:44AM -0400, Wietse Venema wrote:
> Once a program runs out of stack space, that is is an unrecoverable
> error.
A cursory glance at the PCRE2 docs suggests that we can ask libpcre
to enforce more conservative limits before it runs out of stack, and
it would
On 14 May 2020, at 13:06, Thomas Strike wrote:
I looked in postconf -d | grep 'mynetworks ' and the following came
up. Could this error be caused by any of this stuff? Does Postfix
really use all of this or is it superfluous and widening the SMTPd
server for attach?
'postconf -d' shows you
> Thanks. When tweaks may have been made over the years, is there a page in the
> docs that just has a clean list of defaults for master.cf? Or check the .dist
> files?
You suspect tweaks have been made to your system? Use
postconf -n | grep tls
postconf -M | grep tls
to find out. Go
On Thu, May 14, 2020 at 12:56:46PM -0400, Ian Evans wrote:
> As some test suite recommendations might be harsher than what is practical
> I thought I'd check with the people who actually work on Postfix.
The most important question is: are you talking about mandatory or
opportunistic TLS. All
> If you are curious about the defaults in your Postfix use
> postconf | grep tls
That should be:
postconf -d | grep tls
br, Petri
smime.p7s
Description: S/MIME cryptographic signature
On Thu, May 14, 2020 at 12:06:34PM -0500, Thomas Strike wrote:
> This error is still showing up in the log but it doesn't appear to be
> causing any problems that I have detected.
>
> "May 12 14:21:44 sleepyvalley postfix/smtpd[16326]: error: open
> /etc/postfix/mysql-aliases.cf: No such file
Viktor Dukhovni:
> On Thu, May 14, 2020 at 10:04:44AM -0400, Wietse Venema wrote:
>
> > Once a program runs out of stack space, that is is an unrecoverable
> > error.
>
> A cursory glance at the PCRE2 docs suggests that we can ask libpcre
> to enforce more conservative limits before it runs out
On Thu, May 14, 2020 at 01:40:23PM -0400, Wietse Venema wrote:
> > A cursory glance at the PCRE2 docs suggests that we can ask libpcre
> > to enforce more conservative limits before it runs out of stack, and
> > it would presumably then unwind and return a recoverable error.
>
> That looks like
43 matches
Mail list logo
