Re: [mailop] dnsbl.cyberlogic.net seems to be wildcarded
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 the valli.org site continuously for >> many years. Also, any DNSBL tool that is still firing on 'any answer' >> instead of requiring 127.0.0.2 or some other specific result really >> merits flushing out of the ecosystem by this sort of event. >> > > Sorry, I did not know that. I figured it was a live RBL when I saw an > alert come across our monitors, for some reason it must have been added > in error here. Don't apologize. You did a good thing noting that it is misbehaving. The person complaining has never run a DNSBL nor been in a deliverability role where they've had to deal with the fallout from bogus DNSBL listings. I've done both, and I appreciate you sharing this information. This appears to have been a free-to-use DNSBL that shows up in multi-DNSBL (RBL) checking sites, and I know that mail admins often copy lists of DNSBLs into their mail server config without necessarily understanding the listing criteria and without having a feel for how trustworthy the DNSBL operator may or may not be. And a lot of them set it and forget it, not checking the config periodically. Now, hopefully, admins using that DNSBL will see mail bouncing, will google this error, and find your mailing list post or my blog post about it and know what happened and how to address it. Stuff like this is the whole reason my dumb website at www.dnsbl.com exists. It's not like I make money off of a website list of dead / broken DNSBLs. It is that so many of them are run so badly or blow up unexpectedly with no explanation or documentation, so I recognized the need to log what's happening. Regards, Al Iverson -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] dnsbl.cyberlogic.net seems to be wildcarded
> 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 firing on 'any answer' > instead of requiring 127.0.0.2 or some other specific result really > merits flushing out of the ecosystem by this sort of event. > Sorry, I did not know that. I figured it was a live RBL when I saw an alert come across our monitors, for some reason it must have been added in error here. - mark -- Mark E. Jeftovic Co-founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 x 225 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 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 the *intention* is OK, but I'm struggling with the actual regulations. 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 usually the name/email address of the sender never mind the content which could be anything (outside our control)). That causes issues for GDPR. When we send the outgoing message to another mail server, that other server's operator is also a Data Processor. According to Article 28 of GDPR, we have to get prior approval of the Data Controller before using them, and a responsibility to check that they are GDPR compliant. Obviously that isn't going to happen in any feasible way... Then there's the question about whether Internet connectivity/Wifi hotspt providers are also Data Processors as they potentially have access to the message data (including personal data) and could be classed as 'processing' it. Also, if a user is on holiday in the USA and downloads email to their phone or in an Internet cafe, we are 'sending it outside the EU', so again, GDPR has issues. I thought it was all OK, but one of our customers asked us to sign a contract for GDPR which prevents us from sending data outside of the UK and from sending it to any other companies without prior written permission. I've pointed out the problems to them, but wondered if anyone else had come across this. 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 unencrypted. Am I forced to use disk encryption? /rolf ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] dnsbl.cyberlogic.net seems to be wildcarded
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 205.210.42.30 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.42 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.57 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.58 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.59 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.70 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.80 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.183 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 firing on 'any answer' instead of requiring 127.0.0.2 or some other specific result really merits flushing out of the ecosystem by this sort of event. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steadier Work: https://linkedin.com/in/billcole ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] dnsbl.cyberlogic.net seems to be wildcarded
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 > 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 for 205.210.42.42 > dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.57 > dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.58 > dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.59 > dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.70 > dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.80 > dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.183 > > - mark > > -- > Mark E. Jeftovic > Co-founder & CEO, easyDNS Technologies Inc. > +1-(416)-535-8672 x 225 > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 encryption) on the server could be encrypted using a key that is brokered elsewhere in the infrastructure. A hypothetical example would be Exchange retrieving the encryption key used from AD which housed on DCs, physically separate machines. The key does not need to live on the machine that has encrypted data. The machine just needs to have access to it through a tightly controlled mechanism. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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. I guess (hope?) other MTAs do support it too. I've not heard this of a feature for any traditional unix MTAs. (Sendmail, Postfix, Qmail, etc.) I know that Lotus Domino can do it. (I don't know if it's done by default or not.) I suspect that Exchange can have an encrypted .edb file, but I don't know. - As I type this, I don't know that the mail queue is in the .edb file. It may just be files on the NTFS file system. So that may mean that you would need to leverage NTFS' encrypted file system and control access to the decryption key via group membership. I have no idea if GroupWise supports encrypted queues or not. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] dnsbl.cyberlogic.net seems to be wildcarded
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 for 205.210.42.42 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.57 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.58 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.59 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.70 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.80 dnsbl.cyberlogic.net returned result 38.102.67.13/32 for 205.210.42.183 - mark -- Mark E. Jeftovic Co-founder & CEO, easyDNS Technologies Inc. +1-(416)-535-8672 x 225 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Office365 Bulking Escalations
Hi, I was wondering if there was a general escalation channel for bulking issues with Office365. I know there is a delisting portal available, but was wondering how ESP's address clients that are seeing bulking issues. Thanks much! Albert On Fri, May 25, 2018 at 3:43 PM, wrote: > Send mailop mailing list submissions to > mailop@mailop.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > or, via email, send a message with subject or body 'help' to > mailop-requ...@mailop.org > > You can reach the person managing the list at > mailop-ow...@mailop.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mailop digest..." > > > Today's Topics: > >1. DMARC deployment statistics (Alexey Melnikov) >2. Re: GDPR and SMTP in general (David Hofstee) >3. Re: DMARC deployment statistics (Vittorio Bertola) >4. Re: GDPR and SMTP in general (Anne P. Mitchell Esq.) >5. Re: GDPR and SMTP in general (Brandon Long) >6. Re: DMARC deployment statistics (Matt Vernhout) > > > -- > > Message: 1 > Date: Fri, 25 May 2018 15:21:32 +0100 > From: Alexey Melnikov > To: mailop@mailop.org > Subject: [mailop] DMARC deployment statistics > Message-ID: <21a78fc4-9f07-0c13-9993-23296f4d7...@isode.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 > > > > > > -- > > Message: 2 > Date: Fri, 25 May 2018 17:19:12 +0200 > From: David Hofstee > To: Renaud Allard > Cc: mailop > Subject: Re: [mailop] GDPR and SMTP in general > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > wrote: > > > > > > > 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, are unencrypted. 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? > > > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > > > > -- > -- > My opinion is mine. > -- next part -- > An HTML attachment was scrubbed... > URL: <https://chilli.nosignal.org/cgi-bin/mailman/private/ > mailop/attachments/20180525/b49506f8/attachment-0001.html> > > -- > > Message: 3 > Date: Fri, 25 May 2018 19:25:55 +0200 (CEST) > From: Vittorio Bertola > To: Alexey Melnikov , mailop@mailop.org > Subject: Re: [mailop] DMARC deployment statistics > Message-ID: <503677422.11245.1527269156...@appsuite.open-xchange.com> > Content-Type: text/plain; charset=UTF-8 > > > 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 countries), that would be much > appreciated. > > The Online Trust Alliance releases a yearly report with useful data points > on email authentication and more, though it's focused on the U.S.: > > https://otalliance.org/HonorRoll > > Google published some stats in the past, including a number on DMARC > adoption, but this was last updated in 2016 - don't know if they released > anything newer to compare with: > > https://security.googleblog.c
Re: [mailop] DMARC deployment statistics
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 http://www.emailkarma.net Twitter: @emailkarma On Fri, May 25, 2018 at 5:36 PM Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote: > > 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 countries), that would be much > appreciated. > > The Online Trust Alliance releases a yearly report with useful data points > on email authentication and more, though it's focused on the U.S.: > > https://otalliance.org/HonorRoll > > Google published some stats in the past, including a number on DMARC > adoption, but this was last updated in 2016 - don't know if they released > anything newer to compare with: > > > https://security.googleblog.com/2013/12/internet-wide-efforts-to-fight-email.html > > Also Return Path released a nice report, but I could not find any later > version than 2016: > > > https://returnpath.com/wp-content/uploads/2016/02/DMARCIntelligenceReport_2016.pdf > > Any further data would be interesting to us as well, we also try to track > the adoption of email authentication protocols. > > Regards, > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bert...@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 significantly harder than gaining access to a single server. I have no idea if GDPR requires that level of protection, especially if you're only dealing with data in transit, but I'd be surprised if major customers were happy without it for stored data. Brandon On Fri, May 25, 2018, 4:05 AM Paul Smith wrote: > 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 unencrypted. Am I forced to > > use disk encryption? > > For that, I've just told people that the mail is held unencrypted > locally, and if they want them to be encrypted, then I've told them to > use end-to-end encryption (eg PGP, password-protected ZIP/DOC file etc) > > I've explained that even if the mail is encrypted here, we have no way > to make sure it's encrypted anywhere else, unless they use end-to-end > encryption. > > To be honest, there's little point using disk encryption for this, but > it's hard to explain that to people. If someone can hack into the > server, the disk encryption achieves nothing. If the server can restart > automatically and "enter it's own" decryption key, then disk encryption > achieves nothing. If it needs the key to be manually entered at reboot, > then that's a disaster waiting to happen. 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. > > Disk encryption is great on a laptop. Not sure it is anywhere else. > > > -- > > > Paul Smith Computer Services > Tel: 01484 855800 > Vat No: GB 685 6987 53 > > Sign up for news & updates at http://www.pscs.co.uk/go/subscribe > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
> 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 Cormack of Jisc UK) pertains >> to packet-pushing, it's conceptually identical to the SMTP "issue" you raise: >> >> >> https://community.jisc.ac.uk/blogs/regulatory-developments/article/are-networks-data-processors >> >> >> In your context, the processor is the sender (or sending organisation). It's >> not you. They're the ones making the decision to shift data from A to B, you >> are only the conduit (or one of many). >> > > I wish that was the case, but it's not what GDPR says, certainly for SMTP > relay services > > Article 28: (1) "Where processing is to be carried out on behalf of a > controller, the controller shall use only processors providing sufficient > guarantees to implement appropriate technical and organisational measures in > such a manner that processing will meet the requirements of this Regulation > and ensure the protection of the rights of the data subject." > > Article 4: (2) "Processing means any operation or set of operations which is > performed on personal data or on sets of personal data, whether or not by > automated means, such as collection, recording, organisation, structuring, > storage, adaptation or alteration, retrieval, consultation, use, disclosure > by transmission, dissemination or otherwise making available, alignment or > combination, restriction, erasure or destruction;" > > SMTP relay services do the highlighted operations on personal data. Thus they > are Data Processors. Whether a pure network operator is is more debatable, > but 'any operation' is a broad brush. Right..and GDPR specifically admits of the potential for many processors/co-processors in a chain. Moreover, the controller is required to have an executed contract with the processor to whom they are handing off the data which explicitly states that the processor is GDPR compliant...and that holds true for contracts between processors and additional processors. And because liability can pass back up the chain in the even to of a breach, to the tune of even the *full* amount of fines, we have been recommending that orgs be sure to insist on an indemnification clause with all of their third-party processors with which they do business. It would even be smart to include a clause about the processor warranting that they will ensure that any additional processors to whom they pass on data are also GDPR compliant. http://www.gettingemaildelivered.com/what-your-contracts-must-contain-to-be-gdpr-compliant-and-gdpr-proof Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance GDPR Compliance Consultant GDPR Compliance Certification http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Board of Directors, Asilomar Microcomputer Workshop Member, Advisory Board, Cause for Awareness Member, Elevations Credit Union Member Council Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Available for consultations by special arrangement. amitch...@isipp.com | @AnnePMitchell Facebook/AnnePMitchell | LinkedIn/in/annemitchell ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] DMARC deployment statistics
> 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 countries), that would be much > appreciated. The Online Trust Alliance releases a yearly report with useful data points on email authentication and more, though it's focused on the U.S.: https://otalliance.org/HonorRoll Google published some stats in the past, including a number on DMARC adoption, but this was last updated in 2016 - don't know if they released anything newer to compare with: https://security.googleblog.com/2013/12/internet-wide-efforts-to-fight-email.html Also Return Path released a nice report, but I could not find any later version than 2016: https://returnpath.com/wp-content/uploads/2016/02/DMARCIntelligenceReport_2016.pdf Any further data would be interesting to us as well, we also try to track the adoption of email authentication protocols. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 wrote: > > > 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, are unencrypted. 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? > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > -- -- My opinion is mine. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] DMARC deployment statistics
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 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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, are unencrypted. 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? smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 benefit, and a pretty helpful one at scale. Also for thwarting those pesky data center ninjas sneaking in at night and escaping with random drives! Ray ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
On Fri, 25 May 2018 at 13:03, Paul Smith wrote: > 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 usually the name/email address >>> of the sender never mind the content which could be anything (outside >>> our control)). That causes issues for GDPR. >> NO, you are not transferring them as processor. > Why not? We are 'processing' personal data on behalf of the controller. > "Processor means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller." > "Processing means any operation or set of operations which is performed on personal data or on sets of personal data", including such basic things as storage and erasure of data. If simply storing data on someone's behalf is 'processing', then distributing an email certainly is (at the very least, the data is temporarily stored, and then erased, both of which are explicitly listed as 'processing') OK, but there's no problem with transferring data when the controller ask you to do that. GDPR - Article 28 - Processor, about the contract between the controller and the processor (the one your customer is asking you to sign): "That contract or other legal act shall stipulate, in particular, that the processor: (a) processes the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation," So your DPA/contract will simply tell that you won't transfer data to another country unless undire direct instructions of the controller, and the controller sending an email is a direct instruction, IMHO. That's different than a Processor that by its own decision, decide to use Amazon SES as "other processor" (sub-processor) for the delivery and by doing this, move the data to another country (and also adopts a new processor): both of them have to be notified, and sometimes needs a prior agreement by the controller. IANAL, Stefano ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 usually the name/email address of the sender never mind the content which could be anything (outside our control)). That causes issues for GDPR. NO, you are not transferring them as processor. Why not? We are 'processing' personal data on behalf of the controller. "Processor means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller." "Processing means*any operation* or set of operations which is performed on personal data or on sets of personal data", including such basic things as storage and erasure of data. If simply storing data on someone's behalf is 'processing', then distributing an email certainly is (at the very least, the data is temporarily stored, and then erased, both of which are explicitly listed as 'processing') It's not YOU, it's the sender that is sending and in "control" of this operation and perfectly aware that the email moves informations around the world to be sent to a specific target, IMHO. Yes, they're 'in control', so they're the Data Controller. Under GDPR a 'Processor' is defined as pretty much anyone who touches that data on behalf of the Controller (and doesn't make decisions about it) - which is any SMTP server (and possibly network) which the messages passes through. (I'm fairly sure this isn't the intention, but it's what the GDPR words say, and trying to explain to a worried customer that the words don't mean what they say isn't going to get very far) When (outside the domestic use case) you use Gmail or Hotmail (just to name 2) to host your job emails/contact lists, you are using Google or Microsoft as processor of your contact list data (for which you are the controller). You would need a DPA from Microsoft or Google about that, but they don't give this for free inboxes. You'll need Office365 or GSuite for your business even if you are a personal business. Oh, I agree with that totally. But people like gmail, and it's free so they won't even think about that. -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 unencrypted. Am I forced to use disk encryption? For that, I've just told people that the mail is held unencrypted locally, and if they want them to be encrypted, then I've told them to use end-to-end encryption (eg PGP, password-protected ZIP/DOC file etc) I've explained that even if the mail is encrypted here, we have no way to make sure it's encrypted anywhere else, unless they use end-to-end encryption. To be honest, there's little point using disk encryption for this, but it's hard to explain that to people. If someone can hack into the server, the disk encryption achieves nothing. If the server can restart automatically and "enter it's own" decryption key, then disk encryption achieves nothing. If it needs the key to be manually entered at reboot, then that's a disaster waiting to happen. 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. Disk encryption is great on a laptop. Not sure it is anywhere else. -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 by Andrew Cormack of Jisc UK) pertains to packet-pushing, it's conceptually identical to the SMTP "issue" you raise: https://community.jisc.ac.uk/blogs/regulatory-developments/article/are-networks-data-processors In your context, the processor is the sender (or sending organisation). It's not you. They're the ones making the decision to shift data from A to B, you are only the conduit (or one of many). I wish that was the case, but it's not what GDPR says, certainly for SMTP relay services Article 28: (1) "Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject." Article 4: (2) "Processing means *a**ny operation* or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, *storage*, adaptation or alteration, retrieval, consultation, use, *disclosure by transmission*, *dissemination* or *otherwise making available*, alignment or combination, restriction, *erasure* or destruction;" SMTP relay services do the highlighted operations on personal data. Thus they are Data Processors. Whether a pure network operator is is more debatable, but 'any operation' is a broad brush. -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Disabling TLS1.0 for SMTP
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 onlyis that really > much of a concern? Perspective from a small corporate who runs their own mail, A quick dip in our logs suggests disabling TLS1.0 would cut off a fair few of our decent customers. Inbound and outbound. By the look of it, mainly exchange mailsystems. A lot of them kind of IT companies, so not sure whether they would appreciate a call saying `you need to upgrade`. Turns out we also have 1 big customer who doesn't support TLS for mail at all. Lets see what they say. Everything else plain text is spam or `newsletters`. (Certainly my experience of contacting our customers who are using HTTP API clients that can't talk TLS1.2 has been general indifference. I'm hoping when their payments providers cut them off at the PCI deadline, I can cut them off too.) I've also been looking at whether we can deploy dmarc. We've published SPF and DKIM stuff for years. But the reports that come back suggest a lot of our customers doing dodgy mailforwarding. (there is no easy answer) Tim ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 packet-pushing, it's conceptually identical to the SMTP "issue" you raise: https://community.jisc.ac.uk/blogs/regulatory-developments/article/are-networks-data-processors In your context, the processor is the sender (or sending organisation). It's not you. They're the ones making the decision to shift data from A to B, you are only the conduit (or one of many). Regards Graeme ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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, are unencrypted. Am I forced to use > disk encryption? Just for the record, OpenSMTPD supports queue encryption with the `queue encryption` option. I guess (hope?) other MTAs do support it too. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] GDPR and SMTP in general
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 email, it all seems to get very horrible. I suspect the *intention* is OK, but I'm struggling with the actual regulations. 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 usually the name/email address of the sender never mind the content which could be anything (outside our control)). That causes issues for GDPR. When we send the outgoing message to another mail server, that other server's operator is also a Data Processor. According to Article 28 of GDPR, we have to get prior approval of the Data Controller before using them, and a responsibility to check that they are GDPR compliant. Obviously that isn't going to happen in any feasible way... Then there's the question about whether Internet connectivity/Wifi hotspt providers are also Data Processors as they potentially have access to the message data (including personal data) and could be classed as 'processing' it. Also, if a user is on holiday in the USA and downloads email to their phone or in an Internet cafe, we are 'sending it outside the EU', so again, GDPR has issues. I thought it was all OK, but one of our customers asked us to sign a contract for GDPR which prevents us from sending data outside of the UK and from sending it to any other companies without prior written permission. I've pointed out the problems to them, but wondered if anyone else had come across this. 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 unencrypted. Am I forced to use disk encryption? /rolf ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] GDPR and SMTP in general
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 the *intention* is OK, but I'm struggling with the actual regulations. 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 usually the name/email address of the sender never mind the content which could be anything (outside our control)). That causes issues for GDPR. When we send the outgoing message to another mail server, that other server's operator is also a Data Processor. According to Article 28 of GDPR, we have to get prior approval of the Data Controller before using them, and a responsibility to check that they are GDPR compliant. Obviously that isn't going to happen in any feasible way... Then there's the question about whether Internet connectivity/Wifi hotspt providers are also Data Processors as they potentially have access to the message data (including personal data) and could be classed as 'processing' it. Also, if a user is on holiday in the USA and downloads email to their phone or in an Internet cafe, we are 'sending it outside the EU', so again, GDPR has issues. I thought it was all OK, but one of our customers asked us to sign a contract for GDPR which prevents us from sending data outside of the UK and from sending it to any other companies without prior written permission. I've pointed out the problems to them, but wondered if anyone else had come across this. -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Disabling TLS1.0 for SMTP
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 onlyis that really much of a concern? Cheers, Al Iverson Have you disabled cleartext SMTP and only allow TLS SMTP? If you still have cleartext SMTP enabled, there is no point in disabling TLS1.0 (except flaws that could reveal your keys). Of course, for submission, disabling TLS1.0 might be interesting, all recent devices (2 years old or less) support TLS1.2. And many older ones also support it. But it all depends on where your market is. smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Yahoo DKIM Signing, not folding the header..
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 folded since the start of this month. - Original message - From: Carl Byington To: mailop@mailop.org Subject: Re: [mailop] Yahoo DKIM Signing, not folding the header.. Date: Thu, 24 May 2018 15:49:00 -0700 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2018-05-24 at 18:02 -0400, John Levine wrote: > By the way, I sent myself a message from my AOL account, and it > showed up with a DKIM signature all tidily folded. Signatures with d=mx.aol.com seem to be wrapped. Signatures with d=aol.com seem to be one long line. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlsHQUcACgkQL6j7milTFsGKrQCgiFhruEyHK3Ye1dIjmcs8VdYh L2EAn0g0uMzi7j8O+mkSmvHgB1uZSxxB =NXwg -END PGP SIGNATURE- _ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Marc Bradshaw - Deliverability/Abuse at FastMail m...@fastmailteam.com | @marcbradshaw[1] Links: 1. https://twitter.com/marcbradshaw ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [EXTERNAL] Re: Disabling TLS1.0 for SMTP
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" , Rohan Sheth , mailop@mailop.orgSubject: Re: [mailop] [EXTERNAL] Re: Disabling TLS1.0 for SMTP Date: Thu, 24 May 2018 11:17:28 +0200 (CEST) > Il 22 maggio 2018 alle 17.41 "Brotman, Alexander" > ha scritto:> > > If someone is interested, we could potentially ask Binu if he has > newer data available. He had done a presentation on the same data at > M3AAWG a few years ago. It would be great to get new data from big players, and to share information in general. For the TES project ( https://tesmail.org/ ) one year ago we ran a scan of the top 1000 domains by web traffic, to see which degree of transport security they offered. Among those who actually had working email servers, we found 58% TLS 1.2, 14% TLS 1.1, 7% TLS 1.0, and 21% no TLS. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy _ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Marc Bradshaw - Deliverability/Abuse at FastMail m...@fastmailteam.com | @marcbradshaw[1] Links: 1. https://twitter.com/marcbradshaw ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
