Hi David, I dare to disagree with your opinion that the sender is to blame. Gmail decides to alter the way the message is shown. This is misleading. I'd say either accept the message and show it completely, or if it's to large, then don't accept it at all on smtp level with a corresponding bounce message. Maybe that's not really a big issue because we require senders so set up list-unsubscribe headers and it will be a requirement in the next, reviewed criteria to implement RFC 8058 as well, so Gmail will use that in their interface. In any case, the receiver should be able to see the complete content of the email with a single click. If I'm looking for an unsubscribe link in an email I always scroll down completely, because this is where I expect it. If I find there something like "email was clipped, click here to see the entire content", I'd click on that. Of course we don't tolerate unsubscribe links in light grey on white background. But it's not necessary to have that in the criteria, because that's already regulated by law and it's obvious for serious ESPs that this is way off of any best practices. If we'd have to add all these possible abuse cases in the criteria they would be even longer then they already are. That's one of many reasons why we have a vetting process in place to find problems like these.
Regarding the complaint team: The team does not only process CSA complaints but all spam complaints in Germany and is operated by eco (like the CSA). I'm sorry, but the content is only available in german as far as I know: https://www.eco.de/services/internet-beschwerdestelle.html <https://www.eco.de/services/internet-beschwerdestelle.html> Anyway.. as you can imagine they receive tons of (non CSA related) complaints, and it's not viable to answer every single complaint. And even if they do, we already received complaints about the mails from out complaint team to the complainant. But I understand your point here. We will discuss that internally how we can optimise the communication towards complainants. Regarding our header: I'm sure you're talking about the X-CSA-Complaints header. Of course the header is not used by ISPs or technology partners to identify whitelisted emails. We operate an IP-based whitelist for that. The header is added for transparency reasons to receive complaints by persons who are actually able to read headers. The downside is, that there are many emails out there with that header who were not sent by a certified sender, because email abusers simply thought it might give them better delivery, or maybe because they used an email of a certified sender as a "template" for their spam. I hope I could shed some light into the "black box CSA" and how we work. I'm not sure if this still is interesting and relevant for everybody on the list, and I don't want to annoy the subscribers with an ongoing discussion between us. Anyway, I'm on this list now and will reply to questions here and off-list as well. And as I already said: Feedback and hints about senders who do not comply is highly appreciated. Best Alexander > Am 02.11.2017 um 14:47 schrieb David Hofstee <opentext.dhofs...@gmail.com>: > > Hi Alexander, > > > 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? > The sender. He knows that by sending to Gmail, it will be cut off. Or he > should now. He could add the unsubscribe button at the top as an alternative > (but does not). Anyway, in effect there is no unsubscribe link. Would you > allow an unsubscribe link in white text on a white background? Very light > gray on white? Your rules should reflect that too. > > > That's why not every complaint gets feedback but is still used and highly > > appreciated. > Well, maybe I expected something differently. E.g. a reply the next business > day (as a means to say that matters are looked into and how they are dealt > with). Because "no reply" means, in my book, that nothing happened (call it > "industry standard"). It certainly does not motivate people to complain if > you don't respond. > > So I don't think that being a CSA member is "bad". But I don't see the "good" > or "exceptional" as part of your plan to make the deliverability landscape a > better place. Just some compromise by committee. And in practice, some say > your header is already a small spam indicator. The CSA seems to lag and not > lead. I would really like it to be the opposite (otherwise I would not take > time to respond). > > Yours, > > > David > > On 2 November 2017 at 13:59, Alexander Zeh <alexander....@eco.de > <mailto:alexander....@eco.de>> wrote: > 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 >> <mailto: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 >> <https://maps.google.com/?q=Lichtstrasse+43h50825+Cologne+Germany&entry=gmail&source=g> >> 50825 Cologne >> <https://maps.google.com/?q=Lichtstrasse+43h50825+Cologne+Germany&entry=gmail&source=g> >> Germany >> <https://maps.google.com/?q=Lichtstrasse+43h50825+Cologne+Germany&entry=gmail&source=g> >> >> 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 > <https://maps.google.com/?q=Lichtstrasse+43h+50825+Cologne+Germany&entry=gmail&source=g> > 50825 Cologne > <https://maps.google.com/?q=Lichtstrasse+43h+50825+Cologne+Germany&entry=gmail&source=g> > Germany > <https://maps.google.com/?q=Lichtstrasse+43h+50825+Cologne+Germany&entry=gmail&source=g> > > 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/> > > 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 > > > > > -- > -- > My opinion is mine.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
