* Will Yardley post...@veggiechinese.net:
On Mon, Sep 15, 2014 at 04:54:11AM +, Viktor Dukhovni wrote:
* Your DNS resolution is not functioning, which could also
explain slow login, but in this case, you'd generally max
out the smtpd(8) process limit.
Yes, this one
* Patrick Ben Koetter postfix-users@postfix.org:
* Will Yardley post...@veggiechinese.net:
On Mon, Sep 15, 2014 at 04:54:11AM +, Viktor Dukhovni wrote:
* Your DNS resolution is not functioning, which could also
explain slow login, but in this case, you'd generally max
On Mon, Sep 15, 2014 at 08:29:47AM +0200, Patrick Ben Koetter wrote:
A good way to check if this bug applies to your case is to cat /proc/mounts |
grep unbound. As you can see there are several mounts in place in my example:
I don't see any of these at the present, but will look if / when
Wietse Venema writes:
[join vs union]
I think there is something to be said for either name. It does not matter to
me, I think you should decide on a name, if you should choose to include
such functionality, to ensure it fits with Postfix's naming conventions
best.
That was a
hi
postfix 2.11.1-1 from debian jessie amd64
this server is using an EC cert not RSA
eventually, the email gets sent in the clear
any help appreciated
openssl on the server reports ok:
OpenSSL 1.0.1i 6 Aug 2014
$ openssl s_client -cipher SSLv3 -starttls smtp -connect
if i have an EC mail server cert and if an MTA setup to send/receive
gives the following:
$ openssl s_client -cipher ECDH -starttls smtp -connect
medusa.blackops.org:25
CONNECTED(0003)
139821090178704:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake
if i have an EC mail server cert and if an MTA setup to send/receive?
gives the following:
$ openssl s_client -cipher ECDH -starttls smtp -connect
medusa.blackops.org:25
CONNECTED(0003)
139821090178704:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake
shmick:
CONNECTED(0003)
139821090178704:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:762:
medusa.blackops.org smtp *SERVER* just doesn't support the selected cipher.
does that mean it cannot connect *to* me because it doesn't have any EC
A. Schulze wrote:
shmick:
CONNECTED(0003)
139821090178704:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:762:
medusa.blackops.org smtp *SERVER* just doesn't support the selected cipher.
does that mean it cannot connect *to* me because
Dennis L wrote:
if i have an EC mail server cert and if an MTA setup to send/receive?
gives the following:
$ openssl s_client -cipher ECDH -starttls smtp -connect
medusa.blackops.org:25
CONNECTED(0003)
139821090178704:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert
On Sun, Sep 14, 2014 at 11:42:24PM -0700, Will Yardley wrote:
On Mon, Sep 15, 2014 at 08:29:47AM +0200, Patrick Ben Koetter wrote:
A good way to check if this bug applies to your case is to cat
/proc/mounts | grep unbound. As you can see there are several
mounts in place in my example:
On Mon, Sep 15, 2014 at 05:16:19PM +1000, shm...@riseup.net wrote:
if i have an EC mail server cert and if an MTA setup to send/receive
gives the following:
Always configure at least some sort of RSA certificate along with
any ECDSA certificates. The RSA certificate can be self-signed.
Many
Viktor Dukhovni wrote:
On Mon, Sep 15, 2014 at 05:16:19PM +1000, shm...@riseup.net wrote:
if i have an EC mail server cert and if an MTA setup to send/receive
gives the following:
Always configure at least some sort of RSA certificate along with
any ECDSA certificates. The RSA
On Tue, Sep 16, 2014 at 12:00:33AM +1000, shm...@riseup.net wrote:
Viktor Dukhovni wrote:
On Mon, Sep 15, 2014 at 05:16:19PM +1000, shm...@riseup.net wrote:
if i have an EC mail server cert and if an MTA setup to send/receive
gives the following:
Always configure at least some sort
Roel van Meer:
That was a question that I had about the proposed implementation.
The current behavior loses information about which inputs do/don't
contribute to a result.
In the proposed implementation, only the *original* input contributes to a
result.
My question is no longer about
On Mon, Sep 15, 2014 at 11:36:54AM +0300, Dennis L wrote:
Do you have this in your main.cf? I think it may fix your issue.
smtpd_tls_ciphers = export
Unlikely to be the problem, and is the default setting.
--
Viktor.
Hi,
I enabled postscreen deep protocol tests in postfix 2.11.1 and found this
problem with Amazon. I see these entries in the log:
Sep 14 12:41:45 ti74 postfix/postscreen[18143]: [ID info] CONNECT from
[54.240.13.2]:36074 to [38.76.0.61]:25
Sep 14 12:41:51 ti74 postfix/postscreen[18143]: [ID
Viktor Dukhovni wrote:
On Tue, Sep 16, 2014 at 12:00:33AM +1000, shm...@riseup.net wrote:
Viktor Dukhovni wrote:
On Mon, Sep 15, 2014 at 05:16:19PM +1000, shm...@riseup.net wrote:
if i have an EC mail server cert and if an MTA setup to send/receive
gives the following:
Always configure
Andrew J. Schorr:
Hi,
I enabled postscreen deep protocol tests in postfix 2.11.1 and found this
problem with Amazon. I see these entries in the log:
Sep 14 12:41:45 ti74 postfix/postscreen[18143]: [ID info] CONNECT from
[54.240.13.2]:36074 to [38.76.0.61]:25
Sep 14 12:41:51 ti74
On Mon, Sep 15, 2014 at 10:39:22AM -0400, Wietse Venema wrote:
If someone specifies multiple maps, each map is given the same
query. When only some of the maps produce a result, what should
the final result be:
- The result is not found. This is may be desirable in some cases.
Right
Wietse Venema wrote:
As long as the SMTP session still exists, the client may still make
a mistake, and postscreen will not whitelist it.
Thanks for the explanation. I am surprised that Amazon's mailservers are so
stupid.
Don't use deep protocol tests if they cause problems. These tests
are
Am 15.09.2014 um 18:19 schrieb Andrew J. Schorr:
Wietse Venema wrote:
As long as the SMTP session still exists, the client may still make
a mistake, and postscreen will not whitelist it.
Thanks for the explanation. I am surprised that Amazon's mailservers are so
stupid.
Don't use deep
Andrew J. Schorr:
Wietse Venema wrote:
As long as the SMTP session still exists, the client may still make
a mistake, and postscreen will not whitelist it.
Thanks for the explanation. I am surprised that Amazon's mailservers are so
stupid.
Don't use deep protocol tests if they cause
Wietse Venema wrote:
A possible option is to periodically grab the SPF records of Amazon,
Google, and the like, and to whitelist those IP addresses permanently.
I had been hoping that the whitelisting would obviate the need to do
something like this. Perhaps with the extra whitelists that I
li...@rhsoft.net wrote:
what i recently implemented was
* give thx MX a second IP
* add it everywehere as backup-mx
* disable postcreen WL on that IP
I am doing the same thing here. It is helpful, but I don't think it solves all
problems. The implicit greylisting of the deep protocol tests
Am 15.09.2014 um 22:31 schrieb Andrew J. Schorr:
li...@rhsoft.net wrote:
what i recently implemented was
* give thx MX a second IP
* add it everywehere as backup-mx
* disable postcreen WL on that IP
I am doing the same thing here. It is helpful, but I don't think it solves all
Lots of logs of postfix trying to talk to spamexperts.com and
aspmx.X.google.com Only problem is, I'm not connected to the Internet,
so this is never going to work :-) I can't find anything relevant in
any of the postfix files, so... how do I tell it to quit trying?
--
Am 15.09.2014 um 23:09 schrieb John Oliver:
Lots of logs of postfix trying to talk to spamexperts.com and
aspmx.X.google.com Only problem is, I'm not connected to the Internet,
so this is never going to work :-) I can't find anything relevant in
any of the postfix files, so... how do I tell
Andrew J. Schorr:
Wietse Venema wrote:
A possible option is to periodically grab the SPF records of Amazon,
Google, and the like, and to whitelist those IP addresses permanently.
I had been hoping that the whitelisting would obviate the need to do
something like this. Perhaps with the
Extract the queue-ids from the logs and hold those messages for later
delivery:
postsuper -h queue-id (or postsuper -h ALL to hold everything in the queue)
to un-hold:
postqueue -H queue-id (or postsuper -H ALL to un-hold everything in HOLD)
-Original Message-
From:
On Mon, Sep 15, 2014 at 5:42 PM, Marius Gologan
marius.golo...@gmail.com wrote:
Extract the queue-ids from the logs and hold those messages for later
delivery:
postsuper -h queue-id (or postsuper -h ALL to hold everything in the queue)
to un-hold:
postqueue -H queue-id (or postsuper -H ALL to
The IETF has just published a new RFC that specifies particular enhanced status
codes for email authentication failures:
https://www.rfc-editor.org/rfc/rfc7372.txt
I have a policy server for which this is relevant. I'd like to provide an
enhanced status code for Postfix to use, but I don't
On Mon, Sep 15, 2014 at 08:40:24PM -0400, Scott Kitterman wrote:
The IETF has just published a new RFC that specifies particular enhanced
status codes for email authentication failures:
https://www.rfc-editor.org/rfc/rfc7372.txt
I see little in this document that a policy service can
On September 15, 2014 9:09:03 PM EDT, Viktor Dukhovni
postfix-us...@dukhovni.org wrote:
On Mon, Sep 15, 2014 at 08:40:24PM -0400, Scott Kitterman wrote:
The IETF has just published a new RFC that specifies particular
enhanced
status codes for email authentication failures:
34 matches
Mail list logo
