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, <mailop-requ...@mailop.org> 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 <alexey.melni...@isode.com> > 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 <opentext.dhofs...@gmail.com> > To: Renaud Allard <ren...@allard.it> > Cc: mailop <mailop@mailop.org> > Subject: Re: [mailop] GDPR and SMTP in general > Message-ID: > <CAKxMAXwwA5kHc22s0QyrkoNrfaNUHs_MUdgjWiaMbq5wnVWzUw@mail. > 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 <mailop@mailop.org> > 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 <vittorio.bert...@open-xchange.com> > To: Alexey Melnikov <alexey.melni...@isode.com>, 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 <alexey.melni...@isode.com> > 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 > > > > ------------------------------ > > Message: 4 > Date: Fri, 25 May 2018 11:34:31 -0600 > From: "Anne P. Mitchell Esq." <amitch...@isipp.com> > To: Michael Wise via mailop <mailop@mailop.org> > Subject: Re: [mailop] GDPR and SMTP in general > Message-ID: <bdec1adb-f208-42cc-9986-d6ce857f6...@isipp.com> > Content-Type: text/plain; charset=us-ascii > > > > > On May 25, 2018, at 4:40 AM, Paul Smith <p...@pscs.co.uk> 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 > > > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 25 May 2018 12:23:39 -0700 > From: Brandon Long <bl...@google.com> > To: Paul Smith <p...@pscs.co.uk> > Cc: "Rolf E. Sonneveld" <r.e.sonnev...@sonnection.nl>, mailop > <mailop@mailop.org> > Subject: Re: [mailop] GDPR and SMTP in general > Message-ID: > <CABa8R6vRUWWZGBVdiXgL_u2V+Rut0yAebBRhc0_AQL_LufO4Mw@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 <p...@pscs.co.uk> 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <https://chilli.nosignal.org/cgi-bin/mailman/private/ > mailop/attachments/20180525/ea94fbeb/attachment-0001.html> > > ------------------------------ > > Message: 6 > Date: Fri, 25 May 2018 18:39:40 +0000 > From: Matt Vernhout <zvernh...@gmail.com> > To: vittorio.bert...@open-xchange.com > Cc: alexey.melni...@isode.com, mailop@mailop.org > Subject: Re: [mailop] DMARC deployment statistics > Message-ID: > <CAC+0R-pkEXRMxY7-aV-K07BX+YjZzbEAPU1v5EyEdvXs_xm6TA@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 < > alexey.melni...@isode.com> > > 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 > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <https://chilli.nosignal.org/cgi-bin/mailman/private/ > mailop/attachments/20180525/94fcea23/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > ------------------------------ > > End of mailop Digest, Vol 127, Issue 39 > *************************************** > -- [image: mg-icon-logo-notm (2).png] <http://messagegears.com/?utm_source=sigstr&utm_medium=email&utm_campaign=signature_logo> Albert Liu Head of Deliverability P: 404.334.0920 W: https://linkedin.com/in/albertliu8 <https://messagegears.sigstr.net/uc/5a569b29e8b0ad28ac214152?do_not_track=true>
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
