Re: [dmarc-ietf] Support for DMARC "p=reject"

[Rolf E. Sonneveld]

Hi, Doug,

On 05/22/2014 11:56 PM, Douglas Otis wrote:

[...]



This number of 30K has been first mentioned by Yahoo! and after that 
it has been mentioned a couple of times by various people, but I have 
yet to see any proof that this figure is correct. Apart from this, 
quoting your own mail, you mention "[...] tens of thousands of 
legitimate services that might be sending on behalf of their client 
[...]". Although I think TPA may have its use for specific 
author/sender combinations [1], it definitely is not the answer to 
the current problems, introduced by Yahoo! and AOL, when they 
activated 'p=reject'. It simply will not scale enough and it remains 
to be seen that the too-big-to-ignore ESPs will spend time and money 
on the use of TPA, as they have their own mailing-list-like fora, 
which provide them revenues. Not to mention the privacy aspects of TPA...


Dear Rolf,

I strongly disagree with the assumption TPA does not scale to levels 
needed by AOL or Yahoo. Not having TPA declare the exceptions needed, 
both receiving and then offering feedback will likely to involve 
greater levels of network resources.  TPA is structured to ensure it 
can be supported by a single DNS transaction.  This allows for 
effective caching so perhaps only one out of 10 queries sees an 
authoritative response.  Can that be said for any other email protocol?


I'm not talking about that type of scaling. What I mean is, that it will 
take a massive amount of work to gather the right information about who 
is subscribed where to what list, to update this information on a 
continuous basis and to get this (changing information) in DNS. But 
maybe I misunderstand what will be in the draft, I'd better wait for the 
draft.


/rolf

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Support for DMARC "p=reject"

[Douglas Otis]

On May 22, 2014, at 2:03 PM, Rolf E. Sonneveld  
wrote:

> Hi, Doug,
> 
> On 05/22/2014 10:21 PM, Douglas Otis wrote:
>> Dear Brandon, 
>> See comments inline:
>> 
>> On May 12, 2014, at 12:30 PM, Brandon Long  wrote:
>> 
>>> On Mon, May 12, 2014 at 12:16 PM, Douglas Otis  
>>> wrote:
>>> 
>>> On May 11, 2014, at 12:47 PM, Gabriel Iovino  
>>> wrote:
>>> 
>>> > Greetings,
>>> >
>>> > Last week I was having a conversation with a familiar person on this
>>> > mailing list and I was expressing my disappointment with the
>>> > negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was
>>> > encouraged to share these thoughts on this list.
>>> >
>>> > I believe email is already broken[3][4][5][6] and DMARC "p=reject"
>>> > moves us towards a position where email is "less" broken. Will there
>>> > be some bumps[7] along the road? Sure but a few bumps are no reason to
>>> > leave email in it's current state.
>>> >
>>> > I applaud Yahoo and AOL for taking the first few punches and I look
>>> > forward to the day when Google and Microsoft follow their lead.
>>> >
>>> > Thank you for all the hard work you have done to improve the state of
>>> > email!
>>> >
>>> > Gabriel Iovino
>>> 
>>> Dear Gabriel,
>>> 
>>> While email is generally abused, DMARC's intent was to better protect 
>>> transactional email which Yahoo may put in jeopardy.  There will be a 
>>> forthcoming draft to allow Author-Domains a means to request restrictive 
>>> policies against normal user email accounts without disrupting very 
>>> legitimate communications.  The draft places the burden of mitigating 
>>> disruption on those making the requests.  Otherwise, it won't be too much 
>>> longer before even DMARC is ignored when misapplied against user accounts.
>>> 
>>> Where can we learn more about this?
>> 
>> An update is pending recovery of xml.resource.org/public/rfc/bibxml/. You 
>> don't miss it until it is gone. :^(  I should have been more proactive about 
>> transferring reference content.
>> 
>>> Yahoo has suffered from a lack of security permitting millions of their 
>>> users accounts to be compromised.  A better approach would not use DMARC, 
>>> but would federate third-party services they can see their customers 
>>> employ.  The federation of email, much like that of XMPP, would be an 
>>> effective means to exclude bad actors without breaking mailing-list and 
>>> other third-party email services.  As it is now, it seems Yahoo only 
>>> protects their own mailing-list operations which really does not warrant a 
>>> basis for applauding such efforts.
>>> 
>>> I feel that there is a theory that has gone around as to why AOL and Yahoo! 
>>> have done this, but I don't know as there has been any proof of that or 
>>> acknowledgement.  For one, the level of hijacking we see, and the level of 
>>> spam I personally receive that has at least a From name of someone I know, 
>>> lead me to question that theory.
>> 
>> I have notified several friends that their accounts were compromised.  Most 
>> did not like having to change their password. 
>> 
>>> Also, unless you know otherwise, my understanding was that Yahoo Groups 
>>> didn't have any mitigation of DMARC policies until recently, and they 
>>> implemented the same (and only currently useful) mitigation of re-writing 
>>> the From header, and did so well after yahoo.com went to REJECT.
>> 
>> Rewriting the From header field in itself is disruptive.  This prevents 
>> review of prior conversations from an individual.  Often you might remember 
>> who said something without recalling some of the details.
>> 
>>> Also... federation across millions of servers?  That seems... unlikely.
>> 
>> Federation simply means sending servers authenticate their domain and allow 
>> receivers to decide whether they wish to disallow messaging from unknown 
>> domains.  That feature is sorely missing from SMTP.  In this case, it only 
>> comes into play for third-party servers used by users of the Author-Domain 
>> asserting a DMARC policy request.  The scale of this is likely to be in the 
>> area of about 30K.
> 
> This number of 30K has been first mentioned by Yahoo! and after that it has 
> been mentioned a couple of times by various people, but I have yet to see any 
> proof that this figure is correct. Apart from this, quoting your own mail, 
> you mention "[...] tens of thousands of legitimate services that might be 
> sending on behalf of their client [...]". Although I think TPA may have its 
> use for specific author/sender combinations [1], it definitely is not the 
> answer to the current problems, introduced by Yahoo! and AOL, when they 
> activated 'p=reject'. It simply will not scale enough and it remains to be 
> seen that the too-big-to-ignore ESPs will spend time and money on the use of 
> TPA, as they have their own mailing-list-like fora, which provide them 
> revenues. Not to mention the privacy aspects of TPA...

Dear Rolf,

I strongly disagree with the assumption TPA does

Re: [dmarc-ietf] Support for DMARC "p=reject"

[Douglas Otis]

On May 12, 2014, at 1:38 PM, S Moonesamy  wrote:

> Hi Doug,
> At 12:16 12-05-2014, Douglas Otis wrote:
>> be compromised.  A better approach would not use DMARC, but would federate 
>> third-party services they can see their customers employ.  The federation of 
>> email, much like that of XMPP, would be an effective means to exclude bad 
>> actors without breaking mailing-list and other third-party email services.  
>> As it is now, it seems Yahoo only protects their own
> 
> Is federation effective in excluding bad stuff?  Bad stuff also occurs in 
> closed systems (see 
> https://support.twitter.com/groups/56-policies-violations/topics/238-report-a-violation/articles/64986-reporting-spam-on-twitter
>  ).  XMPP has been mentioned previously.  There wasn't any information 
> provided to assess whether it does exclude bad stuff.

Dear SM,

The goal of federated services is to prevent inclusion of unknown servers.  It 
does not in itself exclude bad stuff.  When bad stuff is noted, federation 
enables blocking future exchanges. Direct tweets are possible, although 
messaging constrained to 140 characters is difficult to take seriously since it 
is nearly impossible to know whether a tweet is being auto-generated.  Much of 
it is.  The way this would relate to DMARC is in the handling of non-aligned 
messages. When sources are identified, and feedback is generated for all known 
exceptions, it should not be difficult to then invert "block" logic into 
"accept" logic. 

Imagine your domain supporting millions of users had their accounts exposed 
along with their address-books.  This can easily get ugly in respect to the 
harm this would allow.  Yahoo likely considered DMARC the closest approximation 
of server federation that could be enabled.  After all, there are no other 
email policy layers reliably acted upon.   What is missing is a minor amount of 
feedback needed to communicate what the Author-Domain knows to be legitimate 
sources.  Doing so should represent a negligible amount of effort. 

I supported a system that reported on _all_ identified bad IPv4 addresses.  To 
do this, it required careful exclusion of those randomly assigned addresses.  
We would then apply about 15 million updates every 5 minutes for the entire 
IPv4 address space orchestrated by two redundant servers.  This information 
then supported several very large ISPs.  The larger ISPs wanted to do zone 
transfers, but a DMARC exception rate for an Author Domain will be several 
orders of magnitude lower in scale. I'll admit this was all done using C code 
that avoided SQL or Hadoop.  Judy is your friend. :^).

Regards,
Douglas Otis

  


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Support for DMARC "p=reject"

[Rolf E. Sonneveld]

Hi, Doug,

On 05/22/2014 10:21 PM, Douglas Otis wrote:

Dear Brandon,
See comments inline:

On May 12, 2014, at 12:30 PM, Brandon Long > wrote:


On Mon, May 12, 2014 at 12:16 PM, Douglas Otis > wrote:



On May 11, 2014, at 12:47 PM, Gabriel Iovino
mailto:giov...@people.ops-trust.net>> wrote:

> Greetings,
>
> Last week I was having a conversation with a familiar person on
this
> mailing list and I was expressing my disappointment with the
> negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was
> encouraged to share these thoughts on this list.
>
> I believe email is already broken[3][4][5][6] and DMARC "p=reject"
> moves us towards a position where email is "less" broken. Will
there
> be some bumps[7] along the road? Sure but a few bumps are no
reason to
> leave email in it's current state.
>
> I applaud Yahoo and AOL for taking the first few punches and I look
> forward to the day when Google and Microsoft follow their lead.
>
> Thank you for all the hard work you have done to improve the
state of
> email!
>
> Gabriel Iovino

Dear Gabriel,

While email is generally abused, DMARC's intent was to better
protect transactional email which Yahoo may put in jeopardy.
 There will be a forthcoming draft to allow Author-Domains a
means to request restrictive policies against normal user email
accounts without disrupting very legitimate communications.  The
draft places the burden of mitigating disruption on those making
the requests.  Otherwise, it won't be too much longer before even
DMARC is ignored when misapplied against user accounts.


Where can we learn more about this?


An update is pending recovery of xml.resource.org/public/rfc/bibxml/ 
. You don't miss it until 
it is gone. :^(  I should have been more proactive about transferring 
reference content.



Yahoo has suffered from a lack of security permitting millions of
their users accounts to be compromised.  A better approach would
not use DMARC, but would federate third-party services they can
see their customers employ.  The federation of email, much like
that of XMPP, would be an effective means to exclude bad actors
without breaking mailing-list and other third-party email
services.  As it is now, it seems Yahoo only protects their own
mailing-list operations which really does not warrant a basis for
applauding such efforts.


I feel that there is a theory that has gone around as to why AOL and 
Yahoo! have done this, but I don't know as there has been any proof 
of that or acknowledgement.  For one, the level of hijacking we see, 
and the level of spam I personally receive that has at least a From 
name of someone I know, lead me to question that theory.


I have notified several friends that their accounts were compromised. 
 Most did not like having to change their password.


Also, unless you know otherwise, my understanding was that Yahoo 
Groups didn't have any mitigation of DMARC policies until recently, 
and they implemented the same (and only currently useful) mitigation 
of re-writing the From header, and did so well after yahoo.com 
 went to REJECT.


Rewriting the From header field in itself is disruptive.  This 
prevents review of prior conversations from an individual.  Often you 
might remember who said something without recalling some of the details.



Also... federation across millions of servers?  That seems... unlikely.


Federation simply means sending servers authenticate their domain and 
allow receivers to decide whether they wish to disallow messaging from 
unknown domains.  That feature is sorely missing from SMTP.  In this 
case, it only comes into play for third-party servers used by users of 
the Author-Domain asserting a DMARC policy request.  The scale of this 
is likely to be in the area of about 30K.


This number of 30K has been first mentioned by Yahoo! and after that it 
has been mentioned a couple of times by various people, but I have yet 
to see any proof that this figure is correct. Apart from this, quoting 
your own mail, you mention "[...] tens of thousands of legitimate 
services that might be sending on behalf of their client [...]". 
Although I think TPA may have its use for specific author/sender 
combinations [1], it definitely is not the answer to the current 
problems, introduced by Yahoo! and AOL, when they activated 'p=reject'. 
It simply will not scale enough and it remains to be seen that the 
too-big-to-ignore ESPs will spend time and money on the use of TPA, as 
they have their own mailing-list-like fora, which provide them revenues. 
Not to mention the privacy aspects of TPA...


/rolf

[1] My company DKIM-signs mail on behalf of some customers, a proper TPA 
standard that is implemented by ma

Re: [dmarc-ietf] Support for DMARC "p=reject"

[Douglas Otis]

Dear Brandon, 
See comments inline:

On May 12, 2014, at 12:30 PM, Brandon Long  wrote:

> On Mon, May 12, 2014 at 12:16 PM, Douglas Otis  wrote:
> 
> On May 11, 2014, at 12:47 PM, Gabriel Iovino  
> wrote:
> 
> > Greetings,
> >
> > Last week I was having a conversation with a familiar person on this
> > mailing list and I was expressing my disappointment with the
> > negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was
> > encouraged to share these thoughts on this list.
> >
> > I believe email is already broken[3][4][5][6] and DMARC "p=reject"
> > moves us towards a position where email is "less" broken. Will there
> > be some bumps[7] along the road? Sure but a few bumps are no reason to
> > leave email in it's current state.
> >
> > I applaud Yahoo and AOL for taking the first few punches and I look
> > forward to the day when Google and Microsoft follow their lead.
> >
> > Thank you for all the hard work you have done to improve the state of
> > email!
> >
> > Gabriel Iovino
> 
> Dear Gabriel,
> 
> While email is generally abused, DMARC's intent was to better protect 
> transactional email which Yahoo may put in jeopardy.  There will be a 
> forthcoming draft to allow Author-Domains a means to request restrictive 
> policies against normal user email accounts without disrupting very 
> legitimate communications.  The draft places the burden of mitigating 
> disruption on those making the requests.  Otherwise, it won't be too much 
> longer before even DMARC is ignored when misapplied against user accounts.
> 
> Where can we learn more about this?

An update is pending recovery of xml.resource.org/public/rfc/bibxml/. You don't 
miss it until it is gone. :^(  I should have been more proactive about 
transferring reference content.

> Yahoo has suffered from a lack of security permitting millions of their users 
> accounts to be compromised.  A better approach would not use DMARC, but would 
> federate third-party services they can see their customers employ.  The 
> federation of email, much like that of XMPP, would be an effective means to 
> exclude bad actors without breaking mailing-list and other third-party email 
> services.  As it is now, it seems Yahoo only protects their own mailing-list 
> operations which really does not warrant a basis for applauding such efforts.
> 
> I feel that there is a theory that has gone around as to why AOL and Yahoo! 
> have done this, but I don't know as there has been any proof of that or 
> acknowledgement.  For one, the level of hijacking we see, and the level of 
> spam I personally receive that has at least a From name of someone I know, 
> lead me to question that theory.

I have notified several friends that their accounts were compromised.  Most did 
not like having to change their password. 

> Also, unless you know otherwise, my understanding was that Yahoo Groups 
> didn't have any mitigation of DMARC policies until recently, and they 
> implemented the same (and only currently useful) mitigation of re-writing the 
> From header, and did so well after yahoo.com went to REJECT.

Rewriting the From header field in itself is disruptive.  This prevents review 
of prior conversations from an individual.  Often you might remember who said 
something without recalling some of the details.

> Also... federation across millions of servers?  That seems... unlikely.

Federation simply means sending servers authenticate their domain and allow 
receivers to decide whether they wish to disallow messaging from unknown 
domains.  That feature is sorely missing from SMTP.  In this case, it only 
comes into play for third-party servers used by users of the Author-Domain 
asserting a DMARC policy request.  The scale of this is likely to be in the 
area of about 30K.  The exception list is something the Author-Domain feedback 
processing should be able to handle with negligible effort.

DMARC Author-Domain responding to a single DNS transaction for non-aligned 
domains provides two important benefits.  TPA helps curb the growth of "abuse" 
feedback that cooperating receivers might wish to provide.  Secondly, TPA also 
prevents disrupting the tens of thousands of legitimate services that might be 
sending on behalf of their client and properly indicate their relationship in 
the Sender header field.  Of course, TPA is also able to check the List-ID to 
better ensure the origination of the message. In any case, only sources that 
authenticate will be granted exceptions.  This could be described as a type of 
federation.  Think of this as circling the wagons in response to overwhelming 
problems. 

Regards,
Douglas Otis___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc