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 u
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 curiosit
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 Schet
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 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,
>> opportu
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 respon
On Mon, Mar 03, 2014 at 11:34:20AM -0500, Wietse Venema wrote:
> Ralf Hildebrandt:
> > * Wietse Venema :
> >
> > > > 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 ema
Ralf Hildebrandt:
> * Wietse Venema :
>
> > > 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 :-) After ponder
* 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 months*
> unti
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 unavaila
> 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 unavail
* Wietse Venema :
> > 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 90 46 64
Franzisk
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 ev
Wietse Venema:
> Ralf Hildebrandt:
> > * Viktor Dukhovni :
> >
> > > 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 (p
Ralf Hildebrandt:
> * Viktor Dukhovni :
>
> > 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 e
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 eve
* Viktor Dukhovni :
> 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.
--
[*] sys4 AG
http:
-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 Postfi
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 i
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 on
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
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
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 wise
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
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.
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 B
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 re
-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. An
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
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 offe
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]
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
32 matches
Mail list logo
