Re: [mailop] [EXTERNAL] Re: Disabling TLS1.0 for SMTP

2018-05-25 Thread Marc Bradshaw via mailop
Worth collecting some data on, we collect metrics on ingress for ciphers used and key sizes but not on tls verion, I'll add that to what we collect. - Original message - From: Vittorio Bertola To: "Brotman, Alexander" ,

Re: [mailop] Disabling TLS1.0 for SMTP

2018-05-25 Thread Renaud Allard via mailop
On 05/22/2018 04:47 PM, Al Iverson wrote: Are folks disabling TLS1.0 support in SMTP? Our security team has asked, but I'm a bit concerned about potential failure cases when trying to deliver mail to smaller corporate sites that might be doing stuff like requiring TLS but supporting 1.0

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Graeme Fowler
On 25 May 2018, at 10:46, Paul Smith wrote: > But, how it interacts with email, it all seems to get very horrible. I > suspect the *intention* is OK, but I'm struggling with the actual regulations. Whilst this specific article (written by Andrew Cormack of Jisc UK) pertains to

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Leo Gaspard via mailop
On 05/25/2018 12:14 PM, Rolf E. Sonneveld wrote: > Yes, dealing with exactly the same kind of problem(s). One of my > customers asks me to sign for the fact that mail is encrypted when > handling it. However, using standard MTA software, messages that are in > the queue waiting to get delivered,

Re: [mailop] Yahoo DKIM Signing, not folding the header..

2018-05-25 Thread Marc Bradshaw via mailop
My testing shows signatures from both aol and yahoo not being folded, but I don't really see that as a problem. Yahoo signatures used to be folded, I guess there was an OATH related infrastructure change recently, with as you say a change from mx.aol.com to aol.com. They have been consistently not

[mailop] GDPR and SMTP in general

2018-05-25 Thread Paul Smith
I've been going through some GDPR stuff. Amongst other things, we provide SMTP relay services to some customers, so are a 'Data Processor' under GDPR. In itself, that's OK as our own operations are GDPR compliant. But, how it interacts with email, it all seems to get very horrible. I suspect

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Rolf E. Sonneveld
Hi, Paul, On 25-05-18 11:46, Paul Smith wrote: I've been going through some GDPR stuff. Amongst other things, we provide SMTP relay services to some customers, so are a 'Data Processor' under GDPR. In itself, that's OK as our own operations are GDPR compliant. But, how it interacts with

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Paul Smith
On 25/05/2018 11:14, Rolf E. Sonneveld wrote: Yes, dealing with exactly the same kind of problem(s). One of my customers asks me to sign for the fact that mail is encrypted when handling it. However, using standard MTA software, messages that are in the queue waiting to get delivered, are

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Paul Smith
On 25/05/2018 11:22, Stefano Bagnara wrote: On Fri, 25 May 2018 at 11:55, Paul Smith wrote: [...] If someone sends a message from the UK to someone in the USA, by definition, we must send that email outside of the EU. When we send the email, we are sending personal data (eg

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Paul Smith
On 25/05/2018 11:33, Graeme Fowler wrote: On 25 May 2018, at 10:46, Paul Smith wrote: But, how it interacts with email, it all seems to get very horrible. I suspect the *intention* is OK, but I'm struggling with the actual regulations. Whilst this specific article (written

Re: [mailop] Disabling TLS1.0 for SMTP

2018-05-25 Thread Tim Bray
On 22/05/18 15:47, Al Iverson wrote: > Are folks disabling TLS1.0 support in SMTP? Our security team has > asked, but I'm a bit concerned about potential failure cases when > trying to deliver mail to smaller corporate sites that might be doing > stuff like requiring TLS but supporting 1.0

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Jeremy Harris
On 25/05/18 11:49, Paul Smith wrote: > Disk encryption is great on a laptop. Not sure it is anywhere else. It does mean you don't have to secure-destroy that sour disk you swapped out from the raid set. -- Jeremy ___ mailop mailing list

[mailop] DMARC deployment statistics

2018-05-25 Thread Alexey Melnikov
Hi, I will be doing a presentation on DMARC/ARC at an operators group. If people can point me at information about growth of DMARC use over time (graphs, presentations, globally or by countries), that would be much appreciated. Thank you, Alexey

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread David Hofstee
Hi, There is a difference between being a "processor" and "telecommunications". The telecommunications laws are different, more strict sometimes. I know what the difference was in Dutch law, not sure in the EU area. Yours, David On 25 May 2018 at 15:51, Renaud Allard via mailop

Re: [mailop] DMARC deployment statistics

2018-05-25 Thread Matt Vernhout
DMARC.org has some stats you can look at, most recently updated December 2017. https://dmarc.org/2017/12/number-of-domains-actively-using-dmarc-triples/ Dmarcian has a list of report generators: https://us.dmarcian.com/dmarc-data-providers/ Cheers, ~ Matt Vernhout, CIPP/C

[mailop] Office365 Bulking Escalations

2018-05-25 Thread Albert Liu
d. Am I forced to use disk > >> encryption? > >> > >> > > In the same vein, isn't encryption also required on the transmission > > channel? Should we now require for every mail TLS SMTP? > > > > > >

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Brandon Long via mailop
Encryption of data stored on disk that is resistant to these types of attacks is not impossible, assuming that the keys are stored somewhere else. The pieces are mostly available, from trusted boot through software attestation and more. I won't say what we do is impossible to break, but it's

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Ray Van Dolson
On Fri, May 25, 2018 at 12:13:15PM +0100, Jeremy Harris wrote: > On 25/05/18 11:49, Paul Smith wrote: > > Disk encryption is great on a laptop. Not sure it is anywhere else. > > It does mean you don't have to secure-destroy that sour disk you > swapped out from the raid set. This is the main

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Renaud Allard via mailop
On 05/25/2018 12:14 PM, Rolf E. Sonneveld wrote: Yes, dealing with exactly the same kind of problem(s). One of my customers asks me to sign for the fact that mail is encrypted when handling it. However, using standard MTA software, messages that are in the queue waiting to get delivered,

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Anne P. Mitchell Esq.
> On May 25, 2018, at 4:40 AM, Paul Smith wrote: > >>> But, how it interacts with email, it all seems to get very horrible. I >>> suspect the *intention* is OK, but I'm struggling with the actual >>> regulations. >>> >> Whilst this specific article (written by Andrew

Re: [mailop] DMARC deployment statistics

2018-05-25 Thread Vittorio Bertola
> Il 25 maggio 2018 alle 16.21 Alexey Melnikov ha > scritto: > > > Hi, > > I will be doing a presentation on DMARC/ARC at an operators group. If > people can point me at information about growth of DMARC use over time > (graphs, presentations, globally or by

[mailop] dnsbl.cyberlogic.net seems to be wildcarded

2018-05-25 Thread Mark E. Jeftovic
Looks like dnsbl.cyberlogic.net just wildcarded itself to 38.102.67.13 within the last hour or so. dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.10 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.30 dnsbl.cyberlogic.net returned result 38.102.67.13/32

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Grant Taylor via mailop
On 05/25/2018 04:32 AM, Leo Gaspard via mailop wrote: Just for the record, OpenSMTPD supports queue encryption with the `queue encryption` option. Nice. I'll have to look into that, particularly how it does things. I'm assuming that it encrypts / decrypts individual files / message stores.

Re: [mailop] dnsbl.cyberlogic.net seems to be wildcarded

2018-05-25 Thread Al Iverson
Thanks for sharing this. It appears to still be happening, so I've put up a quick post about this on https://www.dnsbl.com Cheers, Al Iverson On Fri, May 25, 2018 at 6:59 PM, Mark E. Jeftovic wrote: > > Looks like dnsbl.cyberlogic.net just wildcarded itself to 38.102.67.13 >

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Grant Taylor via mailop
On 05/25/2018 04:49 AM, Paul Smith wrote: If the software can decrypt its own encrypted data automatically, then the decryption key/method is on the PC, so not going to stop a determined attacker. I don't know if this exists or not, but I could see how files (independently of disk

Re: [mailop] GDPR and SMTP in general

2018-05-25 Thread Large Hadron Collider
I suspect in practice they are going to DTRT and only enforce against violations of the spirit. On 05/25/2018 10:14, Rolf E. Sonneveld wrote: Hi, Paul, On 25-05-18 11:46, Paul Smith wrote: I've been going through some GDPR stuff. Amongst other things, we provide SMTP relay services to some

Re: [mailop] dnsbl.cyberlogic.net seems to be wildcarded

2018-05-25 Thread Bill Cole
On 25 May 2018, at 18:59 (-0400), Mark E. Jeftovic wrote: Looks like dnsbl.cyberlogic.net just wildcarded itself to 38.102.67.13 within the last hour or so. dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.10 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for

Re: [mailop] dnsbl.cyberlogic.net seems to be wildcarded

2018-05-25 Thread Mark E. Jeftovic
> OK, but why would this matter? > > To the best of my recollection and as best I can figure out from > what's at archive.org and elsewhere, that was never a public DNSBL. > They've been marked as private at the valli.org site continuously for > many years. Also, any DNSBL tool that is still

Re: [mailop] dnsbl.cyberlogic.net seems to be wildcarded

2018-05-25 Thread Al Iverson
On Fri, May 25, 2018 at 10:43 PM, Mark E. Jeftovic wrote: > > >> OK, but why would this matter? >> >> To the best of my recollection and as best I can figure out from >> what's at archive.org and elsewhere, that was never a public DNSBL. >> They've been marked as private at