I can say that after digging into DMARC with numerous marketers that work with our delivery team, sometimes getting past that barrier of creating a p=none DMARC policy helps so much in moving to enforcement. I personally like the push for a required DMARC policy. Yes, a false sense of security at its initial stage but sometimes that first push helps to make the next step (enforcement) happen faster.
*Jacob Hansen* Senior Delivery Consultant | Expert Services jacob.han...@sendgrid.com On Thu, Nov 2, 2017 at 6:53 AM, <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. Re: About the Certified Senders Alliance (Tobias Herkula) > 2. Re: About the Certified Senders Alliance (Alexander Zeh) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 2 Nov 2017 12:53:56 +0000 > From: Tobias Herkula <tobias.herk...@optivo.com> > To: David Hofstee <opentext.dhofs...@gmail.com> > Cc: "mailop@mailop.org" <mailop@mailop.org> > Subject: Re: [mailop] About the Certified Senders Alliance > Message-ID: > <AM4PR02MB31372950D8B82C3FD2DBDAA4EE5C0@AM4PR02MB3137. > eurprd02.prod.outlook.com> > > Content-Type: text/plain; charset="Windows-1252" > > By forcing Domain Alignment you would inevitably sacrifice the ability to > send marketing mails for a huge amount of mom-and-pop shops. Even destroy > the business model of a couple of ESPs. I don't argue against it, on my > platform here, we even go the next step and try to force our customers to > even hide the used subdomain (5321.From == t.example.com | 5322.From == > example.com) signed by example.com and our own domain. But we do this out > of data protection reasoning, we simply don't want to handle "answers" of > recipients. > > I also think that even if you are a mom-and-pop shop you should get your > own domain and not using gmail.com or whatever as your primary business > contact. But we are not there yet and pushing to hard on this change would > simply engage an even bigger unwillingness to change the status quo. > > The CSA requirements are being reevaluated every year and if the ISP > representatives in the CSA counsel think it's time to tighten the rules it > will happen. From my personal experience, they lag the ability to do an > ongoing vetting of their members and it often hurts to see competitors not > getting punished for obvious violations. But they bring something to the > table that helps to clean up a lot of communication problems an ESP > normally faces on the day to day operations. > > PS: i will bring the domain alignment issue as topic to the discussion for > adding that as an requirement for the next iteration of the CSA rules... > > Kind regards, > > Tobias Herkula > -- > optivo GmbH > Product Management (Infrastructure) > ________________________________________ > From: David Hofstee <opentext.dhofs...@gmail.com> > Sent: Thursday, November 2, 2017 13:33 > To: Tobias Herkula > Cc: mailop@mailop.org > Subject: Re: [mailop] About the Certified Senders Alliance > > Hi Tobias, > > > I'm working for an ESP who is member of the CSA and ECO and I'm one of > the biggest contender on the authentication requirements front, I don't > think that DMARC is an ESP responsibility, but think that an ESP should > provide everything necessary so that a Brand can use DMARC. > So you agree with me? Good. > > > By forcing the ESP community of CSA to implement DMARC we would not help > our customers, we would simply give them a false feeling of having done > something, that does not solves the underlying problem. > I did not say DMARC. I said DMARC-type authentication (SPF and DKIM > aligned to sender domain). I specifically made that distinction because I > agree that requiring (a) DMARC (policy) is not our job. > > That said: As an ESP you are not required to support DKIM and SPF aligned > to the sender domain according to the CSA. Therefore an ESP could become a > member and their customers may not be able to follow the advise to > implement DMARC (as given in the guidelines, paragraph 3.10). > > Yours, > > > David > > On 2 November 2017 at 13:00, Tobias Herkula <tobias.herk...@optivo.com< > mailto:tobias.herk...@optivo.com>> wrote: > I'm working for an ESP who is member of the CSA and ECO and I'm one of the > biggest contender on the authentication requirements front, I don't think > that DMARC is an ESP responsibility, but think that an ESP should provide > everything necessary so that a Brand can use DMARC. By forcing the ESP > community of CSA to implement DMARC we would not help our customers, we > would simply give them a false feeling of having done something, that does > not solves the underlying problem. > > Kind regards, > > Tobias Herkula > -- > optivo GmbH > Product Management (Infrastructure) > ________________________________________ > From: mailop <mailop-boun...@mailop.org<mailto:mailop-boun...@mailop.org>> > on behalf of David Hofstee <opentext.dhofs...@gmail.com<mailto: > opentext.dhofs...@gmail.com>> > Sent: Thursday, November 2, 2017 11:19 > To: Alexander Zeh > Cc: mailop@mailop.org<mailto:mailop@mailop.org> > Subject: Re: [mailop] About the Certified Senders Alliance > > Hi Alexander, > > Welcome to Mailop. A few somewhat criticising questions on the CSA: > - Complaint policy: What is the complaint policy for recipients? I tried > to find it, but could not. Is anonymity guaranteed? Also not available in > the data protection policy as found on the website. Please consider > creating one. > - Oversight: Do you have a group of people that monitor compliance of > senders (and not just complaints)? > - Unsubscribing. I subscribed to a few newsletters but I seem to notice a > high "does not follow policy"-rate. Two examples (of 3 subscriptions, > headers provided below): > - Size of message: Google clips large messages. This is often where > the unsubscribe link is. I did not see an unsubscribe link in this message. > - List-Unsubscribe: Missing the required URL (requirement 2.21 of > your admission criteria, see https://certified-senders.org/ > wp-content/uploads/2017/07/CSA_Admission_Criteria.pdf ). Were these not > tested at admission? > - Leadership: I think the authentication requirements in your policy are > outdated. An ESP does not even need to support DMARC-type authentication > nor is it a requirement for its customers to prove they are the real > senders. Do you agree? Do you think the CSA should lead in setting > requirements on these topics? Is the CSA able to change such requirements? > Or is the CSA afraid of the current customer base (who might protest to > adding authentication)? I would like to hear CSA's opinion on that. > > Yours, > > > David > > Example of message too large; the unsubscribe link is no longer visible in > Gmail: > X-CSA-Complaints: whitelist-complai...@eco.de<mailto:whitelist-complaints@ > eco.de><mailto:whitelist-complai...@eco.de<mailto:white > list-complai...@eco.de>> > MIME-Version: 1.0 > Content-Type: multipart/mixed; boundary="----msg_border_bwvxxxxx" > Date: Thu, 14 Sep 2017 22:01:07 -0700 > To: xyz > From: HSE24 TV Programm <newslet...@angebote.hse24.de<mailto: > newslet...@angebote.hse24.de><mailto:newslet...@angebote.hse24.de<mailto: > newslet...@angebote.hse24.de>>> > Reply-To: HSE24 TV Programm <serv...@hse24.de<mailto:serv...@hse24.de > ><mailto:serv...@hse24.de<mailto:serv...@hse24.de>>> > Subject: Hui...jetzt wird's richtig stylisch > > Example of List-Unsubscribe not having URL: > Date: Wed, 25 Oct 2017 15:01:33 +0000 (GMT) > From: TUI <t...@email.tui.nl<mailto:t...@email.tui.nl><mailto:tui@ > email.tui.nl<mailto:t...@email.tui.nl>>> > Reply-To: t...@email.tui.nl<mailto:t...@email.tui.nl><mailto:tui@ > email.tui.nl<mailto:t...@email.tui.nl>> > To: xyz > Message-ID: <43699742.JavaMail.app@rbg62.f2is> > Subject: Welkom bij TUI > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary="----=_Part_334583_ > 459599753.150234563453456" > x-mid: 2369485 > X-CSA-Complaints: whitelist-complai...@eco.de<mailto:whitelist-complaints@ > eco.de><mailto:whitelist-complai...@eco.de<mailto:white > list-complai...@eco.de>> > x-rpcampaign: sp2375598 > Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop > x-job: 2375598 > x-orgId: 15062 > List-Unsubscribe: <mailto:v-removed-for-an...@bounce.email.tui.nl<mailto: > v-removed-for-an...@bounce.email.tui.nl><mailto:v- > removed-for-an...@bounce.email.tui.nl<mailto:v-removed- > for-an...@bounce.email.tui.nl>>?subject=Unsubscribe> > > > On 1 November 2017 at 17:33, Alexander Zeh <alexander....@eco.de<mailto:a > lexander....@eco.de><mailto:alexander....@eco.de<mailto:alex > ander....@eco.de>>> wrote: > Hello everyone, > > a friend informed me about a topic going on about the Certified Senders > Alliance on this mailing list. That’s why I joined it. > I work for the CSA for many years now. > First and foremost of all: > It is definitely not true that a sender can join the CSA without any > vetting. That statement bothered me a lot, because it’s a plain lie. Maybe > because important information was lost in some communication between more > than two parties, I don’t want to assume ill intent by anybody. In fact > from every sender who wants to get certified and be whitelisted only about > 10% make it through the whole process and are approved. Btw: the > certification needs to be confirmed by the certification committee in which > 2 seats out of 4 are major ISP partners. > I totally agree that if you have delivery issues it shouldn’t be the first > step to reach out any certification program to fix it. And this is not how > CSA works. If a sender has delivery issues, in 99% these problems are > justified and self made. So what the CSA does is, that in the process we > find potential issues and help senders to align with current best practices > aka. the CSA admission criteria. This whole process can take weeks and > months and still many senders don’t achieve a certification in the end, > because we take that very serious. > Anybody on this mailing list, please feel free to have a look at our > criteria and see for yourself if they are reasonable or not. As everything > we do is completely transparent, you can find them on > https://certified-senders.org/library either at the end, or you can > select the type “CSA specific” to filter. > > Sorry about this rant-ish post, but we try our best to improve overall > quality of senders, so the initial post kind of annoyed me. > > Anyway. I am open for discussion either here, direct with me or for > example on the next M3AAWG meeting in person. > > Best > Alex > > > -- > > Best regards > > > Alexander Zeh > > > Engineering Manager > > > --------------------------------------------------- > > > eco - Association of the Internet Industry > > Certified Senders Alliance > > > Lichtstrasse 43h > > 50825 Cologne > > Germany > > > phone: +49 (0) 221 - 70 00 48 - 171<tel:%2B49%20%280%29%20221%20- > %2070%2000%2048%20-%20171><tel:+49%20221%20700048171> > > fax: +49 (0) 221 - 70 00 48 - 111<tel:%2B49%20%280%29%20221% > 20-%2070%2000%2048%20-%20111><tel:+49%20221%20700048111> > > mobile: +49 (0) 171 - 657 2628<tel:%2B49%20%280%29% > 20171%20-%20657%202628><tel:+49%20171%206572628> > > e-mail: alexander....@eco.de<mailto:alexander....@eco.de><mailto:ale > xander....@eco.de<mailto:alexander....@eco.de>> > > web: http://www.eco.de > > > --------------------------------------------------- > > > eco - Association of the Internet Industry > > CEO: Harald A. Summa > > Executive board: Prof. Michael Rotert (Chairman), Oliver Süme (Deputy > > Chairman), Klaus Landefeld, Felix Höger, Prof. Dr. Norbert Pohlmann > > Register of Associations: District court (Amtsgericht) Cologne, VR 14478 > > Registered office: Cologne > > _______________________________________________ > mailop mailing list > mailop@mailop.org<mailto:mailop@mailop.org><mailto:mailop@mailop.org > <mailto:mailop@mailop.org>> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > > -- > -- > My opinion is mine. > > _______________________________________________ > mailop mailing list > mailop@mailop.org<mailto:mailop@mailop.org> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > -- > -- > My opinion is mine. > > > > ------------------------------ > > Message: 2 > Date: Thu, 2 Nov 2017 12:59:31 +0000 > From: Alexander Zeh <alexander....@eco.de> > To: David Hofstee <opentext.dhofs...@gmail.com> > Cc: "mailop@mailop.org" <mailop@mailop.org> > Subject: Re: [mailop] About the Certified Senders Alliance > Message-ID: <b5f5a582-7758-46ce-b4a5-0a8731c03...@eco.de> > Content-Type: text/plain; charset="utf-8" > > Hello David, > > thanks for the welcome. :) > About your questions: > > - Complaint policy: We distinct between two different types of complaints. > First we have what we call a "spam click". That's basically FBL data. These > are completely anonymous of course. We simply see "spam click rates" and > act if the rate of spam clicks in comparison to the number of emails > received exceeds a certain threshold. > The other kind of complaints are individual user complaints. This is a > whole different topic, because if someone tells us "Hey, I just received an > email from someone I never gave my consent to" that's way more serious than > a simple click in a webinterface from my ISP which can happen by accident. > But in these cases, there are still "false positives", like people who > forgot that they subscribed, people who received kind of embarrassing > content, like the newsletter from a dating site, and get caught by somebody > who shouldn't know it. So the complaint team checks these complaints and > works with the complainant and the ESP (who did send the email in behalf of > e.g. the dating site) to find out the exact cause of the problem so it can > be fixed. Most of the time, if there is a real issue with the opt-in > process of a sender the complaint team receives multiple complaints for the > same sender in a short period of time. That's why not every complaint gets > feedback but is still used and highly appreciated. > Anyway.. as we operate in Germany and take data protection very serious we > ask the complainant for explicit consent to allow us to share his personal > information (his email address) with the ESP who sent the email to work on > the issue. So from a process perspective and a legal perspective, these > individual user complaints can't be handled anonymously. > > -Oversight: Yes, of course. We have people and tools who check that. But > of course we never see the full picture of each and every single email sent > by every certified sender. Hints from receivers are also highly appreciated. > > -Unsubscribing: > - Size of message: I'm not sure how we should handle this. The sender/ESP > did send out a correct message, but Google decided to cut off content. > Who's to blame? > - List-Unsubscribe: Of course we check every ESP in the certification > process. But we can't check and monitor every single sent message. This > goes back to the "Oversight" question. If we see this in our monitoring, or > if we get the hint by a receiver we can work on that. I'd like to contact > you off-list about the samples you showed, so we can take actions against > the responsible sender. > > - Leadership: As you can see by Tobias reaction, the opinions around > authentication differ. To make that clear: The CSA criteria are not made up > by me and my colleagues, nor are they based on opinions. They are the > results of the different needs and requirements by all participating ISPs > and technology partners. We gather all the feedback, try to find the best > possible solution and discuss them with our partners, again. Finally every > change made to the admission criteria need to be approved by the CSA > committee, who I mentioned early consists of two ISP partners and two ESPs. > Right now SPF and DKIM are mandatory for CSA senders. DMARC, or DMARC-ish > authentication by alignment might be in the criteria in the future, or it > might not. It depends on the feedback by our ISP and technology partners. > > Best > Alexander > > > Am 02.11.2017 um 11:19 schrieb David Hofstee < > opentext.dhofs...@gmail.com>: > > > > Hi Alexander, > > > > Welcome to Mailop. A few somewhat criticising questions on the CSA: > > - Complaint policy: What is the complaint policy for recipients? I tried > to find it, but could not. Is anonymity guaranteed? Also not available in > the data protection policy as found on the website. Please consider > creating one. > > - Oversight: Do you have a group of people that monitor compliance of > senders (and not just complaints)? > > - Unsubscribing. I subscribed to a few newsletters but I seem to notice > a high "does not follow policy"-rate. Two examples (of 3 subscriptions, > headers provided below): > > - Size of message: Google clips large messages. This is often where > the unsubscribe link is. I did not see an unsubscribe link in this message. > > - List-Unsubscribe: Missing the required URL (requirement 2.21 of > your admission criteria, see https://certified-senders.org/ > wp-content/uploads/2017/07/CSA_Admission_Criteria.pdf < > https://certified-senders.org/wp-content/uploads/2017/ > 07/CSA_Admission_Criteria.pdf> ). Were these not tested at admission? > > - Leadership: I think the authentication requirements in your policy are > outdated. An ESP does not even need to support DMARC-type authentication > nor is it a requirement for its customers to prove they are the real > senders. Do you agree? Do you think the CSA should lead in setting > requirements on these topics? Is the CSA able to change such requirements? > Or is the CSA afraid of the current customer base (who might protest to > adding authentication)? I would like to hear CSA's opinion on that. > > > > Yours, > > > > > > David > > > > Example of message too large; the unsubscribe link is no longer visible > in Gmail: > > X-CSA-Complaints: whitelist-complai...@eco.de <mailto: > whitelist-complai...@eco.de> > > MIME-Version: 1.0 > > Content-Type: multipart/mixed; boundary="----msg_border_bwvxxxxx" > > Date: Thu, 14 Sep 2017 22:01:07 -0700 > > To: xyz > > From: HSE24 TV Programm <newslet...@angebote.hse24.de <mailto: > newslet...@angebote.hse24.de>> > > Reply-To: HSE24 TV Programm <serv...@hse24.de <mailto:serv...@hse24.de>> > > Subject: Hui...jetzt wird's richtig stylisch > > > > Example of List-Unsubscribe not having URL: > > Date: Wed, 25 Oct 2017 15:01:33 +0000 (GMT) > > From: TUI <t...@email.tui.nl <mailto:t...@email.tui.nl>> > > Reply-To: t...@email.tui.nl <mailto:t...@email.tui.nl> > > To: xyz > > Message-ID: <43699742.JavaMail.app@rbg62.f2is> > > Subject: Welkom bij TUI > > MIME-Version: 1.0 > > Content-Type: multipart/alternative; boundary="----=_Part_334583_ > 459599753.150234563453456" > > x-mid: 2369485 > > X-CSA-Complaints: whitelist-complai...@eco.de <mailto: > whitelist-complai...@eco.de> > > x-rpcampaign: sp2375598 > > Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop > > x-job: 2375598 > > x-orgId: 15062 > > List-Unsubscribe: <mailto:v-removed-for-an...@bounce.email.tui.nl > <mailto:v-removed-for-an...@bounce.email.tui.nl>?subject=Unsubscribe> > > > > > > On 1 November 2017 at 17:33, Alexander Zeh <alexander....@eco.de > <mailto:alexander....@eco.de>> wrote: > > Hello everyone, > > > > a friend informed me about a topic going on about the Certified Senders > Alliance on this mailing list. That’s why I joined it. > > I work for the CSA for many years now. > > First and foremost of all: > > It is definitely not true that a sender can join the CSA without any > vetting. That statement bothered me a lot, because it’s a plain lie. Maybe > because important information was lost in some communication between more > than two parties, I don’t want to assume ill intent by anybody. In fact > from every sender who wants to get certified and be whitelisted only about > 10% make it through the whole process and are approved. Btw: the > certification needs to be confirmed by the certification committee in which > 2 seats out of 4 are major ISP partners. > > I totally agree that if you have delivery issues it shouldn’t be the > first step to reach out any certification program to fix it. And this is > not how CSA works. If a sender has delivery issues, in 99% these problems > are justified and self made. So what the CSA does is, that in the process > we find potential issues and help senders to align with current best > practices aka. the CSA admission criteria. This whole process can take > weeks and months and still many senders don’t achieve a certification in > the end, because we take that very serious. > > Anybody on this mailing list, please feel free to have a look at our > criteria and see for yourself if they are reasonable or not. As everything > we do is completely transparent, you can find them on > https://certified-senders.org/library <https://certified-senders. > org/library> either at the end, or you can select the type “CSA specific” > to filter. > > > > Sorry about this rant-ish post, but we try our best to improve overall > quality of senders, so the initial post kind of annoyed me. > > > > Anyway. I am open for discussion either here, direct with me or for > example on the next M3AAWG meeting in person. > > > > Best > > Alex > > > > -- > > > > Best regards > > > > Alexander Zeh > > > > Engineering Manager > > > > --------------------------------------------------- > > > > eco - Association of the Internet Industry > > Certified Senders Alliance > > > > Lichtstrasse 43h > > 50825 Cologne > > Germany > > > > phone: +49 (0) 221 - 70 00 48 - 171 <tel:+49%20221%20700048171> > > fax: +49 (0) 221 - 70 00 48 - 111 <tel:+49%20221%20700048111> > > mobile: +49 (0) 171 - 657 2628 <tel:+49%20171%206572628> > > e-mail: alexander....@eco.de <mailto:alexander....@eco.de> > > web: http://www.eco.de <http://www.eco.de/> > > > > --------------------------------------------------- > > > > eco - Association of the Internet Industry > > CEO: Harald A. Summa > > Executive board: Prof. Michael Rotert (Chairman), Oliver Süme (Deputy > > Chairman), Klaus Landefeld, Felix Höger, Prof. Dr. Norbert Pohlmann > > Register of Associations: District court (Amtsgericht) Cologne, VR 14478 > > Registered office: Cologne > > > > _______________________________________________ > > mailop mailing list > > mailop@mailop.org <mailto:mailop@mailop.org> > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop < > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop> > > > > > > > > > > -- > > -- > > My opinion is mine. > > -- > Best regards > > Alexander Zeh > > Engineering Manager > > --------------------------------------------------- > > eco - Association of the Internet Industry > Certified Senders Alliance > > Lichtstrasse 43h > 50825 Cologne > Germany > > phone: +49 (0) 221 - 70 00 48 - 171 > fax: +49 (0) 221 - 70 00 48 - 111 > mobile: +49 (0) 171 - 657 2628 > e-mail: alexander....@eco.de > web: http://www.eco.de > > GPG fingerprint: ADEA 1BF7 1D2E 670B EB51 0C54 7A45 64E2 A167 37EF > > --------------------------------------------------- > > eco Association of the Internet Industry > CEO: Harald A. Summa > Executive board: Prof. Michael Rotert (Chairman), Oliver Süme (Deputy > Chairman), Klaus Landefeld, Felix Höger, Prof. Dr. Norbert Pohlmann > Register of Associations: District court (Amtsgericht) Cologne, VR 14478 > Registered office: Cologne > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <https://chilli.nosignal.org/cgi-bin/mailman/private/ > mailop/attachments/20171102/afe9f0da/attachment.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 4152 bytes > Desc: not available > URL: <https://chilli.nosignal.org/cgi-bin/mailman/private/ > mailop/attachments/20171102/afe9f0da/attachment.bin> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > ------------------------------ > > End of mailop Digest, Vol 121, Issue 9 > ************************************** >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
