Re: [mailop] SendGrid Abuse unresponsive

2020-05-05 Thread Alexander Zeh via mailop
Hi Andy,

well.. there is software out there that does exactly that. Follow every single 
link. Sometimes multiple times even with a delay of hours. At least that’s what 
I am seeing. That stuff is pretty annoying. But you’re right, for abuse reports 
there should be a webform and some kind of captcha. I don’t agree with the 
unsubscribe mechanism though. As list-unsubscribe is supposed to be done by the 
mail client in the background without showing the result to the user, a captcha 
or something like that would defeat the purpose. But that’s already kind of 
solved with https://tools.ietf.org/html/rfc8058 
<https://tools.ietf.org/html/rfc8058>.

Cheers,
Alex

> Am 05.05.2020 um 17:42 schrieb Andy Smith via mailop :
> 
> Hi Alexander,
> 
> On Tue, May 05, 2020 at 05:25:38PM +0200, Alexander Zeh via mailop wrote:
>>> It would also be great if SendGrid would include an abuse reporting
>>> URL in the headers of each message, specific to that message, i.e.
>>> that passes along all info that SendGrid would need to identify that
>>> campaign/client.
>> 
>> I’m not so sure about that, having in mind that the list-unsubscribe header 
>> already causes some headache on my end as some filters are checking and 
>> therefore „clicking“ all the URLs they find in body and header. 
> 
> At a minimum wouldn't such software already follow all links and
> confirm deliverability on behalf of the recipient every time they
> got marketing email? That seems like a bad idea to begin with, and
> also a bad idea from the web server side.
> 
> All web contact forms already need some sort of "I am not a bot"
> detection because of software like that; you couldn't have some sort
> of "this is spam" web service that took a report solely based on a
> GET request, and sensible unsubscribe mechanisms don't work that way
> either.
> 
> Cheers,
> Andy
> 
> ___
> 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] SendGrid Abuse unresponsive

2020-05-05 Thread Alexander Zeh via mailop
Hello,

> It would also be great if SendGrid would include an abuse reporting
> URL in the headers of each message, specific to that message, i.e.
> that passes along all info that SendGrid would need to identify that
> campaign/client.

I’m not so sure about that, having in mind that the list-unsubscribe header 
already causes some headache on my end as some filters are checking and 
therefore „clicking“ all the URLs they find in body and header. 

Cheers,
Alex
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] contact to freenet.de mail admin here on the list ?

2020-05-04 Thread Alexander Zeh via mailop
Hi,

I get responses from postmas...@freenet.de . 
(Sometimes it takes a few days, depending on the amount of requests they get).

Cheers,
Alex

> Am 04.05.2020 um 14:05 schrieb Kurt Jaeger via mailop :
> 
> Hi!
> 
> For a mailserver I'm operating we see rejections when the connecting
> IP is from IPv6, with the error message:
> 
> 550-Inconsistent/Missing DNS PTR record (RFC 1912 2.1)
> 
> I've checked forward/reverse/SPF records for that domain and
> set of IPs and everything checks out.
> 
> Is there some freenet.de mailadmin at hand so that we can find the
> cause of that problem ?
> 
> -- 
> p...@opsec.eu+49 171 3101372Now what ?
> 
> ___
> 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] authentication failures for messages from microsoft

2019-10-18 Thread Alexander Zeh via mailop
Hi,

I have a similar issue with confirmation mails from the Office 365 Delist 
Portal.
When using an outlook-freemail address it’s going to the spam folder at least, 
where I can access it.

Alex

> Am 18.10.2019 um 07:56 schrieb Andreas Schulze via mailop :
> 
> Am 11.10.19 um 15:27 schrieb Andreas Schulze via mailop:
>> we receive multiple complains from out customers not getting notification 
>> messages from Microsoft.
>> Our DMARC filter reject them.
> 
> Hello,
> 
> no one has similar observations? Mr. Micheal Wise: could you share some 
> insides?
> 
> -- 
> A. Schulze
> DATEV eG
> 
> ___
> 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] Do we need Spam folders?

2019-10-16 Thread Alexander Zeh via mailop
The thing is.. maybe technically savvy users don’t need spam folders. But 
having „normies“ in mind, like I’m thinking of my parents or friends who work 
in a totally different industry, I’m sure we need spam folders.
Why? Because most people are kind of lazy. They don’t want to move spam away, 
even if it’s only one click. They want the provider to do it for them. And if 
they can choose from multiple providers (e.g. Google vs. outlook.com 
 vs. Yahoo …) they will choose the more convenient option. 
(Just think of WhatsApp or messengers in general.. WA was so extremely 
successful, because it was the first who’s was really convenient for the users).

And (especially big) providers do whatever the majority of the users want, 
because that’s what enables their business.
If you run a server for a couple of users, simply try the approach you’re 
suggesting here and wait for the reaction. I’m pretty sure most users won’t be 
very happy and ask you to bring back the old behavior.


> Am 16.10.2019 um 14:19 schrieb Jaroslaw Rafa via mailop :
> 
> Dnia 16.10.2019 o godz. 13:01:49 Paul Smith via mailop pisze:
>> In your first situation, rejecting the messages is very bad. In the
>> second situation, rejecting the messages *may* be better than
>> accepting and semi-hiding - but only if you have another viable way
>> of contacting the recipient. So, in general, rejecting is the worse
>> option.
> 
> I'm not in favour of rejecting.
> 
> I would rather be in favour of only *marking* the possible spam as spam,
> without auto-moving it to the spam folder, and leaving the option to do so
> to the user. It may be a single-click setup that turns on automatical moving
> of messages marked as spam to the spam folder, but still if this would
> require user's decision, the user will be more aware that such thing as spam
> folder exists at all, and more likely to check this folder periodically than
> in case when this is set up automatically by email provider and the user
> might even don't know about it.
> -- 
> Regards,
>   Jaroslaw Rafa
>   r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> 
> ___
> 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] Gmail marking email from me as spam

2019-10-14 Thread Alexander Zeh via mailop
My best guess from a receivers perspective is:
If >99.9% of the traffic from a netblock were spam (let’s say from half of the 
IPs in that block), I don’t want to accept any more messages from the other IPs 
from the same netblock (and risk unhappy recipients and - even worse - 
financial impact because they contact support) because statistically they are 
most likely spam too.

Even though some of the other IPs might be clean.. the positive impact of 
rejecting the whole netblock is most likely no more spam, even from IPs I never 
received a single mail from before (meaning happier users, no support costs,…) 
vs. the negative impact of very few false positives which cost almost nothing.

I don’t say that this is necessarily good the way it is, but I can totally 
understand the idea behind that.


> Am 14.10.2019 um 15:58 schrieb Nick via mailop :
> 
> On 2019-10-14 14:41 BST, Graeme Fowler via mailop wrote:
>> On 14 Oct 2019, at 14:30, Nick via mailop  wrote:
>>> If an ip address in the range is held by a legitimate mailer, you're
>>> saying the legitimate mailer will be evicted to make way for the
>>> spammer?  Does that really happen?
>> 
>> No; but if you don't get any email from the 'legitimate' sender then
>> your only signal is that from the neighbours.
> 
> Sure, and blocking the neighbours who are deemed spammers is not what
> I'm questioning.
> 
>> If a large percentage of them have a signal which is 'poor' (FSVO
>> 'poor') then the inference is that the whole block is poisonous, and
>> you bin it (or put mail from it in the junk folder).
> 
> It is not an inference.  You agreed ("Does that really happen?" "No")
> that legitimate senders remain in the block.  The whole block is not
> poisonous.
> 
> My question remains unanswered.  Why not treat each ip address on its
> own merits?  Is it technically infeasible, too expensive, less
> convenient, or what?
> -- 
> Nick
> 
> ___
> 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


[mailop] https://sender.office.com/ not working (or only with outlook.com addresses)

2019-09-30 Thread Alexander Zeh via mailop
Hi all,

I recently wanted to delist an IP using https://sender.office.com/ 

Unfortunately I never received the confirmation email from step 2. I heard from 
others that they received the email when using an address @outlook.com, I 
didn’t confirm that though. Do others see the same behavior? It’d be weird to 
be forced to register a mailbox there to do that, as I don’t need it that often.

Cheers,
Alex


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Resolving issues for several yahoo domains?

2019-09-05 Thread Alexander Zeh via mailop
Same problem here.
Seems to be a general problem: https://downforeveryoneorjustme.com/yahoo.de 


> Am 05.09.2019 um 10:18 schrieb tobisworld--- via mailop :
> 
> We're currently seeing several yahoo domains (ex yahoo.de) cannot be
> resolved any more in DNS. All the responsable nameservers for that
> domain do not reply anymore. Only ns4.yahoo.com replies from time to
> time for yahoo.de but according to glue record ns4.yahoo.com is not in
> charge for yahoo.de anymore.
> 
> anyone else seeing such problems with yahoo?
> 
> --
> Cheers
> 
> tobi
> 
> ___
> 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] [ext] Re: Return Path / Sender Score

2019-08-26 Thread Alexander Zeh via mailop
This might also be an issue of different wordings used in different parts of 
the world. I started working in the email space 10+ years ago for the eco 
Association in Germany. In every document, in every personal conversation I 
had, always the term DOI was used. Not only by marketeers, also by postmasters 
and lawyers.
I heard the term COI for the very first time at a M3AAWG meeting, and indeed 
thought it’s the term for „I’ll send the recipient a confirmation email that 
he’s now subscribed“.
I’m not sure how these terms are used in other european countries.

Alex

> Am 26.08.2019 um 00:06 schrieb Luke via mailop :
> 
> Personally, I consider every effort to quietly redefine elements of language
> to suit a particular set of political, economic, or personal objectives to be
> concerning
> 
> As do I. I guess my argument is that this isn't what is happening when some 
> email marketer says "double opt in" or "cold outreach."
> 
> If you're someone who hasn't spent a great deal of time thinking about the 
> world's spam problem or haven't really given much thought to the consequences 
> of not requiring some kind of confirmation before adding an address to your 
> mailing list, the term double opt in makes sense. 
> 
> Should they be corrected? Sure. Should they be taught that "double opt in" 
> isn't actually accurate because the recipient is only opting in once. Sure. 
> Do they deserve to be labeled a spammer or be told they are talking like a 
> spammer? No. Is it some kind of concerted effort to normalize spammy 
> behavior? No. 
> 
> I don't like the terms double opt in or cold outreach either and I don't use 
> them. But I don't think the term "spamspeak" and the allusion to 1984 is 
> appropriate.
> 
> Luke
> 
> 
>  
> 
> On Sun, Aug 25, 2019 at 10:06 AM Michael Rathbun  > wrote:
> On Sun, 25 Aug 2019 08:14:16 -0700, Luke via mailop  > wrote:
> 
> >I did intend to send it to the whole list.
> >
> >"Spamspeak" makes it sound so clandestine. So Orwellian. Like there is some
> >> subversive element on the list trying to turn the tides and normalize spam.
> >> Sounds spooky. Sounds provocative. Let's run with this.
> >> *Rolls eyes*
> >
> >
> >But yes, I was poking fun at the use of the term spamspeak. The allusion to
> >1984's newspeak or doublespeak is silly.
> 
> I have seldom been accused of being overly serious.
> 
> >If alluding to 1984 in the context of permission based email isn't a little
> >funny to you, then I apologize for my remarks.
> 
> Personally, I consider every effort to quietly redefine elements of language
> to suit a particular set of political, economic, or personal objectives to be
> concerning, however "funny" they may appear at the onset.  (I leave out of the
> discussion the fact that I once had a role in a stage production of "1984"
> that made me more than slightly well-acquainted with that work.)
> 
> Rob's remarks were, to my knowledge, accurate and apposite.
> 
> mdr
> -- 
>Those who can make you believe absurdities 
>can make you commit atrocities.
> -- Voltaire
> 
> ___
> 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] Any t-online.de admins here?

2019-01-25 Thread Alexander Zeh
Hi,

again, I'm not sure if anyone from them is on this list, but I forwarded your 
mail to my contact.

Best,
Alex

> Am 25.01.2019 um 11:41 schrieb Eike Armbrust :
> 
> Hello everyone!
> 
> For the third time in the last three months one of our mail servers was 
> blacklisted by T-Online. In all cases the reason for being blacklisted was 
> that users had an automated forwarding to T-Online and one(!) uncaught spam 
> email got forwarded.
> 
> 
> 
> Eike Armbrust
> Rechenzentrum
> 
> Ostfalia Hochschule für angewandte Wissenschaften
> — Hochschule Braunschweig/Wolfenbüttel 
> Rechenzentrum
> Salzdahlumer Straße 46/48
> 38302 Wolfenbüttel
> 
> Tel.:   +49 5331 939 19410
> Fax:   +49 5331 939 19004
> E-Mail:   eike.armbr...@ostfalia.de <mailto:eike.armbr...@ostfalia.de>
> Internet: www.ostfalia.de/rz 
> <http://www.ostfalia.de/rz>___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

-- 
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
Managing Director: Alexander Rabe
Management Board: Oliver Süme (Chairman), Klaus Landefeld (Vice Chairman), 
Felix Höger, Prof. Dr. Norbert Pohlmann
Register of Associations: District Court (Amtsgericht) Cologne, VR 14478
Registered Office: Cologne



smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] Contact at Posteo.de

2019-01-23 Thread Alexander Zeh
Hi Florent,

I'm not sure if someone from posteo is on this list, but I forwarded your 
request to my contacts there directly.

HTH,
Alex

> Am 23.01.2019 um 09:57 schrieb Florent Destors 
> :
> 
> Hi,
>  
> Is there anybody from Posteo.de <http://posteo.de/> here I can reach out to ? 
> Or Could someone provide me with a contact address ?
> 
> Thank you
> 
> Best regards
> Florent
>  
>  
> - - - - -
> FLORENT DESTORS
> DELIVERABILITY CONSULTANT
>  
> direct  +33 1 44 68 10 78
> mobile  +33 6 13 20 61 16
> email  florent.dest...@selligent.com <mailto:florent.dest...@selligent.com>
>  
> SELLIGENT MARKETING CLOUD
> CONSUMER-FIRST MARKETING
> www.selligent.com <http://www.selligent.com/>
>  
> The information contained in this communication is confidential and is only 
> for the use of the intended addressee. If you have received this 
> communication in error, please destroy it immediately, including all 
> attachments.
>  
> ___
> 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>
-- 
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
Managing Director: Alexander Rabe
Management Board: Oliver Süme (Chairman), Klaus Landefeld (Vice Chairman), 
Felix Höger, Prof. Dr. Norbert Pohlmann
Register of Associations: District Court (Amtsgericht) Cologne, VR 14478
Registered Office: Cologne



smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] About the Certified Senders Alliance

2017-11-03 Thread Alexander Zeh
Hello Grant,

thanks for your thoughts. Basically that applies to everybody on this list.
I will bring that information about gmail and the clipping of mails into 
account when he next review of the criteria is due.

I was a bit careful when talking about the details how we need to optimise the 
feedback to complainants, because we really want to make it so it can't be 
abused.

For everybody to know: I won't be available the next week with very limited 
access to my emails. Be aware I don't ignore mails, I might just not be able to 
access them. ;)

Best
Alexander

> Am 02.11.2017 um 19:28 schrieb Grant Taylor via mailop <mailop@mailop.org>:
> 
> On 11/02/2017 08:53 AM, Alexander Zeh wrote:
>> I dare to disagree with your opinion that the sender is to blame.
> 
> I don't think that the sender is responsible for what receivers do with 
> messages.
> 
> I *do* think that it is /prudent/ for the sender to be aware of what 
> recipients /might/ do with the messages, including only displaying part of 
> the message.
> 
> How many other things are changed about messages based on what mailbox 
> providers do, in an attempt to try to ensure messages are placed in the 
> inbox?  -  I consider these common action as self evidence that senders do 
> care about what receivers do.
> 
>> Gmail decides to alter the way the message is shown.
> Gmail is one of many providers / MUA vendors that have undesired behaviors.  
> (Possibly by default.)
> 
>> This is misleading.
> 
> I agree.
> 
>> 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.
> 
> I have to disagree with this statement.
> 
> MUAs have had the ability to only download part of messages from the email 
> server for years, based on various criteria.  I.e. IMAP clients not 
> downloading attachments until requested.
> 
> I see zero reason to reject a message at SMTP time.  (At least not for 
> message size unless it exceeds an upper maximum bound, which needs to be well 
> documented.)
> 
>> 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.
> 
> I have seen recent public discussion that Gmail /might/ use the 
> List-Unsubscribe header.  I would not count on this actually being consumed.  
> -  Providing it is a good thing.
> 
>> 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.
> 
> That is you (and many others.)  But that is NOT everybody.
> 
>> 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.
> 
> Would it be possible to request that CSA members include an additional 
> subscriber / recipient in messages that is a CSA monitoring email?  - I'd 
> think that it would be trivial to look for things like the existence of the 
> List-Unsubscribe / X-CSA-Complaints headers.
> 
> I'm sure there are many flaws with such automated monitoring.  But I think 
> it's better than nothing, and would provide some data points.
> 
>> 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
>> Anyway.. as you can imagine they receive tons of (non CSA related) 
>> complaints, and it's not viable to answer every single complaint.
> 
> Does ECO not send auto-responders (with proper Auto-Submitted header) back to 
> the (purported) complaint sender?
> 
> I'd think that would be trivial.
> 
> It would also provide a place to provide some boiler plate stating that not 
> every email is responded to.  -  It could even provide a place to state 
> something like "Spam repo

Re: [mailop] About the Certified Senders Alliance

2017-11-02 Thread Alexander Zeh
Hello Felix,

right now the whitelist can only be queried if we set up access for you. This 
has various historical and legal reasons.
If you are interested in using the whitelist (or simply try it) please send me 
an email off-list.
And we're always happy to receive abuse reports. It helps us to maintain the 
list. Thanks for that. :)

Best
Alexander

> Am 02.11.2017 um 16:33 schrieb Felix Schwarz via mailop <mailop@mailop.org>:
> 
> 
> Am 02.11.2017 um 15:53 schrieb Alexander Zeh:
>> 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.
> 
> Is there any public information about how to query that whitelist? I didn't
> find any information about the whitelist on your website.
> 
> (Also I just checked our mail stats and kicked a few abuse reports with fresh
> "CSA" spam. The kajomi guys still seem to have some "quality" issues.)
> 
> Felix Schwarz
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Re: [mailop] About the Certified Senders Alliance

2017-11-02 Thread Alexander Zeh
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

Re: [mailop] About the Certified Senders Alliance

2017-11-02 Thread Alexander Zeh
ree? 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_bwvx"
> 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 + (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ög

[mailop] About the Certified Senders Alliance

2017-11-01 Thread Alexander Zeh
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
fax: +49 (0) 221 - 70 00 48 - 111
mobile: +49 (0) 171 - 657 2628
e-mail: 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

smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop