That's a good point.
The number is only for encrypted, not authenticated and it looks like we
don't currently log verification.
We do CA verification and a GSuite domain can choose to require it for a
connection, but we don't use the
information generally. Presumably when we finish our STS and
On 07/28/2017 05:19 PM, Brandon Long wrote:
>
> We're hovering at 88% encrypted, inbound & outbound, if those in charge
> decided to move the needle, they could
> probably start a path along the likes of what Chrome is doing
>
On Fri, Jul 28, 2017 at 5:58 AM, Michael Orlitzky
wrote:
> On 07/27/2017 01:44 PM, Dave Warren wrote:
> >>
> >> "Even if it were generally possible to determine a secure server name,
> >> the SMTP client would still need to verify that the server's
> >> certificate chain is
On 07/28/2017 02:10 AM, Vittorio Bertola wrote:
On the Web, instead, users do want to know which company is actually
running the website that they are visiting, and not just that they are
really connecting to that hostname, so CAs offer additional value in
respect to DANE.
Full STOP!
I
In article <808816365.710.1501249729...@appsuite.open-xchange.com> you write:
>> The practical reason is that unencrypted SMTP has to work if you want to
>> be able to communicate with the world. ...
>This, by the way, is another advantage of DANE. By publishing a TLSA record
>for the
On 07/28/2017 06:58 AM, Michael Orlitzky wrote:
If someone connects to me and I don't like his CA, he
can fall back to plain text and I have to allow it (because of the
bajillions of people who don't do TLS over SMTP at all).
I disagree. You do have the choice to not accept messages over an
Our Spam Auditors reported a large outbreak yesterday, but they still
fell under the 'too big to flag', without other specific variables in
place.. (eg, Confirmed Malware, length of time of outbreak, etc..)
But it was large, triggered alerts at over 25% of the telco's we monitor..
On
according to their postmaster page
(https://postmaster.gmx.net/en/email-server) the IPs behind
mout-xforward.gmx.net are used for forward mails and mailer daemons. So
no surprise that they are listed.
It would be more concerning if mout.gmx.net IPs would be listed.
On 07/28/2017 04:47 PM, Benoit
https://www.spamhaus.org/sbl/query/SBL229646
This one is a pretty old listing.
Kirk MacDonald
-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Benoit Panizzon
Sent: Friday, July 28, 2017 11:47 AM
To: mailop@mailop.org
Subject: [mailop] GMX on various
Hi
http://multirbl.valli.org/lookup/82.165.159.13.html
Blacklisted: 17
Anyone knows if some outbreak just got GMX thrown in that many
lists?
-Benoît Panizzon-
--
I m p r o W a r e A G-Leiter Commerce Kunden
__
Zurlindenstrasse 29
> Il 28 luglio 2017 alle 14.58 Michael Orlitzky ha scritto:
>
> The practical reason is that unencrypted SMTP has to work if you want to
> be able to communicate with the world. So, adding a second more-secure
> channel *in addition to* the existing unsecured channel doesn't really
>
On 07/27/2017 01:44 PM, Dave Warren wrote:
>>
>> "Even if it were generally possible to determine a secure server name,
>> the SMTP client would still need to verify that the server's
>> certificate chain is issued by a trusted CA (a trust anchor).
>>
>
> I've never understood why this is a
> Il 27 luglio 2017 alle 23.48 Brandon Long via mailop ha
> scritto:
>
> Well, yes, that is the DANE argument in a nutshell. That doesn't mean
> it's correct, and there are reasons why DANE was not the solution chosen for
> the browser market.
>
Can I ask which
13 matches
Mail list logo