Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-06-01 Thread Roland Turner via dmarc-discuss 

On 01/06/18 17:04, Alessandro Vesely via dmarc-discuss wrote:


I see.  As a small receiver, I didn't even think about comparing different
forwarders of the same senders.  In my case, such coincidences only cover a
handful of trusted mailing lists.  Your argument further confirms how ARC
better suits large receivers.


Not quite:

 * It confirms that mapping who to trust requires both access to and
   the ability to process a view of a large subset of the world's
   mail-servers. This is comparable to the work of cartographers in the
   physical world: you *could* drive from one end of a continent to the
   other without ever examining a map (or roadside signs prepared by
   people who had examined maps), but it would be very, very difficult.
 * It confirms that rational use of ARC by small receivers will require
   help from "cartographers", whereas big receivers are large enough to
   have their own. This sounds bad, but note that this is already true
   for SMTP anyway. Yes, you can deploy a mail-server at will, but
   securing it without the use of reputation data (typically a DNSBL)
   will be somewhere between very difficult and actually infeasible.
   Few people attempt this in practice. My guess is that if ARC turns
   out to be useful, then the reputation data required for small
   receivers to make good use of it will be readily available.



Thank you for a nice discussion


Likewise!

- Roland
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-06-01 Thread Alessandro Vesely via dmarc-discuss 
On Fri 01/Jun/2018 07:40:07 +0200 Roland Turner via dmarc-discuss wrote:
> On 31/05/18 23:13, Alessandro Vesely via dmarc-discuss wrote:
> 
>> My filtering ability is visible to the people I forward to.  Although targets
>> don't see what I spare them, they can imagine.  If you receive spam from me,
>> you lower my reputation.  Easy.
>>
>> OTOH, my good faith ARC signing has to be assumed.  To prove the opposite, 
>> you
>> start with a message I forward to you; say it ARC-claims I received it from 
>> X.
>> Afterwards, you need to contact X and have them deny they ever sent it.  A
>> rather impractical method, especially since you need an X such that you can
>> trust their word against mine.  How come?
>>
>> Orthogonality is broken by mandating filter-before-forward.  That way,
>> receivers of ARC-signed, obvious spam can infer that the corresponding ARC
>> signature is faked.  The better the filtering, the stronger the trust, and 
>> the
>> more evident will a possible ARC key compromise be.  So, if you pardon my
>> geometry-fictional wording, the "trust not to lie in ARC signing/sealing" 
>> gets
>> measured by assessing its projection onto the filtering axis.
> 
> OK, I see what you're getting at (and therefore why you mentioned spam traps).
> As a [large] receiver, I would not be tackling it in this way at all, mostly
> because I don't get to ask any of the Xs what the truth is, but also because
> spam filtering and ARC signing really are largely orthogonal capabilities[1]
> (and to the extent that they're not, there's too much noise to make good use 
> of
> the results). I would instead - to further extend the use of over-specified
> geometric analogies - be performing something akin to gravitational lensing:
> 
>   * For each of [tens of] thousands of domain names[2], I have from their 
> email
> received directly an assessment of their expertise at ensuring that their
> email can be authenticated, broken down by stream (IP address, subnet,
> service provider, etc.).
>   * For each forwarder, I can see how they're reporting authentication results
> for many of the same senders at the same IP addresses, assuming that SPF
> authentication results are included in ARC.
>   * From this I can determine whether the forwarder is ARC-signing correctly.
> Note that this is different to comparing the forwarder's probabilistic 
> spam
> filtering with my own; in the ARC-signing case there are correct actions
> and incorrect actions, and a large receiver has enough information to tell
> which a forwarder is doing.
> 
> 
> Note that none of these steps has any relationship with spam which - given 
> that
> spammers can (and do) cause their email to authenticate, and legitimate 
> senders
> can (and do) fail to do so - is as it should be.
> 
> - Roland
> 
> 1: Yes, it is likely that forwarders who are exceptionally good at spam
> filtering will tend to be really good at ARC signing, but most of the 
> important
> information is about forwarders who aren't exceptionally good at filtering, so
> this correlation appears largely unimportant.
> 2: or registrants, to the extent that this information becomes available again
> once ICANN stops arguing absurdities in front of European courts and focuses 
> on
> the actual problem

I see.  As a small receiver, I didn't even think about comparing different
forwarders of the same senders.  In my case, such coincidences only cover a
handful of trusted mailing lists.  Your argument further confirms how ARC
better suits large receivers.

Thank you for a nice discussion

Best
Ale
-- 






___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-31 Thread Roland Turner via dmarc-discuss 

On 31/05/18 23:13, Alessandro Vesely via dmarc-discuss wrote:


1: Granted, the list becomes a priority list for compromise attempts

no spam indicator implies that the upstream ARC chain is faked.>>> You've lost 
me:

difficulty of substantiating statements like "I trust these guys not
to lie in ARC signing/sealing".>

This is the bit where I'm not following you. Failing to provide neighbourly
attention to the stream of mail coming out of your mail-server and failure to
accurately ARC sign appear to be orthogonal concerns. (They might be loosely
correlated to your level of diligence certainly, but are not otherwise causally
related.)

They'd better be more than loosely correlated.  If you keep them orthogonal,
you cannot make consistent assessments:

My filtering ability is visible to the people I forward to.  Although targets
don't see what I spare them, they can imagine.  If you receive spam from me,
you lower my reputation.  Easy.

OTOH, my good faith ARC signing has to be assumed.  To prove the opposite, you
start with a message I forward to you; say it ARC-claims I received it from X.
Afterwards, you need to contact X and have them deny they ever sent it.  A
rather impractical method, especially since you need an X such that you can
trust their word against mine.  How come?

Orthogonality is broken by mandating filter-before-forward.  That way,
receivers of ARC-signed, obvious spam can infer that the corresponding ARC
signature is faked.  The better the filtering, the stronger the trust, and the
more evident will a possible ARC key compromise be.  So, if you pardon my
geometry-fictional wording, the "trust not to lie in ARC signing/sealing" gets
measured by assessing its projection onto the filtering axis.


OK, I see what you're getting at (and therefore why you mentioned spam 
traps). As a [large] receiver, I would not be tackling it in this way at 
all, mostly because I don't get to ask any of the Xs what the truth is, 
but also because spam filtering and ARC signing really are largely 
orthogonal capabilities[1] (and to the extent that they're not, there's 
too much noise to make good use of the results). I would instead - to 
further extend the use of over-specified geometric analogies - be 
performing something akin to gravitational lensing:


 * For each of [tens of] thousands of domain names[2], I have from
   their email received directly an assessment of their expertise at
   ensuring that their email can be authenticated, broken down by
   stream (IP address, subnet, service provider, etc.).
 * For each forwarder, I can see how they're reporting authentication
   results for many of the same senders at the same IP addresses,
   assuming that SPF authentication results are included in ARC.
 *  From this I can determine whether the forwarder is ARC-signing
   correctly. Note that this is different to comparing the forwarder's
   probabilistic spam filtering with my own; in the ARC-signing case
   there are correct actions and incorrect actions, and a large
   receiver has enough information to tell which a forwarder is doing.


Note that none of these steps has any relationship with spam which - 
given that spammers can (and do) cause their email to authenticate, and 
legitimate senders can (and do) fail to do so - is as it should be.


- Roland

1: Yes, it is likely that forwarders who are exceptionally good at spam 
filtering will tend to be really good at ARC signing, but most of the 
important information is about forwarders who aren't exceptionally good 
at filtering, so this correlation appears largely unimportant.
2: or registrants, to the extent that this information becomes available 
again once ICANN stops arguing absurdities in front of European courts 
and focuses on the actual problem
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-31 Thread Alessandro Vesely via dmarc-discuss 
On Thu 31/May/2018 02:27:35 +0200 Roland Turner via dmarc-discuss wrote:
> On 31/05/18 02:31, Alessandro Vesely via dmarc-discuss wrote:
> 
> I took it as self-evident that I was describing a transition from an
> embedded list to a reputation data feed.
Got it :-)

> 1: Granted, the list becomes a priority list for compromise attempts
 no spam indicator implies that the upstream ARC chain is faked.>>> You've 
 lost me:
>> difficulty of substantiating statements like "I trust these guys not
>> to lie in ARC signing/sealing".>
> This is the bit where I'm not following you. Failing to provide neighbourly
> attention to the stream of mail coming out of your mail-server and failure to
> accurately ARC sign appear to be orthogonal concerns. (They might be loosely
> correlated to your level of diligence certainly, but are not otherwise 
> causally
> related.)

They'd better be more than loosely correlated.  If you keep them orthogonal,
you cannot make consistent assessments:

My filtering ability is visible to the people I forward to.  Although targets
don't see what I spare them, they can imagine.  If you receive spam from me,
you lower my reputation.  Easy.

OTOH, my good faith ARC signing has to be assumed.  To prove the opposite, you
start with a message I forward to you; say it ARC-claims I received it from X.
Afterwards, you need to contact X and have them deny they ever sent it.  A
rather impractical method, especially since you need an X such that you can
trust their word against mine.  How come?

Orthogonality is broken by mandating filter-before-forward.  That way,
receivers of ARC-signed, obvious spam can infer that the corresponding ARC
signature is faked.  The better the filtering, the stronger the trust, and the
more evident will a possible ARC key compromise be.  So, if you pardon my
geometry-fictional wording, the "trust not to lie in ARC signing/sealing" gets
measured by assessing its projection onto the filtering axis.

Best
Ale
-- 





___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-30 Thread Roland Turner via dmarc-discuss 

On 31/05/18 02:31, Alessandro Vesely via dmarc-discuss wrote:


On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote:

On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:

[...] which includes pretty much all mail sites.  The latter is *not* a
slow-moving data set.  It grows steadily.

Steady growth *is* slow movement.

Uh?  I run a tiny mail site and get about 1.6 new domains per hour.  It is much
slower than light, but still too fast for an embedded list...  Any global
figure, anywhere?


Too fast for an embedded list certainly. As I said, "forwarding 
mail-servers more generally would then be an obvious refinement", but 
also "Even the complete set of honestly operated mail-servers in the 
world - whether forwarding or not - is changing at a rate that is still 
orders of magnitude lower than the rate of change of IP addresses used 
for abuse, consequently collecting, distributing, and using this data 
would be relatively straightforward." I took it as self-evident that I 
was describing a transition from an embedded list to a reputation data 
feed. You would presumably not attempt to list all of the IP addresses 
used for abuse in an embedded list?




1: Granted, the list becomes a priority list for compromise attempts, much as
happened with ESPs several years ago, but sudden spikes in volume can be
treated as suspicious anyway, so the benefit in compromising a small forwarder
is limited.

Spamtraps will also work well, as usual.  However, no spam indicator implies
that the upstream ARC chain is faked.  In theory, for example, ARC would allow
me to switch to forward-before-filter (maybe CPU happened to cost me more than
bandwidth, say.)  In that case, you would tend to classify me as a spammer and
possibly suspect that my keys were compromised.  How to maintain the list
remains unclear.

You've lost me:

   * If you're forwarding unfiltered email to receivers who are able to make
 good use of ARC information, and assuming that they still trust you, then
 there is no problem here: you just have lousy filters.
   * If you're forwarding to people for whom either of those things is false,
 then you're shooting yourself in the foot.

Don't be a bad neighbour: filter to the best of your ability, but don't sweat
the rest. Your neighbours are most unlikely to appreciate your dumping cost
onto them if you do otherwise.

100% agreed.  The example —admittedly somewhat stretched— was meant to
highlight the difficulty of substantiating statements like "I trust these guys
not to lie in ARC signing/sealing".


This is the bit where I'm not following you. Failing to provide 
neighbourly attention to the stream of mail coming out of your 
mail-server and failure to accurately ARC sign appear to be orthogonal 
concerns. (They might be loosely correlated to your level of diligence 
certainly, but are not otherwise causally related.)


- Roland
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-30 Thread Alessandro Vesely via dmarc-discuss 
On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote:
> On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:
>> [...] which includes pretty much all mail sites.  The latter is *not* a
>> slow-moving data set.  It grows steadily.
> 
> Steady growth *is* slow movement.

Uh?  I run a tiny mail site and get about 1.6 new domains per hour.  It is much
slower than light, but still too fast for an embedded list...  Any global
figure, anywhere?

>>> 1: Granted, the list becomes a priority list for compromise attempts, much 
>>> as
>>> happened with ESPs several years ago, but sudden spikes in volume can be
>>> treated as suspicious anyway, so the benefit in compromising a small 
>>> forwarder
>>> is limited.
>>
>> Spamtraps will also work well, as usual.  However, no spam indicator implies
>> that the upstream ARC chain is faked.  In theory, for example, ARC would 
>> allow
>> me to switch to forward-before-filter (maybe CPU happened to cost me more 
>> than
>> bandwidth, say.)  In that case, you would tend to classify me as a spammer 
>> and
>> possibly suspect that my keys were compromised.  How to maintain the list
>> remains unclear.
> 
> You've lost me:
> 
>   * If you're forwarding unfiltered email to receivers who are able to make
> good use of ARC information, and assuming that they still trust you, then
> there is no problem here: you just have lousy filters.
>   * If you're forwarding to people for whom either of those things is false,
> then you're shooting yourself in the foot.
> 
> Don't be a bad neighbour: filter to the best of your ability, but don't sweat
> the rest. Your neighbours are most unlikely to appreciate your dumping cost
> onto them if you do otherwise.

100% agreed.  The example —admittedly somewhat stretched— was meant to
highlight the difficulty of substantiating statements like "I trust these guys
not to lie in ARC signing/sealing".

Best
Ale
-- 




___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-30 Thread Roland Turner via dmarc-discuss 

On 30/05/18 06:09, Brandon Long via dmarc-discuss wrote:



On Tue, May 29, 2018 at 8:10 AM Alessandro Vesely via dmarc-discuss 
mailto:dmarc-discuss@dmarc.org>> wrote:



I know ARC proponents don't want author's domains to sign ARC-0,
but never
understood why.  Anyway, ordinary forwarders will need to ARC sign
forwarded
messages too, which includes pretty much all mail sites. The
latter is *not* a
slow-moving data set.  It grows steadily.


No, ordinary forwarders which break DKIM need to ARC sign.  If you're 
just an ordinary forwarder, why break DKIM?


Plenty of ordinary forwarders break DKIM:

 * Essentially all customer-controlled Exchange servers. (Office 365
   fixed this a while back for server-side rules, but this has not made
   its way into customer-controlled installations generally, or perhaps
   not even into the product.)
 * Plenty of ordinary forwarders add footers, strip attachments.
   Fortunately virus scanner spam has largely stopped.
 * Etc.

I have previously singled out MIMEsweeper for gratuitous re-encoding of 
body parts and am pleased to report that my doing so led to that problem 
being fixed. 1 down, 999 to go... Cases like this will appear as a small 
fraction of the email volume of large receivers, but require a 
disproportionately large number of fixes. It may not be 1,000, but I'm 
certain that it's hundreds.


- Roland
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-30 Thread Roland Turner via dmarc-discuss 

On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:


  * A single public whitelist is not necessary for ARC to work, multiple
    lists are certainly possible, but the mapping of well-behaved
    whitelist operators is:
  o much easier than mapping abusers, as the latter are seeking to
    _*evade*_ detection;
  o much slower moving (new small list operators appear at a rate of
    perhaps one per week; abusers gain control of IP addresses at a
    rate of many per second); and
  o more resilient in that possession of the abuse data by abusers
    doesn't provide a means to optimise abuse by focusing on IP
    addresses and identifiers that haven't yet been identified[1],

        meaning that a slow-moving list can be included in email
    security software, as with the current rule set for something
    like SpamAssassin.

You seem to imply that only mailing list activity needs to deploy ARC.


I hadn't meant to imply quite that, however the paragraph was already 
getting a little long so I did not elaborate further. The list operators 
would be a starting point for ARC reputation data, certainly; forwarding 
mail-servers more generally would then be an obvious refinement. Even 
the complete set of honestly operated mail-servers in the world - 
whether forwarding or not - is changing at a rate that is still orders 
of magnitude lower than the rate of change of IP addresses used for 
abuse, consequently collecting, distributing, and using this data would 
be relatively straightforward.



I know ARC proponents don't want author's domains to sign ARC-0, but never
understood why.  Anyway, ordinary forwarders will need to ARC sign forwarded
messages too, which includes pretty much all mail sites.  The latter is *not* a
slow-moving data set.  It grows steadily.


Steady growth *is* slow movement.


1: Granted, the list becomes a priority list for compromise attempts, much as
happened with ESPs several years ago, but sudden spikes in volume can be
treated as suspicious anyway, so the benefit in compromising a small forwarder
is limited.


Spamtraps will also work well, as usual.  However, no spam indicator implies
that the upstream ARC chain is faked.  In theory, for example, ARC would allow
me to switch to forward-before-filter (maybe CPU happened to cost me more than
bandwidth, say.)  In that case, you would tend to classify me as a spammer and
possibly suspect that my keys were compromised.  How to maintain the list
remains unclear.


You've lost me:

 * If you're forwarding unfiltered email to receivers who are able to
   make good use of ARC information, and assuming that they still trust
   you, then there is no problem here: you just have lousy filters.
 * If you're forwarding to people for whom either of those things is
   false, then you're shooting yourself in the foot.

Don't be a bad neighbour: filter to the best of your ability, but don't 
sweat the rest. Your neighbours are most unlikely to appreciate your 
dumping cost onto them if you do otherwise.


- Roland








Best
Ale



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-29 Thread John Levine via dmarc-discuss 
In article  
you write:
>No, ordinary forwarders which break DKIM need to ARC sign.  If you're just
>an ordinary forwarder, why break DKIM?

Unfortunately, some people still authenticate with SPF, so an unmodified forward
can break DMARC.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-29 Thread Brandon Long via dmarc-discuss 
On Tue, May 29, 2018 at 8:10 AM Alessandro Vesely via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> On Tue 29/May/2018 01:27:33 +0200 Roland Turner via dmarc-discuss wrote:
> > On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote:
> >
> > For the implied question ("Why would small guys be interested?"):
> >
> >  * ARC headers simply provide a view as to what happened upstream.
> >Whatever effort you're willing to invest in hand-to-hand fighting is
> >amplified (greater efficiency and/or effectiveness) simply by making
> >use of that visibility.
> >  * A single public whitelist is not necessary for ARC to work, multiple
> >lists are certainly possible, but the mapping of well-behaved
> >whitelist operators is:
> >  o much easier than mapping abusers, as the latter are seeking to
> >_*evade*_ detection;
> >  o much slower moving (new small list operators appear at a rate of
> >perhaps one per week; abusers gain control of IP addresses at a
> >rate of many per second); and
> >  o more resilient in that possession of the abuse data by abusers
> >doesn't provide a means to optimise abuse by focusing on IP
> >addresses and identifiers that haven't yet been identified[1],
> >
> >meaning that a slow-moving list can be included in email
> >security software, as with the current rule set for something
> >like SpamAssassin.
>
> You seem to imply that only mailing list activity needs to deploy ARC.
>
> I know ARC proponents don't want author's domains to sign ARC-0, but never
> understood why.  Anyway, ordinary forwarders will need to ARC sign
> forwarded
> messages too, which includes pretty much all mail sites.  The latter is
> *not* a
> slow-moving data set.  It grows steadily.
>

No, ordinary forwarders which break DKIM need to ARC sign.  If you're just
an ordinary forwarder, why break DKIM?

As for ARC-0, there's no need for the actual From domain to sign as ARC,
that's what DKIM/SPF are for.  If you're talking about
a third party author, that's a very different trust statement.

Ie, for regular ARC forwarding, the trust is that they implement ARC
correctly and are not faking the ARC results.
For ARC-0, the trust is that the "author" domain has permission to send on
behalf of another domain.  What that permission
looks like can vary greatly, from say the simplest level of "email address
confirmation" to some level of live user query.

Ie, the simple confirmation won't typically do a good job of preventing an
ex-employee who already registered with a third party service from sending
mail as that service, unless you required every sent message to first have
a confirmation via email to the sender.  Is that really a useful level of
service to justify ARC-0?

I'm sure there are vendors who would benefit from that, typically those
sending larger volumes of messages for users from domains that don't
support that, ie your small business using an @gmail.com address and using
say Constant Contact.  But is Gmail really going to trust a third party to
send mail on it's behalf (pretty sure the answer would be no).

Another use case would be "having my hosted domains set up SPF/DKIM is too
hard, I'll just sign for them".  I can see some utility in that, but it has
the same "how do I know that?"  Ie, we probably have some documentation on
how we manage domain ownership for GSuite domains and enforce that
ownership, and even if we do an excellent job with that, there's almost
certainly some grace period involved in verification failures, during which
the ex-domain owner would still be able to send mail as the domain.  We've
even debating doing something like that for Gmail to Gmail mail when we had
some big issues with a prominent DNS provider having outages.  I still have
a hard time believing the rest of the world wants to just say "trust
anything Gmail sends as authed".

Really, the solution for ARC-0 is probably MSA with OAUTHBEARER, which
allows for an individual to auth a specific sender for their own address,
and enforces all of the regular controls for the account, and allows the
individual to list and manage those auths.  It won't help the cases where
they want to use their address for higher volume, though.

Brandon
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-29 Thread Alessandro Vesely via dmarc-discuss 
On Tue 29/May/2018 01:27:33 +0200 Roland Turner via dmarc-discuss wrote:
> On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote:
> 
> For the implied question ("Why would small guys be interested?"):
> 
>  * ARC headers simply provide a view as to what happened upstream.
>    Whatever effort you're willing to invest in hand-to-hand fighting is
>    amplified (greater efficiency and/or effectiveness) simply by making
>    use of that visibility.
>  * A single public whitelist is not necessary for ARC to work, multiple
>    lists are certainly possible, but the mapping of well-behaved
>    whitelist operators is:
>  o much easier than mapping abusers, as the latter are seeking to
>    _*evade*_ detection;
>  o much slower moving (new small list operators appear at a rate of
>    perhaps one per week; abusers gain control of IP addresses at a
>    rate of many per second); and
>  o more resilient in that possession of the abuse data by abusers
>    doesn't provide a means to optimise abuse by focusing on IP
>    addresses and identifiers that haven't yet been identified[1],
> 
>        meaning that a slow-moving list can be included in email
>    security software, as with the current rule set for something
>    like SpamAssassin.

You seem to imply that only mailing list activity needs to deploy ARC.

I know ARC proponents don't want author's domains to sign ARC-0, but never
understood why.  Anyway, ordinary forwarders will need to ARC sign forwarded
messages too, which includes pretty much all mail sites.  The latter is *not* a
slow-moving data set.  It grows steadily.


> 1: Granted, the list becomes a priority list for compromise attempts, much as
> happened with ESPs several years ago, but sudden spikes in volume can be
> treated as suspicious anyway, so the benefit in compromising a small forwarder
> is limited.


Spamtraps will also work well, as usual.  However, no spam indicator implies
that the upstream ARC chain is faked.  In theory, for example, ARC would allow
me to switch to forward-before-filter (maybe CPU happened to cost me more than
bandwidth, say.)  In that case, you would tend to classify me as a spammer and
possibly suspect that my keys were compromised.  How to maintain the list
remains unclear.


Best
Ale
-- 



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-28 Thread Roland Turner via dmarc-discuss 

On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote:


Your points define ARC's scope very well.  But what's big guys' role?

Let me call /semantic mailbox providers/ those company or personal mail sites
whose users have some kind of trust relationship with, e.g. because they work
for the company, are postmaster's friends, or whatever.  These providers can
afford to let their users transparently perceive forwarders' filtering ability,
be it naive SA deployment or sophisticated AI categorization.  They may
consider that users subscribing to mailing lists know what they do and let them
enjoy or suffer its output as-is.  "I trust these guys not to lie in From:
rewriting" could be enough for them to whitelist DMARC breakage while keeping
its anti-phishing feature, and dnswl.org would probably suffice to implement
that, if agreeing on any single public whitelist were an acceptable means to
make a protocol work.

By contrast, big guys have so many users because they offer astounding
functionalities, among which filtering is one of the most relevant.  They need
to filter forwarded messages in a manner 100% consistent with messages coming
in directly.  As you say, ARC will permit that by removing dependencies upon
upstream filtering.  I doubt anybody but big guys really needs that, but will
be glad to be confuted.


Your question was "what's big guys' role", but your argument appears to 
be the reverse:


 * That small guys can function without ARC on a hand-to-hand fighting
   basis, perhaps with the aid of third-party reputation data.
 * That big guys have a clear interest in ARC so they can project their
   filtering expertise upstream.

I'd suggest that you've therefore answered your stated question in your 
second paragraph.


For the implied question ("Why would small guys be interested?"):

 * ARC headers simply provide a view as to what happened upstream.
   Whatever effort you're willing to invest in hand-to-hand fighting is
   amplified (greater efficiency and/or effectiveness) simply by making
   use of that visibility.
 * A single public whitelist is not necessary for ARC to work, multiple
   lists are certainly possible, but the mapping of well-behaved
   whitelist operators is:
 o much easier than mapping abusers, as the latter are seeking to
   _*evade*_ detection;
 o much slower moving (new small list operators appear at a rate of
   perhaps one per week; abusers gain control of IP addresses at a
   rate of many per second); and
 o more resilient in that possession of the abuse data by abusers
   doesn't provide a means to optimise abuse by focusing on IP
   addresses and identifiers that haven't yet been identified[1],

   meaning that a slow-moving list can be included in email
   security software, as with the current rule set for something like
   SpamAssassin.

- Roland

1: Granted, the list becomes a priority list for compromise attempts, 
much as happened with ESPs several years ago, but sudden spikes in 
volume can be treated as suspicious anyway, so the benefit in 
compromising a small forwarder is limited.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-28 Thread Alessandro Vesely via dmarc-discuss 
On Sat 26/May/2018 06:55:55 +0200 Roland Turner via dmarc-discuss wrote:
> On 25/05/18 19:00, Alessandro Vesely via dmarc-discuss wrote:
> 
>> Wasn't this tried for SPF already?
> 
> A whitelist of "I trust these guys to make exactly the same abuse-filtering
> decisions that I'd make" and a whitelist of "I trust these guys not to lie in
> ARC signing/sealing" are two very different things:
> 
>  * The former is somewhat imaginary and generally devolves to "I trust
>    these guys to filter abuse at or better than my ability to do so",
>    which essentially means a handful of big guys.
>  * The latter could readily include every existing mailing list
>    operator, and add new ones with minimal fuss.


Your points define ARC's scope very well.  But what's big guys' role?

Let me call /semantic mailbox providers/ those company or personal mail sites
whose users have some kind of trust relationship with, e.g. because they work
for the company, are postmaster's friends, or whatever.  These providers can
afford to let their users transparently perceive forwarders' filtering ability,
be it naive SA deployment or sophisticated AI categorization.  They may
consider that users subscribing to mailing lists know what they do and let them
enjoy or suffer its output as-is.  "I trust these guys not to lie in From:
rewriting" could be enough for them to whitelist DMARC breakage while keeping
its anti-phishing feature, and dnswl.org would probably suffice to implement
that, if agreeing on any single public whitelist were an acceptable means to
make a protocol work.

By contrast, big guys have so many users because they offer astounding
functionalities, among which filtering is one of the most relevant.  They need
to filter forwarded messages in a manner 100% consistent with messages coming
in directly.  As you say, ARC will permit that by removing dependencies upon
upstream filtering.  I doubt anybody but big guys really needs that, but will
be glad to be confuted.

Best
Ale
-- 


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-25 Thread Roland Turner via dmarc-discuss 

On 25/05/18 19:00, Alessandro Vesely via dmarc-discuss wrote:


Wasn't this tried for SPF already?


A whitelist of "I trust these guys to make exactly the same 
abuse-filtering decisions that I'd make" and a whitelist of "I trust 
these guys not to lie in ARC signing/sealing" are two very different things:


 * The former is somewhat imaginary and generally devolves to "I trust
   these guys to filter abuse at or better than my ability to do so",
   which essentially means a handful of big guys.
 * The latter could readily include every existing mailing list
   operator, and add new ones with minimal fuss.

Your question is a bit like asking whether DMARC p=reject hadn't been 
tried for ADSP already. In both cases yes, but with the addition of a 
small but vital component (feedback in DMARC's case, no dependence upon 
upstream filtering in ARC's case) that has the potential to immensely 
alter the outcome.



Assuming, for the sake of argument, that such a whitelist will be ready right
after ARC's availability, by that time most mailing lists will have adjusted
their From: rewriting so as to work smoothly with DMARC.  Hence, by the "If it
ain't broke, don't fix it" principle, I see no likely looking mass adoption of
ARC+whitelist.  What am I missing?


From the viewpoint of a lot of people[1], list handling very broken at 
present. Also, the thousands of small forwarding cases which break DKIM 
aren't ever likely to be fixed because in each case doing so would break 
someone's expectation. ARC creates no dilemmas (contrast asserting or 
honouring -all, o=-, discardable, or even p=reject), but allows the vast 
majority of the small forwarding cases to be fixed, and mailing list 
behaviour to be restored to its traditional form.


I do take your point that there's a fait accomplis risk, but I suspect 
that there's enough residual pain on both fronts (indignation at 
currently necessary list behaviour, smaller forwarding cases that just 
break) that ARC's deployment will proceed. Whether we'll get to the 
point where all MTA vendors recommend that ARC-signing be turned on 
unconditionally (and the associated DNS gymnastics performed) is an open 
question.


- Roland

1: I don't share this viewpoint, but accept it as a legitimate concern.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-25 Thread John R Levine via dmarc-discuss 

On Fri, 25 May 2018, Rolf E. Sonneveld wrote:
I may live in another world or the mailing lists to which I subscribe may be 
different from the ones you subscribe to, but it is my experience that most 
mailing lists didn't implement the From rewriting kludge, but instead 
implemented the 'reject from domains that publish p=reject'.


You definitely live in another world.  Even RIPE and the IETF do rewrites 
now.



Rewriting the From address can be seen as 'breaking the system'.


No kidding.  That's why we hope ARC will work well enough that we don't 
have to.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-25 Thread Rolf E. Sonneveld via dmarc-discuss 

On 25-05-18 13:00, Alessandro Vesely via dmarc-discuss wrote:

On Thu 24/May/2018 20:58:30 +0200 John Levine via dmarc-discuss wrote:


In article <445884976.7940.1527153118...@appsuite.open-xchange.com> you write:

This is actually an area of concern to us: how will small scale operations, 
like a server that only hosts a handful
of mailing lists for local non profits / open source projects / amateur groups 
etc, be able to be recognized as
trusted ARC intermediaries? The big players have reputation systems that could 
be used for this as well, but what
about everyone else?

People at big providers tell me that they're likely to seed a public
whitelist of ARC forwarders.

Wasn't this tried for SPF already?

Assuming, for the sake of argument, that such a whitelist will be ready right
after ARC's availability, by that time most mailing lists will have adjusted
their From: rewriting so as to work smoothly with DMARC.


I may live in another world or the mailing lists to which I subscribe 
may be different from the ones you subscribe to, but it is my experience 
that most mailing lists didn't implement the From rewriting kludge, but 
instead implemented the 'reject from domains that publish p=reject'. For 
the mailing lists I manage I have set the sender addresses like 
@yahoo.com etc. to 'nomail' and told the subscribers to switch ESP.



Hence, by the "If it
ain't broke, don't fix it" principle, I see no likely looking mass adoption of
ARC+whitelist.  What am I missing?


Rewriting the From address can be seen as 'breaking the system'. For 
example: in my Inbox overview I see your message coming from 
'dmarc-discuss@dmarc.org' so I can't make an informed decision about 
what prio to give your message in relation to all the other messages in 
my Inbox waiting to be opened. So, paraphrasing on what you write I 
would suggest: 'if it's broken, fix it!'. ARC+whitelist may prevent mail 
admins from using kludges like the rewriting of From addresses.


/rolf

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-25 Thread Alessandro Vesely via dmarc-discuss 
On Thu 24/May/2018 20:58:30 +0200 John Levine via dmarc-discuss wrote:

> In article <445884976.7940.1527153118...@appsuite.open-xchange.com> you write:
>>This is actually an area of concern to us: how will small scale operations, 
>>like a server that only hosts a handful
>>of mailing lists for local non profits / open source projects / amateur 
>>groups etc, be able to be recognized as
>>trusted ARC intermediaries? The big players have reputation systems that 
>>could be used for this as well, but what
>>about everyone else?
> 
> People at big providers tell me that they're likely to seed a public
> whitelist of ARC forwarders.

Wasn't this tried for SPF already?

Assuming, for the sake of argument, that such a whitelist will be ready right
after ARC's availability, by that time most mailing lists will have adjusted
their From: rewriting so as to work smoothly with DMARC.  Hence, by the "If it
ain't broke, don't fix it" principle, I see no likely looking mass adoption of
ARC+whitelist.  What am I missing?

Best
Ale
-- 



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-24 Thread John Levine via dmarc-discuss 
In article <445884976.7940.1527153118...@appsuite.open-xchange.com> you write:
>This is actually an area of concern to us: how will small scale operations, 
>like a server that only hosts a handful
>of mailing lists for local non profits / open source projects / amateur groups 
>etc, be able to be recognized as
>trusted ARC intermediaries? The big players have reputation systems that could 
>be used for this as well, but what
>about everyone else?

People at big providers tell me that they're likely to seed a public
whitelist of ARC forwarders.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-24 Thread Brock, Anthony D. via dmarc-discuss 
*You* are the answer…



Tony Brock
Senior IT Systems and Security Engineer

[Parker Poe]

Three Wells Fargo Center | 401 South Tryon Street | Suite 3000 | Charlotte, NC 
28202
Office: 704.335.9535 | Fax: 704.335.9780 | 
map<https://www.google.com/maps?q=401+South+Tryon+Street,Charlotte,NC,28202,United+States>

Visit our website at
www.parkerpoe.com<http://www.parkerpoe.com>

From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of Al 
Iverson via dmarc-discuss
Sent: Thursday, May 24, 2018 9:33 AM
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] General DMARC weakness - personal forwarding

***Caution: External email***

On Thu, May 24, 2018 at 5:11 AM, Vittorio Bertola via dmarc-discuss
mailto:dmarc-discuss@dmarc.org>> wrote:
>> Il 23 maggio 2018 alle 9.43 Alessandro Vesely via dmarc-discuss 
>> mailto:dmarc-discuss@dmarc.org>> ha scritto:
>>
>> ARC will allow message modifications. However, it will require that 
>> Google/Apple/etc recognize SomeCo as a trusted forwarder, in order to 
>> believe reported authentication results.
>
> This is actually an area of concern to us: how will small scale operations, 
> like a server that only hosts a handful of mailing lists for local non 
> profits / open source projects / amateur groups etc, be able to be recognized 
> as trusted ARC intermediaries? The big players have reputation systems that 
> could be used for this as well, but what about everyone else? The risk is to 
> prompt more centralization in email services, which is not how the Internet 
> should work - or to prompt people to use instant messaging groups instead.

Those entities can handle it the same way they do today - rewriting
headers to become the sender, so any authentication falls to them.
This is basically already settled, if you want to run a mailing list
today and you want to maximize delivery of the mail, you have to do
this. Like this very list does.

Maybe the small guys will have to keep using this method?

I am curious to know the answer to your question. But also, I run a
small number of mailing lists myself, just fine, without ARC. So I am
not worried about having to directly support ARC. Maybe my opinion on
that will change? But for now, that is what it is.

Regards,
Al Iverson

--
al iverson // wombatmail // miami
http://www.aliverson.com<http://www.aliverson.com>
http://www.spamresource.com<http://www.spamresource.com>

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>
http://www.dmarc.org/mailman/listinfo/dmarc-discuss<http://www.dmarc.org/mailman/listinfo/dmarc-discuss>

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html<http://www.dmarc.org/note_well.html>)

PRIVILEGED AND CONFIDENTIAL: This electronic message and any attachments are 
confidential property of the sender. The information is intended only for the 
use of the person to whom it was addressed. Any other interception, copying, 
accessing, or disclosure of this message is prohibited. The sender takes no 
responsibility for any unauthorized reliance on this message. If you have 
received this message in error, please immediately notify the sender and purge 
the message you received. Do not forward this message without permission. 
[ppab_p&c]
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-24 Thread Al Iverson via dmarc-discuss 
On Thu, May 24, 2018 at 5:11 AM, Vittorio Bertola via dmarc-discuss
 wrote:
>> Il 23 maggio 2018 alle 9.43 Alessandro Vesely via dmarc-discuss 
>>  ha scritto:
>>
>> ARC will allow message modifications.  However, it will require that 
>> Google/Apple/etc recognize SomeCo as a trusted forwarder, in order to 
>> believe reported authentication results.
>
> This is actually an area of concern to us: how will small scale operations, 
> like a server that only hosts a handful of mailing lists for local non 
> profits / open source projects / amateur groups etc, be able to be recognized 
> as trusted ARC intermediaries? The big players have reputation systems that 
> could be used for this as well, but what about everyone else? The risk is to 
> prompt more centralization in email services, which is not how the Internet 
> should work - or to prompt people to use instant messaging groups instead.

Those entities can handle it the same way they do today - rewriting
headers to become the sender, so any authentication falls to them.
This is basically already settled, if you want to run a mailing list
today and you want to maximize delivery of the mail, you have to do
this. Like this very list does.

Maybe the small guys will have to keep using this method?

I am curious to know the answer to your question. But also, I run a
small number of mailing lists myself, just fine, without ARC. So I am
not worried about having to directly support ARC. Maybe my opinion on
that will change? But for now, that is what it is.

Regards,
Al Iverson

-- 
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-24 Thread Vittorio Bertola via dmarc-discuss 
> Il 23 maggio 2018 alle 9.43 Alessandro Vesely via dmarc-discuss 
>  ha scritto:
>
> ARC will allow message modifications.  However, it will require that 
> Google/Apple/etc recognize SomeCo as a trusted forwarder, in order to believe 
> reported authentication results.

This is actually an area of concern to us: how will small scale operations, 
like a server that only hosts a handful of mailing lists for local non profits 
/ open source projects / amateur groups etc, be able to be recognized as 
trusted ARC intermediaries? The big players have reputation systems that could 
be used for this as well, but what about everyone else? The risk is to prompt 
more centralization in email services, which is not how the Internet should 
work - or to prompt people to use instant messaging groups instead.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-23 Thread Dave Crocker via dmarc-discuss 

(adding to the comments already posted...)

On 5/21/2018 8:29 AM, Pete Holzmann via dmarc-discuss wrote:
* From 'R's perspective, they simply want those emails to show up in 
their "other inbox"


Most of the anti-spam technical work has focused on transport-related 
mechanisms, without much attention to end-user effects, other than 
reducing abuse.  So, for example, possible changes in the user 
experience of standard email semantics, such as making threading or 
sorting problematic, hasn't been part of the discussion.  The main 
argument for this is the very real fact that abuse has been crippling 
the system.




In a perfect world all software will perfectly implement DMARC. In the 
meantime, users get frustrated and email gets blocked.


Indeed.  The original work on DMARC was for limited use, by large/bulk 
senders directly to recipients.  The problems caused by re-posting the 
message, such as through a mailing list, were well-understood at the 
time.  What happened, eventually, was that DMARC use was expanded to 
cover p2p mail, for which is creates more extensive problems.  The 
expanded use was, again, in response to a service survivability threat.





*QUESTIONS:*
1) Is anyone working to solve these issues?


As noted, there is hope that ARC will help.  I view ARC as a worthy 
experiment,.  It's like but I expect its large-scale operation to be at 
least challenging.  I suspect it will have complexities and fragilities 
that are significant.



2) Has there been consideration of a forwarding token that could 
validate all such emails?


There have been many alternatives considered.  For starters, basic ideas 
always sound appealing but wind up suffering a death blow as soon as the 
idea is considered in detail, in terms of operational usability.  That's 
not meant to discourage considering new ideas, but rather caution 
against thinking anything useful will be easy.





*SUGGESTION: *
a) Since user+al...@dom.ain is a valid alias for u...@dom.ain ...


To emphasize the comments already made on this:  It is an alias only if 
the hosting domain interprets it that way.  There are no Internet 
standards for this, which has generally been beneficial, albeit also 
having some limitations.  (FWIW, some years ago, there was a discussion 
about possibly standardizing some aspects of left-hand-side (mailbox) 
interpretation, but it stalled.)



b) Why not create a standard for personal forwarding authentication 
tokens? I.e.


I don't know what means exactly.  (cf, above.)  Feel free to post a note 
with the idea more fleshed out, in design and operations terms; that is, 
how would it work, exactly; consider which actors are involved, what 
they have to do, and what will convince them to do it.  On the average, 
schemes are far more challenging to get adopted, by critical actors and 
to make operational for the long term at at scale, than people realize.


There have been some previous proposals that might be similar to what 
you have in mind, but I can't tell.




d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-23 Thread John Levine via dmarc-discuss 
In article  you write:
>Until then, a simple forwarding —refraining to append any disclaimer or virus
>scanning notice to the body of the message— would not break DKIM signatures and
>hence leave DMARC authenticity intact.  That is exactly the problem that DKIM
>was designed to solve, to overcome the fact that SPF breaks forwarding.

Well, unless the original sender only authenticated with SPF.

It's a mess.

> Finally, user+al...@dom.ain is not standard.

It's a perfectly standard RFC 5321/5322 address.  The way it's
interpreted by the recipient MTA is up to that MTA, but the
way that *any* address is interpreted is up to the recipient MTA.

R's,
John
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-23 Thread Alessandro Vesely via dmarc-discuss 
On Mon 21/May/2018 18:24:13 +0200 Ken O'Driscoll via dmarc-discuss wrote:
> On Mon, 2018-05-21 at 09:29 -0600, Pete Holzmann via dmarc-discuss wrote:
>> QUESTIONS:
>> 1) Is anyone working to solve these issues?
>> 2) Has there been consideration of a forwarding token that could validate
>> all such emails
> 
> Take a look at the work being done on Authenticated Received Chain (ARC) - 
> http://arc-spec.org/
> 
> ARC breaks DMARC in those use cases where authenticated email is then
> forwarded on to another mailbox provider in a way which invalidates DMARC.
> Basically, it achieves this by including the previous DMARC authentication
> results in the message so that the receiver can then make more a informed
> filtering decision which is not solely based on the original domain's DMARC
> policy.

Until then, a simple forwarding —refraining to append any disclaimer or virus
scanning notice to the body of the message— would not break DKIM signatures and
hence leave DMARC authenticity intact.  That is exactly the problem that DKIM
was designed to solve, to overcome the fact that SPF breaks forwarding.

ARC will allow message modifications.  However, it will require that
Google/Apple/etc recognize SomeCo as a trusted forwarder, in order to believe
reported authentication results.

Finally, user+al...@dom.ain is not standard.  Not all MTAs support it, and some
support it with a different syntax (for example, user-al...@dom.ain in
Courier-MTA).

Best
Ale
-- 




___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-21 Thread Ken O'Driscoll via dmarc-discuss 
On Mon, 2018-05-21 at 09:29 -0600, Pete Holzmann via dmarc-discuss wrote:
> QUESTIONS:
> 1) Is anyone working to solve these issues?
> 2) Has there been consideration of a forwarding token that could validate
> all such emails

Take a look at the work being done on Authenticated Received Chain (ARC) - 
http://arc-spec.org/

ARC breaks DMARC in those use cases where authenticated email is then
forwarded on to another mailbox provider in a way which invalidates DMARC.
Basically, it achieves this by including the previous DMARC authentication
results in the message so that the receiver can then make more a informed
filtering decision which is not solely based on the original domain's DMARC
policy.

They have a dedicated mailing list.

Ken.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-21 Thread Paul Rock via dmarc-discuss 
1) Yes, via two methods - The first is mailbox aggregation (why setup
forwarding when I can just read the mailbox for you?) which is currently
supported by a number of email providers. The second is via Authenticated
Received Chain (ARC - see http://arc-spec.org/). Also currently supported
by a number of email providers.
2) Yes, but because it requires potentially significant user and provider
work, it's not really seen as a preferred solution. It also doesn't solve
many other issues that forwarding (and things like Lists) have with DMARC.
ARC should be able to solve these problems without requiring user
work/effort - it will however require provider effort, but most of the
major providers and several large FOSS mail packages/libraries already have
implemented or have committed to implementing ARC. See http://arc-spec.org/
for the current state of things.

On Mon, May 21, 2018 at 11:29 AM, Pete Holzmann via dmarc-discuss <
dmarc-discuss@dmarc.org> wrote:

> I'm seeing a growing number of bounce-back errors from major players who
> have DMARC fully implemented.
>
> I have some observations, questions and a suggestion.
>
> Blessings,
> Pete
>
> *OBSERVATIONS*
>
> There's a pattern here that I suspect is only going to grow:
>
> * User R with SomeCo creates an email filter rule to auto-forward some
> subset of incoming emails to their smart phone or other alternate mailbox
> (gmail, apple, etc)
>
> * From 'R's perspective, they simply want those emails to show up in their
> "other inbox"
>
> * From Google/Apple/etc perspective, those emails get the full treatment
> for:
> - SPF/DKIM/DMARC validity
> - Anti-spam filtering
> - Etc.
>
> The result (with varying details):
>
> a) Originator "O" of the email may get a DMARC bounceback (see example
> below) indicating that gmail (or whoever) would not accept the message.
> b) User "R" with the forwarding rule may find messages not showing up on
> their phone.
> c) Google/Apple/etc may start treating SomeCo as a source of spam
>
> ...and the hard part: from Originator and User perspective, everybody's
> doing what is "normal" but the email systems are causing grief. Only an
> expert examining headers and server logs can get a clue about what is
> happening.
>
> In a perfect world all software will perfectly implement DMARC. In the
> meantime, users get frustrated and email gets blocked.
>
> *QUESTIONS:*
> 1) Is anyone working to solve these issues?
> 2) Has there been consideration of a forwarding token that could validate
> all such emails?
>
> *SUGGESTION: *
> a) Since user+al...@dom.ain is a valid alias for u...@dom.ain ...
> b) Why not create a standard for personal forwarding authentication
> tokens? I.e.
>* A typical mechanism is used to create token asd!_4521Zxy
>* asd!_4521Zxy is stored as PrivateForwardToken in gmail box or
> ???
>* User forwards their email to user+asd!_4521...@gmail.com
> instead of
>   u...@gmail.com
>* Google auto-approves all such email as if it were internal
> rather than
>   externally sourced.
>
> [Probably needs modifying so such messages are rapidly recognized during
> transport... but I want to make sure end users can easily implement this on
> ANY email client, ANY email service, without help.]
>
>
> *EXAMPLE*
>
> I sent email to a friend. I received this bounceback. I was surprised to
> hear that my friend received the message... until on questioning he
> realized he also was auto-copying to a gmail box.
>
>
> Sorry. Your message could not be delivered to:
>
> gmail.com
>  DATA
>  Received: 5.7.1 Unauthenticated email from icta.net is
> not accepted due to domain's
>5.7.1 DMARC policy. Please contact
> the administrator of icta.net domain if
>5.7.1 this was a legitimate mail.
> Please visit
>5.7.1  https://support.google.com/
> mail/answer/2451690 to learn about the
>5.7.1 DMARC initiative.
> s4-v6si8436056ita.127 - gsmtp
>
> [end]
>
>
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
>
> NOTE: Participating in this list means you agree to the DMARC Note Well
> terms (http://www.dmarc.org/note_well.html)
>



-- 
PAUL ROCK
*Sr Software Dev Engineer* | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick Dr.| Dulles, VA | 20166-9305
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-21 Thread Gerben Wierda via dmarc-discuss 
There are many issues with DMARC. I’m trying it out now, but having looked at 
IETF documents (https://datatracker.ietf.org/wg/dmarc/documents/ 
) especially RFC 7960 
 ("Interoperability Issues between 
Domain-based Message Authentication, Reporting, and Conformance (DMARC) and 
Indirect Email Flows" which has a catalog of many issues) has made me less than 
optimistic. 

Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

> On 21 May 2018, at 17:29, Pete Holzmann via dmarc-discuss 
>  wrote:
> 
> I'm seeing a growing number of bounce-back errors from major players who have 
> DMARC fully implemented.
> 
> I have some observations, questions and a suggestion.
> 
> Blessings,
> Pete
> 
> OBSERVATIONS
> 
> There's a pattern here that I suspect is only going to grow:
> 
> * User R with SomeCo creates an email filter rule to auto-forward some subset 
> of incoming emails to their smart phone or other alternate mailbox (gmail, 
> apple, etc)
> 
> * From 'R's perspective, they simply want those emails to show up in their 
> "other inbox"
> 
> * From Google/Apple/etc perspective, those emails get the full treatment for:
> - SPF/DKIM/DMARC validity
> - Anti-spam filtering
> - Etc.
> 
> The result (with varying details):
> 
> a) Originator "O" of the email may get a DMARC bounceback (see example below) 
> indicating that gmail (or whoever) would not accept the message.
> b) User "R" with the forwarding rule may find messages not showing up on 
> their phone.
> c) Google/Apple/etc may start treating SomeCo as a source of spam
> 
> ...and the hard part: from Originator and User perspective, everybody's doing 
> what is "normal" but the email systems are causing grief. Only an expert 
> examining headers and server logs can get a clue about what is happening.
> 
> In a perfect world all software will perfectly implement DMARC. In the 
> meantime, users get frustrated and email gets blocked.
> 
> QUESTIONS:
> 1) Is anyone working to solve these issues?
> 2) Has there been consideration of a forwarding token that could validate all 
> such emails?
> 
> SUGGESTION:
> a) Since user+al...@dom.ain is a valid alias for u...@dom.ain ...
> b) Why not create a standard for personal forwarding authentication tokens? 
> I.e.
>* A typical mechanism is used to create token asd!_4521Zxy
>* asd!_4521Zxy is stored as PrivateForwardToken in gmail box or ???
>* User forwards their email to user+asd!_4521...@gmail.com instead 
> of
>   u...@gmail.com
>* Google auto-approves all such email as if it were internal 
> rather than
>   externally sourced.
> 
> [Probably needs modifying so such messages are rapidly recognized during 
> transport... but I want to make sure end users can easily implement this on 
> ANY email client, ANY email service, without help.]
> 
> 
> EXAMPLE
> 
> I sent email to a friend. I received this bounceback. I was surprised to hear 
> that my friend received the message... until on questioning he realized he 
> also was auto-copying to a gmail box.
> 
> 
> Sorry. Your message could not be delivered to:
> 
> gmail.com
>  DATA
>  Received: 5.7.1 Unauthenticated email from icta.net is not 
> accepted due to domain's
>5.7.1 DMARC policy. Please contact the 
> administrator of icta.net domain if
>5.7.1 this was a legitimate mail. 
> Please visit
>5.7.1  
> https://support.google.com/mail/answer/2451690 to learn about the
>5.7.1 DMARC initiative. 
> s4-v6si8436056ita.127 - gsmtp
> 
> [end] 
>   
> ___
> dmarc-discuss mailing list
> dmarc-discuss@dmarc.org
> http://www.dmarc.org/mailman/listinfo/dmarc-discuss
> 
> NOTE: Participating in this list means you agree to the DMARC Note Well terms 
> (http://www.dmarc.org/note_well.html)

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

[dmarc-discuss] General DMARC weakness - personal forwarding

2018-05-21 Thread Pete Holzmann via dmarc-discuss 



I'm seeing a growing number of bounce-back errors from major players who 
have DMARC fully implemented.


I have some observations, questions and a suggestion.


Blessings,
Pete


OBSERVATIONS


There's a pattern here that I suspect is only going to grow:


* User R with SomeCo creates an email filter rule to auto-forward some subset of 
incoming emails to their smart phone or other alternate mailbox (gmail, apple, 
etc)


* From 'R's perspective, they simply want those emails to show up in their "other 
inbox"


* From Google/Apple/etc perspective, those emails get the full treatment for:
    - SPF/DKIM/DMARC validity
    - Anti-spam filtering
    - Etc.


The result (with varying details):


a) Originator "O" of the email may get a DMARC bounceback (see example 
below) indicating that gmail (or whoever) would not accept the message.
b) User "R" with the forwarding rule may find messages not showing up on their 
phone.
c) Google/Apple/etc may start treating SomeCo as a source of spam


...and the hard part: from Originator and User perspective, everybody's doing 
what is "normal" but the email systems are causing grief. Only an expert 
examining headers and server logs can get a clue about what is happening.


In a perfect world all software will perfectly implement DMARC. In the meantime, 
users get frustrated and email gets blocked.


QUESTIONS:
1) Is anyone working to solve these issues?
2) Has there been consideration of a forwarding token that could validate all such 
emails?


SUGGESTION: 
a) Since user+al...@dom.ain is a valid alias for u...@dom.ain ...
b) Why not create a standard for personal forwarding authentication tokens? I.e.
   * A typical mechanism is used to create token asd!_4521Zxy
   * asd!_4521Zxy is stored as PrivateForwardToken in gmail box or ???
   * User forwards their email to user+asd!_4521...@gmail.com instead of
  u...@gmail.com
   * Google auto-approves all such email as if it were internal rather than
  externally sourced.


[Probably needs modifying so such messages are rapidly recognized during 
transport... but I want to make sure end users can easily implement this on ANY 
email client, ANY email service, without help.]




EXAMPLE


I sent email to a friend. I received this bounceback. I was surprised to hear that 
my friend received the message... until on questioning he realized he also was 
auto-copying to a gmail box.




Sorry. Your message could not be delivered to:


gmail.com
 DATA
 Received: 5.7.1 Unauthenticated email from icta.net is not accepted due to domain's
   5.7.1 DMARC policy. Please contact 
the administrator of icta.net domain if
   5.7.1 this was a legitimate mail. 
Please visit
   5.7.1  https://support.google.com/mail/answer/2451690 
to learn about the
   5.7.1 DMARC initiative. s4-v6si8436056ita.127 
- gsmtp


[end]  
  


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)