search

authindicators / rfc-brand-indicators-for-message-identification

Other
20 stars 6 forks source link

Why DNS if it's only for mail? #3

Closed Lockhead closed 7 years ago

Lockhead commented 7 years ago

Wouldn't it be easier if the sender simply puts the BIMI-location Header into the mail? You still have to track all the stuff but you would avoid additional DNS requests and if the Header is in the list of signed headers in the corresponding DKIM signature you can still use that as trust anchor.

Lockhead commented 7 years ago

any remarks to this topic? I'm pretty sure the IETF people will raise this question and it should be covered in the document to simply anticipate that...

tzink7 commented 7 years ago

There are multiple ways to do it:

  1. Shove it in a header
  2. Do it via DNS

We picked a single way to do BIMI, and not support multiple methods. That reduces operational complexity to do it one way, vs. two different ways. Each method has its pros and cons, but we are sticking with just one.

The advantage of DNS is that it can support more than just email, and images can also be dynamically resolved (i.e., publish a new image in the drop location) which you can't do with a header.

Lockhead commented 7 years ago

But the whole doc is written exclusivly for mail as the only channel. It only want's to register the header for mail, perhaps we should work on a more open version that simply brings in mail as it's first big example but also offers the usage in HTTP response headers, that would allow a HEAD request to construct an icon for website.

Your argument for DNS is feeble, as the header is static in both cases, you can also replace the image in the header only variant without any issues. But I can totally understand why DNS is favored over the static header. You or we need to bring that into the document.

tzink7 commented 7 years ago

Who is the audience that this more open version is supposed to be for? Do we have any implementers? For email, we have several implementers, all at large receivers or email client maintainers. To make a specific version for them AND a more general version for others expands the scope of the work and delays implementation.

Since if we don't have more general implementers other than email, we have a doc that can be extended in the future but is currently scoped to email. And since it is scoped to email, we had to pick and choose what methods we wanted to support. Additional complexity is a deployment blocker (since an implementer would now have to code up multiple mechanisms, and test them). Rather than adding operational complexity, we picked a single way and lived with the trade-offs.

Lockhead commented 7 years ago

It could be used as a favicon replacement and I think browser vendors would be happy to have something like this, because of the same reason we want that for email. But yeah you are right, concentrating on the actual need is the way to go. Offtopic are there any thoughts about my pull request? (I only added the author stuff like @AntiFreeze did, I'm fine as a silent contributer) But I reworded the example and think this would fit better.

AntiFreeze commented 7 years ago

I'll look into this soon and let you know

On Fri, Apr 7, 2017 at 9:57 AM, Tobias Herkula notifications@github.com wrote:

It could be used as a favicon replacement and I think browser vendors would be happy to have something like this, because of the same reason we want that for email. But yeah you are right, concentrating on the actual need is the way to go. Offtopic are there any thoughts about my pull request? (I only added the author stuff like @AntiFreeze https://github.com/AntiFreeze did, I'm fine as a silent contributer) But I reworded the example and think this would fit better.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/authindicators/rfc-brand-indicators-for-message-identification/issues/3#issuecomment-292592058, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKPFlffy85dm8BAQL0_-MSAPhITYEJ_ks5rtmsGgaJpZM4MbZsJ .

--

[image: logo for sig file.png]

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724>

AntiFreeze commented 7 years ago

The current version of the document substantially reworked how this is communicated. It covers why DNS and not a header is the vector for image suggestion, and how the BIMI-Location header is constructed and trust is relayed.

Can you confirm if the latest document refresh has addressed all your concerns from this issue and your pull request?