Re: [mailop] IPs blacklisted with Microsoft

[Michael Wise via mailop]

If you don't get a response back to the reply from a human inside of 24 hours, 
I'd reply again.

It's also possible they're a tad busy at the moment… what with Convergence and 
all.

Responses might be delayed, but if no reply in 24 hours, try again regardless.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool ?



-Original Message-
From: Andreas Ziegler [mailto:m...@andreas-ziegler.de]
Sent: Thursday, November 2, 2017 6:21 PM
To: Michael Wise 
Cc: mailop@mailop.org
Subject: Re: [mailop] IPs blacklisted with Microsoft



Hi Michael,



we also have a similar case ( SRX1402507373ID )



We acted like you suggested many times, the subnet also doesn't show any

problems in SNDS and there were no JMRP mails.



nevertheless, the robot didn't mitigate the issue and our manual

response didn't trigger any action from "your" side yet - it's almost 7

days now.



we deliver the mail via a relay in a totally different subnet at the

moment and there's no issue with that relay's IP - it's just working.

so i really can't see what the problem might be with our customer's mails.



Regards



Andreas





Michael Wise via mailop schrieb am 20.09.2017 um 00:30:

> Standard response is to start by opening a ticket … using this link.

>

>

>

> The first response will be from a robot confirming that the ticket has

> been opened, and then within 24 hours (typically much less), the robot

> will respond with the details of the Mitigation applied (“If any…”).

>

>

>

> If the results are not to your satisfaction, reply to that 2^nd email

> and … State Your Case.

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

Re: [mailop] IPs blacklisted with Microsoft

[Andreas Ziegler]

Hi Michael,

we also have a similar case ( SRX1402507373ID )

We acted like you suggested many times, the subnet also doesn't show any
problems in SNDS and there were no JMRP mails.

nevertheless, the robot didn't mitigate the issue and our manual
response didn't trigger any action from "your" side yet - it's almost 7
days now.

we deliver the mail via a relay in a totally different subnet at the
moment and there's no issue with that relay's IP - it's just working.
so i really can't see what the problem might be with our customer's mails.

Regards

Andreas


Michael Wise via mailop schrieb am 20.09.2017 um 00:30:
> Standard response is to start by opening a ticket … using this link.
> 
>  
> 
> The first response will be from a robot confirming that the ticket has
> been opened, and then within 24 hours (typically much less), the robot
> will respond with the details of the Mitigation applied (“If any…”).
> 
>  
> 
> If the results are not to your satisfaction, reply to that 2^nd email
> and … State Your Case.
> 

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

Re: [mailop] mail.ru google and DMARC

[Brandon Long via mailop]

I would add that SRS itself is fairly useless, it was never adopted as a
spec, and it's unlikely many people are going to do anything special with
it.  There was never any method given for how one would validate SRS, so
the most one could do would be to say trust the SRS of a domain if the SPF
reputation or IP reputation was above a certain threshold... but the usage
of SRS is so low I doubt many folks would bother adding rules for it.

Using SRS to forward to Gmail is against our recommendations for
forwarding, and yes, it will likely cause your domain to accumulate bad
reputation for any spam you forward to us.

I disagree with Vladimir that ARC requires a whitelist for trust, using a
whitelist is certainly how I expect smaller operators and folks running
their own servers to work.  We think it's possible for an operator with
sufficient mail volume to programmatically learn mailflows, assign
reputations and build a trust framework.  It should also be possible for
operators to contract with third party vendors who have the expertise
and/or volume to do that.  We could also be wrong, that's one of the
reasons the current plan is to publish the ARC RFC on the experimental
track.

Brandon


On Thu, Nov 2, 2017 at 8:34 AM Vladimir Dubrovin via mailop <
mailop@mailop.org> wrote:

>
>
> ARC doesn't solve the problem either, because ARC requires trust to be
> established between all signers in the chain and receiver of the mesage.
> ARC doesn't provide any means to establish this trust. In short: ARC
> will only work with the whitelist of known forwarders and it doesn't
> contain any means to redistribute or update this whitelist. It's
> intended product like OpenARC to be destributed with the whitelist of
> known forwarders preloaded.
>
> It's quite sad people misunderstand this fact and believe ARC can
> replace DMARC. It can not. ARC doesn't work without DMARC, because ARC
> only ads whitelist and tracking functionality to DMARC.
>
> Currently, we have whitelists based on DKIM signatures / IP addresses of
> known forwarders, so the profit from ARC is close to zero. It allows to
> distinguish between forwarded and locally generated message and is
> helpful in the case message is forwarded for multiple times. That's all.
>
> P.S.
> Benoit provided the original message - it was a spam message with the
> fake address, so it had no DKIM authentication. Forwarding message like
> that with SRS to GMail gives negative reputation for both forwarding IP
> and authorizing domain (one used for SRS). DMARC filter on forwarding
> server could eliminate this problem. No problems are expected for real
> message with DKIM authentication in current configuration.
>
> 02.11.2017 17:12, Ken O'Driscoll пишет:
> > On Thu, 2017-11-02 at 13:28 +0100, Benoit Panizzon wrote:
> >> How would one correctly implement email forwarding which works with all
> >> kind of SPF, DKIM and DMARC Variants?
> > Hi Benoit,
> >
> > Short answer - you can't. DMARC is simply not designed to facilitate any
> > type of address re-writing or forwarding.
> >
> > As Vladimir points out, DKIM can sometimes prevail after an email is
> > forwarded, but it can't be assumed. Plus, that DKIM signature must be
> > already working and aligned to the original sending domain.
> >
> > DMARC also breaks mailing lists. Mailman "gets around" DMARC by
> re-writing
> > the From address to be that of the list and putting the original sender
> in
> > the Reply-To. Fine for mailing lists, not so fine for one-to-one emails
> > etc.
> >
> > There is an emerging mechanism called ARC (http://arc-spec.org/) which
> > addresses this restriction in DMARC to some degree in certain cases. Many
> > providers, including Google, are already trialing ARC and it is being
> > actively worked on.
> >
> > Ken.
> >
> > --
> > Ken O'Driscoll / We Monitor Email
> > t: +353 1 254 9400 | w: www.wemonitoremail.com
> >
> > Need to understand deliverability? Now there's a book:
> > www.wemonitoremail.com/book
> >
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Vladimir Dubrovin
> @Mail.Ru
>
>
>
> ___
> 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] Message recipients column in SNDS

[Emre Üst |euro . message|]

Hello Maarten ,

Errors you have received,  returned to normal?

We too ,detected large difference between these numbers,

RCPT
commands  111829

DATA
commands 106093

Message
recipients 1215

 and we only see

451 4.7.500 Server busy. Please try again later from []. (AS3114) [
AM5EUR02FT027.eop-EUR02.prod.protection.outlook.com]" while connected from
() to hotmail-com.olc.protection.outlook.com (104.47.4.33)

Thank you


-- 

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

Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some

[Emre Üst |euro . message|]

Hi Michael ,

Unfortunately , it doesnt work . Outlook Support team said that there is
not blocking on their side .

Although the ips are Returnpath certified. Sometimes we also get 421 RP-001
(BAY004-MC2F28) errors. But mostly 451 4.7.500 Server busy. Meanwhile, on
snds I see that there is a lot of difference between the number of RCPT
fields and Message recipientss.

For Exp.

RCPT
commands  111829

DATA
commands 106093

Message
recipients 1215

Thank you


On Thu, Nov 2, 2017 at 10:18 PM, Michael Wise 
wrote:

>
>
> Please open a ticket.
>
>
>
>   https://go.microsoft.com/fwlink/?LinkID=614866
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *Emre Üst
> |euro.message|
> *Sent:* Wednesday, November 1, 2017 2:20 PM
> *To:* mailop@mailop.org
> *Subject:* Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some
>
>
>
> Hello Michael,
>
> We have same issues
>
> 185.11.213.11;185.11.213.12;185.11.213.13;185.11.213.14;185.11.213.15
>
> İts kind of like all network blocked .
>
> Thank you
>
>
>
>
> --
>
> [image: Image removed by sender.]
>
> [image: Image removed by sender.]
>
> *EMRE ÜST*
>
> Deliverability Specialist
>
>
>
> *t.*   +902123430739 <(0212)%20343%2007%2039>
> *f.*   +902123430742 <(0212)%20343%2007%2042>
>
> *email: *emre@euromsg.com <%23>
> *skype:* user_name
> *web:* euromsg.com
> 
> Yeşilce Mh. Yunus Emre Cd. Ada İş Mrk. No: 4 Zemin Kat 4. Levent / İstanbul
>
>
>
> [image: Image removed by sender.]
>
> [image: Image removed by sender.]
> 
>
> [image: Image removed by sender.]
> 
>
> [image: Image removed by sender.]
> 
>
> [image: Image removed by sender.]
> 
>
> [image: Image removed by sender.]
>
> [image: Image removed by sender.]
>
> [image: Image removed by sender.]
> 
>
> [image: Image removed by sender.]
> 
>
> [image: Image removed by sender.]
> 
>
> [image: Image removed by sender.]
> 
>
> [image: Image removed by sender.]
> 

Re: [mailop] Hotmail, green SNDS and junk folder placement

[Michael Wise via mailop]

I have not received a confirmation that I consider authoritative at this point 
in time.
There's a lot going on at the moment, and I'm still trying to find out who can 
speak to this authoritatively.

Apologies for the delay.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool ?

From: Bressier Simon [mailto:bressie...@gmail.com]
Sent: Thursday, November 2, 2017 6:16 AM
To: Michael Wise 
Cc: Benjamin BILLON ; mailop@mailop.org
Subject: Re: [mailop] Hotmail, green SNDS and junk folder placement

Hey Michael,

Sorry to bother :) did you have any news regarding these questions ? The point 
is really interesting for all of us here, and as a router to know if we have to 
be more strict with all our customers and "grey" senders, it could helps a lot 
to know if we have to multiply the current spam complaints count by xxx.

Thank you very much in advance !

Simon

2017-10-30 18:49 GMT+01:00 Michael Wise via mailop 
>:

I'm asking a few people to confirm my understanding and will get back to y'all.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool
 ?

From: Benjamin BILLON [mailto:bbillon...@splio.fr]
Sent: Saturday, October 28, 2017 1:13 AM
To: Michael Wise >

Cc: mailop@mailop.org
Subject: Re: [mailop] Hotmail, green SNDS and junk folder placement

Hi Michael,

> Also, the JMRP doesn't generate 1:1 reports for each piece of traffic 
> reported as spam.
> The ratio is much smaller than that, otherwise senders would use it for List 
> Washing, and that's frowned upon.
Wow, wow wow wow.
This is absolutely new to me.
That would explain why we receive only 1/3 of the volume of ARF from 
Hotmail/Live than from Yahoo, while we send twice more to Hotmail/Live than 
Yahoo.
However, that's not what 
https://mail.live.com/mail/services.aspx
 says: "Returns the full message with headers of *any* email marked as "junk" 
or "phishing""
This is a HUGE change, if potential list washing is the issue, IMHO this is the 
wrong answer. This basically makes JMRP irrelevant for ESPs: we don't have 
reliable metrics, we can not satisfy people complaining as they'll keep getting 
the same message, probably in junk folder, which will probably weight 
negatively in the reputation ...

I'm totally amazed by this information.

That being said, even though the ratio is not 1:1, I _guess_ it's roughly the 
same for everybody. So we have clients that generate more than 9 complains a 
month and still enjoy a low BCL and inbox placement, while this one got an 
inexplicable BCL of 8.

For the record, the ticket is SRX1401741292ID it highlights the discrepancy 
SNDS color / inbox placement (as Terry told me to do), and timidly mention the 
BCL without naming it (I reminded my folks to be more explicit in the tickets).
The last reply we got was "after reviewing the information you provided and in 
compliance with our mail policies, we are unable to offer immediate mitigation 
for your deliverability issue", so I guess we washed off the Support Level 2. I 
wonder how many levels before the final boss!

Cheers,


--


Benjamin

2017-10-28 7:46 GMT+08:00 Michael Wise via mailop 
>:

There are ways of dealing with BCL, but I'd suggest you point it out when 
opening the ticket.
Also, the JMRP doesn't generate 1:1 reports for each piece of traffic reported 
as spam.
The ratio is much smaller than that, otherwise senders would use it for List 
Washing, and that's frowned upon.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool
 ?

From: mailop 

Re: [mailop] About the Certified Senders Alliance

[Grant Taylor via mailop]

On 11/02/2017 12:49 PM, Michael Peddemors wrote:

Ouch, I can name a hundred reasons to..


Sorry, let me clarify.

I see no reason to reject messages at SMTP time just because you might 
choose not to display all of the message in the default view, yet make 
it available in a full message view.


I.e. why reject an otherwise perfectly legitimate email to a perfectly 
legitimate recipient when dmesg out put is in the body of the message vs 
as an attachment?


Rejecting immediately with a clear notice, allows the sender to identify 
why the message didn't go through..


I agree that rejecting at SMTP time is the best thing to do, for 
warranted reasons.  -  I think that a long message body (that is still 
smaller than published maximums) is not a valid reason in and of itself.



Need I go on?


Not about rejecting at SMTP time vs bouncing after the fact.

I'm curious why you would reject a message just because the MUA might 
choose to fold / not display some of the body by default, yet make it 
available at the click of a button.




--
Grant. . . .
unix || die



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

Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some

[Michael Wise via mailop]

Please open a ticket.

  https://go.microsoft.com/fwlink/?LinkID=614866

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool ?

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Emre Üst 
|euro.message|
Sent: Wednesday, November 1, 2017 2:20 PM
To: mailop@mailop.org
Subject: Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some

Hello Michael,
We have same issues

185.11.213.11;185.11.213.12;185.11.213.13;185.11.213.14;185.11.213.15
İts kind of like all network blocked .
Thank you


--
[Image removed by sender.]

[Image removed by sender.]

EMRE ÜST

Deliverability Specialist



t.   +902123430739
f.   +902123430742

email: emre@euromsg.com
skype: user_name
web: 
euromsg.com
Yeşilce Mh. Yunus Emre Cd. Ada İş Mrk. No: 4 Zemin Kat 4. Levent / İstanbul





[Image removed by sender.]

[Image removed by 
sender.]

[Image removed by 
sender.]

[Image removed by 
sender.]

[Image removed by 
sender.]

[Image removed by sender.]


[Image removed by sender.]

[Image removed by 
sender.]


[Image removed by 
sender.]

[Image removed by 
sender.]

[Image removed by 
sender.]

[Image removed by 
sender.]

[Image removed by sender.]

[Image removed by sender.]

[Image removed by 
sender.]


[Image removed by sender.]



This e-mail message may contain confidential or legally privileged information 
and is intended only for the use of the intended recipient(s). Any unauthorized 
disclosure, 

Re: [mailop] iCloud "Message rejected due to local policy"

[Felix Schwarz via mailop]

Am 02.11.2017 um 16:48 schrieb Chris Nagele:
> Hi all. Does anyone have experience dealing with the SMTP response
> "550 5.7.1 Message rejected due to local policy" from iCloud / Apple?

Probably not so helpful but we saw similar issues in the past. I contacted
icloudad...@apple.com then but usually we were able to send before they got
back to us.

For it only affected some recipients even though all messages were sent from
the same domain/IP.

Felix

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

Re: [mailop] About the Certified Senders Alliance

[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 :
> 
> 
> 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

[mailop] iCloud "Message rejected due to local policy"

[Chris Nagele]

Hi all. Does anyone have experience dealing with the SMTP response
"550 5.7.1 Message rejected due to local policy" from iCloud / Apple?

We have a few customers receiving these responses back, but so far it
seems random. We can't tell if it is related to the local policy of
the sending domain (DMARC, etc) or the local policy of the receiving
account (if that even exists in iCloud). For now, neither makes sense,
because a single recipient who was successfully delivered to yesterday
might get the 550 response today.

I can't find any useful info on this response code, so if anyone has
more info I would love to know.

Thanks,
Chris

-- 
Chris Nagele
CTO, Wildbit
http://wildbit.com

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

Re: [mailop] About the Certified Senders Alliance

[Felix Schwarz via mailop]

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

Re: [mailop] mail.ru google and DMARC

[Vladimir Dubrovin via mailop]

ARC doesn't solve the problem either, because ARC requires trust to be
established between all signers in the chain and receiver of the mesage.
ARC doesn't provide any means to establish this trust. In short: ARC
will only work with the whitelist of known forwarders and it doesn't
contain any means to redistribute or update this whitelist. It's
intended product like OpenARC to be destributed with the whitelist of
known forwarders preloaded.

It's quite sad people misunderstand this fact and believe ARC can
replace DMARC. It can not. ARC doesn't work without DMARC, because ARC
only ads whitelist and tracking functionality to DMARC.

Currently, we have whitelists based on DKIM signatures / IP addresses of
known forwarders, so the profit from ARC is close to zero. It allows to
distinguish between forwarded and locally generated message and is
helpful in the case message is forwarded for multiple times. That's all.

P.S.
Benoit provided the original message - it was a spam message with the
fake address, so it had no DKIM authentication. Forwarding message like
that with SRS to GMail gives negative reputation for both forwarding IP
and authorizing domain (one used for SRS). DMARC filter on forwarding
server could eliminate this problem. No problems are expected for real
message with DKIM authentication in current configuration.

02.11.2017 17:12, Ken O'Driscoll пишет:
> On Thu, 2017-11-02 at 13:28 +0100, Benoit Panizzon wrote:
>> How would one correctly implement email forwarding which works with all
>> kind of SPF, DKIM and DMARC Variants?
> Hi Benoit,
>
> Short answer - you can't. DMARC is simply not designed to facilitate any
> type of address re-writing or forwarding.
>
> As Vladimir points out, DKIM can sometimes prevail after an email is
> forwarded, but it can't be assumed. Plus, that DKIM signature must be
> already working and aligned to the original sending domain. 
>
> DMARC also breaks mailing lists. Mailman "gets around" DMARC by re-writing
> the From address to be that of the list and putting the original sender in
> the Reply-To. Fine for mailing lists, not so fine for one-to-one emails
> etc.
>
> There is an emerging mechanism called ARC (http://arc-spec.org/) which
> addresses this restriction in DMARC to some degree in certain cases. Many
> providers, including Google, are already trialing ARC and it is being
> actively worked on.
>
> Ken.
>
> -- 
> Ken O'Driscoll / We Monitor Email
> t: +353 1 254 9400 | w: www.wemonitoremail.com
>
> Need to understand deliverability? Now there's a book:
> www.wemonitoremail.com/book
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


-- 
Vladimir Dubrovin
@Mail.Ru



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

Re: [mailop] mailop Digest, Vol 121, Issue 9

[Jacob Hansen via mailop]

aid 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  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  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  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

Re: [mailop] About the Certified Senders Alliance

[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 

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 :
> 
> 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  > 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 
> 

Re: [mailop] mail.ru google and DMARC

[Ken O'Driscoll]

On Thu, 2017-11-02 at 13:28 +0100, Benoit Panizzon wrote:
> How would one correctly implement email forwarding which works with all
> kind of SPF, DKIM and DMARC Variants?

Hi Benoit,

Short answer - you can't. DMARC is simply not designed to facilitate any
type of address re-writing or forwarding.

As Vladimir points out, DKIM can sometimes prevail after an email is
forwarded, but it can't be assumed. Plus, that DKIM signature must be
already working and aligned to the original sending domain. 

DMARC also breaks mailing lists. Mailman "gets around" DMARC by re-writing
the From address to be that of the list and putting the original sender in
the Reply-To. Fine for mailing lists, not so fine for one-to-one emails
etc.

There is an emerging mechanism called ARC (http://arc-spec.org/) which
addresses this restriction in DMARC to some degree in certain cases. Many
providers, including Google, are already trialing ARC and it is being
actively worked on.

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book


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

Re: [mailop] About the Certified Senders Alliance

[David Hofstee]

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  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 

Re: [mailop] mail.ru google and DMARC

[Vladimir Dubrovin via mailop]

SPF record is OK, see https://tools.ietf.org/html/rfc7208#section-3.3

mail.ru publishes strict DMARC policy (reject) to prevent spoofing.

DMARC requires alignment between SPF authenticated domain and domain
from RFC5322.From
You perform SRS, so message you send is SPF-authenticated by your
domain, but this domain is not aligned with mail.ru domain from
RFC5322.From. Any redirecton makes SPF useless for DMARC.

DKIM is intended to fix this problem, and the real issue here is you
probably break DKIM signature of the message. It can happen if you
change content of the message or headers, by e.g. modifying Subject: or
adding something to mail body.

Can you diff original message and forwarded one to find possible
modifications?


02.11.2017 15:28, Benoit Panizzon пишет:
> Dear List
>
> I have come across a strange problem.
>
> One of our customers is forwarding his emails to his google account.
>
> We do implement SRS to rewrite the envelope sender to match our SPF
> record.
> All other headers are preserved, in case they are DKIM Signed.
>
> Google rejects the emails with:
>
> : host
> gmail-smtp-in.l.google.com[2a00:1450:4013:c00::1b] said: 550-5.7.1
> Unauthenticated email from mail.ru is not accepted due to domain's
> 550-5.7.1 DMARC policy. Please contact the administrator of mail.ru
> domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1
> https://support.google.com/mail/answer/2451690 to learn about the
> 550 5.7.1 DMARC initiative. m43si134563edm.154 - gsmtp (in reply to end
> of DATA command)
>
> Ok I have not yet stumbled over a lot of email senders using DMARC. So
> I read on: https://en.wikipedia.org/wiki/DMARC
>
> Did I get that right? DMARC checks that the envelope-from and From:
> header are 'aligned'?
>
> Well how the hell should that work when an email is being forwarded?
>
> SPF requires that I rewrite the envelope sender, DKIM requires that I
> don't alter the signed From: Header, DMARC requires that I do alter the
> From: Header?
>
> And where the heck does mail.ru publish it's DMARC policy via DNS?
>
> mail.ru has address 217.69.139.201
> mail.ru has address 94.100.180.201
> mail.ru has address 217.69.139.200
> mail.ru has address 94.100.180.200
> mail.ru name server ns3.mail.ru.
> mail.ru name server ns1.mail.ru.
> mail.ru name server ns2.mail.ru.
> mail.ru has SOA record ns1.mail.ru. hostmaster.mail.ru. 3300745053 900
> 900 604800 60 mail.ru mail is handled by 10 mxs.mail.ru.
> mail.ru descriptive text "v=spf1 redirect=_spf.mail.ru"
> mail.ru has IPv6 address 2a00:1148:db00:0:b0b0::1
>
> _spf.mail.ru descriptive text "v=spf1 ip4:94.100.176.0/20
> ip4:217.69.128.0/20 i" "p4:128.140.168.0/21 ip4:188.93.58.0/24
> ip4:195.2" "11.128.0/22 ip4:188.93.59.0/24 ip4:128.140.170.0" "/24
> ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5." "61.237.0/26
> ip4:5.61.237.128/25 ip4:5.61.236.0/2" "4 ip4:5.61.239.143/32
> ip4:5.61.239.144/32 ~all"
>
> Well his somehow looks like a broken SPF record. Anyway ~all would
> specify softfail and not reject.
>
> Can anyone help putting the puzzle together?
>
> How would one correctly implement email forwarding which works with all
> kind of SPF, DKIM and DMARC Variants?
>
> And yes I know, email forwarding is considered bad(tm), but it is still
> widely used.
>
> -Benoît Panizzon-


-- 
Vladimir Dubrovin
@Mail.Ru



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

Re: [mailop] Hotmail, green SNDS and junk folder placement

[Bressier Simon]

Hey Michael,

Sorry to bother :) did you have any news regarding these questions ? The
point is really interesting for all of us here, and as a router to know if
we have to be more strict with all our customers and "grey" senders, it
could helps a lot to know if we have to multiply the current spam
complaints count by xxx.

Thank you very much in advance !

Simon

2017-10-30 18:49 GMT+01:00 Michael Wise via mailop :

>
>
> I'm asking a few people to confirm my understanding and will get back to
> y'all.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* Benjamin BILLON [mailto:bbillon...@splio.fr]
> *Sent:* Saturday, October 28, 2017 1:13 AM
> *To:* Michael Wise 
>
> *Cc:* mailop@mailop.org
> *Subject:* Re: [mailop] Hotmail, green SNDS and junk folder placement
>
>
>
> Hi Michael,
>
>
>
> > Also, the JMRP doesn't generate 1:1 reports for each piece of traffic
> reported as spam.
>
> > The ratio is much smaller than that, otherwise senders would use it for
> List Washing, and that's frowned upon.
>
> Wow, wow wow wow.
>
> This is absolutely new to me.
>
> That would explain why we receive only 1/3 of the volume of ARF from
> Hotmail/Live than from Yahoo, while we send twice more to Hotmail/Live than
> Yahoo.
>
> However, that's not what https://mail.live.com/mail/services.aspx
> 
> says: "Returns the full message with headers of *any* email marked as
> "junk" or "phishing""
>
> This is a HUGE change, if potential list washing is the issue, IMHO this
> is the wrong answer. This basically makes JMRP irrelevant for ESPs: we
> don't have reliable metrics, we can not satisfy people complaining as
> they'll keep getting the same message, probably in junk folder, which will
> probably weight negatively in the reputation ...
>
>
>
> I'm totally amazed by this information.
>
>
>
> That being said, even though the ratio is not 1:1, I _guess_ it's roughly
> the same for everybody. So we have clients that generate more than 9
> complains a month and still enjoy a low BCL and inbox placement, while this
> one got an inexplicable BCL of 8.
>
>
>
> For the record, the ticket is SRX1401741292ID it highlights the
> discrepancy SNDS color / inbox placement (as Terry told me to do), and
> timidly mention the BCL without naming it (I reminded my folks to be more
> explicit in the tickets).
>
> The last reply we got was "after reviewing the information you provided
> and in compliance with our mail policies, we are unable to offer immediate
> mitigation for your deliverability issue", so I guess we washed off the
> Support Level 2. I wonder how many levels before the final boss!
>
>
>
> Cheers,
>
>
>
> --
>
> Benjamin
>
>
>
> 2017-10-28 7:46 GMT+08:00 Michael Wise via mailop :
>
>
>
> There are ways of dealing with BCL, but I'd suggest you point it out when
> opening the ticket.
>
> Also, the JMRP doesn't generate 1:1 reports for each piece of traffic
> reported as spam.
>
> The ratio is much smaller than that, otherwise senders would use it for
> List Washing, and that's frowned upon.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Got the Junk Mail Reporting Tool
> 
> ?
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *Brett
> Schenker
> *Sent:* Friday, October 27, 2017 8:02 AM
> *To:* Stefano Bagnara 
> *Cc:* mailop@mailop.org
> *Subject:* Re: [mailop] Hotmail, green SNDS and junk folder placement
>
>
>
> My experience too is that BCL is the deciding factor over everything and
> have yet to figure out how to really move it towards the positive.
>
>
>
> On Fri, Oct 27, 2017 at 10:51 AM, Stefano Bagnara  wrote:
>
> On 24 October 2017 at 17:22, Benjamin BILLON via mailop 
> wrote:
>
> Following Microsoft's folks recommendations (on this list and in ... a
> Canadian city a few weeks ago), we're going through tickets as usual, but
> we're for now circling around.
>
> I just wonder if other senders witnessed the same as described below:
>
>
>
> - SNDS says green
>
> - given the open rates 

Re: [mailop] About the Certified Senders Alliance

[Alexander Zeh]

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 :
> 
> 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 

Re: [mailop] About the Certified Senders Alliance

[Tobias Herkula]

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 
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 
> 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 > on 
behalf of David Hofstee 
>
Sent: Thursday, November 2, 2017 11:19
To: Alexander Zeh
Cc: 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 

Re: [mailop] mail.ru google and DMARC

[David Hofstee]

> And where the heck does mail.ru publish it's DMARC policy via DNS?

dig txt _dmarc.mail.ru



David

On 2 November 2017 at 13:28, Benoit Panizzon  wrote:

> Dear List
>
> I have come across a strange problem.
>
> One of our customers is forwarding his emails to his google account.
>
> We do implement SRS to rewrite the envelope sender to match our SPF
> record.
> All other headers are preserved, in case they are DKIM Signed.
>
> Google rejects the emails with:
>
> : host
> gmail-smtp-in.l.google.com[2a00:1450:4013:c00::1b] said: 550-5.7.1
> Unauthenticated email from mail.ru is not accepted due to domain's
> 550-5.7.1 DMARC policy. Please contact the administrator of mail.ru
> domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1
> https://support.google.com/mail/answer/2451690 to learn about the
> 550 5.7.1 DMARC initiative. m43si134563edm.154 - gsmtp (in reply to end
> of DATA command)
>
> Ok I have not yet stumbled over a lot of email senders using DMARC. So
> I read on: https://en.wikipedia.org/wiki/DMARC
>
> Did I get that right? DMARC checks that the envelope-from and From:
> header are 'aligned'?
>
> Well how the hell should that work when an email is being forwarded?
>
> SPF requires that I rewrite the envelope sender, DKIM requires that I
> don't alter the signed From: Header, DMARC requires that I do alter the
> From: Header?
>
> And where the heck does mail.ru publish it's DMARC policy via DNS?
>
> mail.ru has address 217.69.139.201
> mail.ru has address 94.100.180.201
> mail.ru has address 217.69.139.200
> mail.ru has address 94.100.180.200
> mail.ru name server ns3.mail.ru.
> mail.ru name server ns1.mail.ru.
> mail.ru name server ns2.mail.ru.
> mail.ru has SOA record ns1.mail.ru. hostmaster.mail.ru. 3300745053 900
> 900 604800 60 mail.ru mail is handled by 10 mxs.mail.ru.
> mail.ru descriptive text "v=spf1 redirect=_spf.mail.ru"
> mail.ru has IPv6 address 2a00:1148:db00:0:b0b0::1
>
> _spf.mail.ru descriptive text "v=spf1 ip4:94.100.176.0/20
> ip4:217.69.128.0/20 i" "p4:128.140.168.0/21 ip4:188.93.58.0/24
> ip4:195.2" "11.128.0/22 ip4:188.93.59.0/24 ip4:128.140.170.0" "/24
> ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5." "61.237.0/26
> ip4:5.61.237.128/25 ip4:5.61.236.0/2" "4 ip4:5.61.239.143/32
> ip4:5.61.239.144/32 ~all"
>
> Well his somehow looks like a broken SPF record. Anyway ~all would
> specify softfail and not reject.
>
> Can anyone help putting the puzzle together?
>
> How would one correctly implement email forwarding which works with all
> kind of SPF, DKIM and DMARC Variants?
>
> And yes I know, email forwarding is considered bad(tm), but it is still
> widely used.
>
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>



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

Re: [mailop] About the Certified Senders Alliance

[David Hofstee]

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 
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  on behalf of David Hofstee <
> opentext.dhofs...@gmail.com>
> Sent: Thursday, November 2, 2017 11:19
> To: Alexander Zeh
> Cc: 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 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 >
> Reply-To: HSE24 TV Programm >
> 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 >
> Reply-To: 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 eco.de>
> x-rpcampaign: sp2375598
> Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop
> x-job: 2375598
> x-orgId: 15062
> List-Unsubscribe: ?subject=Unsubscribe>
>
>
> On 1 November 2017 at 17:33, Alexander Zeh > wrote:
> Hello everyone,
>
> a friend informed me about a topic going on about the Certified Senders
> Alliance 

[mailop] mail.ru google and DMARC

[Benoit Panizzon]

Dear List

I have come across a strange problem.

One of our customers is forwarding his emails to his google account.

We do implement SRS to rewrite the envelope sender to match our SPF
record.
All other headers are preserved, in case they are DKIM Signed.

Google rejects the emails with:

: host
gmail-smtp-in.l.google.com[2a00:1450:4013:c00::1b] said: 550-5.7.1
Unauthenticated email from mail.ru is not accepted due to domain's
550-5.7.1 DMARC policy. Please contact the administrator of mail.ru
domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1
https://support.google.com/mail/answer/2451690 to learn about the
550 5.7.1 DMARC initiative. m43si134563edm.154 - gsmtp (in reply to end
of DATA command)

Ok I have not yet stumbled over a lot of email senders using DMARC. So
I read on: https://en.wikipedia.org/wiki/DMARC

Did I get that right? DMARC checks that the envelope-from and From:
header are 'aligned'?

Well how the hell should that work when an email is being forwarded?

SPF requires that I rewrite the envelope sender, DKIM requires that I
don't alter the signed From: Header, DMARC requires that I do alter the
From: Header?

And where the heck does mail.ru publish it's DMARC policy via DNS?

mail.ru has address 217.69.139.201
mail.ru has address 94.100.180.201
mail.ru has address 217.69.139.200
mail.ru has address 94.100.180.200
mail.ru name server ns3.mail.ru.
mail.ru name server ns1.mail.ru.
mail.ru name server ns2.mail.ru.
mail.ru has SOA record ns1.mail.ru. hostmaster.mail.ru. 3300745053 900
900 604800 60 mail.ru mail is handled by 10 mxs.mail.ru.
mail.ru descriptive text "v=spf1 redirect=_spf.mail.ru"
mail.ru has IPv6 address 2a00:1148:db00:0:b0b0::1

_spf.mail.ru descriptive text "v=spf1 ip4:94.100.176.0/20
ip4:217.69.128.0/20 i" "p4:128.140.168.0/21 ip4:188.93.58.0/24
ip4:195.2" "11.128.0/22 ip4:188.93.59.0/24 ip4:128.140.170.0" "/24
ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5." "61.237.0/26
ip4:5.61.237.128/25 ip4:5.61.236.0/2" "4 ip4:5.61.239.143/32
ip4:5.61.239.144/32 ~all"

Well his somehow looks like a broken SPF record. Anyway ~all would
specify softfail and not reject.

Can anyone help putting the puzzle together?

How would one correctly implement email forwarding which works with all
kind of SPF, DKIM and DMARC Variants?

And yes I know, email forwarding is considered bad(tm), but it is still
widely used.

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

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

Re: [mailop] About the Certified Senders Alliance

[Tobias Herkula]

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  on behalf of David Hofstee 

Sent: Thursday, November 2, 2017 11:19
To: Alexander Zeh
Cc: 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
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 
>
Reply-To: HSE24 TV Programm >
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 >
Reply-To: 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
x-rpcampaign: sp2375598
Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop
x-job: 2375598
x-orgId: 15062
List-Unsubscribe: 
?subject=Unsubscribe>


On 1 November 2017 at 17:33, Alexander Zeh 
> 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 

Re: [mailop] About the Certified Senders Alliance

[Tobias Herkula]

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  on behalf of David Hofstee 

Sent: Thursday, November 2, 2017 11:19
To: Alexander Zeh
Cc: 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
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 
>
Reply-To: HSE24 TV Programm >
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 >
Reply-To: 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
x-rpcampaign: sp2375598
Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop
x-job: 2375598
x-orgId: 15062
List-Unsubscribe: 
?subject=Unsubscribe>


On 1 November 2017 at 17:33, Alexander Zeh 
> 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 

Re: [mailop] About the Certified Senders Alliance

[David Hofstee]

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
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 
Reply-To: HSE24 TV Programm 
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 
Reply-To: 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
x-rpcampaign: sp2375598
Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop
x-job: 2375598
x-orgId: 15062
List-Unsubscribe: 


On 1 November 2017 at 17:33, Alexander Zeh  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 <+49%20221%20700048171>
>
> fax: +49 (0) 221 - 70 00 48 - 111 <+49%20221%20700048111>
>
> mobile: +49 (0) 171 - 657 2628 <+49%20171%206572628>
>
> e-mail: alexander@eco.de
>
> web: 

Re: [mailop] Certified Senders Alliance

[Philip Paeps]

On 2017-11-01 08:28:39 (-0500), Alexander Burch wrote:
What is the general opinion of the Certified Senders Alliance? 


I receive quite a lot of spam with an `X-CSA-Complaints` header pointing
at ...

Does anyone find it impactful for delivery? They offered to let us join 
without any vetting, just sent us a bill for $___ without any 
questions. If there is no vetting process I have a hard time seeing how 
it would validate any sender as trustworthy.


I consider the presence of `X-CSA-Complaints` header to be a weak 
indicator of spam.


Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

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

Re: [mailop] Sort of old but Apple now accepts TLS1.2 on IMAP...

[Philip Paeps]

On 2017-11-01 18:49:42 (-0400), Eric Tykwinski wrote:
I just saw on Full Disclosure about Apple patching a bunch of services 
for disabling TLS1.0, so I figured I’d give Apple Mail a shot.
I can confirm that Apple Mail Version 11.1 (3445.4.7) does in fact use 
TLS1.2 now, but of course you’re always going to have older clients 
hitting your servers unless you are corporate and can control it.


I can’t remember who was asking, but at least we are getting there to 
disabling TLS1.0.


That's very good news.  Hopefully TLS1.0 will linger for a much shorter 
time than SSLv3 and RC4-MD5.  But as you say, users still need to update 
their clients!


Overall, it seems that people are getting a little bit better at keeping 
their software up to date but there are always "exceptions".


(I finally turned off support for RC4 earlier this year despite having 
one customer still running a bunch of Windows XP machines.  Sigh.)


Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information

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

Re: [mailop] Sort of old but Apple now accepts TLS1.2 on IMAP...

[Renaud Allard via mailop]

On 01/11/2017 23:49, Eric Tykwinski wrote:
I just saw on Full Disclosure about Apple patching a bunch of services 
for disabling TLS1.0, so I figured I’d give Apple Mail a shot.
I can confirm that Apple Mail Version 11.1 (3445.4.7) does in fact use 
TLS1.2 now, but of course you’re always going to have older clients 
hitting your servers unless you are corporate and can control it.


I can’t remember who was asking, but at least we are getting there to 
disabling TLS1.0.




The only client which had issues with TLS1.2 recently is outlook with 
windows 7. It works,but you need to tweak the registry a little bit. 
Everything else which has followed the free updates works just fine.




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

Re: [mailop] Certified Senders Alliance

[Kurt Jaeger]

Hi!

> What is the general opinion of the Certified Senders Alliance?

I had one case with them in 2009, which ended *very* unpleasent.

We had some spam case from one of their members, complaint by phone and
a few minutes later one of our internal addresses got subscribed via
some Tor relay to some spam lists.

They are a project of ECO, and we complained as member company of ECO.

Got nowhere.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !

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

Re: [mailop] Certified Senders Alliance

[Benoit Panizzon]

Hi

I made mixed experience with CSA.

Their 'complaints' team does react quickly on complaints and also
document the number of complaints they receive per CSA Member.

But by 'reacting' they just acknowledge the complaints and document the
complaint. Not much more happens to make the problem stop.

A big known spamer in germany managed to become CSA member a couple of
years ago.

Well the CSA complaints count for this member skyrocketed. But it took
more than two years for the CSA to finally get rid of that member. (Or
more precisely, tell to get the ESP that was more or less in possession
of the spamer, that they would loose their membership if they would
continue their business with this particular customer)

And as I now browse the 'members' list of CSA I can find at least one
company that keeps being involved in sending spam (from the same
customer mentioned above who then changed ESP) to email address that
were harvested or obtained in a similar manner, but for sure not by
double opt-in.

So from the view-point of an ISP mail platform spamfilter operator, I am
neutral. I don't score them negative nor positive at the moment.

Scoring them for spam could impact a lot of legitimate email from
serious members who paid to have their email less likely flagged as
spam.

Unfortunately the handfull of abusers who have become CSA members also
prevent me from scoring them as ham.

But I find it's a bit questionable if they ask for money from their
members with the promise that their emails will less likely be tagged
as spam. This is not the case, here in Switzerland at least as I
believe.

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

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