On 03.03.2014 18:06, Viktor Dukhovni wrote:
The problem is indeed man-made. DO NOT unilaterally configure
mandatory TLS. To use TLS, the other side has to signal support
for TLS (be it a bilateral agreement to use mandatory TLS,
opportunistic DANE TLS, or just STARTTLS in the EHLO
Am 04.03.2014 09:25, schrieb Robert Sander:
On 03.03.2014 18:06, Viktor Dukhovni wrote:
The problem is indeed man-made. DO NOT unilaterally configure
mandatory TLS. To use TLS, the other side has to signal support
for TLS (be it a bilateral agreement to use mandatory TLS,
opportunistic
Am 04.03.2014 09:49, schrieb Robert Schetterer:
an acceptable workaround, your man made problem was no suprise.
Nobody said it's a surprise.
And: It's not a spurprise and not a man made problem, but an
interesting new use-case where we can provide additional mailadresses
with TLS-encrypted
Am 04.03.2014 10:24, schrieb Peer Heinlein:
But the user need's a fast DSN if the enforced TLS is
not possible.
as written ,an acceptable workaround for this is possible, reread the
postfix docs, or code stuff yourself, as you are an expert shouldnt be
too hard
Best Regards
MfG Robert
On 04/03/2014 10:24, Peer Heinlein wrote:
And: It's not a spurprise and not a man made problem, but an
interesting new use-case where we can provide additional mailadresses
with TLS-encrypted SMTP (next hop)-transfer to/from the recipient's
provider.
Hello,
just for the sake of curiosity,
On Tue, Mar 04, 2014 at 10:24:06AM +0100, Peer Heinlein wrote:
And: It's not a surprise and not a man made problem, but an
interesting new use-case where we can provide additional mailadresses
with TLS-encrypted SMTP (next hop)-transfer to/from the recipient's
provider.
The forced use of
* Wietse Venema wie...@porcupine.org:
Yes, but the delay notice is (probably!) too cryptic for the end-user.
Nonsense. It is the exact same error message that you want Postfix
to send in a bounce email.
None of the users actually read this :(
--
[*] sys4 AG
http://sys4.de, +49 (89) 30
The error mesage being one of:
TLS is required, but host %s refused to start TLS: %s
TLS is required, but was not offered by host %s
TLS is required, but our TLS engine is unavailable
%s: TLS is required but unavailable, don't know why
TLS is required, but unavailable
Am 03.03.2014 15:44, schrieb Ralf Hildebrandt:
The error mesage being one of:
TLS is required, but host %s refused to start TLS: %s
TLS is required, but was not offered by host %s
TLS is required, but our TLS engine is unavailable
%s: TLS is required but unavailable, don't
* li...@rhsoft.net li...@rhsoft.net:
that may also be the MUA
in case of a iPhone you can reject with whatever status code
you like in case of sending without authentication and the
device will try to do the same every 5 minutes
i had a customer doing this for the same message of *3
Ralf Hildebrandt:
* Wietse Venema wie...@porcupine.org:
Yes, but the delay notice is (probably!) too cryptic for the end-user.
Nonsense. It is the exact same error message that you want Postfix
to send in a bounce email.
None of the users actually read this :(
No surprise :-)
On Mon, Mar 03, 2014 at 11:34:20AM -0500, Wietse Venema wrote:
Ralf Hildebrandt:
* Wietse Venema wie...@porcupine.org:
Yes, but the delay notice is (probably!) too cryptic for the end-user.
Nonsense. It is the exact same error message that you want Postfix
to send in a bounce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 27.02.2014 20:15, schrieb Wietse Venema:
Fifth option (best): short queue life time, to that Postfix does
not give up after the first MX host failure...
...but to that Postfix will start having Problems with Greylistung and
that makes Postfix
* Viktor Dukhovni postfix-users@postfix.org:
It is far easier to enable fast delay notices, or set a very short
maximal queue lifetime if fast failure is more appropriate than
eventual success for the messages being sent.
Yes, but the delay notice is (probably!) too cryptic for the end-user.
Peer Heinlein:
Am 27.02.2014 20:15, schrieb Wietse Venema:
Fifth option (best): short queue life time, to that Postfix does
not give up after the first MX host failure...
...but to that Postfix will start having Problems with Greylistung and
that makes Postfix bouncing mails even in
Ralf Hildebrandt:
* Viktor Dukhovni postfix-users@postfix.org:
It is far easier to enable fast delay notices, or set a very short
maximal queue lifetime if fast failure is more appropriate than
eventual success for the messages being sent.
Yes, but the delay notice is (probably!) too
Wietse Venema:
Ralf Hildebrandt:
* Viktor Dukhovni postfix-users@postfix.org:
It is far easier to enable fast delay notices, or set a very short
maximal queue lifetime if fast failure is more appropriate than
eventual success for the messages being sent.
Yes, but the delay
On Fri, Feb 28, 2014 at 09:16:56AM +0100, Peer Heinlein wrote:
Fifth option (best): short queue life time, to that Postfix does
not give up after the first MX host failure...
...but to that Postfix will start having Problems with Greylistung and
that makes Postfix bouncing mails even in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.02.2014 14:43, schrieb Wietse Venema:
You got it. That's what we ARE doing and that's why I'm asking for. :-)
That's my actual workaround. But it's nothing more then a workaround.
We have situations, where a mail MUST send using TLS.
Peer Heinlein:
You got it. That's what we ARE doing and that's why I'm asking for. :-)
Well this is a very non-standard deployment. I have to spend my
limited cycles wisely on things that benefit the most people.
We have situations, where a mail MUST send using TLS. And I need a
FAST and
Am 27.02.2014 18:48, schrieb Wietse Venema:
Are you blindly requiring TLS without even thinking about whether
the remote party supports it?
Yes, and the DSN should inform the user about that fact in a timely manner.
Regards
--
Robert Sander
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119
Robert Sander:
Am 27.02.2014 18:48, schrieb Wietse Venema:
Are you blindly requiring TLS without even thinking about whether
the remote party supports it?
Yes, and the DSN should inform the user about that fact in a timely manner.
Well the otions are:
- Have a lot of patience.
-
On Thu, Feb 27, 2014 at 12:48:47PM -0500, Wietse Venema wrote:
Peer Heinlein:
You got it. That's what we ARE doing and that's why I'm asking for. :-)
Well this is a very non-standard deployment. I have to spend my
limited cycles wisely on things that benefit the most people.
We have
Am 27.02.2014 19:28, schrieb Viktor Dukhovni:
On Thu, Feb 27, 2014 at 12:48:47PM -0500, Wietse Venema wrote:
Peer Heinlein:
You got it. That's what we ARE doing and that's why I'm asking for. :-)
Well this is a very non-standard deployment. I have to spend my
limited cycles wisely on
Fourth option (mentioned before) use a short delay warning time
or message queue life time, so that Postfix does not give
up after the first MX host failure.
Wietse
Fourth option (mentioned before): short delay warning time.
Fifth option (best): short queue life time, to that Postfix does
not give up after the first MX host failure.
Wietse
On Thu, Feb 27, 2014 at 07:33:29PM +0100, li...@rhsoft.net wrote:
Also TLS is a transport mechanism, but transport failure is not
message failure. Equating transport failure with message failure
is semantically flawed.
Are all the destinations in question served by exactly one MX
Viktor Dukhovni:
On Thu, Feb 27, 2014 at 07:33:29PM +0100, li...@rhsoft.net wrote:
Also TLS is a transport mechanism, but transport failure is not
message failure. Equating transport failure with message failure
is semantically flawed.
Are all the destinations in question
At the moment it's a soft failure if a TLS connection fails due to
cipher or protocol mismatches and if tls-encryption is enforced.
F266840008 3238274 Tue Feb 25 08:32:09 x...@example.com
(TLS is required, but was not offered by host
mx3.me.com.akadns.net[17.172.34.64])
I'd like to have this
Peer Heinlein:
At the moment it's a soft failure if a TLS connection fails due to
cipher or protocol mismatches and if tls-encryption is enforced.
F266840008 3238274 Tue Feb 25 08:32:09 x...@example.com
(TLS is required, but was not offered by host
mx3.me.com.akadns.net[17.172.34.64])
On Tue, Feb 25, 2014 at 09:06:50AM +0100, Peer Heinlein wrote:
At the moment it's a soft failure if a TLS connection fails due to
cipher or protocol mismatches and if tls-encryption is enforced.
F266840008 3238274 Tue Feb 25 08:32:09 x...@example.com
(TLS is required, but was not offered
Wietse Venema:
Assuming that you haven't configured a global policy of all mail
deliveries shall use TLS,
that's exactly the limitation Peer has in mind.
Andreas
32 matches
Mail list logo
