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
___
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 and co
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
omething
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
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
ls 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 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 is ready as an
>
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
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)
> <kb...@drkurt.com> wrote:>> On Wed, Jan 3, 2018 at 11:20 PM, Bron Gondwana
>> <br...@fastmailteam.com
n't 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. While dkim=pass
s snippet:>
> On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana
> <br...@fastmailteam.com> wrote:>> __
>>
>> On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote:
>>> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
>>> <br...@fastmailteam.com> wrote:>
reason 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.
Bron.
--
Bron
On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote:
> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
> <br...@fastmailteam.com> wrote:> > That seems like it would be enough to fix
> that objection. An
> > additional "first AMS failure" header at each hop woul
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 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 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
really valuable to me. Being 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...@fa
d 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 Gondwana, CEO, FastMail
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 ge
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, what is ARC doing other than rolling back
DMARC p=reject entirely?
gn 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 keeping AS if it doesn't even
On Fri, 18 Aug 2017, at 04:48, Seth Blank wrote:
> On Thu, Aug 17, 2017 at 1:09 AM, Bron Gondwana
> <br...@fastmailteam.com> 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:>>
, 2017 at 5:47 PM, Bron Gondwana
> <br...@fastmailteam.com> wrote:>> __
>>
>> On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote:
>>> On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana
>>> <br...@fastmailteam.com> wrote:>>>> The only way
On Thu, 17 Aug 2017, at 15:28, Murray S. Kucherawy wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> <br...@fastmailteam.com> 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
On Thu, 17 Aug 2017, at 11:32, Seth Blank wrote:
> On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana
> <br...@fastmailteam.com> 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 with
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 site2.com sends any email on to site3.com. Just that if
site2.com isn't bad, then it receives ema
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.>>
>> It gets you all the same machine readable chain of custody as
>> AS+AMS+AAR in the unbroken case, and it breaks at the same place
>> wi
On Tue, 15 Aug 2017, at 10:46, Seth Blank wrote:
> On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana
> <br...@fastmailteam.com> wrote:>>
>>> If there is a non-participating intermediary, either the message
>>> wasn't modified (so the next hop passes arc) o
On Sat, 12 Aug 2017, at 10:54, Kurt Andersen (b) wrote:
> On Fri, Aug 11, 2017 at 5:50 PM, Bron Gondwana
> <br...@fastmailteam.com> wrote:>> __
>>
>>
>>
>> Again - why seal on ingress? It's bogus.
>>
>> * check authentication on i
On Sat, 12 Aug 2017, at 10:16, Kurt Andersen (b) wrote:
> On Fri, Aug 11, 2017 at 4:54 PM, Bron Gondwana
> <br...@fastmailteam.com> wrote:>> __
>> . . . it's a bad idea to sign if you're not modifying, because then
>> everybody has to trust you or their chain break
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:
>>>
>
until it starts doing them itself, unless people are posting to it
> though another intermediary or you receive it through a separate
> intermediary.
It wasn't so much this list, it was everything else in my entire mail
repository! Not much with ARC on it yet.
Bron.
> Brandon
>
> On Aug 9, 20
On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote:
> On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana
> <br...@fastmailteam.com> wrote:>> __
>>
>> . . . If you aren't willing to agree that the most recent liar can
>> repurpose an existing chain, I
On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:
>> On Aug 7, 2017, at 1:21 AM, Bron Gondwana
>> <br...@fastmailteam.com> wrote:>>
>> A more cheap and nasty fix, assuming it's too late/complex to change
>> the protocol more, would be to keep AS, but chan
On Tue, 8 Aug 2017, at 00:50, Tim Draegen wrote:
>> On Aug 7, 2017, at 1:21 AM, Bron Gondwana
>> <br...@fastmailteam.com> wrote:>>
>> A more cheap and nasty fix, assuming it's too late/complex to change
>> the protocol more, would be to keep AS, but chan
35 matches
Mail list logo
