just an indication of approximate numbers so we choose somewhere suitable for
the size of party.
Cheers,
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
br...@fastmailteam.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
We don't have a table yet, but we have a bar tab :) come find me in my Fastmail
tshirt and say hi!
On Wed, Jul 6, 2022, at 18:07, Bron Gondwana wrote:
> Hopefully I've hit the key working groups where those who are friends of
> email (or email-adjacent stuff like calendars a
is the hash of the associated AAR)
A more cheap and nasty fix, assuming it's too late/complex to change the
protocol more, would be to keep AS, but change the validation to only
require checking the most recent AS, since validating the rest is
meaningless.
Cheers,
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:
>> On Aug 7, 2017, at 1:21 AM, Bron Gondwana
>> wrote:>>
>> A more cheap and nasty fix, assuming it's too late/complex to change
>> the protocol more, would be to keep AS, but change the validation to
>>
On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:
>> On Aug 7, 2017, at 1:21 AM, Bron Gondwana
>> wrote:>>
>> A more cheap and nasty fix, assuming it's too late/complex to change
>> the protocol more, would be to keep AS, but change the validation to
>>
On Tue, 8 Aug 2017, at 09:22, Seth Blank wrote:
> On Sun, Aug 6, 2017 at 10:21 PM, Bron Gondwana
> wrote:>> *AS adds nothing over just having AMS
> signing its own AAR, and then
>> you only have to verify ONE signature, the most recent.*>>
>>
>>
>>
On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
> On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana
> wrote:>> __
>>
>> . . . If you aren't willing to agree that the most recent liar can
>> repurpose an existing chain, I'm happy to avoid making th
e from this list if I'm going to make a proof of concept to show
what I mean, but nobody appears to be sending messages with ARC headers
on them here!
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
IM, then adding an AMS for messages which
are modified (e.g. by Groups)
> Also, you wouldn't expect to see arc signed messages from this list
> until it starts doing them itself, unless people are posting to it
> though another intermediary or you receive it through a separate
> interme
s been altered)
ARC-Seal: v=2 pass
ARC-Message-Signature: v=2 fail (message has been altered)
ARC-Seal: v=1 pass
ARC-Message-Signature: v=1 fail (message has been altered)
The fact that there is an intact chain of ARC-Seal is pointless here.
And as I have (hopefully successfully) argued above, if a
On Sat, 12 Aug 2017, at 10:04, Dave Crocker wrote:
> On 8/11/2017 4:54 PM, Bron Gondwana wrote:
>> On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:
>>
>> I'm just picking out the key quote here:
>>
>>> On 8/7/2017 4:22 PM, Seth Blank wrote:
>>>
On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote:
> On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana
> wrote:>> __
>> . . . it's a bad idea to sign if you're not modifying, because then
>> everybody has to trust you or their chain breaks, even though
On Sat, 12 Aug 2017, at 10:36, Kurt Andersen (b) wrote:
> Splitting out this discussion point into a new thread...
>
> On Fri, Aug 11, 2017 at 5:27 PM, Bron Gondwana
> wrote:>> __
>>
>> On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote:
>>> On Fri,
On Sat, 12 Aug 2017, at 10:54, Kurt Andersen (b) wrote:
> On Fri, Aug 11, 2017 at 5:50 PM, Bron Gondwana
> wrote:>> __
>>
>>
>>
>> Again - why seal on ingress? It's bogus.
>>
>> * check authentication on ingress
>> * add au
On Tue, 15 Aug 2017, at 05:42, Brandon Long wrote:
>
>
> On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana
> wrote:>> __
>> On Sat, 12 Aug 2017, at 03:22, Dave Crocker wrote:
>>
>> I'm just picking out the key quote here:
>>
>>
>>>
On Tue, 15 Aug 2017, at 10:46, Seth Blank wrote:
> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
> wrote:>>
>>> If there is a non-participating intermediary, either the message
>>> wasn't modified (so the next hop passes arc) or it was (and the next
>>
rds,
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
's my fallback position
if I can't convince people that AS is pointless. It's not my preferred
position, which is where I went in response to Brandon's post.
>> We should have AMS sign all the AAR and that's it. No AS, no need to
>> retain broken AMS.>>
&g
d inject the
headers from it to an email generated at site3.com.
Since site3.com is "bad", it can falsify all the mail flow after
site2.com added its ARC headers, and it can falsify it on any email that
followed a different path out of site2 originally. So we don't even
know that sit
y has DMARC p=reject to change
that to a new policy which explicitly means "only reject if no ARC
chain" - otherwise you can't stop rewriting sender until you know that
every receiver on your list is ARC-aware.
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
_
On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana
> wrote:>> The only way you could even hope (as a
> mailing list) to avoid
>> rewriting the sender is for every site that currently has DMARC
>> p=reject to change
On Thu, 17 Aug 2017, at 11:32, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> wrote:>> While there exists A SINGLE SITE which is
> ARC-unaware and DMARC
>> p=reject aware, you can't use ARC on a DMARC p=reject domain without
>> rewriting
On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> wrote:>> While there exists A SINGLE SITE which is
> ARC-unaware and DMARC
>> p=reject aware, you can't use ARC on a DMARC p=reject domain without
>> rewri
ed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> wrote:>> __
>>
>> On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
>>> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana
>>> wrote:>>>> The only way you could even hope (as a
>>> mailing list) t
On Fri, 18 Aug 2017, at 04:48, Seth Blank wrote:
> On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana
> wrote:>> I laugh as well, but it's more than
> p=reject isn't enough in the ARC
>> world, because it doesn't distinguish between:>> a) I'm
ing the
> AMS would be a sign to downstream intermediaries that the prior DKIM
> or AMS was still valid upon egress. (certain details would have to be
> worked out)>
> Does that help the conversation?
On this I agree with Seth. removing AMS breaks AS, and I see even less
value in
on (an email on Aug 9th to this
list and CCd to me which then got resent from a different address)
This will be accepted by an ARC-aware receiver unless I'm on a
blacklist, despite the p=reject.
Creating a new domain and putting a key in its DNS is pretty trivial -
so I guess the question is,
that
the payload was unmodified since it left the jurisdiction which had
access to the private key for its signing domain.
ARC as currently defined is weak on maintaining provenance on the
payload. But provenance on the payload is what really matters, because
falsifying the payload is where attacks against email integrity get
their value.
Bron.
[1] footnote on this - I have alluded to crypto header rewriting such
that you can't rewind. I'll write a separate email on that topic.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
uing?
It's bound to be more complex than ARC-as-defined, but it also makes
faking mail flows a lot harder, because you would have to intercept the
message between site3 and site4 if you wanted to fake the mail flow from
site3 - you couldn't just pick it up later.
Bron.
--
Bron
able to track the provenance on
individual parts of the message payload is a much stronger way to
determine who is at fault when bad content is being injected than just
knowing some bits of the message handling chain.
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
On Sat, 19 Aug 2017, at 16:33, Hector Santos wrote:
> On 8/16/2017 8:21 PM, Bron Gondwana wrote:
>> On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote:
>>> On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote:
>>>
>>> On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos
On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote:
> On 8/18/2017 8:53 PM, Bron Gondwana wrote:
>
>> ...
>>
>> And the message still arrives at receiver with a valid ARC
>> chain, just>> via badsite.com instead of site3.com.
>
> The same receiver? I
On Mon, 21 Aug 2017, at 10:04, Hector Santos wrote:
> On 8/20/2017 7:47 PM, Bron Gondwana wrote:
>> On Mon, 21 Aug 2017, at 09:34, Hector Santos wrote:
>>> On 8/18/2017 8:53 PM, Bron Gondwana wrote:
>>>
>>> ...
>>>
>>> And the message
On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote:
> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
> wrote:> > That seems like it would be enough to fix
> that objection. An
> > additional "first AMS failure" header at each hop would give you a
> > list
ason to MUST that every implementation support signing and
verifying at least two currently presumed strong algorithms at the
start, so if one is found wanting we can immediately deprecate it and
everyone can just turn on the other algorithm in their software
configuration.
Br
captured in this snippet:>
> On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana
> wrote:>> __
>>
>> On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote:
>>> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
>>> wrote:>>> > That seems like it would be
care what it's called, or if it is "oldest-
valid" or "newest-invalid" or whatever, so long as the thing I do care
about can be accurately extracted.
I'd also like to know the bootstrap pre-ARC case, which thankfully AAR
contains as dkim=pass, spf=pass, etc.
I assume this was the one that you wanted my clarification on?
On Wed, 3 Jan 2018, at 12:56, Kurt Andersen (b) wrote:
> On Wed, Jan 3, 2018 at 12:39 AM, Bron Gondwana
> wrote:>> __
>>
>> On Wed, 3 Jan 2018, at 04:34, Kurt Andersen (b) wrote:
>>> As I wen
Instance number please. Less calculation.
On Fri, 5 Jan 2018, at 16:18, Murray S. Kucherawy wrote:
> On Wed, Jan 3, 2018 at 6:28 PM, Kurt Andersen (b)
> wrote:>> On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana
>> wrote:>>> __
>>> I assume this was the one
tal standard
to encourage more deployment so we can collect data on real mail flows
is important too.
Cheers,
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Thu, Jul 26, 2018, at 04:57, Murray S. Kucherawy wrote:
> On Tue, Jul 24, 2018 at 3:55 PM, Bron Gondwana wrote:
>> __
>> This isn't a detailed review, because I haven't had time to do it, but I've
>> been following the process and I'm happy that ARC-16
ARC are
all fails in your Authentication-Results, any earlier ARC and DKIM
headers have no provable causal relationship with the rest of the
message you received.
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Sun, Jul 29, 2018, at 11:12, Seth Blank wrote:
> On Fri, Jul 27, 2018 at 7:39 PM, Bron Gondwana
> wrote:>> __
>>
>> The only thing your ARC Seal will validate is your own ARC-Authentication-
>> Results header - which isn't nothing (it could contain the I
dditional field than to take something
out, so I don't object to simplifying and seeing what happens. Particularly
since we're experimental.
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
you're not going to be in that session but do want to
come to the dinner, then let us know via email.
If you're not in Prague, I'm sorry you're missing out, and we'll drink a beer
for you.
Cheers,
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
br...@fastmailteam.com
45 matches
Mail list logo
