Hello,
After checks I noticed that I had "1.1.1.1" in my resolv.conf. And that
this DNS was specified in my dhcpcd.conf (certainly a mistake on my side).
I deleted this entry in dhcpcd.conf and restarted the service. And no
more "1.1.1.1" in resolv.conf.
I tested to send an email from anoth
On 1/1/23 12:33, Bill Cole wrote:
also, private IP ranges should be excluded from checking in DNS lists.
Yes, but non sequitur...
... as your server connects to 192.168.1.160, I assume that servers
sees your address to be from private range too.
Nope, the connecting address is shown in the
On 2023-01-01 at 13:01:18 UTC-0500 (Sun, 1 Jan 2023 19:01:18 +0100)
Matus UHLAR - fantomas
is rumored to have said:
On 1/1/23 07:23, Forums wrote:
*/postfix/smtp[23430]: 4972423BAF: to=/**/,
relay=192.168.1.160[192.168.1.160]:25, delay=0.99,
delays=0.06/0.03/0.8/0.1, dsn=5.7.1, status=bounced
On 1/1/23 07:23, Forums wrote:
*/postfix/smtp[23430]: 4972423BAF: to=/**/,
relay=192.168.1.160[192.168.1.160]:25, delay=0.99,
delays=0.06/0.03/0.8/0.1, dsn=5.7.1, status=bounced (host
192.168.1.160[192.168.1.160] said: 554 5.7.1 Service unavailable;
Sender address [no-re...@mehl-family.fr] blo
On 1/1/23 07:23, Forums wrote:
*/postfix/smtp[23430]: 4972423BAF: to=/**/,
relay=192.168.1.160[192.168.1.160]:25, delay=0.99,
delays=0.06/0.03/0.8/0.1, dsn=5.7.1, status=bounced (host
192.168.1.160[192.168.1.160] said: 554 5.7.1 Service unavailable; Sender
address [no-re...@mehl-family.fr] blo
Hello,
I have an issue with Postfix after a new OS installation (64bits instead
of 32bits).
OS : raspi-os (Debian for Raspberry Pi, my mailserver run on a Raspberry Pi)
What I've done:
- OS 64bits installation
- Softwares installation (Dovecot, Postfix, Clamav, Spamassassin,
Ope
Ok, Thank you for these useful clarifications
Samuel
Le lun. 4 oct. 2021 à 17:27, Viktor Dukhovni a
écrit :
> On Mon, Oct 04, 2021 at 04:34:39PM +0200, Sam R wrote:
>
> > Now it's working fine!
> >
> > I finally succeeded. I worked around by increasing only the value of the
> > line_length_limi
On Mon, Oct 04, 2021 at 04:34:39PM +0200, Sam R wrote:
> Now it's working fine!
>
> I finally succeeded. I worked around by increasing only the value of the
> line_length_limit option to 12288 ( same value as the default for
> smtpd_sasl_response_limit )
That's the right thing to do when the cl
Now it's working fine!
I finally succeeded. I worked around by increasing only the value of the
line_length_limit option to 12288 ( same value as the default for
smtpd_sasl_response_limit )
And create a specific keytab file containing the SPN (
/etc/postfix/smtp.keytab )
But I haven't thought ab
Good morning Viktor,
Thank you for all this information, I will do the necessary for the keytabs
right away.
Concerning the clients, it is Thunderbird under Windows 10, the AD server
being Samba4. I will try to see why the Kerberos ticket is so long. I don't
think the problem is with Thunderbird b
On Fri, Oct 01, 2021 at 12:47:29PM -0400, Viktor Dukhovni wrote:
> > -- basics --
> > Postfix: 3.5.6
>
> Since you're using Postfix 3.5, which by default supports long SASL
> messages after the initial response, your client is in violation of the
> SMTP SASL specification, and needs to have a bug
On Fri, Oct 01, 2021 at 04:17:03PM +0200, Sam R wrote:
> I added two keytab in /etc/krb5.keytab
There's your problem, the /etc/krb5.keytab file, given services like SSH
with GSSAPI authentication, contains secrets sufficient to login to the
host as any user, possibly including root. It must belo
Hello,
Le 01/10/2021 à 16:17, Sam R a écrit :
Hello,
I want to set up a Postfix SMTP server with cyrus-sasl in GSSAPI mode.
I have two Samba4 servers in AD mode, and my clients are in windows 10.
I removed the execution of Posfix in chroot to simplify.
I added two keytab in /etc/krb5.keytab s
Hello,
I want to set up a Postfix SMTP server with cyrus-sasl in GSSAPI mode. I
have two Samba4 servers in AD mode, and my clients are in windows 10.
I removed the execution of Posfix in chroot to simplify.
I added two keytab in /etc/krb5.keytab smtp/smtptest.domain.fr and host/
smtptest.domain.fr
On 2021-05-12 21:27, Noel Jones wrote:
Oh, and remove any permit_sasl_authenticated from the entries in
main.cf - assuming that no authenticated users should be using port
25.
and make sure main.cf does not have smtpd_sasl_auth_enable=yes
common mistakes
On 5/12/2021 2:21 PM, Noel Jones wrote:
On 5/12/2021 2:11 PM, David Mehler wrote:
Hello,
Thanks. Here's my master.cf submission entry:
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_aut
On 5/12/2021 2:11 PM, David Mehler wrote:
Hello,
Thanks. Here's my master.cf submission entry:
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrict
Hello,
Thanks. Here's my master.cf submission entry:
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milte
On 5/12/2021 12:26 PM, David Mehler wrote:
Hello,
I'm running Postfix 3.6, I just upgraded. I do not know if this issue
occurred because of the upgrade or prior to it as I hadn't sent any
mail through this account lately.
I'm having an issue with spf, error log below, if I comment out check
p
Hello,
I'm running Postfix 3.6, I just upgraded. I do not know if this issue
occurred because of the upgrade or prior to it as I hadn't sent any
mail through this account lately.
I'm having an issue with spf, error log below, if I comment out check
policy for spf under recipient_restrictions thin
Samuel Mutel:
> Hello,
>
> I encountered some issues with postfix when the /var/spool/postfix is on a
> glusterfs.
> The postfix queue is blocked suddenly and no more mail is sent.
>
> I don't know exactly what the issue is with GlusterFS ? Is-it a particular
> option to use when mounting the par
Samuel> I encountered some issues with postfix when the
Samuel> /var/spool/postfix is on a glusterfs. The postfix queue is
Samuel> blocked suddenly and no more mail is sent.
Please see http://www.postfix.org/DEBUG_README.html and re-send your
problem with the right details.
Samuel> I don't kno
Hello,
I encountered some issues with postfix when the /var/spool/postfix is on a
glusterfs.
The postfix queue is blocked suddenly and no more mail is sent.
I don't know exactly what the issue is with GlusterFS ? Is-it a particular
option to use when mounting the partition ?
Thanks in advance to
On 05 Oct 2020, at 13:17, Bob Proulx wrote:
> Here is an old resource but one that I think is still very good is
> "Jim Seymour's suggestions/examples for Postfix anti-UCE configuration."
>
>http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt
It's good, but it does need some updating as some
Erik Thuning wrote:
> Ranjan Maitra wrote:
> > Thanks, I am not very knowledgeable with regard to postfix being a
> > simple user, so do you mind letting me/us know what you had to fix? It
> > is kind of forbidding to me.
> >
> > > Thank you! I had this exact issue and just couldn't wrap my head a
I set the following in main.cf:
smtpd_relay_restrictions = permit_mynetworks, reject
Which, if I understand correctly, should mean that any email coming from
addresses specified in mynetworks will be accepted, while all others get
rejected.
Mynetworks in my case only specifies loopback addre
Hi,
Thanks, I am not very knowledgeable with regard to postfix being a simple user,
so do you mind letting me/us know what you had to fix? It is kind of forbidding
to me.
Thanks again and best wishes,
Ranjan
On Fri, 2 Oct 2020 15:52:34 +0200 Erik Thuning wrote:
> Thank you! I had this exac
Thank you! I had this exact issue and just couldn't wrap my head around
what was wrong, this solved things quite nicely.
/T
On 2020-10-02 00:00, Bob Proulx wrote:
Ranjan Maitra wrote:
> > > Oct 1 14:08:00 localhost postfix/smtpd[4142479]: fatal: in
parameter smtpd_relay_restrictions or smtpd
Ranjan Maitra wrote:
> > > Oct 1 14:08:00 localhost postfix/smtpd[4142479]: fatal: in parameter
> > > smtpd_relay_restrictions or smtpd_recipient_restrictions, specify at
> > > least one working instance of: reject_unauth_destination,
> > > defer_unauth_destination, reject, defer, defer_if_perm
>
> On Oct 1, 2020, at 2:18 PM, Ranjan Maitra wrote:
>
> Thanks, very much. So when I hit "Send" on sylpheed, it goes on a tailspin,
> and says: Connecting to SMTP server: localhost
>
> Looking at the /var/log/maillog as you suggested, I get:
>
> Oct 1 14:08:00 localhost postfix/smtpd[414247
On Thu, 1 Oct 2020 15:39:55 -0400 "Demi M. Obenour"
wrote:
> On 2020-10-01 15:18, Ranjan Maitra wrote:
> > Thanks, very much. So when I hit "Send" on sylpheed, it goes on a tailspin,
> > and says: Connecting to SMTP server: localhost
> >
> > Looking at the /var/log/maillog as you suggested, I g
On 2020-10-01 15:18, Ranjan Maitra wrote:
> Thanks, very much. So when I hit "Send" on sylpheed, it goes on a tailspin,
> and says: Connecting to SMTP server: localhost
>
> Looking at the /var/log/maillog as you suggested, I get:
>
> Oct 1 14:08:00 localhost postfix/smtpd[4142479]: fatal: in pa
Thanks, very much. So when I hit "Send" on sylpheed, it goes on a tailspin, and
says: Connecting to SMTP server: localhost
Looking at the /var/log/maillog as you suggested, I get:
Oct 1 14:08:00 localhost postfix/smtpd[4142479]: fatal: in parameter
smtpd_relay_restrictions or smtpd_recipient_r
Hi.
I'd start with checking your logs (i.e. "/var/log/maillog")
On Thu, Oct 1, 2020 at 10:01 PM Ranjan Maitra wrote:
> Hi,
>
> I have an issue that I can not resolve at my work environment.
>
> When I use commandline mail, my e-mail gets delivered.
>
> However, when I use a mailer (like sylpheed
Hi,
I have an issue that I can not resolve at my work environment.
When I use commandline mail, my e-mail gets delivered.
However, when I use a mailer (like sylpheed) to use localhost, it does not get
delivered. I have SMTP port set to the default, and this same setup works fine
when I send e-
> On Feb 19, 2019, at 11:15 AM, A. Schulze wrote:
>
>> I've not tested what happens
>> with server-side operation in that case, does it refuse service, or
>> try and fail in some manner?
>
> unsure if that's a open question or you expect me something to test?
I am not sure either. :-) I you wa
> On Feb 19, 2019, at 10:50 AM, A. Schulze wrote:
>
>>> Feb 19 13:28:53 spider postfix/tlsproxy[1061]: warning: No server certs
>>> available. TLS can't be enabled
>>
>> For me, applying the patch
>> made the segfaults in a certificateless proxy configuration
>> go away.
>
> indeed, my fault /
Am 19.02.19 um 14:28 schrieb A. Schulze:
>
> A. Schulze:
>
>> Viktor Dukhovni:
>>
>>> diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
>>> diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
>
> there is an other side effect:
>
> I configured
> smtpd_tls_cert_file = /etc/ssl/$
Am 19.02.19 um 15:37 schrieb Viktor Dukhovni:
>> On Feb 19, 2019, at 7:35 AM, A. Schulze wrote:
>>
>> Feb 19 13:25:53 spider postfix/master[2282]: warning: process
>> /usr/lib/postfix/tlsproxy pid 996 killed by signal 11
>> Feb 19 13:25:53 spider postfix/master[2282]: warning:
>> /usr/lib/pos
> On Feb 19, 2019, at 7:35 AM, A. Schulze wrote:
>
> Feb 19 13:25:53 spider postfix/master[2282]: warning: process
> /usr/lib/postfix/tlsproxy pid 996 killed by signal 11
> Feb 19 13:25:53 spider postfix/master[2282]: warning:
> /usr/lib/postfix/tlsproxy: bad command startup -- throttling
> Feb
A. Schulze:
Viktor Dukhovni:
diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
there is an other side effect:
I configured
smtpd_tls_cert_file = /etc/ssl/${myhostname}/cert+intermediate.pem
smtpd_tls_key_file = /etc/ssl/${m
Viktor Dukhovni:
diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
Another issue remains, in that tlsproxy(8) wants
unconditional server-side support before it is willing to be a
client proxy, and therefore also wants server
Viktor Dukhovni:
> Do you want to do that now in a 3.4.0-RC3? Or save the cleanup
> for 3.5?
I wanted to understand why the code is "organized" as it is, as
kinda sorta parallel worlds, instead of client-server style delegation.
I understand that with the proposed code organization, we can relea
On Mon, Feb 18, 2019 at 02:48:32PM -0500, Wietse Venema wrote:
> > > Should we remove the those calls and make tls_pre_jail_init() a
> > > mandatory call?
> >
> > I considered making the pre-jail init mandatory, but decided not
> > to mess with posttls-finger, and left them in place.
>
> We shou
Viktor Dukhovni:
> On Mon, Feb 18, 2019 at 12:05:40PM -0500, Wietse Venema wrote:
>
> > > diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> > > index 01dda8a97..a4a88a392 100644
> > > --- a/src/tls/tls_misc.c
> > > +++ b/src/tls/tls_misc.c
> > > @@ -772,6 +772,8 @@ voidtls_pre_jail_init(T
On Mon, Feb 18, 2019 at 12:05:40PM -0500, Wietse Venema wrote:
> > diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> > index 01dda8a97..a4a88a392 100644
> > --- a/src/tls/tls_misc.c
> > +++ b/src/tls/tls_misc.c
> > @@ -772,6 +772,8 @@ voidtls_pre_jail_init(TLS_ROLE role)
> > };
> >
Am 18.02.19 um 12:04 schrieb Viktor Dukhovni:
> diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
Hello Viktor,
I confirm these modifications fix the delivery failure.
... $ sendmail -f sen...@example.org -bv recipi...@gerve
Viktor Dukhovni:
> On Mon, Feb 18, 2019 at 02:07:29AM -0500, Viktor Dukhovni wrote:
>
> > Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
> > sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
> > subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
> >
> > These callbacks are NOT
On Mon, Feb 18, 2019 at 02:07:29AM -0500, Viktor Dukhovni wrote:
> Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
> sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
> subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>
> These callbacks are NOT expected.
diff --git a/sr
On Sun, Feb 17, 2019 at 10:31:05PM +0100, A. Schulze wrote:
> ok, so I start silent testing ...
>
> https://andreasschulze.de/tmp/reuse_on.txt
> https://andreasschulze.de/tmp/reuse_off.txt
Thanks, these get us much closer to the source of the problem.
Something about the way the way that chain v
Wietse Venema:
> A. Schulze:
> > https://andreasschulze.de/tmp/reuse_on.txt
> > https://andreasschulze.de/tmp/reuse_off.txt
>
> These deliver to different server IP addresses, therefore the
> results may differ.
One is:
Feb 17 22:11:53 mail postfix/smtp[23428]:
sys1.mmini.de[2a01:4f8:162:32ac:
Am 17.02.19 um 22:40 schrieb Wietse Venema:
> A. Schulze:
>> https://andreasschulze.de/tmp/reuse_on.txt
>> https://andreasschulze.de/tmp/reuse_off.txt
>
> These deliver to different server IP addresses, therefore the
> results may differ.
the destination MX has IPv4 and IPv6 working. Depends
A. Schulze:
> https://andreasschulze.de/tmp/reuse_on.txt
> https://andreasschulze.de/tmp/reuse_off.txt
These deliver to different server IP addresses, therefore the
results may differ.
Wietse
Am 17.02.19 um 21:24 schrieb Viktor Dukhovni:
Hello Viktor,
> If you performed a "reload" to get that to take effect, that would
> also have flushed the TLS session cache. And perhaps disabling
> connection re-use is a distraction. It may well have been sufficient
> to just "postfix reload".
On Sun, Feb 17, 2019 at 02:41:27PM +0100, A. Schulze wrote:
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse" Now
> I notice delivery problems to "gervers.com".
The DNS configuration for this domain is:
gervers.com. IN MX 10 sys1.mmini.de. ; NoError AD=1
sys1.mmini
A. Schulze:
>
>
> Am 17.02.19 um 18:23 schrieb Wietse Venema:
> > Conclusion: Postfix works as expected?
>
> hard to say...
>
> delivery deferred if smtp_tls_connection_reuse = yes
> delivery works if smtp_tls_connection_reuse = no
Is the problem that certificate verification failure handling
Am 17.02.19 um 18:23 schrieb Wietse Venema:
> Conclusion: Postfix works as expected?
hard to say...
delivery deferred if smtp_tls_connection_reuse = yes
delivery works if smtp_tls_connection_reuse = no
http://www.postfix.org/TLS_README.html#client_tls_reuse say "As of Postfix 3.4,
TLS connec
Wietse Venema:
> How do those 'other' connections differ from what is shown above?
A. Schulze:
> I don't see differences. This tlsproxy process handled a connection
> to gmail, outlook.com and some other destinations. All unverified
> because I did not configure the matching root certificates.
Co
Am 17.02.19 um 16:10 schrieb Wietse Venema:
> How do those 'other' connections differ from what is shown above?
I don't see differences. This tlsproxy process handled a connection to gmail,
outlook.com and some other destinations. All unverified because I did not
configure the matching root c
A. Schulze:
>
>
> Am 17.02.19 um 15:24 schrieb Wietse Venema:
> > A. Schulze:
> >> Hello,
> >>
> >> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
> >> Now I notice delivery problems to "gervers.com". DANE setup looks OK.
> >> https://dane.sys4.de/smtp/gervers.com
> >>
>
Am 17.02.19 um 15:24 schrieb Wietse Venema:
> A. Schulze:
>> Hello,
>>
>> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
>> Now I notice delivery problems to "gervers.com". DANE setup looks OK.
>> https://dane.sys4.de/smtp/gervers.com
>>
>> "posttls-finger gervers.com" a
A. Schulze:
> Hello,
>
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
> Now I notice delivery problems to "gervers.com". DANE setup looks OK.
> https://dane.sys4.de/smtp/gervers.com
>
> "posttls-finger gervers.com" also show
> posttls-finger: Verified TLS connection est
Am 17.02.19 um 14:41 schrieb A. Schulze:
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
corrected the subject, as DANE is not necessary related here.
Hello,
I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
Now I notice delivery problems to "gervers.com". DANE setup looks OK.
https://dane.sys4.de/smtp/gervers.com
"posttls-finger gervers.com" also show
posttls-finger: Verified TLS connection established to
sys1.mmini.de[2
On 21/03/2014 17:25, Wietse Venema wrote:
Nick Warr:
On 21/03/2014 16:54, Viktor Dukhovni wrote:
On Fri, Mar 21, 2014 at 02:24:49PM +, Nick Warr wrote:
This is the entry in master.cf
dfilt unix- n n - - pipe
flags=Rq user=filter argv=/etc/postf
Nick Warr:
> On 21/03/2014 16:54, Viktor Dukhovni wrote:
> > On Fri, Mar 21, 2014 at 02:24:49PM +, Nick Warr wrote:
> >
> >> This is the entry in master.cf
> >>
> >> dfilt unix- n n - - pipe
> >> flags=Rq user=filter argv=/etc/postfix/disclaimer -f ${s
On 21/03/2014 16:54, Viktor Dukhovni wrote:
On Fri, Mar 21, 2014 at 02:24:49PM +, Nick Warr wrote:
This is the entry in master.cf
dfilt unix- n n - - pipe
flags=Rq user=filter argv=/etc/postfix/disclaimer -f ${sender} --
${recipient}
Any advice o
On Fri, Mar 21, 2014 at 02:24:49PM +, Nick Warr wrote:
> This is the entry in master.cf
>
> dfilt unix- n n - - pipe
> flags=Rq user=filter argv=/etc/postfix/disclaimer -f ${sender} --
> ${recipient}
>
> Any advice or recommendations?
Edit the filte
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.4.0
MIME-Version: 1.0
To: postfix-users@postfix.org
Subject: A strange issue with postfix and altermime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I a
I am running a CentOS 6.3 server with postfix 2.6 and altermime 0.3.10.
I use altermime to append disclaimers to emails submitted by my users
through port port 587, and 99.95% of the time it works without issue,
recently we've had a few issues with messages sent from Mac Outlook
clients, the i
On Tue, Oct 22, 2013 at 01:15:06PM +0300, Deniss wrote:
> > So this is definitely a version of the broken Windows TLS ciphersuite
> > problem. If you must use TLS with this server, disable TLSv1.2
> > and 3DES, allow medium grade ciphers (i.e. RC4) and make sure your
> > policy tables, ... are po
On 2013.10.21. 23:31, Viktor Dukhovni wrote:
>
> Once again after the handshake completes.
>
> When I try:
>
> $ posttls-finger -t30 -T 180 -c -Ldebug "[mail.co.inbox.lv]"
> posttls-finger: initializing the client-side TLS engine
> posttls-finger: Connected to mail.co.inbox.lv[195.
On Mon, Oct 21, 2013 at 10:22:05PM +0300, Deniss wrote:
> >Show all related logging from process 21730.
>
> Oct 21 21:35:01 box postfix/smtp[19887]:
> warning: TLS library problem: 19887:error:1408F10B:
> SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
> Oct 21 21:35:01 box p
Date:
From:
Subject: [none]
On Sun, Oct 20, 2013 at 08:55:33PM +0300, Deniss wrote:
I have an issue with postfix-2.10.2 and latest MS
windows/exchange/outlook: SSL connection cannot be negotiated with
default settings, there is an error in postfix log:
Oct 20 20:13:41 box postfix/smtp[21730
On Sun, Oct 20, 2013 at 08:55:33PM +0300, Deniss wrote:
> I have an issue with postfix-2.10.2 and latest MS
> windows/exchange/outlook: SSL connection cannot be negotiated with
> default settings, there is an error in postfix log:
> Oct 20 20:13:41 box postfix/smtp[21730]: warning:
Hello,
I have an issue with postfix-2.10.2 and latest MS
windows/exchange/outlook: SSL connection cannot be negotiated with
default settings, there is an error in postfix log:
Oct 20 20:13:41 box postfix/smtp[21730]: warning: TLS library problem:
21730:error:1408F10B:SSL
It's true I don't have your experience as you are the postfix coders.
But it's also true you don't know what can be my expericence.
Considering your political answers since the beginning, embarassing for who?
You're right that's enough. I'm going to answer you in private.
Envoyé de mon iPad
Le
> sorry, but after following the thread you are not qualified
> enough to judge design-patterns of a software you do not
> understand enough
I agree totally on that. That's why I write in the users mailing list, not in
the developpers mailing list.
To stop this thread that is borring for everybo
You're right that's enough and I'll answer you in private.
Wietse Venema a écrit :
> Nicolas HAHN:
>> The "archietcture" is not a good excuse for me, I'm sorry. As a
>> coder, allowing a software to start despite the fact there is a
>> FATAL is a total non-sens. And saying finally that is just a
Am 24.04.2013 19:45, schrieb Nicolas HAHN:
> The "archietcture" is not a good excuse for me, I'm sorry. As a coder
well, that's the difference between "coder" and "delevoper"
a "coder" writes something which works for now and every
few years all is thrown away because the architecture
and softw
Nicolas HAHN:
> The "archietcture" is not a good excuse for me, I'm sorry. As a
> coder, allowing a software to start despite the fact there is a
> FATAL is a total non-sens. And saying finally that is just a daemon
> which will not run but the others will, I really don't know how
> to take it...
On Wed, Apr 24, 2013 at 07:45:52PM +0200, Nicolas HAHN wrote:
> The "archietcture" is not a good excuse for me, I'm sorry.
You don't yet known enough about Postfix to appreciate the answer,
this is not your fault, but the design is fine.
--
Viktor.
The "archietcture" is not a good excuse for me, I'm sorry. As a coder, allowing
a software to start despite the fact there is a FATAL is a total non-sens. And
saying finally that is just a daemon which will not run but the others will, I
really don't know how to take it...
And you can daemonize
On Wed, Apr 24, 2013 at 05:23:09PM +0200, Nicolas HAHN wrote:
> > Can you post the fatal error messages you found, especially the
> > messages that log why the queue manager was restarting, as that
> > is the real problem.
>
> Here is what I found:
>
> 2013-04-24T10:04:38.005665+00:00 iccpfxor04
Yea. Thanks, i've seen it the first time you posted it.
But that's not for this reason I'll change my mind about this.
BR.
nicolas
Wietse Venema a écrit :
> Nicolas HAHN:
>> What I consider just abnormal as already written is that for me
>> (so it's my opinion), Postfix should refuse to start
Nicolas HAHN:
> What I consider just abnormal as already written is that for me
> (so it's my opinion), Postfix should refuse to start when it detects
> a fatal about a configuration issue in the config files. But it
> starts any way and display each minute the fatal in the log file.
If you think
> Can you post the fatal error messages you found, especially the
> messages that log why the queue manager was restarting, as that
> is the real problem.
Here is what I found:
2013-04-24T10:04:38.005665+00:00 iccpfxor04 postfix/local[9370]: fatal: main.cf
configuration error: mailbox_size_limit
On Wed, Apr 24, 2013 at 04:47:26PM +0200, Nicolas HAHN wrote:
> This is a reply to myself because I'm reviewing the way it works.
>
> > Yes, but if I'm right, the log message is emitted at the time there
> > is an e-mail processed (by postfix/local for my issue).
>
> In fact, the fatal is writt
This is a reply to myself because I'm reviewing the way it works.
> Yes, but if I'm right, the log message is emitted at the time there
> is an e-mail processed (by postfix/local for my issue).
In fact, the fatal is written in the logs each minute and 1 second for this
issue in my case by the
Nicolas HAHN:
> Yes, but if I'm right, the log message is emitted at the time there
> is an e-mail processed (by postfix/local for my issue).
>
> What I'm speaking about there is that postfix should check the
> configuration for this issue (for example) at the time it is started
> or its configura
This story also makes me think, suddenly, that I should integrate in my Log
Search Tool a feature allowing real time fatal error catching (and not only
fatal) form postfix logs and real time alerting of the users using the tool in
case a fatal comes during e-mail procesing. Will see that for ver
Yes, but if I'm right, the log message is emitted at the time there is an
e-mail processed (by postfix/local for my issue).
What I'm speaking about there is that postfix should check the configuration
for this issue (for example) at the time it is started or its configuration is
reloaded, and R
Nicolas HAHN:
> Postfix feature request: that would be nice that Postfix be able
> to do this kind of basic checks by itself when starting (or when
> configuration is reloaded) between various inter-dependent
> configuration settings, and display in the logs at least some
> warnings when such kind
> 1. Don't send bounces to postmaster, just generate and read log summaries
> that may highlight aggregate problems with your mail stream.
>
> notify_classes =
>
> This applies to any MTA handing mail for a large number of users,
> it is fine to have postmaster notices for a ma
On Wed, Apr 24, 2013 at 03:37:17PM +0200, Nicolas HAHN wrote:
> > More likely you have a mailbox size limit smaller than the message
> > size limit.
>
> Yes, that's the reason. I completely forgot to check the matching
> between both settings.
>
> The mailbox size limit was set to its default va
> More likely you have a mailbox size limit smaller than the message
> size limit.
Yes, that's the reason. I completely forgot to check the matching between both
settings.
The mailbox size limit was set to its default value of 50 Mb. After setting it
to 150 Mb, the issue was fixed.
Note: the b
Nicolas HAHN:
Content-Description: Version texte brut du message
[ Charset ISO-8859-1 unsupported, converting... ]
> OK.
>
> I did some tries and it seems that I cannot go above 40 Mb for
> message_size_limit to avoid the issue.
>
> As you wrote, here below is a set of log lines during the issu
On Wed, Apr 24, 2013 at 03:22:14PM +0200, Nicolas HAHN wrote:
> 2013-04-24T12:32:01.442962+00:00 iccpfxor04 postfix/qmgr[24391]: 6B34360BAA:
> from=, size=8389, nrcpt=1 (queue
> active)
> 2013-04-24T12:36:09.981198+00:00 iccpfxor04 postfix/qmgr[27126]: 6B34360BAA:
> from=, size=8389, nrcpt=1 (q
> Postfix memory usage does not depend on message size. Far more
> likely some filter has message size issues, or perhaps mailbox_size_limit
> has not been raised to match, or the OP failed to reload Postfix, so that
> the message size limit was different in some processes.
Each time I've reloade
Am 24.04.2013 15:22, schrieb Nicolas HAHN:
> As you wrote, here below is a set of log lines during the issue. The emails
> staying in the growing active queue are
> the bounce messages (we intercept them to send a copy to postmaster):
>
> [root@iccpfxor04 postfix]# grep 6B34360BAA /var/log/mail
1 - 100 of 129 matches
Mail list logo
