[mailop] BIMI and ARC

[Andrew C Aitchison via mailop]

[ Also sent to draft-brand-indicators-for-message-identificat...@ietf.org ]

https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/05/
 7.8.  Handle Existing BIMI-Location and BIMI-Indicator Headers
says:
   If the original email message had a DKIM signature, it has already
   been evaluated.  Removing the BIMI-Location header at this point
   should not invalidate the signature since it should not be included
   within it per this spec.

Should ARC follow this point ?

I have recently recieved a message with the extended "header line":

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;

h=bimi-indicator:bimi-location:message-id:subject:from:to:date
 :dkim-signature;
bh=eSJNDNC7jNBO0pA60Jz7iXbtpoaikxev3P6+3CCGPn8=;
fh=NEBFbcz/PfV5kmGdS9fK06GL1w09W1ScXRSY5P0g+gU=;
b=NutfwApfFobPb40qlk1CjsEljekQF+R6frEbKNUIddjp//M46a+HFz2ZQygdghXHrj
 etfgmcqWZbmmeA8uFqlBVijj8Y9VCJZa9IC6ncgQKEfswxGOdGE/LW0bYAldihjNad1O
 tJysP2s2uydDl848Y39jDhF80/c7Q5Bqj4DcqLP1bfEEBG4Ij596oPpWrNOBKqApv5IN
 rzODhITf85Go9hbvkhaAq4gf2K2njcnYsTga5SeRuVqNelll7c5EccsY3uijhOfzgOaa
 AvZIUWTsfz5bNhI4sWX6uwkSMU6joXcTvsCEaaZCJy2TgCLfOJ3aRqI09jAB8Wu9xMwG
 8yWg==;
dara=google.com


- note h=bimi-indicator:bimi-location: ...

We have an ARC signature which includes bimi-location, so the
message breaks the spirit but not the letter of the draft RFC.

Since the point of 7.8 is to say that an MTA MUST remove any 
bimi-indicator or bimi-location headers from incoming messages,

I think we have a problem ?

I haven't yet figured out which of the other headers I can safely post,
but the ARC headers must have been added by either google, mythic-beasts
(or possibly swaks on my machine).


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Louis Laureys via mailop]

> I hope that goes well for you (especially if you're planning to
> compete with the big free webmail providers).

Thanks, it's a saturated market for sure! Hoping I can still differentiate
myself is some key areas, like many of you I imagine :)

Groetjes,
Louis


Op zaterdag 13 januari 2024 om 20:01, schreef Randolf Richardson, Postmaster via
mailop :

> > > I find that helpful too.
> >
> > Good to hear I'm not alone haha
> >
> > > Will your eMail client have a free edition option?
> >
> > Afraid not. Will be starting an email host in the future and this will be
> the
> > webmail + mobile apps, it would access the host though an api so won't be
> > compatible with other hosts (but of course my host does support imap). I'm
> > currently its only user (this email is written in it), and there's no public
> > record of it beyond what you're reading now. Once I get my act together and
> > finally start this thing anyone here would of course be welcome to a free
> > account ;)
> 
> I hope that goes well for you (especially if you're planning to
> compete with the big free webmail providers).
> 
> Thanks for the clarification.
> 
> > > If you support BIMI with and without the "a=" parameter containing a
> > > certificate, that would be fantastic. (You could always indicate
> > > with a golden lock in the corner of BIMI logos when they do have
> > > valid certificates specified with the "a=" parameter.)
> >
> > That's the plan! Sorry to disappoint with the whole being an unreleased
> > proprietary email client part.
> 
> Excellent, and no worries about the proprietary part -- I asked
> because I didn't know what the intended outcome is.
> 
> > Groetjes,
> > Louis
> >
> >
> > Op donderdag 11 januari 2024 om 10:10, schreef Randolf Richardson,
> Postmaster
> > via mailop :
> >
> > > > > Simply, nobody needs this.
> > > >
> > > > I've been building an email client and actually do fetch avatars and
> logos
> > > to be
> > > > displayed next to emails. I find it helps me visually identify emails
> > > easier,
> > > > it's a lot less taxing on the brain than reading sender names or
> addresses.
> > > Of
> > > > course in my case I'm also scraping gravatar and favicons, so it doesn't
> > > have
> > > > much to do with BIMI.
> > >
> > > I find that helpful too.
> > >
> > > Will your eMail client have a free edition option? If so, please do
> > > share a link to it here (or eMail me directly) because I'd be happy
> > > to consider including it in the list of eMail client software options
> > > that we provide to our users (and also include it in the "Resources"
> > > section of the Canadian Lumber Cartel web site).
> > >
> > > (On PCs, most of our users are either using OutLook, Thunderbird, or
> > > our webmail option. A few are using other software, including
> > > Sylpheed, Pegasus Mail, and some others I don't recall the names of.)
> > >
> > > > Just wanted to add that I actually like it for visual clarity. Though I
> > > would
> > > > have liked a more general avatar implementation not geared towards
> > > businesses.
> > >
> > > If you support BIMI with and without the "a=" parameter containing a
> > > certificate, that would be fantastic. (You could always indicate
> > > with a golden lock in the corner of BIMI logos when they do have
> > > valid certificates specified with the "a=" parameter.)
> > >
> > > > Groetjes,
> > > > Louis
> > > >
> > > >
> > > > Op woensdag 10 januari 2024 om 18:18, schreef Jaroslaw Rafa via mailop
> > > >  [mailop@mailop.org]]>:
> > > >
> > > > > Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> > > > > > The hope is that as BIMI gets more widely adopted, the cost (and
> > > > > > automation) of the logo validation drops. Time will tell.
> > > > > >
> > > > > > Of course, for broader adoption, we also need to progress beyond
> > > > > > trademarks, which have their own cost and timeliness issues. The
> working
> > > > > > group is leaning heavily into this, as its our top priority to make
> BIMI
> > > > > > more broadly accessible.
> > > > > >
> > > > > > This covers our technical intent:
> > > > > > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]
> > > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]]
> > > > > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]
> > > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]]] and
> > > > >
> > > > > The document fails to convincingly answer THE one basic question:
> > > > >
> > > > > WHY in the hell is such a strange feature needed at all and for whom?
> > > > >
> > > > > As the OP has written, the only ones that may be interested in this
> may be
> > > > > marketers. Nobody else needs any logos, 

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Randolf Richardson, Postmaster via mailop]

> On 10.01.2024 at 21:59 Randolf Richardson, Postmaster via mailop
> wrote:
> 
> > What's missing from BIMI in its current form?  The option
> > for mail server oparators to use the same TLS certificates that
> > we're already using for our mail servers (and web servers,
> > and FTP servers, etc.).
> 
> A server certificate only verifies domain ownership. It does
> not include any logos, so it's not suitable to authenticate a
> BIMI selector. Therefor a server certificate cannot be used
> as evidence whether a domain is entitled to use a certain logo
> or not.

Correct.

The requirement that a logo's source be encrypted by a TLS (SSL) 
certificate that is valid for the domain of the sender is doable, 
though.  Disallowing redirection to a different domain name (that's 
not covered by SNI) is also doable.

I've also seen some discussion on using a TLS or SSL certificate to 
calculate a signature or fingerprint on an arbitrarily selected file, 
which cover examples of using OpenSSL commands to do it, but I 
haven't looked into this.

> Besides AFAIK the list price for a Verified Mark Certificate
> is 1500$. Depending on other contracts which a company
> might already have with the CA they'd probably receive a 10% to
> 90% discount. Even without any discount, 1500$ per year is
> not really something which I would consider a barrier for
> anyone but very small shops. Even a 3 person business will
> probably pay more for coffee than for the  certificate per year.

The price for registering a trademark in Canada is CAD$347.35 
(USD$259.72 according to Google on 2024-Jan-13), and, as I recall, 
this covers 15 years (and then it needs to be renewed again for the 
next 15 years, probably for the same price or whatever the 
registration price is at that time).

The cost for BIMI's "Verified Mark" certificate for 15 years (to 
match the registered trademark cost) would be USD$22,500.00, which is 
approximately 87 times more expensive.

People are right to be concerned about the costs of certifying their 
BIMI logos because it's so far out of touch with what it acdtually 
costs to get a registered trademark.

If the cost of the certificates was more in line with the cost of 
registering a trademark, then people probably wouldn't be so inclined 
to wonder if this might be yet another money making scheme.

-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Randolf Richardson, Postmaster via mailop]

> > I find that helpful too.
> 
> Good to hear I'm not alone haha
> 
> > Will your eMail client have a free edition option?
> 
> Afraid not. Will be starting an email host in the future and this will be the
> webmail + mobile apps, it would access the host though an api so won't be
> compatible with other hosts (but of course my host does support imap). I'm
> currently its only user (this email is written in it), and there's no public
> record of it beyond what you're reading now. Once I get my act together and
> finally start this thing anyone here would of course be welcome to a free
> account ;)

I hope that goes well for you (especially if you're planning to 
compete with the big free webmail providers).

Thanks for the clarification.

> > If you support BIMI with and without the "a=" parameter containing a
> > certificate, that would be fantastic. (You could always indicate
> > with a golden lock in the corner of BIMI logos when they do have
> > valid certificates specified with the "a=" parameter.)
> 
> That's the plan! Sorry to disappoint with the whole being an unreleased
> proprietary email client part.

Excellent, and no worries about the proprietary part -- I asked 
because I didn't know what the intended outcome is.

> Groetjes,
> Louis
> 
> 
> Op donderdag 11 januari 2024 om 10:10, schreef Randolf Richardson, Postmaster
> via mailop :
> 
> > > > Simply, nobody needs this.
> > >
> > > I've been building an email client and actually do fetch avatars and logos
> > to be
> > > displayed next to emails. I find it helps me visually identify emails
> > easier,
> > > it's a lot less taxing on the brain than reading sender names or 
> > > addresses.
> > Of
> > > course in my case I'm also scraping gravatar and favicons, so it doesn't
> > have
> > > much to do with BIMI.
> > 
> > I find that helpful too.
> > 
> > Will your eMail client have a free edition option? If so, please do
> > share a link to it here (or eMail me directly) because I'd be happy
> > to consider including it in the list of eMail client software options
> > that we provide to our users (and also include it in the "Resources"
> > section of the Canadian Lumber Cartel web site).
> > 
> > (On PCs, most of our users are either using OutLook, Thunderbird, or
> > our webmail option. A few are using other software, including
> > Sylpheed, Pegasus Mail, and some others I don't recall the names of.)
> > 
> > > Just wanted to add that I actually like it for visual clarity. Though I
> > would
> > > have liked a more general avatar implementation not geared towards
> > businesses.
> > 
> > If you support BIMI with and without the "a=" parameter containing a
> > certificate, that would be fantastic. (You could always indicate
> > with a golden lock in the corner of BIMI logos when they do have
> > valid certificates specified with the "a=" parameter.)
> > 
> > > Groetjes,
> > > Louis
> > >
> > >
> > > Op woensdag 10 januari 2024 om 18:18, schreef Jaroslaw Rafa via mailop
> > > :
> > >
> > > > Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> > > > > The hope is that as BIMI gets more widely adopted, the cost (and
> > > > > automation) of the logo validation drops. Time will tell.
> > > > >
> > > > > Of course, for broader adoption, we also need to progress beyond
> > > > > trademarks, which have their own cost and timeliness issues. The 
> > > > > working
> > > > > group is leaning heavily into this, as its our top priority to make 
> > > > > BIMI
> > > > > more broadly accessible.
> > > > >
> > > > > This covers our technical intent:
> > > > > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]
> > > > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]] and
> > > >
> > > > The document fails to convincingly answer THE one basic question:
> > > >
> > > > WHY in the hell is such a strange feature needed at all and for whom?
> > > >
> > > > As the OP has written, the only ones that may be interested in this may 
> > > > be
> > > > marketers. Nobody else needs any logos, avatars etc. displayed alongside
> > the
> > > > email headers. There is a reason why the early attempt at this - I'm
> > talking
> > > > about the X-Face header, which you even refer to in this document - 
> > > > never
> > > > gained any popularity. Simply, nobody needs this. The fact that Gmail
> > > > implemented in its web client putting up some images alongside email
> > headers
> > > > (which, by the way, show anything non-default only if the sender is
> > another
> > > > Gmail user and has a profile picture defined in his/her account) 
> > > > shouldn't
> > > > be any reference nor guide for designing email applications at all. 
> > > > NOBODY
> > > > NEEDS THESE IMAGES.
> > > >
> > > > Also, I see no feasible way - neither now nor in the future - to use it
> > any
> > >

Re: [mailop] BIMI and multiple hops

[Andrew C Aitchison via mailop]

On Sat, 13 Jan 2024, Benny Pedersen via mailop wrote:


Andrew C Aitchison via mailop skrev den 2024-01-13 07:16:

[ Wearing an MTA developer's hat. ]


+1

I see that an MTA is supposed to remove existing Authentication-Results and 
BIMI-Indicator headers, and that generally an MUA may use these headers if 
present.


where is this dokumented ?


https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/

7.8.  Handle Existing BIMI-Location and BIMI-Indicator Headers

   Regardless of success of the BIMI lookup, if a BIMI-Location or a
   BIMI-Indicator header is already present in a message it MUST be
   either removed or renamed.  This is because the MTA performing BIMI-
   related processing immediately prior to a Mail Delivery Agent (or
   within the same administrative realm) is the only entity allowed to
   specify the BIMI-Location or BIMI-Indicator headers (e.g. not the
   sending MTA, and not an intermediate MTA).  Allowing one or more
   existing headers through to a MUA is a security risk.

   If the original email message had a DKIM signature, it has already
   been evaluated.  Removing the BIMI-Location header at this point
   should not invalidate the signature since it should not be included
   within it per this spec.

I presume that most MTAs only add these headers on delivery, but if a 
non-compliant MTA received a message with these headers there is a risk 
that the MUA would trust them.


it is tested on incomming mails, not on outgoing


That is what a well-meaning MTA will do, and I have no evidence that
any MTA does not do this. However Blank et. al. considered the
possibility that a rogue MTA might set these headers on outgoing mail,
so included a rule to handle this risk.

Would it help if MUAs that don't actively support BIMI at least removed 
these headers when delivering to local mailboxes ?


mua must trust LAST MTA, not all MTA on transit, is this a big hint ?


Agreed. But there appears to be no way for the MUA to verify these
headers, so am I right to think that a good MTA should not pass them 
through, even if it does not create its own versions ?


AIUI, at present there are very few MUAs that display BIMI that are
not intimately connected to a mailbox provider that verifies BIMI,
so the question is probably not urgent, but getting it right at
leisure now is better than trying to fix the world in a panic.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI and multiple hops

[Benny Pedersen via mailop]

Andrew C Aitchison via mailop skrev den 2024-01-13 07:16:

[ Wearing an MTA developer's hat. ]


+1

I see that an MTA is supposed to remove existing Authentication-Results 
and BIMI-Indicator headers, and that generally an MUA may use these 
headers if present.


where is this dokumented ?

I presume that most MTAs only add these headers on delivery, but if a 
non-compliant MTA received a message with these headers there is a risk 
that the MUA would trust them.


it is tested on incomming mails, not on outgoing

Would it help if MUAs that don't actively support BIMI at least removed 
these headers when delivering to local mailboxes ?


mua must trust LAST MTA, not all MTA on transit, is this a big hint ?

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] BIMI and multiple hops

[Andrew C Aitchison via mailop]

[ Wearing an MTA developer's hat. ]

I see that an MTA is supposed to remove existing Authentication-Results 
and BIMI-Indicator headers, and that generally an MUA may use these 
headers if present.


I presume that most MTAs only add these headers on delivery, but if a 
non-compliant MTA received a message with these headers there is a risk 
that the MUA would trust them.


Would it help if MUAs that don't actively support BIMI at least removed 
these headers when delivering to local mailboxes ?


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Gellner, Oliver via mailop]

On 10.01.2024 at 21:59 Randolf Richardson, Postmaster via mailop wrote:

> What's missing from BIMI in its current form?  The option for mail server 
> oparators to use the same TLS certificates that we're already using for our 
> mail servers (and web servers, and FTP servers, etc.).

A server certificate only verifies domain ownership. It does not include any 
logos, so it's not suitable to authenticate a BIMI selector. Therefor a server 
certificate cannot be used as evidence whether a domain is entitled to use a 
certain logo or not.

Besides AFAIK the list price for a Verified Mark Certificate is 1500$. 
Depending on other contracts which a company might already have with the CA 
they'd probably receive a 10% to 90% discount. Even without any discount, 1500$ 
per year is not really something which I would consider a barrier for anyone 
but very small shops. Even a 3 person business will probably pay more for 
coffee than for the  certificate per year.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Gellner, Oliver via mailop]

On 11.01.2024 at 17:18 Ángel via mailop wrote:

> On 2024-01-10 at 20:38 +, Gellner, Oliver wrote:
>> Either way, BIMI is not suitable for reader tracking as you cannot
>> provide different logo URIs for each recipient.

> Sorry, but it would be possible:
>> Domain Owners can specify which other selector to use on a per-
>> message basis by utilizing the BIMI-Selector Header

> You could set a different selector per email message sent. You could manage 
> that with a wildcard dns entry and check the dns server logs.

> However, the draft is specified in such manner that the fetching would be 
> done by the MTA, so the BIMI check and fetching wouldn't provide information 
> to the senders.

Yes and even if the MUA fetched the logo directly, tracking would only be 
possible if the receiver displayed unverified BIMI logos. Otherwise the sender 
would have to acquire a different VMC for each selector / recipient, which 
wouldn't scale. There are a lot of ways to track email receivers, BIMI isn't 
one of them.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Louis Laureys via mailop]

> Then the recipient can choose to use a MUA that supports avatars (of course,
> there should always be the possibility to turn them off in configuration -
> which also solves the issue of tracking; if someone doesn't want to be
> tracked, he/she can turn the avatar support off in options, and their MUA
> won't fetch any avatar images from any website).

Of course! In my case avatars can be disabled, it's user preference whether to
have them or not. The avatars are also cached for a month or more on the server
side, are never requested directly from the client as to expose the user IP, and
only ever fetch the root domain to avoid tracking through per user subdomains.
Tracking would still be possible if you use a single domain specifically to
track a single user, but my thinking is that the chances of that are fairly low.

> But what would be actually desirable, is exactly what you wrote - an
> implementation not geared towards businesses. BIMI is nothing like this, as
> John clearly explained below it is and always will be geared towards
> businesses

Yep! To be fair, a lot of people receive mostly B2C email. So in the case of a
recipient wanting to see avatars, it's still quite nice to have as opposed to no
standard at all. A general avatar standard would have been nicer in my opinion.
But then, perhaps the big players would not have adopted it because there are no
verification benefits? Not sure.



Groetjes,
Louis


Op donderdag 11 januari 2024 om 12:19, schreef Jaroslaw Rafa via mailop
:

> Dnia 10.01.2024 o godz. 22:57:21 Louis Laureys via mailop pisze:
> > Just wanted to add that I actually like it for visual clarity. Though I
> would
> > have liked a more general avatar implementation not geared towards
> businesses.
> 
> If someone, *as a recipient*, likes having avatars next to email, I have
> nothing against it - but *only if it's totally optional and decided upon by
> recipient* (and by recipient, I mean the individual person and not the
> organization that runs the receiving mail server). Then the recipient can
> choose to use a MUA that supports avatars (of course, there should always be
> the possibility to turn them off in configuration - which also solves the
> issue of tracking; if someone doesn't want to be tracked, he/she can turn
> the avatar support off in options, and their MUA won't fetch any avatar
> images from any website).
> 
> But what would be actually desirable, is exactly what you wrote - an
> implementation *not geared towards businesses*. BIMI is nothing like this,
> as John clearly explained below it *is and always will be* geared towards
> businesses. And for me BIMI looks more like push from the *senders* (and in
> particular, big marketing senders) on people to use the avatars (and use
> them only in a particular way dictated by big businesses), rather than
> a response to an *actual need* from *recipients* to use them.
> 
> Dnia 10.01.2024 o godz. 21:21:16 John Levine via mailop pisze:
> > While it would be nice to make BIMI available to small organizations
> > without costing a lot of money, the question "is entity A allowed to
> > show logo X" is very hard even for people, and not amenable to
> > authomation. In a few cases where the entity has already paid to put
> > the logo in a trademark database it's easier but that sure doesn't
> > scale.
> 
> There is a very real danger (and this is even predicted in the document
> linked in the previous email) that adoption of BIMI by big mail providers
> will serve as another "antispam" measure; messages having verified BIMI mark
> would be treated by ISPs as more "trustworthy" and "reputable" than the
> messages that don't. This would clearly lead to dividing email service in
> two categories: "first class" would be an email from businesses that are big
> and rich enough that they can afford having their email BIMI certified,
> which would give them a kind of "guarantee" for their emails to be delivered
> to all the big ISPs - and a "second class" consisiting of all the other
> senders, who lack BIMI verification, and thus can only hope to have luck
> that their email gets through the filters (which will happen gradually less
> and less often).
> 
> As it has happened with DMARC, which also in the beginning - as the document
> states - was purely optional and meant only for specific, often-phished
> domains.
> 
> This is a very bad perspective, and BIMI is in my opinion a road straight to
> this direction.
> --
> Regards,
> Jaroslaw Rafa
> r...@rafa.eu.org [r...@rafa.eu.org]
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/li

Re: [mailop] BIMI boycott?

[Louis Laureys via mailop]

> I find that helpful too.

Good to hear I'm not alone haha

> Will your eMail client have a free edition option?

Afraid not. Will be starting an email host in the future and this will be the
webmail + mobile apps, it would access the host though an api so won't be
compatible with other hosts (but of course my host does support imap). I'm
currently its only user (this email is written in it), and there's no public
record of it beyond what you're reading now. Once I get my act together and
finally start this thing anyone here would of course be welcome to a free
account ;)

> If you support BIMI with and without the "a=" parameter containing a
> certificate, that would be fantastic. (You could always indicate
> with a golden lock in the corner of BIMI logos when they do have
> valid certificates specified with the "a=" parameter.)

That's the plan! Sorry to disappoint with the whole being an unreleased
proprietary email client part.



Groetjes,
Louis


Op donderdag 11 januari 2024 om 10:10, schreef Randolf Richardson, Postmaster
via mailop :

> > > Simply, nobody needs this.
> >
> > I've been building an email client and actually do fetch avatars and logos
> to be
> > displayed next to emails. I find it helps me visually identify emails
> easier,
> > it's a lot less taxing on the brain than reading sender names or addresses.
> Of
> > course in my case I'm also scraping gravatar and favicons, so it doesn't
> have
> > much to do with BIMI.
> 
> I find that helpful too.
> 
> Will your eMail client have a free edition option? If so, please do
> share a link to it here (or eMail me directly) because I'd be happy
> to consider including it in the list of eMail client software options
> that we provide to our users (and also include it in the "Resources"
> section of the Canadian Lumber Cartel web site).
> 
> (On PCs, most of our users are either using OutLook, Thunderbird, or
> our webmail option. A few are using other software, including
> Sylpheed, Pegasus Mail, and some others I don't recall the names of.)
> 
> > Just wanted to add that I actually like it for visual clarity. Though I
> would
> > have liked a more general avatar implementation not geared towards
> businesses.
> 
> If you support BIMI with and without the "a=" parameter containing a
> certificate, that would be fantastic. (You could always indicate
> with a golden lock in the corner of BIMI logos when they do have
> valid certificates specified with the "a=" parameter.)
> 
> > Groetjes,
> > Louis
> >
> >
> > Op woensdag 10 januari 2024 om 18:18, schreef Jaroslaw Rafa via mailop
> > :
> >
> > > Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> > > > The hope is that as BIMI gets more widely adopted, the cost (and
> > > > automation) of the logo validation drops. Time will tell.
> > > >
> > > > Of course, for broader adoption, we also need to progress beyond
> > > > trademarks, which have their own cost and timeliness issues. The working
> > > > group is leaning heavily into this, as its our top priority to make BIMI
> > > > more broadly accessible.
> > > >
> > > > This covers our technical intent:
> > > > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]
> > > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00]] and
> > >
> > > The document fails to convincingly answer THE one basic question:
> > >
> > > WHY in the hell is such a strange feature needed at all and for whom?
> > >
> > > As the OP has written, the only ones that may be interested in this may be
> > > marketers. Nobody else needs any logos, avatars etc. displayed alongside
> the
> > > email headers. There is a reason why the early attempt at this - I'm
> talking
> > > about the X-Face header, which you even refer to in this document - never
> > > gained any popularity. Simply, nobody needs this. The fact that Gmail
> > > implemented in its web client putting up some images alongside email
> headers
> > > (which, by the way, show anything non-default only if the sender is
> another
> > > Gmail user and has a profile picture defined in his/her account) shouldn't
> > > be any reference nor guide for designing email applications at all. NOBODY
> > > NEEDS THESE IMAGES.
> > >
> > > Also, I see no feasible way - neither now nor in the future - to use it
> any
> > > meaningful way in person-to-person communication, which is the topic OP
> > > asked about, and you seem to have ignored it completely in your answer.
> The
> > > document you are linking to isn't even trying to address this use case! It
> > > speaks all the time about "organizations" or "brands" and their logotypes,
> > > like companies or organizations were the only senders of emails. Or maybe
> > > this is the actual intent? To make individual people only reicipents of
> > > emails, without the ability to send?
> > >
> > > In section 3.3 you even 

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Louis Laureys via mailop]

Hey all,

> I might have missed something, but wouldn't that be a phisher's wet dream?

It depends on the implementation really. A lot of parallels can be drawn to
things email clients and other platforms have been doing for years. Email
clients have already been using Gravatar, and on almost every social media
platform or forum you can set your own name and avatar. It's not much different.

> I don't think that the regular user will check if the little extra lock is
> there on the icon. They'll see a version of the paypal logo on the phish and
> have an extra feeling of safety.

Maybe, maybe not. I feel about 70% of all commercial emails in my client have
logos. It's essentially same as the sender name being "PayPal". There's really
no implicit extra trust about there being a logo in this context.

> how the user is supposed to distinguish which avatars are verified BIMI logos,
> and which ones come from a totally different source?

An indicator. It's probably not as effective as only ever showing BIMI verified,
but it's been standard on other platforms for a while now. It's not the solution
to all problems, but it does seem like a design pattern that users will
recognize. I have not done any user research into this though, this is just my
thought process at the moment.

> Otherwise, the non-BIMI avatars displayed along the messages, mixed with BIMI
> ones, will just facilitate phishing instead of making it more difficult

I'm honestly not sure whether that was a great promise to begin with. It's an
attractive one, for sure. BIMI being mixed with other avatars was always a thing
that would probably happen. Gravatar is already widely used, and Gmail shows
avatars for other google users (as far as I know).



I've implemented it this way into my client because I liked being able to more
visually differentiate emails, and reduce the mental load of having to scan
text. It initially had absolutely nothing to do with BIMI, in fact I added BIMI
after I added the other sources. But in my case BIMI can still add security
through the verification indicator, which I will be adding. I've hidden avatars
for messages in the junk folder as well, as a precaution.

Anecdotally, none of the mass phishing emails I've received have had the correct
logo associated. It's usually compromised credentials without access to the
domain, and they don't seem to go through the effort of setting up Gravatar. Of
course this really means nothing for targeted attacks by actually competent
phishers, but I thought it was fun to see. It's something I wondered about when
I started adding the avatars.



Groetjes,
Louis


Op donderdag 11 januari 2024 om 20:43, schreef Tim Starr via mailop
:

> They can already rip people off, w/out BIMI. BIMI limits their ability to do
> so in two ways:
> 
> 
> 1) It raises the cost, because BIMI setup costs more.
> 2) It makes it harder for scammers to impersonate trusted brands.
> 
> 
> -Tim
> 
> On Thu, Jan 11, 2024 at 12:58 PM Randolf Richardson, Postmaster via mailop
>  wrote:
> 
> 
> > > I might have missed something, but wouldn't that be a phisher's wet dream?
> > 
> >         Indeed, and because the BIMI record references a URI to load the
> > logo from, so the scammers (spammers, phishers, malware/virus
> > distributors, etc.) could simply specify a different logo file with a
> > recognized brand to make their bad eMail appear legitimate.
> > 
> > > Most spammers know very well how to do a mail with valid DMARC. So, now
> > > they only need to send a valid mail from any throw away cheap domain and
> > > in their BIMI add the logo of paypal?
> > 
> >         Yes.
> > 
> > > I understand it's not great to have to pay for the
> > > verification/certification, but leaving the door open to abuse is a
> > > dangerous path to take.
> > 
> >         Some scammers make a lot of money ripping people off.  They could
> > easily afford set up a company, get a Trademark, and then use a
> > different logo image when sending their junk eMails.
> > 
> >         So, once this happens often enough, end-users will just not trust
> > the BIMI logos to be reliable and it will be another internet feature
> > that security educators will recommend be taken with a grain of salt.
> > 
> > > Being on the antispam side, I would hate to have to start implementing
> > > BIMI spoof checks.
> > 
> >         I agree.  Even if someone else makes a SpamAssassin plug-in or a
> > milter, it still adds to the overall complexity and will have a
> > potentially-noticeable impact on busier systems ... and then everyone
> > has to pay indirectly for BIMI with slower performance of system
> > upgrades to counter the slower performance.
> > 
> > > Regards,
> > > Laurent
> > >
> > > On 11.01.24 00:05, Louis Laureys via mailop wrote:
> > > >      We decided to keep this because I read that some webmail clients
> > are
> > > >      planning to support BIMI without checking for certificates, or,
> > > >      perhaps, also displaying a little lock 

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Tim Starr via mailop]

They can already rip people off, w/out BIMI. BIMI limits their ability to
do so in two ways:

1) It raises the cost, because BIMI setup costs more.
2) It makes it harder for scammers to impersonate trusted brands.

-Tim

On Thu, Jan 11, 2024 at 12:58 PM Randolf Richardson, Postmaster via mailop <
mailop@mailop.org> wrote:

> > I might have missed something, but wouldn't that be a phisher's wet
> dream?
>
> Indeed, and because the BIMI record references a URI to load the
> logo from, so the scammers (spammers, phishers, malware/virus
> distributors, etc.) could simply specify a different logo file with a
> recognized brand to make their bad eMail appear legitimate.
>
> > Most spammers know very well how to do a mail with valid DMARC. So, now
> > they only need to send a valid mail from any throw away cheap domain and
> > in their BIMI add the logo of paypal?
>
> Yes.
>
> > I understand it's not great to have to pay for the
> > verification/certification, but leaving the door open to abuse is a
> > dangerous path to take.
>
> Some scammers make a lot of money ripping people off.  They could
> easily afford set up a company, get a Trademark, and then use a
> different logo image when sending their junk eMails.
>
> So, once this happens often enough, end-users will just not trust
> the BIMI logos to be reliable and it will be another internet feature
> that security educators will recommend be taken with a grain of salt.
>
> > Being on the antispam side, I would hate to have to start implementing
> > BIMI spoof checks.
>
> I agree.  Even if someone else makes a SpamAssassin plug-in or a
> milter, it still adds to the overall complexity and will have a
> potentially-noticeable impact on busier systems ... and then everyone
> has to pay indirectly for BIMI with slower performance of system
> upgrades to counter the slower performance.
>
> > Regards,
> > Laurent
> >
> > On 11.01.24 00:05, Louis Laureys via mailop wrote:
> > >  We decided to keep this because I read that some webmail clients
> are
> > >  planning to support BIMI without checking for certificates, or,
> > >  perhaps, also displaying a little lock icon in the corner of the
> > >  sender's BIMI-style logo image where certification is verified.
> > >
> > > This is exactly what I have in mind for my client, thanks for
> publishing your
> > > logo in an easily accessible and standard way :)
> > >
> > > Groetjes,
> > > Louis
> > >
> > >
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
>
>
> --
> Postmaster - postmas...@inter-corporate.com
> Randolf Richardson, CNA - rand...@inter-corporate.com
> Inter-Corporate Computer & Network Services, Inc.
> Vancouver, British Columbia, Canada
> https://www.inter-corporate.com/
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Benny Pedersen via mailop]

Randolf Richardson, Postmaster via mailop skrev den 2024-01-11 19:52:
I might have missed something, but wouldn't that be a phisher's wet 
dream?


Indeed, and because the BIMI record references a URI to load the
logo from, so the scammers (spammers, phishers, malware/virus
distributors, etc.) could simply specify a different logo file with a
recognized brand to make their bad eMail appear legitimate.


lets hope this is resolved to be same domain as sasl sender, where dkim 
is pass, bimi have no rule if its just random other domains is valid


hopefully no mistakes there

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Randolf Richardson, Postmaster via mailop]

> I might have missed something, but wouldn't that be a phisher's wet dream?

Indeed, and because the BIMI record references a URI to load the 
logo from, so the scammers (spammers, phishers, malware/virus 
distributors, etc.) could simply specify a different logo file with a 
recognized brand to make their bad eMail appear legitimate.

> Most spammers know very well how to do a mail with valid DMARC. So, now 
> they only need to send a valid mail from any throw away cheap domain and 
> in their BIMI add the logo of paypal?

Yes.

> I understand it's not great to have to pay for the 
> verification/certification, but leaving the door open to abuse is a 
> dangerous path to take.

Some scammers make a lot of money ripping people off.  They could 
easily afford set up a company, get a Trademark, and then use a 
different logo image when sending their junk eMails.

So, once this happens often enough, end-users will just not trust 
the BIMI logos to be reliable and it will be another internet feature 
that security educators will recommend be taken with a grain of salt.

> Being on the antispam side, I would hate to have to start implementing 
> BIMI spoof checks.

I agree.  Even if someone else makes a SpamAssassin plug-in or a 
milter, it still adds to the overall complexity and will have a 
potentially-noticeable impact on busier systems ... and then everyone 
has to pay indirectly for BIMI with slower performance of system 
upgrades to counter the slower performance.

> Regards,
> Laurent
> 
> On 11.01.24 00:05, Louis Laureys via mailop wrote:
> >  We decided to keep this because I read that some webmail clients are
> >  planning to support BIMI without checking for certificates, or,
> >  perhaps, also displaying a little lock icon in the corner of the
> >  sender's BIMI-style logo image where certification is verified.
> > 
> > This is exactly what I have in mind for my client, thanks for publishing 
> > your
> > logo in an easily accessible and standard way :)
> > 
> > Groetjes,
> > Louis
> > 
> > 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop


-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Tim Starr via mailop]

You seem to be taking a religious position based on your perception of
"need." If this feature is un-needed, why did Google and Yahoo do it? They
think their users want it, that's why they spent time building this feature
into their UIs, and why they keep it there. Among other things, it serves
as a visible indicator of email that is both authenticated and passes
DMARC. If you also object to authentication and DMARC, then you're making
yourself even more of a minority advocate. I do not expect any such boycott
to get widespread adoption.

Tim Starr

On Wed, Jan 10, 2024 at 11:34 AM Jaroslaw Rafa via mailop 
wrote:

> Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> > The hope is that as BIMI gets more widely adopted, the cost (and
> > automation) of the logo validation drops. Time will tell.
> >
> > Of course, for broader adoption, we also need to progress beyond
> > trademarks, which have their own cost and timeliness issues. The working
> > group is leaning heavily into this, as its our top priority to make BIMI
> > more broadly accessible.
> >
> > This covers our technical intent:
> > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00 and
>
> The document fails to convincingly answer THE one basic question:
>
> WHY in the hell is such a strange feature needed at all and for whom?
>
> As the OP has written, the only ones that may be interested in this may be
> marketers. Nobody else needs any logos, avatars etc. displayed alongside
> the
> email headers. There is a reason why the early attempt at this - I'm
> talking
> about the X-Face header, which you even refer to in this document - never
> gained any popularity. Simply, nobody needs this. The fact that Gmail
> implemented in its web client putting up some images alongside email
> headers
> (which, by the way, show anything non-default only if the sender is another
> Gmail user and has a profile picture defined in his/her account) shouldn't
> be any reference nor guide for designing email applications at all. NOBODY
> NEEDS THESE IMAGES.
>
> Also, I see no feasible way - neither now nor in the future - to use it any
> meaningful way in person-to-person communication, which is the topic OP
> asked about, and you seem to have ignored it completely in your answer. The
> document you are linking to isn't even trying to address this use case! It
> speaks all the time about "organizations" or "brands" and their logotypes,
> like companies or organizations were the only senders of emails. Or maybe
> this is the actual intent? To make individual people only reicipents of
> emails, without the ability to send?
>
> In section 3.3 you even predict that BIMI is about to go the same path
> DMARC
> went - "DMARC started with limited use to protect heavily phished domains",
> and now we have arrived to the point when you almost can't send mail to any
> big mail provider without having DMARC properly set up. You predict that
> likely the same will happen for BIMI, which means, you won't be able to
> send
> mail to any of the "big players" if you don't have BIMI set up. Which
> *will*
> cost money - you are also clear about it. Is the goal to make email a
> closed
> ecosystem in which only the big players can participate?
>
> This was a bad idea from the beginning (I would even say, a crazy idea) and
> will still be a bad idea no matter how much work and effort you put into
> it.
> So maybe it's better not to waste that effort at all and direct it towards
> something actually useful.
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Jaroslaw Rafa via mailop]

Dnia 11.01.2024 o godz. 14:34:16 Laurent S. via mailop pisze:
> The trademark verification is only for those that pay for it. Nothing 
> forbids a MUA from displaying an unverified BIMI. Most are luckily not 
> doing it (yet), I just want to warn that if this becomes common, it will 
> be abused for sure. I don't think that the regular user will check if 
> the little extra lock is there on the icon. They'll see a version of the 
> paypal logo on the phish and have an extra feeling of safety.

Dnia 11.01.2024 o godz. 17:52:34 G. Miliotis via mailop pisze:
> What I believe will happen is most non-big mail client apps will
> support BIMI if they support avatars, otherwise, they won't, cause
> the arguments on the receiver side are the same for both features.
> 
> I don't buy the "promoting authentication" argument.

And it's clearly visible from the Laurent's mail that if MUAs will display
the unverified BIMI logos (and what would prohibit them from that?) the
"authentication" factor can be even weaker than with no avatars at all -
because user who is convinced that the logo being displayed means that the
message is genuine, may not even look at the actual sender field.

Also, if a hypothetical MUA displays BIMI logos, but also displays avatars
obtained by other means (one of the users in the thread mentioned a MUA he
develops that uses eg. favicons, or Gravatar service for that purpose), how
the user is supposed to distinguish which avatars are verified BIMI logos,
and which ones come from a totally different source?

Trying to look at the "broad picture", I realized that the whole concept of
BIMI may actually work as designed *only* if MUA developers could be somehow
*legally prohibited* from displaying any other avatars than verified BIMI
logos. Which not only seems totalitarian in nature, but also politically
completely impossible to actually implement.

Otherwise, the non-BIMI avatars displayed along the messages, mixed with
BIMI ones, will just facilitate phishing instead of making it more
difficult. All the manual work on verifying logos and money invested into
it will be basically a wasted effort.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Ángel via mailop]

On 2024-01-10 at 20:38 +, Gellner, Oliver wrote:
> > Its also may be yet another reader-engagement tracker. Why do those
> > things always have to be out of band.
> 
> Well, there’s no automated way to connect a logo to a domain. The
> BIMI group has decided to build upon the work of trademark offices to
> connect logos to companies and then set up a manual verification
> process to connect the company to a domain. There might be other ways
> to do this, but you cannot just use DNS or a message header to link a
> logo to a domain as this would be trivial to exploit.
> 
> Either way, BIMI is not suitable for reader tracking as you cannot
> provide different logo URIs for each recipient.

Sorry, but it would be possible:
> Domain Owners can specify which other selector to use on a per-
> message basis by utilizing the BIMI-Selector Header

You could set a different selector per email message sent. You could
manage that with a wildcard dns entry and check the dns server logs.


However, the draft is specified in such manner that the fetching would
be done by the MTA, so the BIMI check and fetching wouldn't provide
information to the senders.
Only if a MUA tried to perform all checks itself (because its mail
server doesn't support BIMI, for instance).

Regards


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[G. Miliotis via mailop]

Greetings.

What I believe will happen is most non-big mail client apps will support 
BIMI if they support avatars, otherwise, they won't, cause the arguments 
on the receiver side are the same for both features.


I don't buy the "promoting authentication" argument. There would be a 
marginal benefit in spreading DMARC via a UI good-to-have feature as a 
carrot, thus combating phishing, but DMARC doesn't need help spreading, 
it's become a requirement by the big mail receivers. So BIMI only 
becomes useful if VMCs are used. Yay, another bureaucracy on top of the 
certificate issuer and domain registration ones. Even more hassle and 
expense for small senders.


The big mail players will adopt BIMI cause their clients (the marketers) 
are proposing it. So eventually anyone without a logo next to their mail 
will be met with suspicion by the users.  Have an e-shop but don't have 
VMC-backed BIMI? You get your logo shown but no blue checkmark on it, 
uh-oh, now you're in the spam folder, oops. Tough to be you.


Eventually, no BIMI = +5% spam chance and life will go on as usual: 
small mail operators and SMBs will be even less in control of the 
deliverability of their mailings while the big senders get even more 
closely coupled to big mail providers.


BIMI is trying to do identity. IMO identity will not be solved in mail 
inbox UIs. It'll come from concerted efforts elsewhere and mail will 
integrate into that.


Regards,
G. Miliotis

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[L. Mark Stone via mailop]

FWIW we went through the trademark process for our logo.

It was time-consuming, but straightforward and not expensive.

We've deployed BIMI, but with a= as the SSL certificates are still quite 
expensive; Digicert's BIMI certificate is half-again as much as their EV 
certificate.

If Digicert et. al. offered a combined EV/BIMI certificate (since much of the 
labor-intensive validation tasks as I understand it are identical for both 
certs), I think that could be an attractive option for many senders.

IMHO the industry has several complementary/overlapping initiatives at various 
stages of maturity and adoption, all intended to better authenticate senders 
and prevent domain spoofing. I fully expect there to be friction, resistance 
and bumps in the road as we all work to minimize illegitimate email -- but 
despite Google, Yahoo, Microsoft etc. being a major source of the inbound spam 
that we see tour and our customers' systems, I applaud their efforts to better 
authenticate senders and prevent domain spoofing. 

I just wish they would apply the same strict rulesets to their outbound email 
streams that they are starting to apply/applying to their inbound email 
streams...

Best regards to all, 
Mark 
_ 
L. Mark Stone, Founder 
North America's Leading Zimbra VAR/BSP/Training Partner 
For Companies With Mission-Critical Email Needs

- Original Message -
From: "Laurent S. via mailop" 
To: "mailop" 
Sent: Thursday, January 11, 2024 9:34:16 AM
Subject: Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, 
and intellectual property law considerations

On 11.01.24 14:59, Udeme via mailop wrote:
> There’s a trademark ownership vetting item that’s part of BIMI implementation.
> Not just *anyone* can get past that. #wink
> 

The trademark verification is only for those that pay for it. Nothing 
forbids a MUA from displaying an unverified BIMI. Most are luckily not 
doing it (yet), I just want to warn that if this becomes common, it will 
be abused for sure. I don't think that the regular user will check if 
the little extra lock is there on the icon. They'll see a version of the 
paypal logo on the phish and have an extra feeling of safety.

Best,
Laurent

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Laurent S. via mailop]

On 11.01.24 14:59, Udeme via mailop wrote:
> There’s a trademark ownership vetting item that’s part of BIMI implementation.
> Not just *anyone* can get past that. #wink
> 

The trademark verification is only for those that pay for it. Nothing 
forbids a MUA from displaying an unverified BIMI. Most are luckily not 
doing it (yet), I just want to warn that if this becomes common, it will 
be abused for sure. I don't think that the regular user will check if 
the little extra lock is there on the icon. They'll see a version of the 
paypal logo on the phish and have an extra feeling of safety.

Best,
Laurent

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Udeme via mailop]

There’s a trademark ownership vetting item that’s part of BIMI
implementation. Not just *anyone* can get past that. #wink

-Udeme

On Thu, Jan 11, 2024 at 5:36 AM Laurent S. via mailop 
wrote:

> I might have missed something, but wouldn't that be a phisher's wet dream?
>
> Most spammers know very well how to do a mail with valid DMARC. So, now
> they only need to send a valid mail from any throw away cheap domain and
> in their BIMI add the logo of paypal?
>
> I understand it's not great to have to pay for the
> verification/certification, but leaving the door open to abuse is a
> dangerous path to take.
>
> Being on the antispam side, I would hate to have to start implementing
> BIMI spoof checks.
>
> Regards,
> Laurent
>
> On 11.01.24 00:05, Louis Laureys via mailop wrote:
> >  We decided to keep this because I read that some webmail clients are
> >  planning to support BIMI without checking for certificates, or,
> >  perhaps, also displaying a little lock icon in the corner of the
> >  sender's BIMI-style logo image where certification is verified.
> >
> > This is exactly what I have in mind for my client, thanks for publishing
> your
> > logo in an easily accessible and standard way :)
> >
> > Groetjes,
> > Louis
> >
> >
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Jaroslaw Rafa via mailop]

Dnia 10.01.2024 o godz. 22:57:21 Louis Laureys via mailop pisze:
> Just wanted to add that I actually like it for visual clarity. Though I would
> have liked a more general avatar implementation not geared towards businesses.

If someone, *as a recipient*, likes having avatars next to email, I have
nothing against it - but *only if it's totally optional and decided upon by
recipient* (and by recipient, I mean the individual person and not the
organization that runs the receiving mail server). Then the recipient can
choose to use a MUA that supports avatars (of course, there should always be
the possibility to turn them off in configuration - which also solves the
issue of tracking; if someone doesn't want to be tracked, he/she can turn
the avatar support off in options, and their MUA won't fetch any avatar
images from any website).

But what would be actually desirable, is exactly what you wrote - an
implementation *not geared towards businesses*. BIMI is nothing like this,
as John clearly explained below it *is and always will be* geared towards
businesses. And for me BIMI looks more like push from the *senders* (and in
particular, big marketing senders) on people to use the avatars (and use
them only in a particular way dictated by big businesses), rather than
a response to an *actual need* from *recipients* to use them.

Dnia 10.01.2024 o godz. 21:21:16 John Levine via mailop pisze:
> While it would be nice to make BIMI available to small organizations
> without costing a lot of money, the question "is entity A allowed to
> show logo X" is very hard even for people, and not amenable to
> authomation. In a few cases where the entity has already paid to put
> the logo in a trademark database it's easier but that sure doesn't
> scale.

There is a very real danger (and this is even predicted in the document
linked in the previous email) that adoption of BIMI by big mail providers
will serve as another "antispam" measure; messages having verified BIMI mark
would be treated by ISPs as more "trustworthy" and "reputable" than the
messages that don't. This would clearly lead to dividing email service in
two categories: "first class" would be an email from businesses that are big
and rich enough that they can afford having their email BIMI certified,
which would give them a kind of "guarantee" for their emails to be delivered
to all the big ISPs - and a "second class" consisiting of all the other
senders, who lack BIMI verification, and thus can only hope to have luck
that their email gets through the filters (which will happen gradually less
and less often).

As it has happened with DMARC, which also in the beginning - as the document
states - was purely optional and meant only for specific, often-phished
domains.

This is a very bad perspective, and BIMI is in my opinion a road straight to
this direction.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Taavi Eomäe via mailop]

On 10/01/2024 19:18, Jaroslaw Rafa via mailop wrote:

As the OP has written, the only ones that may be interested in this may be
marketers. Nobody else needs any logos, avatars etc. displayed alongside the
email headers.


That is certainly an overly bold claim. For a lot of people it makes 
navigating the inbox easier and nicer to look at, it also does make 
phishing a bit harder. We've yet to see how much harder because the 
deployment percentage of good DMARC, not to mention BIMI+VMC, is quite low.



Also, I see no feasible way - neither now nor in the future - to use it any
meaningful way in person-to-person communication, which is the topic OP
asked about, and you seem to have ignored it completely in your answer


It's not really designed for that. It could happen in the form of adding 
the logotype OID to S/MIME certificates, but S/MIME is not that far 
along - the new S/MIME baseline (by the CA/B Forum S/MIME workgroup) is 
really new, and that's just the baseline. Maybe in the future.



Is the goal to make email a closed ecosystem in which only the big players can 
participate?


For context, we at Zone Media have implemented BIMI in our mail server 
and web email client, we have also published a BIMI record with VMC. I'd 
say it's far from being something only "big players" can participate in, 
unless you consider us a big player...


Verifying identity is a difficult problem, maybe it doesn't work out in 
this exact form or way, but it's empirically evident that the problems 
BIMI tries to address are real. Boycotting it for the cost is as silly 
as boycotting entire S/MIME for the same reason.


smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Laurent S. via mailop]

I might have missed something, but wouldn't that be a phisher's wet dream?

Most spammers know very well how to do a mail with valid DMARC. So, now 
they only need to send a valid mail from any throw away cheap domain and 
in their BIMI add the logo of paypal?

I understand it's not great to have to pay for the 
verification/certification, but leaving the door open to abuse is a 
dangerous path to take.

Being on the antispam side, I would hate to have to start implementing 
BIMI spoof checks.

Regards,
Laurent

On 11.01.24 00:05, Louis Laureys via mailop wrote:
>  We decided to keep this because I read that some webmail clients are
>  planning to support BIMI without checking for certificates, or,
>  perhaps, also displaying a little lock icon in the corner of the
>  sender's BIMI-style logo image where certification is verified.
> 
> This is exactly what I have in mind for my client, thanks for publishing your
> logo in an easily accessible and standard way :)
> 
> Groetjes,
> Louis
> 
> 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Randolf Richardson, Postmaster via mailop]

> > We decided to keep this because I read that some webmail clients are
> > planning to support BIMI without checking for certificates, or,
> > perhaps, also displaying a little lock icon in the corner of the
> > sender's BIMI-style logo image where certification is verified.
> 
> This is exactly what I have in mind for my client, thanks for publishing your
> logo in an easily accessible and standard way :)

Excellent!

If you need me to send some test messages, please don't hesitate to 
reach out -- I'll be happy to send a few, or a few dozen, as you 
need, and from a few different domains so you can see what different 
logos look like in an Inbox folder.

> Groetjes,
> Louis
> 
> 
> Op woensdag 10 januari 2024 om 21:58, schreef Randolf Richardson, Postmaster 
> via
> mailop :
> 
> > We looked into it and publish our own default BIMI record even
> > though we didn't pay the enormous amount money required to one of two
> > Certificate Authorities.
> > 
> > If anyone is curious to see what the record looks, use this command:
> > 
> > dig txt default._bimi.inter-corporate.com
> > 
> > The results should include:
> > 
> > ;; ANSWER SECTION:
> > default._bimi.inter-corporate.com. 3600 IN TXT
> > "v=BIMI1; l=https://www.inter-corporate.com/images/logo60bimi-iccns.svg
> > [https://www.inter-corporate.com/images/logo60bimi-iccns.svg]; a=;"
> > 
> > It basically just links to an SVG version of the logo from our main
> > web site (which is also in the same DNS zone).
> > 
> > Note: The "a=" portion normally includes a URI to what's called the
> > "VMC/Assertion record" in the form of a typical .pem file. Ours is
> > blank because we don't have the needed file for this.
> > 
> > We decided to keep this because I read that some webmail clients are
> > planning to support BIMI without checking for certificates, or,
> > perhaps, also displaying a little lock icon in the corner of the
> > sender's BIMI-style logo image where certification is verified.
> > 
> > The BIMI Group provides an online checking tool that displays our
> > logo (just search for "inter-corporate.com" to see ours):
> > 
> > BIMI LookUp & Generator :: Check compliance w/ BIMI standards
> > https://www.bimigroup.org/bimi-generator/
> > [https://www.bimigroup.org/bimi-generator/]
> > 
> > Our logo is shown near the end of the report, and for ours there's
> > an indication that we comply, but there's also this warning:
> > 
> > "Note: While your BIMI record is compliant, it doesn't include a
> > Verified Mark Certificate that may be required by some mailbox
> > providers."
> > 
> > What's missing from BIMI in its current form? The option for mail
> > server oparators to use the same TLS certificates that we're already
> > using for our mail servers (and web servers, and FTP servers, etc.).
> > 
> > It makes less sense to me to involve a different CA just for one
> > tiny little image because then that's more technology that has to be
> > administered, managed, troubleshooted, implemented, etc., and paid
> > for separately. For eMail systems that host mlutiple domains and
> > clients, BIMI is not an attractive option in its current state.
> > 
> > If BIMI is to be taken as an open standard, then it needs to embrace
> > openness so that the TLS certificates issued by all CAs (including
> > commercial and free CAs {e.g., Let's Encrypt}) can contribute to BIMI
> > gaining wider adoption.
> > 
> > The "must be a Registered Trademark" requirement is too expensive
> > for a lot of small businesses. A copyrighted logo is already
> > sufficient to provide legal protections in many scenarios (depending
> > on jurisdiction, etc.), so the bar is too high as it is -- DMCA
> > violation notices should be taken seriously regardless of whether the
> > intellectual property (such as an organization's logo) is protected
> > under copyright, servicemark, or trademark property mechanisms.
> > 
> > Another problem with limiting the scope of intellectual property
> > protection to a Registered Trademark is that trademark applications
> > can also be rejected even though a logo is already copyrighted, and
> > the reasons can vary based on a variety of factors, including
> > different jurisdictional regulations, local and/or national laws that
> > limit free expression, cultural sensitivity policies, delays due to
> > fraudulent disputes submitted by intellectual property trolls, etc.
> > 
> > Also: How does BIMI intend to resolve valid Registered Trademarks
> > from two different countires that look almost the same? Is there a
> > mechanism that will only allow BIMI logos to be displayed in cerrtain
> > countries where said Registered Trademark is protected? Will there
> > be enforcement to make sure all vendors adhere to implementing BIMI
> > correctly in this manner? Or, if a Registered Trademark is only
> > registered in one country, will vendors still be able to display it
> > in other countries? Or will the source be the determining factor (in
> > which 

Re: [mailop] BIMI boycott?

[Randolf Richardson, Postmaster via mailop]

> > Simply, nobody needs this.
> 
> I've been building an email client and actually do fetch avatars and logos to 
> be
> displayed next to emails. I find it helps me visually identify emails easier,
> it's a lot less taxing on the brain than reading sender names or addresses. Of
> course in my case I'm also scraping gravatar and favicons, so it doesn't have
> much to do with BIMI.

I find that helpful too.

Will your eMail client have a free edition option?  If so, please do 
share a link to it here (or eMail me directly) because I'd be happy 
to consider including it in the list of eMail client software options 
that we provide to our users (and also include it in the "Resources" 
section of the Canadian Lumber Cartel web site).

(On PCs, most of our users are either using OutLook, Thunderbird, or 
our webmail option.  A few are using other software, including 
Sylpheed, Pegasus Mail, and some others I don't recall the names of.)

> Just wanted to add that I actually like it for visual clarity. Though I would
> have liked a more general avatar implementation not geared towards businesses.

If you support BIMI with and without the "a=" parameter containing a 
certificate, that would be fantastic.  (You could always indicate 
with a golden lock in the corner of BIMI logos when they do have 
valid certificates specified with the "a=" parameter.)

> Groetjes,
> Louis
> 
> 
> Op woensdag 10 januari 2024 om 18:18, schreef Jaroslaw Rafa via mailop
> :
> 
> > Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> > > The hope is that as BIMI gets more widely adopted, the cost (and
> > > automation) of the logo validation drops. Time will tell.
> > >
> > > Of course, for broader adoption, we also need to progress beyond
> > > trademarks, which have their own cost and timeliness issues. The working
> > > group is leaning heavily into this, as its our top priority to make BIMI
> > > more broadly accessible.
> > >
> > > This covers our technical intent:
> > > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> > [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00] and
> > 
> > The document fails to convincingly answer THE one basic question:
> > 
> > WHY in the hell is such a strange feature needed at all and for whom?
> > 
> > As the OP has written, the only ones that may be interested in this may be
> > marketers. Nobody else needs any logos, avatars etc. displayed alongside the
> > email headers. There is a reason why the early attempt at this - I'm talking
> > about the X-Face header, which you even refer to in this document - never
> > gained any popularity. Simply, nobody needs this. The fact that Gmail
> > implemented in its web client putting up some images alongside email headers
> > (which, by the way, show anything non-default only if the sender is another
> > Gmail user and has a profile picture defined in his/her account) shouldn't
> > be any reference nor guide for designing email applications at all. NOBODY
> > NEEDS THESE IMAGES.
> > 
> > Also, I see no feasible way - neither now nor in the future - to use it any
> > meaningful way in person-to-person communication, which is the topic OP
> > asked about, and you seem to have ignored it completely in your answer. The
> > document you are linking to isn't even trying to address this use case! It
> > speaks all the time about "organizations" or "brands" and their logotypes,
> > like companies or organizations were the only senders of emails. Or maybe
> > this is the actual intent? To make individual people only reicipents of
> > emails, without the ability to send?
> > 
> > In section 3.3 you even predict that BIMI is about to go the same path DMARC
> > went - "DMARC started with limited use to protect heavily phished domains",
> > and now we have arrived to the point when you almost can't send mail to any
> > big mail provider without having DMARC properly set up. You predict that
> > likely the same will happen for BIMI, which means, you won't be able to send
> > mail to any of the "big players" if you don't have BIMI set up. Which *will*
> > cost money - you are also clear about it. Is the goal to make email a closed
> > ecosystem in which only the big players can participate?
> > 
> > This was a bad idea from the beginning (I would even say, a crazy idea) and
> > will still be a bad idea no matter how much work and effort you put into it.
> > So maybe it's better not to waste that effort at all and direct it towards
> > something actually useful.
> > --
> > Regards,
> > Jaroslaw Rafa
> > r...@rafa.eu.org [r...@rafa.eu.org]
> > --
> > "In a million years, when kids go to school, they're gonna know: once there
> > was a Hushpuppy, and she lived with her daddy in the Bathtub."
> > ___
> > mailop mailing list
> > mailop@mailop.org [mailop@mailop.org]
> > https://list.mailop.org/listinfo/mailop
> > [https://list.mailop.org/listinfo/mailop]

Re: [mailop] BIMI boycott?

[John Levine via mailop]

It appears that Andrew C Aitchison via mailop  said:
>X-Face was too far ahead of its time. Enough of the market did not have
>the bandwidth to make it practical, and digitisers/cameras were not 
>readily available.

It was, and it also predated phishing. All of the complication of BIMI
comes from trying to ensure that people only show logos they're
entitled to use.

While it would be nice to make BIMI available to small organizations
without costing a lot of money, the question "is entity A allowed to
show logo X" is very hard even for people, and not amenable to
authomation. In a few cases where the entity has already paid to put
the logo in a trademark database it's easier but that sure doesn't
scale.

There are some extremely complicated cases. For example, there are two
unrelated companies called Merck, one in the U.S. and one in Germany.
(The U.S. one started from confiscated assets of the German one after
WW I.) They have the same name, somewhat similar products, and good
luck getting a straight answer to which one is allowed to display
MERCK where.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Opti Pub via mailop]

+1

On Wed, Jan 10, 2024 at 6:14 PM Louis Laureys via mailop 
wrote:

> We decided to keep this because I read that some webmail clients are
> planning to support BIMI without checking for certificates, or,
> perhaps, also displaying a little lock icon in the corner of the
> sender's BIMI-style logo image where certification is verified.
>
> This is exactly what I have in mind for my client, thanks for publishing
> your logo in an easily accessible and standard way :)
>
> Groetjes,
> Louis
>
>
> Op woensdag 10 januari 2024 om 21:58, schreef Randolf Richardson,
> Postmaster via mailop :
>
> We looked into it and publish our own default BIMI record even
> though we didn't pay the enormous amount money required to one of two
> Certificate Authorities.
>
> If anyone is curious to see what the record looks, use this command:
>
> dig txt default._bimi.inter-corporate.com
>
> The results should include:
>
> ;; ANSWER SECTION:
> default._bimi.inter-corporate.com. 3600 IN TXT
> "v=BIMI1; l=https://www.inter-corporate.com/images/logo60bimi-iccns.svg;
> a=;"
>
> It basically just links to an SVG version of the logo from our main
> web site (which is also in the same DNS zone).
>
> Note: The "a=" portion normally includes a URI to what's called the
> "VMC/Assertion record" in the form of a typical .pem file. Ours is
> blank because we don't have the needed file for this.
>
> We decided to keep this because I read that some webmail clients are
> planning to support BIMI without checking for certificates, or,
> perhaps, also displaying a little lock icon in the corner of the
> sender's BIMI-style logo image where certification is verified.
>
> The BIMI Group provides an online checking tool that displays our
> logo (just search for "inter-corporate.com" to see ours):
>
> BIMI LookUp & Generator :: Check compliance w/ BIMI standards
> https://www.bimigroup.org/bimi-generator/
>
> Our logo is shown near the end of the report, and for ours there's
> an indication that we comply, but there's also this warning:
>
> "Note: While your BIMI record is compliant, it doesn't include a
> Verified Mark Certificate that may be required by some mailbox
> providers."
>
> What's missing from BIMI in its current form? The option for mail
> server oparators to use the same TLS certificates that we're already
> using for our mail servers (and web servers, and FTP servers, etc.).
>
> It makes less sense to me to involve a different CA just for one
> tiny little image because then that's more technology that has to be
> administered, managed, troubleshooted, implemented, etc., and paid
> for separately. For eMail systems that host mlutiple domains and
> clients, BIMI is not an attractive option in its current state.
>
> If BIMI is to be taken as an open standard, then it needs to embrace
> openness so that the TLS certificates issued by all CAs (including
> commercial and free CAs {e.g., Let's Encrypt}) can contribute to BIMI
> gaining wider adoption.
>
> The "must be a Registered Trademark" requirement is too expensive
> for a lot of small businesses. A copyrighted logo is already
> sufficient to provide legal protections in many scenarios (depending
> on jurisdiction, etc.), so the bar is too high as it is -- DMCA
> violation notices should be taken seriously regardless of whether the
> intellectual property (such as an organization's logo) is protected
> under copyright, servicemark, or trademark property mechanisms.
>
> Another problem with limiting the scope of intellectual property
> protection to a Registered Trademark is that trademark applications
> can also be rejected even though a logo is already copyrighted, and
> the reasons can vary based on a variety of factors, including
> different jurisdictional regulations, local and/or national laws that
> limit free expression, cultural sensitivity policies, delays due to
> fraudulent disputes submitted by intellectual property trolls, etc.
>
> Also: How does BIMI intend to resolve valid Registered Trademarks
> from two different countires that look almost the same? Is there a
> mechanism that will only allow BIMI logos to be displayed in cerrtain
> countries where said Registered Trademark is protected? Will there
> be enforcement to make sure all vendors adhere to implementing BIMI
> correctly in this manner? Or, if a Registered Trademark is only
> registered in one country, will vendors still be able to display it
> in other countries? Or will the source be the determining factor (in
> which case, what reliable solution does BIMI propose for a company
> using service provider in some other country to deliver their eMail)?
>
> Keeping things simpler, open, and lowering the bar to be more
> inclusive are, in my opinion, some of the more important factors in
> BIMI's future success. Otherwise, it just looks like an attempt to
> make money (which is how at least some people who've looked into it
> seem to perceive it at present).
>
> (If BIMI doesn't lower the bar, then perhaps someone w

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Louis Laureys via mailop]

> We decided to keep this because I read that some webmail clients are
> planning to support BIMI without checking for certificates, or,
> perhaps, also displaying a little lock icon in the corner of the
> sender's BIMI-style logo image where certification is verified.

This is exactly what I have in mind for my client, thanks for publishing your
logo in an easily accessible and standard way :)

Groetjes,
Louis


Op woensdag 10 januari 2024 om 21:58, schreef Randolf Richardson, Postmaster via
mailop :

> We looked into it and publish our own default BIMI record even
> though we didn't pay the enormous amount money required to one of two
> Certificate Authorities.
> 
> If anyone is curious to see what the record looks, use this command:
> 
> dig txt default._bimi.inter-corporate.com
> 
> The results should include:
> 
> ;; ANSWER SECTION:
> default._bimi.inter-corporate.com. 3600 IN TXT
> "v=BIMI1; l=https://www.inter-corporate.com/images/logo60bimi-iccns.svg
> [https://www.inter-corporate.com/images/logo60bimi-iccns.svg]; a=;"
> 
> It basically just links to an SVG version of the logo from our main
> web site (which is also in the same DNS zone).
> 
> Note: The "a=" portion normally includes a URI to what's called the
> "VMC/Assertion record" in the form of a typical .pem file. Ours is
> blank because we don't have the needed file for this.
> 
> We decided to keep this because I read that some webmail clients are
> planning to support BIMI without checking for certificates, or,
> perhaps, also displaying a little lock icon in the corner of the
> sender's BIMI-style logo image where certification is verified.
> 
> The BIMI Group provides an online checking tool that displays our
> logo (just search for "inter-corporate.com" to see ours):
> 
> BIMI LookUp & Generator :: Check compliance w/ BIMI standards
> https://www.bimigroup.org/bimi-generator/
> [https://www.bimigroup.org/bimi-generator/]
> 
> Our logo is shown near the end of the report, and for ours there's
> an indication that we comply, but there's also this warning:
> 
> "Note: While your BIMI record is compliant, it doesn't include a
> Verified Mark Certificate that may be required by some mailbox
> providers."
> 
> What's missing from BIMI in its current form? The option for mail
> server oparators to use the same TLS certificates that we're already
> using for our mail servers (and web servers, and FTP servers, etc.).
> 
> It makes less sense to me to involve a different CA just for one
> tiny little image because then that's more technology that has to be
> administered, managed, troubleshooted, implemented, etc., and paid
> for separately. For eMail systems that host mlutiple domains and
> clients, BIMI is not an attractive option in its current state.
> 
> If BIMI is to be taken as an open standard, then it needs to embrace
> openness so that the TLS certificates issued by all CAs (including
> commercial and free CAs {e.g., Let's Encrypt}) can contribute to BIMI
> gaining wider adoption.
> 
> The "must be a Registered Trademark" requirement is too expensive
> for a lot of small businesses. A copyrighted logo is already
> sufficient to provide legal protections in many scenarios (depending
> on jurisdiction, etc.), so the bar is too high as it is -- DMCA
> violation notices should be taken seriously regardless of whether the
> intellectual property (such as an organization's logo) is protected
> under copyright, servicemark, or trademark property mechanisms.
> 
> Another problem with limiting the scope of intellectual property
> protection to a Registered Trademark is that trademark applications
> can also be rejected even though a logo is already copyrighted, and
> the reasons can vary based on a variety of factors, including
> different jurisdictional regulations, local and/or national laws that
> limit free expression, cultural sensitivity policies, delays due to
> fraudulent disputes submitted by intellectual property trolls, etc.
> 
> Also: How does BIMI intend to resolve valid Registered Trademarks
> from two different countires that look almost the same? Is there a
> mechanism that will only allow BIMI logos to be displayed in cerrtain
> countries where said Registered Trademark is protected? Will there
> be enforcement to make sure all vendors adhere to implementing BIMI
> correctly in this manner? Or, if a Registered Trademark is only
> registered in one country, will vendors still be able to display it
> in other countries? Or will the source be the determining factor (in
> which case, what reliable solution does BIMI propose for a company
> using service provider in some other country to deliver their eMail)?
> 
> Keeping things simpler, open, and lowering the bar to be more
> inclusive are, in my opinion, some of the more important factors in
> BIMI's future success. Otherwise, it just looks like an attempt to
> make money (which is how at least some people who've looked into it
> seem to perceive it at present).
> 
> (If BIMI doesn

Re: [mailop] BIMI boycott?

[Louis Laureys via mailop]

> Simply, nobody needs this.

I've been building an email client and actually do fetch avatars and logos to be
displayed next to emails. I find it helps me visually identify emails easier,
it's a lot less taxing on the brain than reading sender names or addresses. Of
course in my case I'm also scraping gravatar and favicons, so it doesn't have
much to do with BIMI.

Just wanted to add that I actually like it for visual clarity. Though I would
have liked a more general avatar implementation not geared towards businesses.


Groetjes,
Louis


Op woensdag 10 januari 2024 om 18:18, schreef Jaroslaw Rafa via mailop
:

> Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> > The hope is that as BIMI gets more widely adopted, the cost (and
> > automation) of the logo validation drops. Time will tell.
> >
> > Of course, for broader adoption, we also need to progress beyond
> > trademarks, which have their own cost and timeliness issues. The working
> > group is leaning heavily into this, as its our top priority to make BIMI
> > more broadly accessible.
> >
> > This covers our technical intent:
> > https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00
> [https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00] and
> 
> The document fails to convincingly answer THE one basic question:
> 
> WHY in the hell is such a strange feature needed at all and for whom?
> 
> As the OP has written, the only ones that may be interested in this may be
> marketers. Nobody else needs any logos, avatars etc. displayed alongside the
> email headers. There is a reason why the early attempt at this - I'm talking
> about the X-Face header, which you even refer to in this document - never
> gained any popularity. Simply, nobody needs this. The fact that Gmail
> implemented in its web client putting up some images alongside email headers
> (which, by the way, show anything non-default only if the sender is another
> Gmail user and has a profile picture defined in his/her account) shouldn't
> be any reference nor guide for designing email applications at all. NOBODY
> NEEDS THESE IMAGES.
> 
> Also, I see no feasible way - neither now nor in the future - to use it any
> meaningful way in person-to-person communication, which is the topic OP
> asked about, and you seem to have ignored it completely in your answer. The
> document you are linking to isn't even trying to address this use case! It
> speaks all the time about "organizations" or "brands" and their logotypes,
> like companies or organizations were the only senders of emails. Or maybe
> this is the actual intent? To make individual people only reicipents of
> emails, without the ability to send?
> 
> In section 3.3 you even predict that BIMI is about to go the same path DMARC
> went - "DMARC started with limited use to protect heavily phished domains",
> and now we have arrived to the point when you almost can't send mail to any
> big mail provider without having DMARC properly set up. You predict that
> likely the same will happen for BIMI, which means, you won't be able to send
> mail to any of the "big players" if you don't have BIMI set up. Which *will*
> cost money - you are also clear about it. Is the goal to make email a closed
> ecosystem in which only the big players can participate?
> 
> This was a bad idea from the beginning (I would even say, a crazy idea) and
> will still be a bad idea no matter how much work and effort you put into it.
> So maybe it's better not to waste that effort at all and direct it towards
> something actually useful.
> --
> Regards,
> Jaroslaw Rafa
> r...@rafa.eu.org [r...@rafa.eu.org]
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
> ___
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Brett Schenker via mailop]

Since DMARC is now required by Google and Yahoo for bulk sending, it kind
of makes BIMI not as needed. I'm still not sure what BIMI solves that
enforcing authentication doesn't.

On Wed, Jan 10, 2024 at 3:44 PM Gellner, Oliver via mailop <
mailop@mailop.org> wrote:

>
> > On 10.01.2024 at 17:21 Olga Fischer via mailop wrote:
> >
> > Many bigger mailers are blogging about BIMI.
> > As far as I see its exclusively for brands.
> > It has 2 big barriers for entry:
> > - Expensive bespoke cert oids
> > - Registered trademark logos
> >
> > As from my perspective of independent mailing between humans: I fear
> this might be not just a carrot for doing DMARC, but also making
> independent mailers less credible in the UX of mainstream mailer users.
>
> Carrot or not, BIMI can actually be a good incentive to increase the
> adoption of DMARC.
> For ESPs a widespread usage of DMARC is a welcome addition to their
> filtering process, as it makes the impersonation of foreign domains more
> difficult. At the same time setting up DMARC on the sender side can be a
> lot of work, especially for large enterprises, which have hundreds of
> sources where emails are being generated or sent. Finding and adding proper
> authentication to all of them before being able to enable a DMARC reject
> policy requires a non-negligible amount of resources. If you can present a
> direct and clear benefit in return („our logo is going to be displayed next
> to our messages“), the management might be more willing to grant approval
> for it.
>
> I don’t see the fact that BIMI is currently not available to single users
> as a real problem, as their identity is usually not used in phishing
> campaigns anyway. Nobody sends phishing messages that try to impersonate
> Bob the builder.
> Neither SPF, nor DKIM nor DMARC are suitable to identify single users, so
> BIMI which builds upon them cannot magically add this feature. If you want
> to authenticate single users there’s S/MIME.
>
> > Do you have input on how non-marketing mailers deal with this?
> > Because obviously its for brand-logos, as in marketing mails. Not for
> user 2 user.
>
> Not at all. BIMI is about DMARC authenticated emails. Their content
> doesn’t matter. If I‘d send you a personal email off-list and you use a MUA
> that supports BIMI a logo will be displayed next to it.
>
> > Its also may be yet another reader-engagement tracker. Why do those
> things always have to be out of band.
>
> Well, there’s no automated way to connect a logo to a domain. The BIMI
> group has decided to build upon the work of trademark offices to connect
> logos to companies and then set up a manual verification process to connect
> the company to a domain. There might be other ways to do this, but you
> cannot just use DNS or a message header to link a logo to a domain as this
> would be trivial to exploit.
>
> Either way, BIMI is not suitable for reader tracking as you cannot provide
> different logo URIs for each recipient.
>
> —
> BR Oliver
>
> 
>
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten.
> Informationen unter anderem zu den konkreten Datenverarbeitungen,
> Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer
> Datenschutzbeauftragten finden Sie hier<
> https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832
> >.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>


-- 
Brett Schenker
Man of Many Things, Including
5B Consulting - http://www.5bconsulting.com
Graphic Policy - http://www.graphicpolicy.com

Twitter - http://twitter.com/bhschenker
LinkedIn - http://www.linkedin.com/in/brettschenker
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Randolf Richardson, Postmaster via mailop]

We looked into it and publish our own default BIMI record even 
though we didn't pay the enormous amount money required to one of two 
Certificate Authorities.

If anyone is curious to see what the record looks, use this command:

dig txt default._bimi.inter-corporate.com

The results should include:

;; ANSWER SECTION:
default._bimi.inter-corporate.com. 3600 IN TXT
"v=BIMI1; 
l=https://www.inter-corporate.com/images/logo60bimi-iccns.svg; a=;"

It basically just links to an SVG version of the logo from our main 
web site (which is also in the same DNS zone).

Note:  The "a=" portion normally includes a URI to what's called the 
"VMC/Assertion record" in the form of a typical .pem file.  Ours is 
blank because we don't have the needed file for this.

We decided to keep this because I read that some webmail clients are 
planning to support BIMI without checking for certificates, or, 
perhaps, also displaying a little lock icon in the corner of the 
sender's BIMI-style logo image where certification is verified.

The BIMI Group provides an online checking tool that displays our 
logo (just search for "inter-corporate.com" to see ours):

BIMI LookUp & Generator :: Check compliance w/ BIMI standards
https://www.bimigroup.org/bimi-generator/

Our logo is shown near the end of the report, and for ours there's 
an indication that we comply, but there's also this warning:

"Note: While your BIMI record is compliant, it doesn't include 
a 
Verified Mark Certificate that may be required by some mailbox 
providers."

What's missing from BIMI in its current form?  The option for mail 
server oparators to use the same TLS certificates that we're already 
using for our mail servers (and web servers, and FTP servers, etc.).

It makes less sense to me to involve a different CA just for one 
tiny little image because then that's more technology that has to be 
administered, managed, troubleshooted, implemented, etc., and paid 
for separately.  For eMail systems that host mlutiple domains and 
clients, BIMI is not an attractive option in its current state.

If BIMI is to be taken as an open standard, then it needs to embrace 
openness so that the TLS certificates issued by all CAs (including 
commercial and free CAs {e.g., Let's Encrypt}) can contribute to BIMI 
gaining wider adoption.

The "must be a Registered Trademark" requirement is too expensive 
for a lot of small businesses.  A copyrighted logo is already 
sufficient to provide legal protections in many scenarios (depending 
on jurisdiction, etc.), so the bar is too high as it is -- DMCA 
violation notices should be taken seriously regardless of whether the 
intellectual property (such as an organization's logo) is protected 
under copyright, servicemark, or trademark property mechanisms.

Another problem with limiting the scope of intellectual property 
protection to a Registered Trademark is that trademark applications 
can also be rejected even though a logo is already copyrighted, and 
the reasons can vary based on a variety of factors, including 
different jurisdictional regulations, local and/or national laws that 
limit free expression, cultural sensitivity policies, delays due to 
fraudulent disputes submitted by intellectual property trolls, etc.

Also:  How does BIMI intend to resolve valid Registered Trademarks 
from two different countires that look almost the same?  Is there a 
mechanism that will only allow BIMI logos to be displayed in cerrtain 
countries where said Registered Trademark is protected?  Will there 
be enforcement to make sure all vendors adhere to implementing BIMI 
correctly in this manner?  Or, if a Registered Trademark is only 
registered in one country, will vendors still be able to display it 
in other countries?  Or will the source be the determining factor (in 
which case, what reliable solution does BIMI propose for a company 
using service provider in some other country to deliver their eMail)?

Keeping things simpler, open, and lowering the bar to be more 
inclusive are, in my opinion, some of the more important factors in 
BIMI's future success.  Otherwise, it just looks like an attempt to 
make money (which is how at least some people who've looked into it 
seem to perceive it at present).

(If BIMI doesn't lower the bar, then perhaps someone will be 
motivated to create an alternative standard that is simpler, open, 
and more inclusive.)

> Hi mailops,
> 
> I am new here because I want to collect some opinion.
> 
> Many bigger mailers are blogging about BIMI.
> As far as I see its exclusively for brands.
> It has 2 big barriers for entry:
> - Expensive bespoke cert oids
> - Registered trademark logos
> 
> As from my perspective of independent mailing between humans: I fear this 
> might be

Re: [mailop] BIMI boycott?

[Gellner, Oliver via mailop]

> On 10.01.2024 at 17:21 Olga Fischer via mailop wrote:
>
> Many bigger mailers are blogging about BIMI.
> As far as I see its exclusively for brands.
> It has 2 big barriers for entry:
> - Expensive bespoke cert oids
> - Registered trademark logos
>
> As from my perspective of independent mailing between humans: I fear this 
> might be not just a carrot for doing DMARC, but also making independent 
> mailers less credible in the UX of mainstream mailer users.

Carrot or not, BIMI can actually be a good incentive to increase the adoption 
of DMARC.
For ESPs a widespread usage of DMARC is a welcome addition to their filtering 
process, as it makes the impersonation of foreign domains more difficult. At 
the same time setting up DMARC on the sender side can be a lot of work, 
especially for large enterprises, which have hundreds of sources where emails 
are being generated or sent. Finding and adding proper authentication to all of 
them before being able to enable a DMARC reject policy requires a 
non-negligible amount of resources. If you can present a direct and clear 
benefit in return („our logo is going to be displayed next to our messages“), 
the management might be more willing to grant approval for it.

I don’t see the fact that BIMI is currently not available to single users as a 
real problem, as their identity is usually not used in phishing campaigns 
anyway. Nobody sends phishing messages that try to impersonate Bob the builder.
Neither SPF, nor DKIM nor DMARC are suitable to identify single users, so BIMI 
which builds upon them cannot magically add this feature. If you want to 
authenticate single users there’s S/MIME.

> Do you have input on how non-marketing mailers deal with this?
> Because obviously its for brand-logos, as in marketing mails. Not for user 2 
> user.

Not at all. BIMI is about DMARC authenticated emails. Their content doesn’t 
matter. If I‘d send you a personal email off-list and you use a MUA that 
supports BIMI a logo will be displayed next to it.

> Its also may be yet another reader-engagement tracker. Why do those things 
> always have to be out of band.

Well, there’s no automated way to connect a logo to a domain. The BIMI group 
has decided to build upon the work of trademark offices to connect logos to 
companies and then set up a manual verification process to connect the company 
to a domain. There might be other ways to do this, but you cannot just use DNS 
or a message header to link a logo to a domain as this would be trivial to 
exploit.

Either way, BIMI is not suitable for reader tracking as you cannot provide 
different logo URIs for each recipient.

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Andrew C Aitchison via mailop]

On Wed, 10 Jan 2024, Jaroslaw Rafa via mailop wrote:


As the OP has written, the only ones that may be interested in this may be
marketers. Nobody else needs any logos, avatars etc. displayed alongside the
email headers. There is a reason why the early attempt at this - I'm talking
about the X-Face header, which you even refer to in this document - never
gained any popularity. Simply, nobody needs this. The fact that Gmail
implemented in its web client putting up some images alongside email headers
(which, by the way, show anything non-default only if the sender is another
Gmail user and has a profile picture defined in his/her account) shouldn't
be any reference nor guide for designing email applications at all. NOBODY
NEEDS THESE IMAGES.


X-Face was too far ahead of its time. Enough of the market did not have
the bandwidth to make it practical, and digitisers/cameras were not 
readily available.


Today many discussion sites do have avatars. When I look at the discussion
of a bug on github, they do help me to see who made which comment.
key-phrases: visual meta-data, clues to context.

*I* would be interested in avatars with emails, if they didn't have lots 
of costs that far exceed those of the message itself.


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Andrew C Aitchison via mailop]

On Wed, 10 Jan 2024, Olga Fischer via mailop wrote:


Hi mailops,

I am new here because I want to collect some opinion.

Many bigger mailers are blogging about BIMI.
As far as I see its exclusively for brands.
It has 2 big barriers for entry:
- Expensive bespoke cert oids
- Registered trademark logos

As from my perspective of independent mailing between humans: I fear this might 
be not just a carrot for doing DMARC, but also making independent mailers less 
credible in the UX of mainstream mailer users.

Do you have input on how non-marketing mailers deal with this?
Because obviously its for brand-logos, as in marketing mails. Not for user 2 
user.
How will common platforms show user2user?
Will they use platform logos? No logos?

It seems infeasible to do the logo-ing per user.

Can we influence the mailing world to use the standard differently?
Like accepting BIMI logos only depending on valid bog standard cert and DMARC, 
boycotting the moneygrab scheme?

Its also may be yet another reader-engagement tracker. Why do those things 
always have to be out of band.

I wish y'all a happy new year and good mailing weathers!

Olga


I am also interested in user 2 user email and have little interest in BIMI.

My biggest problem is that showing or not showing a logo signals
one bit of information, but even if the technology is perfect,
there are three possibilities that need to be shoe-horned into it,
otherwise someone will be upset.
If a web-mail or MUA displays the logo, does that indicate that it verified
that the sender was entitled to use the logo, or that it failed to confirm
that the sender was not entitled to use the logo ?
It could signal the middle, "I don't know", case by displaying the logo
in monochrome ... except that some logos are monochrome, some people are 
colour-blind, ...


I am confident that displaying a logo will be taken as making a promise 
that cannot be kept.


My other concerns include:

My phone screen has a couple of million pixels, but not enough square inches
for me to comfortably read an email.
Taking space for the logo will make it even harder to read the message
- unless BIMI saves organisations from putting the logo in the HTML version 
of the email (which would have some value).


As a user of Alpine, a text-base mail reader, I will never see the "logo"
without taking extra effort.

I fear that some mailbox operators will make assumptions about what is
valid that are subtlety different from each other or from reality, so
it may require unreasonable effort to make an email satisfy both the
mailbox operators and best practice (just as we have two sender
addresses that may or may not appear when a message is listed or
displayed, so we now have SPF and DKIM verifying different things).

At the same time I fear that there will be short-cuts that allow phishers 
to fake the logo on enough mailbox services to be profitable.


I have just read the bug for BIMI to be added to Thunderbird
  https://bugzilla.mozilla.org/show_bug.cgi?id=1670078
Some people there are advocating that Thunderbird should display the logo
even if no Visual Mark Certificate can be verified.
If that is a common view amongst those who provide MUAs and web-mailers,
users will rightly be confused over whether the logo means anything.

Even ignoring the matter of fees, the ability of the marketing
department to get the branding into everyone's email will be somewhat
independent of the ability of the technical team to correctly do
everything else to make email secure and trustworthy.
I believe this even though one of the aims of BIMI is to encourage
correct use of SPF/DKIM/DMARC.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Jaroslaw Rafa via mailop]

Dnia 10.01.2024 o godz. 11:32:36 Seth Blank via mailop pisze:
> The hope is that as BIMI gets more widely adopted, the cost (and
> automation) of the logo validation drops. Time will tell.
> 
> Of course, for broader adoption, we also need to progress beyond
> trademarks, which have their own cost and timeliness issues. The working
> group is leaning heavily into this, as its our top priority to make BIMI
> more broadly accessible.
> 
> This covers our technical intent:
> https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00 and

The document fails to convincingly answer THE one basic question:

WHY in the hell is such a strange feature needed at all and for whom?

As the OP has written, the only ones that may be interested in this may be
marketers. Nobody else needs any logos, avatars etc. displayed alongside the
email headers. There is a reason why the early attempt at this - I'm talking
about the X-Face header, which you even refer to in this document - never
gained any popularity. Simply, nobody needs this. The fact that Gmail
implemented in its web client putting up some images alongside email headers
(which, by the way, show anything non-default only if the sender is another
Gmail user and has a profile picture defined in his/her account) shouldn't
be any reference nor guide for designing email applications at all. NOBODY
NEEDS THESE IMAGES.

Also, I see no feasible way - neither now nor in the future - to use it any
meaningful way in person-to-person communication, which is the topic OP
asked about, and you seem to have ignored it completely in your answer. The
document you are linking to isn't even trying to address this use case! It
speaks all the time about "organizations" or "brands" and their logotypes,
like companies or organizations were the only senders of emails. Or maybe
this is the actual intent? To make individual people only reicipents of
emails, without the ability to send?

In section 3.3 you even predict that BIMI is about to go the same path DMARC
went - "DMARC started with limited use to protect heavily phished domains",
and now we have arrived to the point when you almost can't send mail to any
big mail provider without having DMARC properly set up. You predict that
likely the same will happen for BIMI, which means, you won't be able to send
mail to any of the "big players" if you don't have BIMI set up. Which *will*
cost money - you are also clear about it. Is the goal to make email a closed
ecosystem in which only the big players can participate?

This was a bad idea from the beginning (I would even say, a crazy idea) and
will still be a bad idea no matter how much work and effort you put into it.
So maybe it's better not to waste that effort at all and direct it towards
something actually useful.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI boycott?

[Seth Blank via mailop]

It's not a money grabbing scheme. Validation of the logo requires human
effort today, so there's a real cost involved. It's also relatively new, so
at its most expensive.

The hope is that as BIMI gets more widely adopted, the cost (and
automation) of the logo validation drops. Time will tell.

Of course, for broader adoption, we also need to progress beyond
trademarks, which have their own cost and timeliness issues. The working
group is leaning heavily into this, as its our top priority to make BIMI
more broadly accessible.

This covers our technical intent:
https://datatracker.ietf.org/doc/html/draft-bkl-bimi-overview-00 and
there's also a lot of content on bimigroup.org.

Seth


On Wed, Jan 10, 2024 at 11:19 AM Olga Fischer via mailop 
wrote:

> Hi mailops,
>
> I am new here because I want to collect some opinion.
>
> Many bigger mailers are blogging about BIMI.
> As far as I see its exclusively for brands.
> It has 2 big barriers for entry:
> - Expensive bespoke cert oids
> - Registered trademark logos
>
> As from my perspective of independent mailing between humans: I fear this
> might be not just a carrot for doing DMARC, but also making independent
> mailers less credible in the UX of mainstream mailer users.
>
> Do you have input on how non-marketing mailers deal with this?
> Because obviously its for brand-logos, as in marketing mails. Not for user
> 2 user.
> How will common platforms show user2user?
> Will they use platform logos? No logos?
>
> It seems infeasible to do the logo-ing per user.
>
> Can we influence the mailing world to use the standard differently?
> Like accepting BIMI logos only depending on valid bog standard cert and
> DMARC, boycotting the moneygrab scheme?
>
> Its also may be yet another reader-engagement tracker. Why do those things
> always have to be out of band.
>
> I wish y'all a happy new year and good mailing weathers!
>
> Olga
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>


-- 

*Seth Blank * | Chief Technology Officer
*e:* s...@valimail.com
*p:*

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] BIMI boycott?

[Olga Fischer via mailop]

Hi mailops,

I am new here because I want to collect some opinion.

Many bigger mailers are blogging about BIMI.
As far as I see its exclusively for brands.
It has 2 big barriers for entry:
- Expensive bespoke cert oids
- Registered trademark logos

As from my perspective of independent mailing between humans: I fear this might 
be not just a carrot for doing DMARC, but also making independent mailers less 
credible in the UX of mainstream mailer users.

Do you have input on how non-marketing mailers deal with this?
Because obviously its for brand-logos, as in marketing mails. Not for user 2 
user.
How will common platforms show user2user?
Will they use platform logos? No logos?

It seems infeasible to do the logo-ing per user.

Can we influence the mailing world to use the standard differently?
Like accepting BIMI logos only depending on valid bog standard cert and DMARC, 
boycotting the moneygrab scheme?

Its also may be yet another reader-engagement tracker. Why do those things 
always have to be out of band.

I wish y'all a happy new year and good mailing weathers!

Olga
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI status and interoperation possibilities

[Mary via mailop]

The moment I read that BIMI requires payment, my mind went to the paid SSL 
certificates and how its all about scamming normal people for money they 
shouldn't pay in the first place.

Once it becomes free (for example if Let's Encrypt starts supporting BIMI) they 
I'll consider it, otherwise no thanks :)



On Mon, 8 Nov 2021 20:54:00 -0500 Tom Kulzer via mailop  
wrote:

> Emails from our blog come from the aweber.com domain which uses BIMI and is 
> VMC authenticated.
> 
> https://blog.aweber.com/
> 
> -Tom
> 
> 
> > On Nov 1, 2021, at 12:26 PM, Vsevolod Stakhov via mailop 
> >  wrote:
> > 
> > Hello Al,
> > 
> > That works like a charm, thank you!
> > 
> > [2021-11-01T16:09:24.566Z INFO  bimi_agent::mini_pki] added trusted CA
> > cert with fp
> > 504386c9ee8932fecc95fade427f69c3e2534b7310489e300fee448e33c46b42
> > [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] got valid pem for
> > domain cnn.com
> > [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verify domain cnn.com
> > against pattern cnn.com
> > [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified name for
> > domain cnn.com
> > [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified expiry for
> > domain cnn.com
> > [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified key usage for
> > domain cnn.com
> > [2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] verified PKI for
> > domain cnn.com
> > [2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] got data url for cnn.com
> > [2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] got data url for
> > data:image/svg+xml;base64,H4...
> > [2021-11-01T16:09:24.569Z INFO  bimi_agent::handler] processed
> > certificate for cnn.com
> > 
> > They use the same digicert chain and are hosted by Valimail.
> > 
> > For now, I'm interested in VMC based BIMI records as I have totally no
> > ideas about what to do with non-VMC as any malicious actor can send
> > their email and publish, e.g. Google logo for any possible domain once
> > it has valid DMARC as well.
> > 
> > I could use our DMARC_WHITELIST list for that purposes but I need to
> > think about it...
> > 
> > VMC is hard and expensive to obtain indeed but it provides at least some
> > level of trust.
> > 
> > Presumably we should use other consensus and authority system for this
> > stuff nowadays aside of PKI with CA who could clearly do bad things for
> > profit (like they did many times in the past).
> > 
> > I would also like to say thanks to other people who have replied as I
> > don't want to amplify ML traffic by individual messages solely with this
> > purpose :)
> > 
> > On 01/11/2021 15:40, Al Iverson wrote:  
> >> CNN has implemented VMC:
> >> https://www.digicert.com/news/pr/digicert-issues-certificate-to-cnn-for-bimi-email-standard/
> >> https://xnnd.com/dns.cgi?t=bimi&d=cnn.com
> >> Their newsletters would be good emails to sign up for, for testing
> >> your BIMI implementation:
> >> https://www.cnn.com/newsletters
> >> 
> >> If you want mail from a non-VMC using sender that publishes a BIMI
> >> record, perhaps wish.com?
> >> https://xnnd.com/dns.cgi?t=bimi&d=wish.com&m=
> >> https://www.wish.com/
> >> 
> >> Hope that helps!
> >> 
> >> Cheers,
> >> Al Iverson
> >> 
> >> On Mon, Nov 1, 2021 at 10:08 AM Vsevolod Stakhov via mailop
> >>  wrote:  
> >>> 
> >>> Hello,
> >>> 
> >>> I'm currently building a prototype of BIMI agent in Rspamd as per this
> >>> Github issue: https://github.com/rspamd/rspamd/issues/3935
> >>> 
> >>> However, this technology seems to be very immature and only fragmentary
> >>> documented in some aspects. I was able to find just one (!) valid VMC
> >>> for `valimail.com` domain in the wild. Other participants of the BIMI WG
> >>> either do not publish BIMI records (e.g. Google), provide just an image
> >>> without VMC (e.g. Proofpoint) or even publish an expired VMC (e.g.
> >>> Paypal)...
> >>> 
> >>> Furthermore, even a valid VMC from Valimail does not include any
> >>> system-wide trusted CA apart of the specific VMC CA that is not trusted
> >>> by system nor cross-signed by other DigiCert CAs (so I had to implement
> >>> my own PKI based on trusted fingerprints which is acceptable but not
> >>> pleasant).
> >>> 
> >>> For now, I'm looking for some other options to test BIMI and one thing
> >>> I'm missing critically is an example of an email that could be validated
> >>> by DMARC for the domain that have a valid BIMI record (either normal but
> >>> preferably with VMC). So I would appreciate any help in getting such
> >>> messages, e.g. if anyone who can send email on behalf of Valimail.com
> >>> domain could send me a message with any content to my personal email.
> >>> 
> >>> I would also appreciate any information about where to get further
> >>> details without signing any sort of bogus agreements which I personally
> >>> will never ever sign (as I have a strong belief that all Internet
> >>> standards must be open for the general public).
> >>> ___
> >>> 

Re: [mailop] BIMI status and interoperation possibilities

[Tom Kulzer via mailop]

Emails from our blog come from the aweber.com domain which uses BIMI and is VMC 
authenticated.

https://blog.aweber.com/

-Tom


> On Nov 1, 2021, at 12:26 PM, Vsevolod Stakhov via mailop  
> wrote:
> 
> Hello Al,
> 
> That works like a charm, thank you!
> 
> [2021-11-01T16:09:24.566Z INFO  bimi_agent::mini_pki] added trusted CA
> cert with fp
> 504386c9ee8932fecc95fade427f69c3e2534b7310489e300fee448e33c46b42
> [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] got valid pem for
> domain cnn.com
> [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verify domain cnn.com
> against pattern cnn.com
> [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified name for
> domain cnn.com
> [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified expiry for
> domain cnn.com
> [2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified key usage for
> domain cnn.com
> [2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] verified PKI for
> domain cnn.com
> [2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] got data url for cnn.com
> [2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] got data url for
> data:image/svg+xml;base64,H4...
> [2021-11-01T16:09:24.569Z INFO  bimi_agent::handler] processed
> certificate for cnn.com
> 
> They use the same digicert chain and are hosted by Valimail.
> 
> For now, I'm interested in VMC based BIMI records as I have totally no
> ideas about what to do with non-VMC as any malicious actor can send
> their email and publish, e.g. Google logo for any possible domain once
> it has valid DMARC as well.
> 
> I could use our DMARC_WHITELIST list for that purposes but I need to
> think about it...
> 
> VMC is hard and expensive to obtain indeed but it provides at least some
> level of trust.
> 
> Presumably we should use other consensus and authority system for this
> stuff nowadays aside of PKI with CA who could clearly do bad things for
> profit (like they did many times in the past).
> 
> I would also like to say thanks to other people who have replied as I
> don't want to amplify ML traffic by individual messages solely with this
> purpose :)
> 
> On 01/11/2021 15:40, Al Iverson wrote:
>> CNN has implemented VMC:
>> https://www.digicert.com/news/pr/digicert-issues-certificate-to-cnn-for-bimi-email-standard/
>> https://xnnd.com/dns.cgi?t=bimi&d=cnn.com
>> Their newsletters would be good emails to sign up for, for testing
>> your BIMI implementation:
>> https://www.cnn.com/newsletters
>> 
>> If you want mail from a non-VMC using sender that publishes a BIMI
>> record, perhaps wish.com?
>> https://xnnd.com/dns.cgi?t=bimi&d=wish.com&m=
>> https://www.wish.com/
>> 
>> Hope that helps!
>> 
>> Cheers,
>> Al Iverson
>> 
>> On Mon, Nov 1, 2021 at 10:08 AM Vsevolod Stakhov via mailop
>>  wrote:
>>> 
>>> Hello,
>>> 
>>> I'm currently building a prototype of BIMI agent in Rspamd as per this
>>> Github issue: https://github.com/rspamd/rspamd/issues/3935
>>> 
>>> However, this technology seems to be very immature and only fragmentary
>>> documented in some aspects. I was able to find just one (!) valid VMC
>>> for `valimail.com` domain in the wild. Other participants of the BIMI WG
>>> either do not publish BIMI records (e.g. Google), provide just an image
>>> without VMC (e.g. Proofpoint) or even publish an expired VMC (e.g.
>>> Paypal)...
>>> 
>>> Furthermore, even a valid VMC from Valimail does not include any
>>> system-wide trusted CA apart of the specific VMC CA that is not trusted
>>> by system nor cross-signed by other DigiCert CAs (so I had to implement
>>> my own PKI based on trusted fingerprints which is acceptable but not
>>> pleasant).
>>> 
>>> For now, I'm looking for some other options to test BIMI and one thing
>>> I'm missing critically is an example of an email that could be validated
>>> by DMARC for the domain that have a valid BIMI record (either normal but
>>> preferably with VMC). So I would appreciate any help in getting such
>>> messages, e.g. if anyone who can send email on behalf of Valimail.com
>>> domain could send me a message with any content to my personal email.
>>> 
>>> I would also appreciate any information about where to get further
>>> details without signing any sort of bogus agreements which I personally
>>> will never ever sign (as I have a strong belief that all Internet
>>> standards must be open for the general public).
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> https://list.mailop.org/listinfo/mailop
>> 
>> 
>> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI status and interoperation possibilities

[Vsevolod Stakhov via mailop]

Hello Al,

That works like a charm, thank you!

[2021-11-01T16:09:24.566Z INFO  bimi_agent::mini_pki] added trusted CA
cert with fp
504386c9ee8932fecc95fade427f69c3e2534b7310489e300fee448e33c46b42
[2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] got valid pem for
domain cnn.com
[2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verify domain cnn.com
against pattern cnn.com
[2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified name for
domain cnn.com
[2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified expiry for
domain cnn.com
[2021-11-01T16:09:24.567Z DEBUG bimi_agent::cert] verified key usage for
domain cnn.com
[2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] verified PKI for
domain cnn.com
[2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] got data url for cnn.com
[2021-11-01T16:09:24.568Z DEBUG bimi_agent::cert] got data url for
data:image/svg+xml;base64,H4...
[2021-11-01T16:09:24.569Z INFO  bimi_agent::handler] processed
certificate for cnn.com

They use the same digicert chain and are hosted by Valimail.

For now, I'm interested in VMC based BIMI records as I have totally no
ideas about what to do with non-VMC as any malicious actor can send
their email and publish, e.g. Google logo for any possible domain once
it has valid DMARC as well.

I could use our DMARC_WHITELIST list for that purposes but I need to
think about it...

VMC is hard and expensive to obtain indeed but it provides at least some
level of trust.

Presumably we should use other consensus and authority system for this
stuff nowadays aside of PKI with CA who could clearly do bad things for
profit (like they did many times in the past).

I would also like to say thanks to other people who have replied as I
don't want to amplify ML traffic by individual messages solely with this
purpose :)

On 01/11/2021 15:40, Al Iverson wrote:
> CNN has implemented VMC:
> https://www.digicert.com/news/pr/digicert-issues-certificate-to-cnn-for-bimi-email-standard/
> https://xnnd.com/dns.cgi?t=bimi&d=cnn.com
> Their newsletters would be good emails to sign up for, for testing
> your BIMI implementation:
> https://www.cnn.com/newsletters
> 
> If you want mail from a non-VMC using sender that publishes a BIMI
> record, perhaps wish.com?
> https://xnnd.com/dns.cgi?t=bimi&d=wish.com&m=
> https://www.wish.com/
> 
> Hope that helps!
> 
> Cheers,
> Al Iverson
> 
> On Mon, Nov 1, 2021 at 10:08 AM Vsevolod Stakhov via mailop
>  wrote:
>>
>> Hello,
>>
>> I'm currently building a prototype of BIMI agent in Rspamd as per this
>> Github issue: https://github.com/rspamd/rspamd/issues/3935
>>
>> However, this technology seems to be very immature and only fragmentary
>> documented in some aspects. I was able to find just one (!) valid VMC
>> for `valimail.com` domain in the wild. Other participants of the BIMI WG
>> either do not publish BIMI records (e.g. Google), provide just an image
>> without VMC (e.g. Proofpoint) or even publish an expired VMC (e.g.
>> Paypal)...
>>
>> Furthermore, even a valid VMC from Valimail does not include any
>> system-wide trusted CA apart of the specific VMC CA that is not trusted
>> by system nor cross-signed by other DigiCert CAs (so I had to implement
>> my own PKI based on trusted fingerprints which is acceptable but not
>> pleasant).
>>
>> For now, I'm looking for some other options to test BIMI and one thing
>> I'm missing critically is an example of an email that could be validated
>> by DMARC for the domain that have a valid BIMI record (either normal but
>> preferably with VMC). So I would appreciate any help in getting such
>> messages, e.g. if anyone who can send email on behalf of Valimail.com
>> domain could send me a message with any content to my personal email.
>>
>> I would also appreciate any information about where to get further
>> details without signing any sort of bogus agreements which I personally
>> will never ever sign (as I have a strong belief that all Internet
>> standards must be open for the general public).
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
> 
> 
> 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI status and interoperation possibilities

[Guillaume Tournat via mailop]

BIMI: I found the idea not bad until it was necessary to pay dearly for 
a certificate


I have SPF, DKIM, DMARC and BIMI record for my domain.

This is checkable on: 
https://mxtoolbox.com/SuperTool.aspx?action=bimi%3aironie.org&run=toolpage


Hope this helps


Le 01/11/2021 à 16:03, Vsevolod Stakhov via mailop a écrit :

Hello,

I'm currently building a prototype of BIMI agent in Rspamd as per this
Github issue: https://github.com/rspamd/rspamd/issues/3935

However, this technology seems to be very immature and only fragmentary
documented in some aspects. I was able to find just one (!) valid VMC
for `valimail.com` domain in the wild. Other participants of the BIMI WG
either do not publish BIMI records (e.g. Google), provide just an image
without VMC (e.g. Proofpoint) or even publish an expired VMC (e.g.
Paypal)...

Furthermore, even a valid VMC from Valimail does not include any
system-wide trusted CA apart of the specific VMC CA that is not trusted
by system nor cross-signed by other DigiCert CAs (so I had to implement
my own PKI based on trusted fingerprints which is acceptable but not
pleasant).

For now, I'm looking for some other options to test BIMI and one thing
I'm missing critically is an example of an email that could be validated
by DMARC for the domain that have a valid BIMI record (either normal but
preferably with VMC). So I would appreciate any help in getting such
messages, e.g. if anyone who can send email on behalf of Valimail.com
domain could send me a message with any content to my personal email.

I would also appreciate any information about where to get further
details without signing any sort of bogus agreements which I personally
will never ever sign (as I have a strong belief that all Internet
standards must be open for the general public).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI status and interoperation possibilities

[Al Iverson via mailop]

CNN has implemented VMC:
https://www.digicert.com/news/pr/digicert-issues-certificate-to-cnn-for-bimi-email-standard/
https://xnnd.com/dns.cgi?t=bimi&d=cnn.com
Their newsletters would be good emails to sign up for, for testing
your BIMI implementation:
https://www.cnn.com/newsletters

If you want mail from a non-VMC using sender that publishes a BIMI
record, perhaps wish.com?
https://xnnd.com/dns.cgi?t=bimi&d=wish.com&m=
https://www.wish.com/

Hope that helps!

Cheers,
Al Iverson

On Mon, Nov 1, 2021 at 10:08 AM Vsevolod Stakhov via mailop
 wrote:
>
> Hello,
>
> I'm currently building a prototype of BIMI agent in Rspamd as per this
> Github issue: https://github.com/rspamd/rspamd/issues/3935
>
> However, this technology seems to be very immature and only fragmentary
> documented in some aspects. I was able to find just one (!) valid VMC
> for `valimail.com` domain in the wild. Other participants of the BIMI WG
> either do not publish BIMI records (e.g. Google), provide just an image
> without VMC (e.g. Proofpoint) or even publish an expired VMC (e.g.
> Paypal)...
>
> Furthermore, even a valid VMC from Valimail does not include any
> system-wide trusted CA apart of the specific VMC CA that is not trusted
> by system nor cross-signed by other DigiCert CAs (so I had to implement
> my own PKI based on trusted fingerprints which is acceptable but not
> pleasant).
>
> For now, I'm looking for some other options to test BIMI and one thing
> I'm missing critically is an example of an email that could be validated
> by DMARC for the domain that have a valid BIMI record (either normal but
> preferably with VMC). So I would appreciate any help in getting such
> messages, e.g. if anyone who can send email on behalf of Valimail.com
> domain could send me a message with any content to my personal email.
>
> I would also appreciate any information about where to get further
> details without signing any sort of bogus agreements which I personally
> will never ever sign (as I have a strong belief that all Internet
> standards must be open for the general public).
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



-- 
Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] BIMI status and interoperation possibilities

[Vsevolod Stakhov via mailop]

Hello,

I'm currently building a prototype of BIMI agent in Rspamd as per this
Github issue: https://github.com/rspamd/rspamd/issues/3935

However, this technology seems to be very immature and only fragmentary
documented in some aspects. I was able to find just one (!) valid VMC
for `valimail.com` domain in the wild. Other participants of the BIMI WG
either do not publish BIMI records (e.g. Google), provide just an image
without VMC (e.g. Proofpoint) or even publish an expired VMC (e.g.
Paypal)...

Furthermore, even a valid VMC from Valimail does not include any
system-wide trusted CA apart of the specific VMC CA that is not trusted
by system nor cross-signed by other DigiCert CAs (so I had to implement
my own PKI based on trusted fingerprints which is acceptable but not
pleasant).

For now, I'm looking for some other options to test BIMI and one thing
I'm missing critically is an example of an email that could be validated
by DMARC for the domain that have a valid BIMI record (either normal but
preferably with VMC). So I would appreciate any help in getting such
messages, e.g. if anyone who can send email on behalf of Valimail.com
domain could send me a message with any content to my personal email.

I would also appreciate any information about where to get further
details without signing any sort of bogus agreements which I personally
will never ever sign (as I have a strong belief that all Internet
standards must be open for the general public).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Roger Marquis via mailop]

John Levine wrote:

In article <20200725194707.ga19...@rafa.eu.org> you write:

My bank - as I have already mentioned in this thread - S/MIME signs the
contents of their messages. ...


Where do you live?  I've never heard of a bank here in North America doing that.
Here they barely undersstand SPF.


Was not that long ago we had to setup a tls-only postfix instance to
force two of California's largest financial institutions to stop sending
financial data in cleartext.  To one of their credit the problem was
fixed within a few days after one long phone call.  The other, one of
the US' largest brokerages, refused to use smtps or starttls for several
subsequent years.  We still have a stack of paper statements 3+ inches
(80mm) high as a result.

It may seem odd that such large organizations with technically capable
staff wouldn't use all available encryption.  Odd perhaps, until you
consider similarities with CALEA and how certain three letter government
agencies acquire political influence at the expense of business and
consumers.  The slow adoption of S/MIME is likely also fallout from
these same special interests.

Roger Marquis

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/25/2020 2:41 PM, Robert L Mathews via mailop wrote:

On 7/25/20 1:52 AM, Christian de Larrinaga via mailop wrote:


My question is is it useful?

Yes, absolutely. If it's a security-sensitive message, like one from my
bank, it's useful for my mail client to show that it was really sent by
(DKIM signed by) them to increase my trust in it. My bank does not sign
messages in any other way, so DKIM is all I can check in terms of
digital signatures.



You appear to be using yourself as the sole source for assessing 
efficacy.  That's not how broad-based efficacy is established. Anecdotal 
data like this is mostly misleading.


You need to be able to demonstrate that there is efficacy for the 
general user population.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jaroslaw Rafa via mailop]

Dnia 25.07.2020 o godz. 14:41:30 Robert L Mathews via mailop pisze:
> A system that actually works probably requires neutral feedback for
> known legitimate messages, and warnings for illegitimate messages, so
> that it surprises people when a message supposedly from their bank has a
> warning.

If I understand correctly, that's probably how Gmail works when a message
fails SPF and/or DKIM check. Gmail then displays a yellow bar at the top of
the message with information, that it may be fake.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jaroslaw Rafa via mailop]

Dnia 25.07.2020 o godz. 19:12:03 John Levine via mailop pisze:
> In article <20200725194707.ga19...@rafa.eu.org> you write:
> >My bank - as I have already mentioned in this thread - S/MIME signs the
> >contents of their messages. ...
> 
> Where do you live?  I've never heard of a bank here in North America doing 
> that.
> 
> Here they barely undersstand SPF.

I live in Poland. Yes, I have heard that American banking industry is now a
bit "backwards" when it comes to technology. It is probably due to fact that
it developed in this form for many years, and so there is quite a big
resistance against introducing any changes.
On the contrary, our banking system was very underdeveloped before 2000s, but
when it started to develop, it adopted all technological novelties very
quickly.
Ever heard of BLIK? https://blikmobile.pl/en/ I'm not a fan of smartphones
and in fact I don't have one at all, but I understand that this is a
completely new service that - to my knowledge - operates currently only in
Poland. I heard that it is being deployed in other European countries now as
well.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[John Levine via mailop]

In article <20200725194707.ga19...@rafa.eu.org> you write:
>My bank - as I have already mentioned in this thread - S/MIME signs the
>contents of their messages. ...

Where do you live?  I've never heard of a bank here in North America doing that.

Here they barely undersstand SPF.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Suresh Ramasubramanian via mailop]

Hotmail webmail has been displaying logos for a very long time now, for some 
selected large senders.  They are the ones most likely to have data on attempts 
to bypass such logo displays.

--srs

From: Dave Crocker 
Sent: Sunday, July 26, 2020 3:19:05 AM
To: Suresh Ramasubramanian 
Cc: mailop@mailop.org 
Subject: Re: [mailop] BIMI pilot @ Google

On 7/25/2020 2:32 PM, Suresh Ramasubramanian via mailop wrote:
> Oh, all I’m saying is that presenting the logo without a proper check or
> after being fooled into a proper check would be a problem.  And there’d
> be some creative ways (css? logo included at random other places in the
> friendly from? etc) spammers would look at mimicking such a logo


spammers explore any avenue they can find that looks at all promising.
but just because they do something does not mean it is effective.

So, yes, I fully expect them to spoof -- where that means what the word
'spoof' actually means -- logos.  Whether it it will have an effect on
end-user deception is a different matter.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/25/2020 2:32 PM, Suresh Ramasubramanian via mailop wrote:
Oh, all I’m saying is that presenting the logo without a proper check or 
after being fooled into a proper check would be a problem.  And there’d 
be some creative ways (css? logo included at random other places in the 
friendly from? etc) spammers would look at mimicking such a logo



spammers explore any avenue they can find that looks at all promising. 
but just because they do something does not mean it is effective.


So, yes, I fully expect them to spoof -- where that means what the word 
'spoof' actually means -- logos.  Whether it it will have an effect on 
end-user deception is a different matter.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/25/2020 2:06 PM, Jaroslaw Rafa via mailop wrote:

Dnia 25.07.2020 o godz. 13:21:02 Dave Crocker via mailop pisze:


DKIM is intended for use by receiving filtering engines, not
end-user evaluation.

Apparently you believe that displaying security-related information
to end-users is helpful?


It's not me who claimed here "if your bank sends you authenticated mail that
your server verifies you’re sure it is from their server and not from a
hacked machine emitting bank phish", meaning DKIM by that.


Except that DKIM is not design to do anything like that.  It has 
completely different semantics.




I was - in response to this - claiming that actual signing of the message by
S/MIME (as my bank does) is a better method of proving the message's
authenticity than DKIM, which mail clients mostly ignore, so "you", as the
recipient (human recipient, not the receiving server), are unable to verify
if the email is really from your bank or not. You are basically confirming
this by writing that DKIM is not intended for end-user evaluation (although
Gmail shows the DKIM verification result to the user).


But you appear to be asserting that end-users will use s/mime validation 
to useful effect.  The problem is that typical users won't, no matter 
how the authentication/validation is done.




So I don't understand why are you suggesting that I "believe that displaying
security-related information to end-users is helpful" and what exactly do
you mean by this.


Your text: "The fact that the message is signed is prominently displayed 
by two email clients" was the reason.





For example displaying information that the message is digitally signed
(S/MIME) and the signature is valid (or not) *is* definitely helpful.


In theory, yes.  In practice, if the goal is evaluation by the recipient 
end-user, it isn't.




Displaying in web browser that the site has valid HTTPS certificate is
helpful as well.


That's been well-demonstrated to NOT have an effect on end-user assessment.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Robert L Mathews via mailop]

On 7/25/20 1:52 AM, Christian de Larrinaga via mailop wrote:

> My question is is it useful?

Yes, absolutely. If it's a security-sensitive message, like one from my
bank, it's useful for my mail client to show that it was really sent by
(DKIM signed by) them to increase my trust in it. My bank does not sign
messages in any other way, so DKIM is all I can check in terms of
digital signatures.

Although I'd prefer that every message I ever receive pass DKIM checks,
I can (and do) simply ignore DKIM failures for messages that aren't
security-sensitive.

Of course, you can't blindly trust all DKIM signed mail either; when a
message it shows as being signed by domain name "X", I need to then be
sure that "X" is really my bank's domain name. This is where additional
MUA interface elements could be added; it would be useful to know "This
message came from bigbank.com, who have sent you at least one message a
month for the last 12 months and are in your address book", vs. "This
message came from bigbank.com.ru, who have not sent you anything before
and who are not in your address book".

But now we're getting back to the generic question of "is there a way
that bigbank.com -- but not bigbank.com.ru -- can always show something
that recipients get used to trusting?", and something like BIMI gets
suggested. In some people's eyes, the fact that it costs significant
money and effort for bigbank.com to make the logo be displayed, and that
it's not time- or cost-effective for small operators (or phishers) to go
through the process, will be seen as a feature. But the same thought was
behind EV TLS certificates, and that didn't pan out. I think that's
mostly because even if you show a "this is valid" message for certain
entities (whether the green bar of an EV certificate or a BIMI logo),
many recipients will not notice the neutral absence of that logo in a
DKIM-signed phishing attempt from a similar domain name later.

A system that actually works probably requires neutral feedback for
known legitimate messages, and warnings for illegitimate messages, so
that it surprises people when a message supposedly from their bank has a
warning.

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Suresh Ramasubramanian via mailop]

Oh, all I’m saying is that presenting the logo without a proper check or after 
being fooled into a proper check would be a problem.  And there’d be some 
creative ways (css? logo included at random other places in the friendly from? 
etc) spammers would look at mimicking such a logo

--srs

From: mailop  on behalf of Dave Crocker via mailop 

Sent: Saturday, July 25, 2020 11:32:46 PM
To: mailop@mailop.org 
Subject: Re: [mailop] BIMI pilot @ Google

On 7/22/2020 3:45 PM, Marcel Becker via mailop wrote:
> However the majority of our users prefer meaningful avatars and brand
> logos in their email experience as it helps them identify email senders
> and it helps with them with triaging.


As others have noted, BIMI is a logo-display service, not a security
service.

To make this point a bit stronger:  BIMI provides no incremental
security-related capabilities, such as anti-phishing.

Claims that presenting logos to users aids in anti-phishing efforts are
counter-factual.  There's no data supporting the view that it's helpful
and substantial history that it isn't.

To the extent anyone disagrees with this assessment, it would be quite
helpful to see the data.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jaroslaw Rafa via mailop]

Dnia 25.07.2020 o godz. 13:21:02 Dave Crocker via mailop pisze:
> 
> DKIM is intended for use by receiving filtering engines, not
> end-user evaluation.
> 
> Apparently you believe that displaying security-related information
> to end-users is helpful?

It's not me who claimed here "if your bank sends you authenticated mail that
your server verifies you’re sure it is from their server and not from a
hacked machine emitting bank phish", meaning DKIM by that.

I was - in response to this - claiming that actual signing of the message by
S/MIME (as my bank does) is a better method of proving the message's
authenticity than DKIM, which mail clients mostly ignore, so "you", as the
recipient (human recipient, not the receiving server), are unable to verify
if the email is really from your bank or not. You are basically confirming
this by writing that DKIM is not intended for end-user evaluation (although
Gmail shows the DKIM verification result to the user).

So I don't understand why are you suggesting that I "believe that displaying
security-related information to end-users is helpful" and what exactly do
you mean by this.

For example displaying information that the message is digitally signed
(S/MIME) and the signature is valid (or not) *is* definitely helpful.
Displaying in web browser that the site has valid HTTPS certificate is
helpful as well.
However, displaying information about DKIM is not so, as most users probably
won't understand what that means.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/25/2020 12:47 PM, Jaroslaw Rafa via mailop wrote:

The fact that the message is signed is
prominently displayed by two email clients I use while none of them cares
about DKIM verification (besides mentioned Thunderbird plugin, I actually
don't know of any mail client - not counting webmails like Gmail - that
displays DKIM verification result). Isn't this a better approach?



DKIM is intended for use by receiving filtering engines, not end-user 
evaluation.


Apparently you believe that displaying security-related information to 
end-users is helpful?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jaroslaw Rafa via mailop]

Dnia 25.07.2020 o godz. 09:36:18 Suresh Ramasubramanian via mailop pisze:
> 
> On the other hand if your bank sends you authenticated mail that your
> server verifies you’re sure it is from their server and not from a hacked
> machine emitting bank phish

My bank - as I have already mentioned in this thread - S/MIME signs the
contents of their messages. The fact that the message is signed is
prominently displayed by two email clients I use while none of them cares
about DKIM verification (besides mentioned Thunderbird plugin, I actually
don't know of any mail client - not counting webmails like Gmail - that
displays DKIM verification result). Isn't this a better approach?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/22/2020 3:45 PM, Marcel Becker via mailop wrote:
However the majority of our users prefer meaningful avatars and brand 
logos in their email experience as it helps them identify email senders 
and it helps with them with triaging.



As others have noted, BIMI is a logo-display service, not a security 
service.


To make this point a bit stronger:  BIMI provides no incremental 
security-related capabilities, such as anti-phishing.


Claims that presenting logos to users aids in anti-phishing efforts are 
counter-factual.  There's no data supporting the view that it's helpful 
and substantial history that it isn't.


To the extent anyone disagrees with this assessment, it would be quite 
helpful to see the data.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Suresh Ramasubramanian via mailop]

You’re confusing authentication with reputation

A spam domain that signs itself is just emitting signed spam

On the other hand if your bank sends you authenticated mail that your server 
verifies you’re sure it is from their server and not from a hacked machine 
emitting bank phish

--srs

From: mailop  on behalf of Christian de Larrinaga 
via mailop 
Sent: Saturday, July 25, 2020 2:22:30 PM
To: mailop@mailop.org 
Subject: Re: [mailop] BIMI pilot @ Google

I am aware of DKIM and DMARC and SPF. You wil note this email address
which I self host uses all three. As  do all domains I run for email.

My question is is it useful?

- given so many lists even one dedicated to email management give "red"
unsigned flags

- that I get a ton of spam '/ phishing and such all beautifully signed
by DKIM even with DMARC etc. which not only get through that filtering
but also zen.spamhaus... etc

- given most email domains which  do use DKIM don't use strict and in
most cases for good reasons.

It may help  and that may be good enough for those tools. But clearly it
isn't a "solution". More a sticky plaster applied to do the job of a
tourniquet

C

On 24/07/2020 17:10, Robert L Mathews via mailop wrote:
> On 7/24/20 2:51 AM, Christian de Larrinaga via mailop wrote:
>
>> All emails on this list are showing with red DKIM signed boxes
> That's because this list alters the message From header and body without
> re-signing it. (If the list re-signed outgoing Mailman messages with a
> "mailop.org" DKIM signature, it would work.)
>
>
>> Is this useful?
> Sure: It's saying you got a message claiming to be from
> mailop@mailop.org that isn't signed by mailop.org, which is exactly what
> it's supposed to do.
>
> Whether one decides to trust something less based on that is a different
> matter. For example, I care about the DKIM verifier result for messages
> claiming to be from my bank, but I don't worry about it for list messages.
>
> That said, if every MUA showed DKIM results, I suspect there would be a
> lot more DKIM signing just based on the naive complaints it would
> generate. Few people cared about making sure their non-financial website
> used SSL until every browser started claiming it was "not secure".
>

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Christian de Larrinaga via mailop]

I am aware of DKIM and DMARC and SPF. You wil note this email address 
which I self host uses all three. As  do all domains I run for email.


My question is is it useful?

- given so many lists even one dedicated to email management give "red" 
unsigned flags


- that I get a ton of spam '/ phishing and such all beautifully signed 
by DKIM even with DMARC etc. which not only get through that filtering 
but also zen.spamhaus... etc


- given most email domains which  do use DKIM don't use strict and in 
most cases for good reasons.


It may help  and that may be good enough for those tools. But clearly it 
isn't a "solution". More a sticky plaster applied to do the job of a 
tourniquet


C

On 24/07/2020 17:10, Robert L Mathews via mailop wrote:

On 7/24/20 2:51 AM, Christian de Larrinaga via mailop wrote:


All emails on this list are showing with red DKIM signed boxes

That's because this list alters the message From header and body without
re-signing it. (If the list re-signed outgoing Mailman messages with a
"mailop.org" DKIM signature, it would work.)



Is this useful?

Sure: It's saying you got a message claiming to be from
mailop@mailop.org that isn't signed by mailop.org, which is exactly what
it's supposed to do.

Whether one decides to trust something less based on that is a different
matter. For example, I care about the DKIM verifier result for messages
claiming to be from my bank, but I don't worry about it for list messages.

That said, if every MUA showed DKIM results, I suspect there would be a
lot more DKIM signing just based on the naive complaints it would
generate. Few people cared about making sure their non-financial website
used SSL until every browser started claiming it was "not secure".



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Robert L Mathews via mailop]

On 7/24/20 2:51 AM, Christian de Larrinaga via mailop wrote:

> All emails on this list are showing with red DKIM signed boxes

That's because this list alters the message From header and body without
re-signing it. (If the list re-signed outgoing Mailman messages with a
"mailop.org" DKIM signature, it would work.)


> Is this useful?

Sure: It's saying you got a message claiming to be from
mailop@mailop.org that isn't signed by mailop.org, which is exactly what
it's supposed to do.

Whether one decides to trust something less based on that is a different
matter. For example, I care about the DKIM verifier result for messages
claiming to be from my bank, but I don't worry about it for list messages.

That said, if every MUA showed DKIM results, I suspect there would be a
lot more DKIM signing just based on the naive complaints it would
generate. Few people cared about making sure their non-financial website
used SSL until every browser started claiming it was "not secure".

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[John Levine via mailop]

In article <7ed4f483-3d83-e6aa-b6f6-07f6f283e...@lightmeter.io> you write:
>This is the concerning part -- it seems that BIMI will disadvantage smaller / 
>independent mail networks by introducing a new barrier to having
>their valid mail treated equally to their large corporate peers.

Having talked at length to people who are working on BIMI, I doubt
it'll be a problem. BIMI is about showing logos, not about getting
into the inbox.

BIMI uses DMARC to decide whether to consider a message for BIMI logo display.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jakub Olexa via mailop]

Hi,

the whole VMC process is still being developed and tested (that's what
the pilot is for). I'd say most of the BIMI group members if not all
understand that the VMC needs to be affordable. BIMI has not been
developed for the fortune 100 but for all brands.

Jakub Olexa
Founder & CEO
E-mail: ja...@mailkit.com 
Tel: +420 777 744 440 

Mailkit - Closing the circle between Deliverability and Engagement


On 24.7.2020 15:04, Jonathan Leroy - Inikup via mailop wrote:
> Le mer. 22 juil. 2020 à 14:50, Sidsel Jensen via mailop
>  a écrit :
>> I read today at 
>> https://cloud.google.com/blog/products/g-suite/gsuite-security-updates-for-gmail-meet-chat-and-admin
>>  - that Google/Gmail is starting a BIMI pilot.
>> I hope Google will share the results of the pilot - perhaps at the next 
>> M3AAWG?
> Regarding the certification part: is there any public page listing
> requirements / processes?
> Also I have not found any public prices on DigiCert or Entrust
> websites. Does anyone know if the certification will be affordable for
> (very) small businesses?
>


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jonathan Leroy - Inikup via mailop]

Le mer. 22 juil. 2020 à 14:50, Sidsel Jensen via mailop
 a écrit :
> I read today at 
> https://cloud.google.com/blog/products/g-suite/gsuite-security-updates-for-gmail-meet-chat-and-admin
>  - that Google/Gmail is starting a BIMI pilot.
> I hope Google will share the results of the pilot - perhaps at the next 
> M3AAWG?

Regarding the certification part: is there any public page listing
requirements / processes?
Also I have not found any public prices on DigiCert or Entrust
websites. Does anyone know if the certification will be affordable for
(very) small businesses?

-- 
Jonathan Leroy

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Sam Tuke via mailop]

On 23/07/2020 23:21, Nick via mailop wrote:
> On 2020-07-23 21:00 BST, Brandon Long via mailop wrote:
>> If you had a workable idea for how to do this without a new authority
>> and money changing hands, I'm sure everyone involved would love to
>> hear about it> I'm not as sure as you are.  To be part of BIMI is to be in a 
>> relatively
> exclusive club.  That's the whole point.

This is the concerning part -- it seems that BIMI will disadvantage smaller / 
independent mail networks by introducing a new barrier to having their valid 
mail treated equally to their large corporate peers.

Any email verification system which relies on centralised, pay-to-play services 
undermines the decentralised principles of email as a whole, harming equal 
access (and fair treatment) for all players.

Sam.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Matthias Leisi via mailop]

> S/MIME offers more traditional digital signatures using CA signed 
> certificates.  I would
> not call that widely deployed, I certainly have never seen it from any 
> marketing/transactional
> mail, maybe once or twice from a medical insurance company.  Support in mail 
> clients is
> fairly widely deployed, possibly more so than DKIM.

Webmail is usually poor in properly showing signature verification. 

One big provider which starts with a „G“ seems to silently ignore attachments 
with „Content-Type: application/pkcs7-signature". :)

(Everything works as it should when accessed over IMAP, no problem there.)

— Matthias


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Christian de Larrinaga via mailop]

On 23/07/2020 20:06, Andrew C Aitchison via mailop wrote:




Are there that many IMAP based mail clients which feature contact 
avatars?


Apparently there is a Thunderbird addon 'dkim verify'
which uses the favicon of the signing domain:
https://stackoverflow.com/questions/59465208/thunderbird-icon-in-from
https://addons.thunderbird.net/en-GB/thunderbird/addon/dkim-verifier/versions/
https://github.com/lieser/dkim_verifier/wiki/Options#use-dmarc-to-heuristically-determine-if-an-e-mail-should-be-signed

It is DMARC aware and supports Thunderbird v68 but not yet the latest 
v78.



I installed it on Monday when I pushed focal fossa onto my laptop but 
stuck with an updated v68. It shows a coloured box on the menu bar. 
Green for compliant and Red when not .. blue when it can't check the DNS.


All emails on this list are showing with red DKIM signed boxes

Is this useful? I'd much prefer to see Thunderlink or equivalent which 
Mozilla trashed. That is very useful - even essential. So I may have to 
fall back on gnus... urgh!


C


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Matt Palmer via mailop]

On Thu, Jul 23, 2020 at 12:56:37PM -0700, Brandon Long via mailop wrote:
> On Thu, Jul 23, 2020 at 1:09 AM Nick via mailop  wrote:
> > On 2020-07-23 03:26 BST, Ted Hatfield via mailop wrote:
> > > It appears that to reach wide spread adoption of this protocol we're
> > > going to be creating a new kind of certificate authority that is
> > > specific to trademarked images and logos.  All so we can certify that
> > > the logo passes BIMI verification.
> >
> > Not just Mark Verifying Authorities but Dispute Resolution Agencies too.
> > They will want to get paid, no?  A great way to make the world safe for
> > Big Internet and downgrade the rest.  So BIMI looks to have a bright
> > future.  Thanks again, Google!
> 
> If you had a workable idea for how to do this without a new authority and
> money changing hands, I'm sure everyone involved would love to hear about
> it.

Except the CAs, presumably...

- Matt


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Brandon Long via mailop]

On Thu, Jul 23, 2020 at 2:24 PM Nick via mailop  wrote:

> On 2020-07-23 21:00 BST, Brandon Long via mailop wrote:
> > If you had a workable idea for how to do this without a new authority
> > and money changing hands, I'm sure everyone involved would love to
> > hear about it.
>
> I'm not as sure as you are.  To be part of BIMI is to be in a relatively
> exclusive club.  That's the whole point.
>

Really, I'm sure they'd love for it to be a mutually exclusive club,
anybody can show what they want, as long as it's not too close to what
someone else is
showing, and where the brand identity goes to the "right" person... but
that is not a solved problem.  Will this solve it?

Bad actors suck, it turns the problem of "I want this person to see this
for my profile photo on my email" into a potentially unsolvable problem.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Nick via mailop]

On 2020-07-23 21:00 BST, Brandon Long via mailop wrote:
> If you had a workable idea for how to do this without a new authority
> and money changing hands, I'm sure everyone involved would love to
> hear about it.

I'm not as sure as you are.  To be part of BIMI is to be in a relatively
exclusive club.  That's the whole point.
-- 
Nick

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Marcel Becker via mailop]

On Thu, Jul 23, 2020 at 1:30 PM Jaroslaw Rafa via mailop 
wrote:

> That's the real purpose of BIMI -
> "even if recipient decides not to read our message, let's force him/her to
> see our logo at least". It has nothing to do with protection against
> anything.


Of course it's your choice to ignore at least our data & user centric
driven motivation behind BIM which I shared with you. And you can of course
present your personal opinion as a general fact.

It doesn't make it true though.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jaroslaw Rafa via mailop]

Dnia 23.07.2020 o godz. 13:05:26 Brandon Long via mailop pisze:
> I don't know whether you're talking about a real thing or not.
> 
> DKIM is a digital signature of a message, and obviously broadly deployed,
> but there
> are no Certificate Authorities involved.  Keys are self generated and
> depend on
> DNS ownership, no more.
> 
> S/MIME offers more traditional digital signatures using CA signed
> certificates.  I would
> not call that widely deployed, I certainly have never seen it from any
> marketing/transactional
> mail, maybe once or twice from a medical insurance company.  Support in
> mail clients is
> fairly widely deployed, possibly more so than DKIM.

I'm talking exactly about "real", S/MIME digital signing of the message
contents. As I have already mentioned, I routinely receive S/MIME digitally
signed messages from companies that have actual reasons to write to me, like
my bank, my phone operator, my ISP etc. Messages from them (for example
informing about monthly bills etc.) are always digitally signed.

Of course, there's no need to digitally sign a marketing message, because
there's no critical information in it, that needs to be authenticated and
verified. It's just blah-blah-blah. There's no need to use BIMI as well,
other than purely marketing purposes, as I already wrote - to push the
company's logo before recipient's eyes even if he/she decides to delete the
message right away and don't open it. That's the real purpose of BIMI -
"even if recipient decides not to read our message, let's force him/her to
see our logo at least". It has nothing to do with protection against
anything.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Brandon Long via mailop]

I don't know whether you're talking about a real thing or not.

DKIM is a digital signature of a message, and obviously broadly deployed,
but there
are no Certificate Authorities involved.  Keys are self generated and
depend on
DNS ownership, no more.

S/MIME offers more traditional digital signatures using CA signed
certificates.  I would
not call that widely deployed, I certainly have never seen it from any
marketing/transactional
mail, maybe once or twice from a medical insurance company.  Support in
mail clients is
fairly widely deployed, possibly more so than DKIM.

Widespread use, especially to consumers, would depend on some amazing
complications
for key generation, especially if you correctly rotate keys... how many
hardware signing
boxes do you need to handle a billion keys rotating yearly?  Anyways,
consumer level
is not what we're talking about here anyways.

And that CA signature is as meaningful as it is in HTTPS, which is to say
not very much...
but related to that was the attempt at extended validation certificate
signatures, and now
you're getting closer to what BIMI is trying to do.

Brandon

On Thu, Jul 23, 2020 at 3:08 AM Jaroslaw Rafa via mailop 
wrote:

> All this BIMI thing seems to be only about increased pushing of big
> companys' logos before people's eyes than to any fraud prevention.
>
> If it were about fraud prevention, then instead of inventing something
> completely new, the companies could use solution that is standard, already
> available and widely supported - that is, digital signing of a message.
>
> Many companies already do this for years. For example, I am always
> receiving
> emails from my bank, phone operator, ISP, electricity provider etc.
> digitally signed. When I open such a message, my email client (two
> different
> ones, actually) prominently displays that the message is digitally signed
> by
>  and the signature is valid/invalid. Thus it's simple to
> verify that the email is really from them. (You have of course to trust the
> CA issuing the signing certificate - exactly as in the case of BIMI, where
> you have to trust the CA as well; so protection level is no less).
>
> But this can display only the company name, and not LOGO! So marketoids
> don't like it, because they want company's logo pushed before people's eyes
> as often as they could. It's sad that someone is pushing a solution that
> adds no value to actual email communication on topics important and useful
> for the recipient, but only to marketoids who want to send people more
> useless marketing blah-blah junk. :(
> --
> Regards,
>Jaroslaw Rafa
>r...@rafa.eu.org
> --
> "In a million years, when kids go to school, they're gonna know: once there
> was a Hushpuppy, and she lived with her daddy in the Bathtub."
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Brandon Long via mailop]

On Thu, Jul 23, 2020 at 1:09 AM Nick via mailop  wrote:

> On 2020-07-23 03:26 BST, Ted Hatfield via mailop wrote:
> > It appears that to reach wide spread adoption of this protocol we're
> going
> > to be creating a new kind of certificate authority that is specific to
> > trademarked images and logos.  All so we can certify that the logo passes
> > BIMI verification.
>
> Not just Mark Verifying Authorities but Dispute Resolution Agencies too.
> They will want to get paid, no?  A great way to make the world safe for
> Big Internet and downgrade the rest.  So BIMI looks to have a bright
> future.  Thanks again, Google!
>

If you had a workable idea for how to do this without a new authority and
money changing hands,
I'm sure everyone involved would love to hear about it.

I'm not sure this would be better if only the large providers could come up
with some fancy ML
and web crawling to automate the validation, for example or used their
large view and only
applied it based on volume, reputation, and phishing score... which the
smaller players can't duplicate
either.

OTOH, I'm sure everyone's worried about the similarities to extended
validation certificates, and
what level of benefit those ever provided over standard certs.  It would be
a good comparison
for the likely cost of having a brand verified, though.  Sure, it doesn't
scale down to the
smallest brand operators, but I'm not sure it qualifies as only "big
internet" either.

Would you do this for your personal domain?  Why?  Would you do this for
the local flower shop?
I mean, if it was cheap enough, but often they are just sending from their
local isp or gmail.com account
anyways, they haven't even upgraded to a full domain.  Maybe this kind of
thing would be included
at the ESP level when you're sending a million messages, and it's no big
deal at that point.  How many
brands are at that level, probably still 10s of thousands.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Andrew C Aitchison via mailop]

On Wed, 22 Jul 2020, Brandon Long via mailop wrote:


An interesting question might be, how would you implement this for an MUA
using IMAP without inbox style exposure...

You'd probably have to do it through your contacts server, ie CardDav.
Server side, you could collect all of the avatars and
populate them per-user into their Contacts data.  That might have annoying
aspects to the size of their contact data and the
sync size, though you could automate population and pruning from the user's
mailbox to their contacts data to somewhat
control that.

Otherwise, you could expand IMAP metadata with it, but there'd have to be
some work to standardize that.
Or create an X-face style header that's just added locally by the MDA.

Are there that many IMAP based mail clients which feature contact avatars?


Apparently there is a Thunderbird addon 'dkim verify'
which uses the favicon of the signing domain:
  https://stackoverflow.com/questions/59465208/thunderbird-icon-in-from
  https://addons.thunderbird.net/en-GB/thunderbird/addon/dkim-verifier/versions/
  
https://github.com/lieser/dkim_verifier/wiki/Options#use-dmarc-to-heuristically-determine-if-an-e-mail-should-be-signed

It is DMARC aware and supports Thunderbird v68 but not yet the latest v78.


--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[John Levine via mailop]

In article <20200723100713.ga2...@rafa.eu.org> you write:
>All this BIMI thing seems to be only about increased pushing of big
>companys' logos before people's eyes than to any fraud prevention.

That's right.  It seems basically harmless but I don't see any reason
for anyone to care about it unless being paid to do so.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jaroslaw Rafa via mailop]

All this BIMI thing seems to be only about increased pushing of big
companys' logos before people's eyes than to any fraud prevention.

If it were about fraud prevention, then instead of inventing something
completely new, the companies could use solution that is standard, already
available and widely supported - that is, digital signing of a message.

Many companies already do this for years. For example, I am always receiving
emails from my bank, phone operator, ISP, electricity provider etc.
digitally signed. When I open such a message, my email client (two different
ones, actually) prominently displays that the message is digitally signed by
 and the signature is valid/invalid. Thus it's simple to
verify that the email is really from them. (You have of course to trust the
CA issuing the signing certificate - exactly as in the case of BIMI, where
you have to trust the CA as well; so protection level is no less).

But this can display only the company name, and not LOGO! So marketoids
don't like it, because they want company's logo pushed before people's eyes
as often as they could. It's sad that someone is pushing a solution that
adds no value to actual email communication on topics important and useful
for the recipient, but only to marketoids who want to send people more
useless marketing blah-blah junk. :(
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Vittorio Bertola via mailop]

> Il 23/07/2020 03:24 Matt Corallo via mailop  ha scritto:
> 
>  
> The standard appears to provide no protection whatsoever, but the specific 
> implementation announced by Google relies on
> CAs to "authenticate" the domains' logo. Seems like there should be a 
> standard for that, too.

It's in the standard - BIMI would not make sense if there were not strict 
controls on who can display the logo, to avoid that other (more or less shady) 
parties register and display a very similar logo. However, this will soon get 
into all the trademark craziness of different companies having rights to the 
same logo in different parts of the world and so on. Also, when reduced to a 
square a few pixels wide, many logos look quite the same. So we'll see how well 
the certificate authorities can manage this, also because if they start to say 
no to legitimate companies because their logo would look too similar to another 
one by a bigger company, I suspect that antitrust lawsuits may ensue.

More generally, BIMI is exclusive by principle; the point is having only a few 
logos shown, so that they actually constitute a signal of legitimacy; if all 
email had BIMI logos, then having a logo would not mean anything. This is 
something I personally dislike.

The Internet draft linked in the thread was presented at a BoF at the Prague 
IETF about 18 months ago, and there was substantial opposition in the room to 
making this an IETF activity or standard, for the above considerations and 
more. So at this point in time it is just an initiative by a group of companies.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Benjamin BILLON via mailop]

VMG (Yahoo/Aol) uses their own matching table (domain <=> brand <=> logo), 
mixed with reputation (you proved you're good, then we can display the logo). 
In other words, they don't display the logo for just any BIMI record. As Marcel 
said, the main challenge is scalability as it requires manual tweaking.

Gmail's approach is, as often/always, to only implement if it's 
scalable/automatic, and that means relying on CA, themselves relying on 
trademarks of logos, to avoid having someone abusing someone else's logo. The 
whole process is yet TBD, folks will be busy during this pilot phase =)

Both approaches are valid, and there might be other options.
In any case, the logo abuse point is a long-time concern and was one of the 
reason why BIMI stalled for some times a few years ago. But yes, it's up to the 
MUA to make sure logos can't be abused, like it's up to the MUA to display 
friendly From: instead of visible From:'s email address even if the friendly 
From: looks like an email address (yet Outlook, I'm looking at you). It's 
easier if the MUA and the mail server are both managed by the same entity.

> As a small mail server administrator this raises a lot of questions about 
> actual implentation and what tools are available to implement this standard.
You might need to define a new approach for it if it doesn't exist yet. Or wait 
for someone else to do it.
Also, as a small server administrator, you probably don't develop your own 
webmail/MUA, so probably the challenge would be to work with webmail's 
developers (it's been a long time since I touched that part so the only name 
that comes to me is roundcube, but I guess there are others) on the 
implementation.

--
Benjamin 

-Original Message-
From: mailop  On Behalf Of Ted Hatfield via mailop
Sent: jeudi 23 juillet 2020 04:23
To: Matt Corallo 
Cc: mailop ; Marcel Becker 
Subject: Re: [mailop] BIMI pilot @ Google


Further down in one of the faq's on the bimigroup website is a link to an IETF 
document.  draft-brotman-ietf-bimi-guidance-01

https://tools.ietf.org/html/draft-brotman-ietf-bimi-guidance-01


It has information on the actual recommended implementation of BIMI including 
more information about BIMI Certificates.


It appears that to reach wide spread adoption of this protocol we're going 
to be creating a new kind of certificate authority that is specific to 
trademarked images and logos.  All so we can certify that the logo passes 
BIMI verification.


Read section 6.4.  Basic flow example.

If the bimi verification passes,

o  The email receiver then sets either the appropriate IMAP flags, or
   other mailstore flag, or other message property that signals to a
   downstream email client that the message passed BIMI and is safe
   to load the logo, along with a pointer to the logo (e.g., to the
   https location specified in the BIMI record).

o  What eventually happens is the email client then looks at the
   flags set by the email receiver (MTA).  If the flags are set to
   show a BIMI logo, then the email client downloads the image and
   displays it in the sender photo (or however else it chooses to
   render the BIMI logo in conjunction with the message).


As a small mail server administrator this raises a lot of questions about 
actual implentation and what tools are available to implement this 
standard.


Ted





On Wed, 22 Jul 2020, Matt Corallo via mailop wrote:

> The standard appears to provide no protection whatsoever, but the specific 
> implementation announced by Google relies on
> CAs to "authenticate" the domains' logo. Seems like there should be a 
> standard for that, too.
>
> Matt
>
> On 7/22/20 9:17 PM, Ted Hatfield via mailop wrote:
>>
>>
>> On Wed, 22 Jul 2020, Marcel Becker via mailop wrote:
>>> On Wed, Jul 22, 2020 at 5:27 PM Ted Hatfield  wrote:
>>>
>>>   Maybe this is a stupid question but
>>>
>>>
>>> Excuse me, but: Re-read the Google announcement and https://bimigroup.org 
>>> ;-)
>>>
>>>
>>>
>>>  
>>>
>>>
>>
>>
>> I read the page at https://bimigroup.org/
>>
>> The first statement to come up is:
>>
>>
>> What is BIMI?
>>
>> Brand Indicators for Message Identification or BIMI (pronounced: Bih-mee)
>> is an emerging email specification that enables the use of brand-controlled 
>> logos within supporting email clients. BIMI
>> leverages the
>> work an organization has put into deploying DMARC protection, by bringing
>> brand logos to the customers inbox. For the brands logo to be displayed,
>> the email must pass DMARC authentication checks, ensuring that the

Re: [mailop] BIMI pilot @ Google

[Nick via mailop]

On 2020-07-23 03:26 BST, Ted Hatfield via mailop wrote:
> It appears that to reach wide spread adoption of this protocol we're going
> to be creating a new kind of certificate authority that is specific to
> trademarked images and logos.  All so we can certify that the logo passes
> BIMI verification.

Not just Mark Verifying Authorities but Dispute Resolution Agencies too.
They will want to get paid, no?  A great way to make the world safe for
Big Internet and downgrade the rest.  So BIMI looks to have a bright
future.  Thanks again, Google!
-- 
Nick

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Ted Hatfield via mailop]

Further down in one of the faq's on the bimigroup website is a link to an 
IETF document.  draft-brotman-ietf-bimi-guidance-01


https://tools.ietf.org/html/draft-brotman-ietf-bimi-guidance-01


It has information on the actual recommended implementation of BIMI 
including more information about BIMI Certificates.



It appears that to reach wide spread adoption of this protocol we're going 
to be creating a new kind of certificate authority that is specific to 
trademarked images and logos.  All so we can certify that the logo passes 
BIMI verification.



Read section 6.4.  Basic flow example.

If the bimi verification passes,

   o  The email receiver then sets either the appropriate IMAP flags, or
  other mailstore flag, or other message property that signals to a
  downstream email client that the message passed BIMI and is safe
  to load the logo, along with a pointer to the logo (e.g., to the
  https location specified in the BIMI record).

   o  What eventually happens is the email client then looks at the
  flags set by the email receiver (MTA).  If the flags are set to
  show a BIMI logo, then the email client downloads the image and
  displays it in the sender photo (or however else it chooses to
  render the BIMI logo in conjunction with the message).


As a small mail server administrator this raises a lot of questions about 
actual implentation and what tools are available to implement this 
standard.



Ted





On Wed, 22 Jul 2020, Matt Corallo via mailop wrote:


The standard appears to provide no protection whatsoever, but the specific 
implementation announced by Google relies on
CAs to "authenticate" the domains' logo. Seems like there should be a standard 
for that, too.

Matt

On 7/22/20 9:17 PM, Ted Hatfield via mailop wrote:



On Wed, 22 Jul 2020, Marcel Becker via mailop wrote:

On Wed, Jul 22, 2020 at 5:27 PM Ted Hatfield  wrote:

  Maybe this is a stupid question but


Excuse me, but: Re-read the Google announcement and https://bimigroup.org ;-)



 





I read the page at https://bimigroup.org/

The first statement to come up is:


What is BIMI?

Brand Indicators for Message Identification or BIMI (pronounced: Bih-mee)
is an emerging email specification that enables the use of brand-controlled 
logos within supporting email clients. BIMI
leverages the
work an organization has put into deploying DMARC protection, by bringing
brand logos to the customers inbox. For the brands logo to be displayed,
the email must pass DMARC authentication checks, ensuring that the
organizations domain has not been impersonated.


How does enabling bimi keep someone from publishing their own dmarc, spf, and 
dkim records and still impersonating your
brand image?

Isn't it just a little disingenuous to promote this as a anti-phishing scheme 
when all it does it add brand and logo
marketing to a person's email.


Ted

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Daniel Jakots via mailop]

On Wed, 22 Jul 2020 20:59:54 -0400, Matt Corallo via mailop
 wrote:

> but I don't see an answer to this question

I assume it's the sentence

> We’ll be starting the BIMI pilot in the coming weeks with a limited
> number of senders, and with two Certification Authorities to validate
> logo ownership: Entrust Datacard and DigiCert.

from the Google announcement.


Cheers,
Daniel

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Matt Corallo via mailop]

The standard appears to provide no protection whatsoever, but the specific 
implementation announced by Google relies on
CAs to "authenticate" the domains' logo. Seems like there should be a standard 
for that, too.

Matt

On 7/22/20 9:17 PM, Ted Hatfield via mailop wrote:
> 
> 
> On Wed, 22 Jul 2020, Marcel Becker via mailop wrote:
>> On Wed, Jul 22, 2020 at 5:27 PM Ted Hatfield  wrote:
>>
>>   Maybe this is a stupid question but
>>
>>
>> Excuse me, but: Re-read the Google announcement and https://bimigroup.org ;-)
>>
>>
>>
>>  
>>
>>
> 
> 
> I read the page at https://bimigroup.org/
> 
> The first statement to come up is:
> 
> 
> What is BIMI?
> 
> Brand Indicators for Message Identification or BIMI (pronounced: Bih-mee)
> is an emerging email specification that enables the use of brand-controlled 
> logos within supporting email clients. BIMI
> leverages the
> work an organization has put into deploying DMARC protection, by bringing
> brand logos to the customers inbox. For the brands logo to be displayed,
> the email must pass DMARC authentication checks, ensuring that the
> organizations domain has not been impersonated.
> 
> 
> How does enabling bimi keep someone from publishing their own dmarc, spf, and 
> dkim records and still impersonating your
> brand image?
> 
> Isn't it just a little disingenuous to promote this as a anti-phishing scheme 
> when all it does it add brand and logo
> marketing to a person's email.
> 
> 
> Ted
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Matt Corallo via mailop]

Right, the BIMI website doesn't mention it anywhere, silly me forgot to read 
the non-official source :).

On 7/22/20 9:20 PM, Daniel Jakots wrote:
> On Wed, 22 Jul 2020 20:59:54 -0400, Matt Corallo via mailop
>  wrote:
> 
>> but I don't see an answer to this question
> 
> I assume it's the sentence
> 
>> We’ll be starting the BIMI pilot in the coming weeks with a limited
>> number of senders, and with two Certification Authorities to validate
>> logo ownership: Entrust Datacard and DigiCert.
> 
> from the Google announcement.
> 
> 
> Cheers,
> Daniel
> 

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Patrick via mailop]

On 2020-07-22 20:59, Matt Corallo via mailop wrote:
> Maybe I'm missing something, but I don't see an answer to this
> question - Ted's point seems well-made and it seems like this will
> retrain users to be more vulnerable to phishing attacks by putting the
> correct logo on an unrelated domain.

Because you have to buy a VMC for your logo.

Which means we are back to managing certificate authorities

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Ted Hatfield via mailop]

On Wed, 22 Jul 2020, Marcel Becker via mailop wrote:

On Wed, Jul 22, 2020 at 5:27 PM Ted Hatfield  wrote:

  Maybe this is a stupid question but


Excuse me, but: Re-read the Google announcement and https://bimigroup.org ;-)



 





I read the page at https://bimigroup.org/

The first statement to come up is:


What is BIMI?

Brand Indicators for Message Identification or BIMI (pronounced: Bih-mee)
is an emerging email specification that enables the use of 
brand-controlled logos within supporting email clients. BIMI leverages the

work an organization has put into deploying DMARC protection, by bringing
brand logos to the customers inbox. For the brands logo to be displayed,
the email must pass DMARC authentication checks, ensuring that the
organizations domain has not been impersonated.


How does enabling bimi keep someone from publishing their own dmarc, spf, 
and dkim records and still impersonating your brand image?


Isn't it just a little disingenuous to promote this as a anti-phishing 
scheme when all it does it add brand and logo marketing to a person's 
email.



Ted___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Matt Corallo via mailop]

Maybe I'm missing something, but I don't see an answer to this question - Ted's 
point seems well-made and it seems like
this will retrain users to be more vulnerable to phishing attacks by putting 
the correct logo on an unrelated domain.

Matt

On 7/22/20 8:30 PM, Marcel Becker via mailop wrote:
> On Wed, Jul 22, 2020 at 5:27 PM Ted Hatfield  > wrote:
> 
> 
> Maybe this is a stupid question but
> 
> 
> Excuse me, but: Re-read the Google announcement and https://bimigroup.org ;-)
> 
> 
> 
>  
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Marcel Becker via mailop]

On Wed, Jul 22, 2020 at 5:27 PM Ted Hatfield  wrote:

>
> Maybe this is a stupid question but
>
>
Excuse me, but: Re-read the Google announcement and https://bimigroup.org
;-)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Marcel Becker via mailop]

On Wed, Jul 22, 2020 at 5:22 PM Brandon Long via mailop 
wrote:

> An interesting question might be, how would you implement this for an MUA
> using IMAP without inbox style exposure...
>
>
THIS is indeed a very relevant question which I don't think we have a (good
enough) answer for. It remains a challenge. How do we scale this beyond
just the big guys who control both MTA and MUA (or for instances where an
MUA can not "trust" the MTA) -- and how do we do this in a privacy
conscious way?

That's exactly the kind of conversation I'd like to have. There are ideas
in some variants of the spec -- and you hit some of them on the head
already -- but me (personally) am not convinced that we (as a group) have
nailed that one yet. But you need to start somewhere I think. Iterate.
Listen. Improve.

- Marcel
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Ted Hatfield via mailop]

Maybe this is a stupid question but

as BIMI is a txt record in dns

An example BIMI TXT record.

"v=BIMI1; l=https://images.example.com/somedir/logo.svg;";

What exactly keeps someone from publishing their own BIMI TXT record and 
simply copying your image.


How exactly does this improve fraudulent email protection.  It would seem 
that it would do the opposite.  You are training your users to trust based 
on the image provided rather than the actual email address.



Ted



On Wed, 22 Jul 2020, Marcel Becker via mailop wrote:




On Wed, Jul 22, 2020 at 4:49 PM Jim Popovitch via mailop  
wrote:

  Good, DMARC is good, but we don't need yet another standard to get DKIM
  and SPF into the wider use.


Based on the data I see on the receiving side I disagree. But that's ok. 
 
  I hope you understand that most providers don't care if your logo
  service is alive and well.  Surely we don't need a spec for that.


Exactly. I see this went over your head. 

  Whether you understand it or not, if a proxy or cache fetches your logo,
  you can get very valuable data about inbox hit rate data, eg tracking.


No, if you care about your users' privacy you would not implement anything 
which would allow senders to do what you say BIMI
enables.

This means in our case: If you -- as a sender -- publishes a BIMI logo all you 
can track is when our logo service is fetching
your logo.  Which might be exactly once (ie: one time) when you update it. Our 
MUAs don't fetch BIMI logos from the source. 

So all it well tell you is

1: Our MTA saw mail coming in from your domain
2: We probably trusted you enough to see if you have a BIMI logo
3: We fetched that BIMI logo
4: A Verizon Media IP connected to your hosting server
5: Our system is alive and working (well, at least it's requesting logos)

That's it. 




___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Brandon Long via mailop]

An interesting question might be, how would you implement this for an MUA
using IMAP without inbox style exposure...

You'd probably have to do it through your contacts server, ie CardDav.
Server side, you could collect all of the avatars and
populate them per-user into their Contacts data.  That might have annoying
aspects to the size of their contact data and the
sync size, though you could automate population and pruning from the user's
mailbox to their contacts data to somewhat
control that.

Otherwise, you could expand IMAP metadata with it, but there'd have to be
some work to standardize that.
Or create an X-face style header that's just added locally by the MDA.

Are there that many IMAP based mail clients which feature contact avatars?

Purely client-side versions would be challenged with the "high reputation"
aspect of not just fetching
any given one.  I guess you could prompt the user, kind of the equivalent
of "always load images from this
sender", control the avatar and the images with the same per-sender flag.

Brandon

On Wed, Jul 22, 2020 at 5:06 PM Brandon Long  wrote:

>
>
> On Wed, Jul 22, 2020 at 4:46 PM Jim Popovitch via mailop <
> mailop@mailop.org> wrote:
>
>> On Wed, 2020-07-22 at 11:56 -0700, Marcel Becker via mailop wrote:
>> >
>> > On Wed, Jul 22, 2020 at 11:35 AM Jim Popovitch via mailop <
>> mailop@mailop.org> wrote:
>> > > On Wed, 2020-07-22 at 14:49 +0200, Sidsel Jensen via mailop wrote:
>> > > > but if the effect is that it will drive up the adoption rate for
>> DMARC then I am clapping my hands.
>> > >
>> > > "Once verified, the BIMI file tells the email service where to find
>> the
>> > > sender’s logo and the email service pulls that logo into the inbox."
>> > >
>> > >
>> > > I don't think this is anything about DMARC, this is about inbox
>> > > tracking.
>> >
>> > Um. No.
>> > 1: DMARC is required for BIMI.
>>
>> Good, DMARC is good, but we don't need yet another standard to get DKIM
>> and SPF into the wider use.
>>
>> > 2: A proper setup will proxy and cache the logo. eg: for us all you can
>> track through BIMI is if our logo service is alive and well...
>>
>> I hope you understand that most providers don't care if your logo
>> service is alive and well.  Surely we don't need a spec for that.
>>
>
> Once upon a time, there was the X-Face header... I guess we could have
> updated that for some modern version
> and sent it with every message.  For better or worse, a lot of mail
> clients these days include an avatar
> for the author, and acquiring that avatar can be complicated.  For the
> larger mailbox services, there was usually
> a proprietary way to set that avatar... iirc, for Gmail that meant
> creating a G+ account for the email address
> and setting the account profile photo.  Obviously, a standardized way to
> specify avatars across clients is
> better than proprietary methods... but that leads to a bunch of other
> questions when it comes to
> validation and preventing "abuse" of the avatar... whether or not BIMI is
> a great answer to that is probably
> still TBD.
>
>
>> Whether you understand it or not, if a proxy or cache fetches your logo,
>> you can get very valuable data about inbox hit rate data, eg tracking.
>>
>
> I think this highly depends on your MUA and it's model.  If Gmail fetches
> and
> caches the images, and there's no method in BIMI for "per user" images,
> then
> tracking BIMI images is nothing more useful than "gmail received my
> message."
>
> If the fetching comes from the individual client running locally on some
> personal
> computer or mobile devices, the tracking level would be higher... at least
> on the
> "first" hit, assuming they did any caching at the client level.
>
> This is all based on my assumptions about how this is all implemented, I
> haven't read the spec yet.
>
> Brandon
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Brandon Long via mailop]

On Wed, Jul 22, 2020 at 4:46 PM Jim Popovitch via mailop 
wrote:

> On Wed, 2020-07-22 at 11:56 -0700, Marcel Becker via mailop wrote:
> >
> > On Wed, Jul 22, 2020 at 11:35 AM Jim Popovitch via mailop <
> mailop@mailop.org> wrote:
> > > On Wed, 2020-07-22 at 14:49 +0200, Sidsel Jensen via mailop wrote:
> > > > but if the effect is that it will drive up the adoption rate for
> DMARC then I am clapping my hands.
> > >
> > > "Once verified, the BIMI file tells the email service where to find the
> > > sender’s logo and the email service pulls that logo into the inbox."
> > >
> > >
> > > I don't think this is anything about DMARC, this is about inbox
> > > tracking.
> >
> > Um. No.
> > 1: DMARC is required for BIMI.
>
> Good, DMARC is good, but we don't need yet another standard to get DKIM
> and SPF into the wider use.
>
> > 2: A proper setup will proxy and cache the logo. eg: for us all you can
> track through BIMI is if our logo service is alive and well...
>
> I hope you understand that most providers don't care if your logo
> service is alive and well.  Surely we don't need a spec for that.
>

Once upon a time, there was the X-Face header... I guess we could have
updated that for some modern version
and sent it with every message.  For better or worse, a lot of mail clients
these days include an avatar
for the author, and acquiring that avatar can be complicated.  For the
larger mailbox services, there was usually
a proprietary way to set that avatar... iirc, for Gmail that meant creating
a G+ account for the email address
and setting the account profile photo.  Obviously, a standardized way to
specify avatars across clients is
better than proprietary methods... but that leads to a bunch of other
questions when it comes to
validation and preventing "abuse" of the avatar... whether or not BIMI is a
great answer to that is probably
still TBD.


> Whether you understand it or not, if a proxy or cache fetches your logo,
> you can get very valuable data about inbox hit rate data, eg tracking.
>

I think this highly depends on your MUA and it's model.  If Gmail fetches
and
caches the images, and there's no method in BIMI for "per user" images, then
tracking BIMI images is nothing more useful than "gmail received my
message."

If the fetching comes from the individual client running locally on some
personal
computer or mobile devices, the tracking level would be higher... at least
on the
"first" hit, assuming they did any caching at the client level.

This is all based on my assumptions about how this is all implemented, I
haven't read the spec yet.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Marcel Becker via mailop]

On Wed, Jul 22, 2020 at 4:49 PM Jim Popovitch via mailop 
wrote:

>
> Good, DMARC is good, but we don't need yet another standard to get DKIM
> and SPF into the wider use.
>

Based on the data I see on the receiving side I disagree. But that's ok.


> I hope you understand that most providers don't care if your logo
> service is alive and well.  Surely we don't need a spec for that.
>

Exactly. I see this went over your head.

Whether you understand it or not, if a proxy or cache fetches your logo,
> you can get very valuable data about inbox hit rate data, eg tracking.


No, if you care about your users' privacy you would not implement anything
which would allow senders to do what you say BIMI enables.

This means in our case: If you -- as a sender -- publishes a BIMI logo all
you can track is when our logo service is fetching your logo.  Which might
be exactly once (ie: one time) when you update it. Our MUAs don't fetch
BIMI logos from the source.

So all it well tell you is

1: Our MTA saw mail coming in from your domain
2: We probably trusted you enough to see if you have a BIMI logo
3: We fetched that BIMI logo
4: A Verizon Media IP connected to your hosting server
5: Our system is alive and working (well, at least it's requesting logos)

That's it.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jim Popovitch via mailop]

On Wed, 2020-07-22 at 11:56 -0700, Marcel Becker via mailop wrote:
> 
> On Wed, Jul 22, 2020 at 11:35 AM Jim Popovitch via mailop  
> wrote:
> > On Wed, 2020-07-22 at 14:49 +0200, Sidsel Jensen via mailop wrote:
> > > but if the effect is that it will drive up the adoption rate for DMARC 
> > > then I am clapping my hands.
> > 
> > "Once verified, the BIMI file tells the email service where to find the
> > sender’s logo and the email service pulls that logo into the inbox."
> > 
> > 
> > I don't think this is anything about DMARC, this is about inbox
> > tracking.
> 
> Um. No.
> 1: DMARC is required for BIMI. 

Good, DMARC is good, but we don't need yet another standard to get DKIM
and SPF into the wider use.

> 2: A proper setup will proxy and cache the logo. eg: for us all you can track 
> through BIMI is if our logo service is alive and well...

I hope you understand that most providers don't care if your logo
service is alive and well.  Surely we don't need a spec for that.

Whether you understand it or not, if a proxy or cache fetches your logo,
you can get very valuable data about inbox hit rate data, eg tracking.

-Jim P.




___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Marcel Becker via mailop]

On Wed, Jul 22, 2020 at 4:06 PM Jim Popovitch via mailop 
wrote:

>
> That's inbox tracking, just like tracking pixels that are
> blocked by most reasonable and sane filters/firewalls.
>

No. It's not. And I explained why.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jim Popovitch via mailop]

On Thu, 2020-07-23 at 00:19 +0200, Jaroslaw Rafa via mailop wrote:
> Dnia 22.07.2020 o godz. 14:27:52 Jim Popovitch via mailop pisze:
> > "Once verified, the BIMI file tells the email service where to find the
> > sender’s logo and the email service pulls that logo into the inbox."
> > 
> > 
> > I don't think this is anything about DMARC, this is about inbox
> > tracking.
> 
> Do I understand correctly that this works on MUA level and not MTA?

To me, it seems pretty clear based on their text "pulls that logo into
the inbox".  That's inbox tracking, just like tracking pixels that are
blocked by most reasonable and sane filters/firewalls.

> Hope that reasonable MUAs won't implement it anytime soon (or maybe at
> all?), and when they do, it will be possible to turn this "feature" off (as
> it is with downloading images embedded in HTML emails). I'm putting
> "feature" in quotes because I see absolutely no benefit to the email user
> that may be provided by such a mechanism.

+1

-Jim P.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Marcel Becker via mailop]

On Wed, Jul 22, 2020 at 3:30 PM Jaroslaw Rafa via mailop 
wrote:

>
> Do I understand correctly that this works on MUA level and not MTA?
>
>
Long answer: http://bimigroup.org
Short answer: no, with BIMI you can't track our users.


>  I'm putting
> "feature" in quotes because I see absolutely no benefit to the email user
> that may be provided by such a mechanism.
>

It's ok if you don't see it. However the majority of our users prefer
meaningful avatars and brand logos in their email experience as it helps
them identify email senders and it helps with them with triaging.  That's
why us (and others) spend a lot of money on proprietary solutions. Which is
silly. BIMI allows senders to control their brand in a standardized way.
And it incentives email authentication.

Looks like a win-win-win to me.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Jaroslaw Rafa via mailop]

Dnia 22.07.2020 o godz. 14:27:52 Jim Popovitch via mailop pisze:
> 
> "Once verified, the BIMI file tells the email service where to find the
> sender’s logo and the email service pulls that logo into the inbox."
> 
> 
> I don't think this is anything about DMARC, this is about inbox
> tracking.

Do I understand correctly that this works on MUA level and not MTA?

Hope that reasonable MUAs won't implement it anytime soon (or maybe at
all?), and when they do, it will be possible to turn this "feature" off (as
it is with downloading images embedded in HTML emails). I'm putting
"feature" in quotes because I see absolutely no benefit to the email user
that may be provided by such a mechanism.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Marcel Becker via mailop]

On Wed, Jul 22, 2020 at 11:35 AM Jim Popovitch via mailop 
wrote:

> On Wed, 2020-07-22 at 14:49 +0200, Sidsel Jensen via mailop wrote:
> > but if the effect is that it will drive up the adoption rate for DMARC
> then I am clapping my hands.
>
> "Once verified, the BIMI file tells the email service where to find the
> sender’s logo and the email service pulls that logo into the inbox."
>
>
> I don't think this is anything about DMARC, this is about inbox
> tracking.
>

Um. No.
1: DMARC is required for BIMI. 2: A proper setup will proxy and cache the
logo. eg: for us all you can track through BIMI is if our logo service is
alive and well...
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop