Re: [mailop] About the Certified Senders Alliance

[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 :
> 
> 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 report ## is being processed.  For details, 
> check ."
> 
> It would be more than a (potential) black hole.
> 
>> And even if they do, we already received complaints about the mails from out 
>> complaint team to the complainant.
> 
> I'm not following you completely.  -  Either you're stating that you (CSA / 
> ECO) already have the information that you 

Re: [mailop] mail.ru google and DMARC

[Vladimir Dubrovin via mailop]

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

Yes, ARC is useful for big guys like GMail, cause we can automate things
and anyway we get new entity to use in antispam and it's useful to
decrease the number of type I/II errors.
The problem here is failed expectations for community. Mailing list
administrator has DMARC issues and he believes ARC to fix the problem.
Currently, things are simple: if sender's domain has stong DMARC,
rewrite From address.
ARC only makes things more complex for mailing list administrator. He
can not know if receiving side
a) supports ARC
b) trusts his domain
and there is no way for recipient to indicate it.
So, any mailing list administrator is forced to maintain (another one)
whitelist of domains where ARC (or may be DKIM/SPF/IP whitelist or good
karma or absence of DMARC filtering on receiving side - cause he can not
know exactly) actually works for him, and he still needs to rewrite From
for all other recipients. The things are worsened by the fact this list
is not redistributable, because you can know (a), but you can not know
(b) and (b) can change in time or depend on message class, the only way
for mailing lists administrator is to compile this list by trial and
error. In the case of "quarantine" DMARC policy there is no way at all
except registering box in every domain.



03.11.2017 1:28, 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
> > 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
>  

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

[Emre Üst |euro . message|]

Hi Michael,

Yes we are still seeing same code .

2017-11-03 09:17:02 "451 4.7.500 Server busy. Please try again later
from []. (AS3110)" received from hotmail-com.olc.protection.outlook.com
(104.47.5.33) matching /451 4.7.500 Server busy/

We cant send even 1000 mails to Hotmail per day .

Thank you


On Fri, Nov 3, 2017 at 12:13 AM, Michael Wise 
wrote:

>
>
> This may be related to an incident a few days ago.
>
> Are you still seeing the 4xx retry results?
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise*
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* Emre Üst |euro.message| [mailto:emre@euromsg.com]
> *Sent:* Thursday, November 2, 2017 1:05 PM
> *To:* Michael Wise 
> *Cc:* mailop@mailop.org
>
> *Subject:* Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some
>
>
>
> 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.]
>