Hello
Could anyone download the latest 2.12-20140518 snapshot ?
thanks
--
Levi
Birta Levente:
> Hello
>
> Could anyone download the latest 2.12-20140518 snapshot ?
My mistake. 2.12-20140516 is the latest snapshot. The 20140518
date stamp is valid only for the non-production release.
Wietse
Hi,
I am currently working on an outgoing SMTP relay.
Nothing magic about that but what I like to achieve is a way to reroute
rejected mail to another SMTP relay.
Has somebody been facing the same question and found a solution for it?
Kind regards,
John
Am 20.05.2014 10:54, schrieb John Donath:
> I am currently working on an outgoing SMTP relay.
>
> Nothing magic about that but what I like to achieve is a way to reroute
> rejected mail to another SMTP relay.
>
> Has somebody been facing the same question and found a solution for it?
wrong ap
John Donath:
> Hi,
>
> I am currently working on an outgoing SMTP relay.
>
> Nothing magic about that but what I like to achieve is a way to
> reroute rejected mail to another SMTP relay.
You want to send mail "direct to the internet" and when that fails
you want to relay it via the provider? Th
ADH is susceptible to MITM attacks, but I can't seem to turn it off.
I've tried various permutations of
tls_preempt_cipherlist = yes
tls_high_cipherlist (with !DH and !ADH)
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high
I'm running 2.9.6 on Debian Wheezy.
An
Am 20.05.2014 13:03, schrieb Colin Fowler:
> ADH is susceptible to MITM attacks, but I can't seem to turn it off.
>
> I've tried various permutations of
>
> tls_preempt_cipherlist = yes
> tls_high_cipherlist (with !DH and !ADH)
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
> smtpd_tls_mandat
On 20-05-2014 12:16, li...@rhsoft.net wrote:
Am 20.05.2014 13:03, schrieb Colin Fowler:
ADH is susceptible to MITM attacks, but I can't seem to turn it off.
I've tried various permutations of
tls_preempt_cipherlist = yes
tls_high_cipherlist (with !DH and !ADH)
smtpd_tls_mandatory_protocols =
On Tue, May 20, 2014 at 12:03:29PM +0100, Colin Fowler wrote:
> ADH is susceptible to MITM attacks, but I can't seem to turn it off.
Opportunistic TLS, which is all that is possible for SMTP without
DANE (DNSSEC with TLSA records for SMTP) is vulnerable to multiple
MiTM attacks, and turning off N
* li...@rhsoft.net 2014.05.20 13:16:
> a few days ago we had a genius with troubles caused by !SSLv3
Nice one. Not really sure your slander is the result of your language skills or
you actually gain something from calling other people names. In any case you
miserably failed to elaborate how to
Am 20.05.2014 14:25, schrieb Thomas Leuxner:
> * li...@rhsoft.net 2014.05.20 13:16:
>
>> a few days ago we had a genius with troubles caused by !SSLv3
>
> Nice one. Not really sure your slander is the result of your language
> skills or you actually gain something from calling other people na
On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:
> In any case you miserably failed to elaborate how to mitigate
> the issue other than stating 'revert the change'.
Without defending the tone of that advice, I'd like to affirm its
technical content. Receiving MTAs should not disab
* Viktor Dukhovni 2014.05.20 14:44:
> Most other "hardening" configuration changes are likely to reduce,
> rather than improve SMTP transport security.
Thank you for your detailed explanation Viktor!
signature.asc
Description: Digital signature
Thank you Viktor for your reply!
On 20-05-2014 13:44, Viktor Dukhovni wrote:
On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:
In any case you miserably failed to elaborate how to mitigate
the issue other than stating 'revert the change'.
Without defending the tone of that advi
On 20.05.2014 15:11, Colin Fowler wrote:
> Thank you Viktor for your reply!
>
> On 20-05-2014 13:44, Viktor Dukhovni wrote:
>> On Tue, May 20, 2014 at 02:25:49PM +0200, Thomas Leuxner wrote:
>>
>>> In any case you miserably failed to elaborate how to mitigate
>>> the issue other than stating 'reve
Am 20.05.2014 15:11, schrieb Colin Fowler:
> Is it not true though that allowing weak features merely
> gives the illusion of security? It could be argued that a
> weak method is technically no better than no encryption
not in reality
with no encryption at all any boy sharing the same
WLAN i
On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:
> >Opportunistic TLS is sometimes counter-intuitive, attempting to
> >make it stronger by removing weaker features actually makes it
> >weaker. Don't give in to the urge to tweak TLS settings, they
> >are largely fine as they are.
> >
Thank you Viktor (and other commenters)
One of the primary reasons I use {ostfix is because of its great track
record in security (its stability, performance and feature set are also
great too). It would be foolish of me to disregard the devs who have
achieved helped give Postfix its recommend
On Tue, May 20, 2014 at 02:35:04PM +0100, Colin Fowler wrote:
> BTW, this whole thing came about from me testing using
> https://starttls.info/ which scored what I thought was a well secured server
> quite badly. I see now that the testing site is itself the problem, not my
> original config.
Yep
As the initiator of https://starttls.info/ (developed and run by Einar
Otto Stangvik), let me just say that I've e-mailed this list earlier on
this topic.
While Viktor shows very clearly why starttls by itself is insufficient
through his IETF draft, I still personally vote for disabling SSLv2 and
"Useless" and "Clueless" is rather harsh Viktor, and you most certainly
don't us what we're trying to accomplish.
Fact is we've achieved quite a lot by launching this service, several
ISPs have implemented STARTTLS, same goes for large companies and
government organisations after launch and media
On Tue, May 20, 2014 at 03:58:22PM +0200, Per Thorsheim wrote:
> I still personally vote for disabling SSLv2
Which is the default in Postfix.
> and ANON ciphers used with STARTTLS as we do today. My reasoning is simple:
And simply wrong:
http://tools.ietf.org/html/draft-ietf-dane-smtp-with
On 20 May 2014, at 15:25, Viktor Dukhovni wrote:
> On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:
>
>> I've heard anecdotes of clients not using the best mutually supported
>> encryption and instead just using whatever's first in the list of methods
>> accepted by the server. I do
On Tue, May 20, 2014 at 02:21:22PM +, Viktor Dukhovni wrote:
> Please change your site to reflect the correct risk model (opportunistic
> TLS). You should also add support for DANE, so that DANE-capable
> MTAs are not mis-identified as insecure (for example DANE-EE(3)
> certificate usage obvi
On 20.05.2014 16:21, Viktor Dukhovni wrote:
We did discuss and
change the scoring soon after the service launched, while originally
being based on the scoring system from Ivan Ristic @ Qualys at
ssllabs.com for https. Yes, perhaps stupid, but it seemed better than
creating our own scoring system.
Hi Wietse,
Thanks very much for your advise; the solution you proposed worked
straight-away!
Regards,
John
From: owner-postfix-us...@postfix.org [owner-postfix-us...@postfix.org] on
behalf of Wietse Venema [wie...@porcupine.org]
Sent: Tuesday, May 20, 20
Hi Viktor,
On Tue, May 20, 2014 at 14:21:22 +, Viktor Dukhovni wrote:
> Facebook made the same mistakes you did:
>
> http://www.metzdowd.com/pipermail/cryptography/2014-May/021344.html
In that thread you say that CA certs are futile for SMTP servers.
I think that the statement is untrue
27 matches
Mail list logo
