No subject

Tue Jul 23 12:40:59 CEST 2013

And apparently this only escalated because we failed to address it in private,
during support, which he claims did not respond to him:

<a href=""></a>
<a href=""></a>

That's not cool, at all.

He also states that Qualys is irrelevant as response, because it never tests
SMTP ports, see end of this conversation:

<a href=""></a>

This reputational risk is still severe, and live.

We need a public page on the kind of settings we're using for what, and why.

So likely an explanation of the kind:

 SMTP -&gt; only incoming, fairly liberal because any encryption is better than
 SUBMISSION -&gt; user mail transport, using only strong cyphers: [details]
 HTTP -&gt; never used
 HTTPS -&gt; strongest setup, following these principles: [details]

HSTS &amp; Co as general principles.

Also, any improvement to this setup would be always good, as per
<a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED --- - Improve SMTP/IMAP/HTTP encryption settings to pass"
   href="show_bug.cgi?id=3209#c0"></a> guidelines and such.

But keep in mind that these are different applications, protocols, ports.

So we need a per-protocol policy explanation and configuration background, also
for ourselves. With a public version that explains how this is the best
possible at the moment.

And meanwhile I'll look into getting ourselves a better cert with SHA256, for
that's obviously needed. I'll likely be looking at an organisational verified
cert, and am thinking to up the &quot;Swissness&quot; of things for marketing purposes,
and because of <a href=""></a>

So * seems like what we want.

Which means we will need to update our configuration a bit, and need to think
how to handle the transition from .com to .ch.</pre>
      <span>You are receiving this mail because:</span>
          <li>You are on the CC list for the bug.</li>


More information about the websites-team mailing list