Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
Hi Tim On Thu, Jan 11, 2024 at 05:02:01PM -0600, Tim Starr via mailop wrote: > The image has to be specified in the DNS, and it has to be certified w/ a > VMC. The VMC certification process includes checking if it's trademarked. That's why the process started with: get a trademark. Also such a check is manual work, so pretty weak. I found https://datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang, which seems reasonably okay. Just the requirement to use HTTPS to fetch such a document and use CRL stand out. And to answer my other question: The VMC certificate actually embeds the image itself. Bastian PS: Please don't send me copies of e-mails. I explicitly set Mail-Followup-To in mine. -- Immortality consists largely of boredom. -- Zefrem Cochrane, "Metamorphosis", stardate 3219.8 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] BIMI boycott?
> 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
Re: [mailop] BIMI boycott?
> 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] MUA images, avatars and icons
> It can be useful to show X-Face or Gravatar from certain mails, such as > those coming from a (trusted) forum (hint to Louis: it may be useful to > be able to configure the images to show for specific senders) Will be implementing something like this later on, probably for workplace platforms. All my emails from GitHub discussions for example have the GitHub logo right now, making individual users not that visually distinguishable. GitHub sends a user header from which I could fetch the associated users' avatar. I didn't know about the X-Face header! Is that something still in use? What kind of configurability would you be looking for? Aside from overriding through contacts of course. Groetjes, Louis Op donderdag 11 januari 2024 om 22:31, schreef Ángel via mailop : > On 2024-01-11 at 17:43 +0100, Jaroslaw Rafa wrote: > > 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? > > Every MUA must be able to show whatever it wants. And each one will > have its own some design goals. Hopefully sane and consistent, albeit > they might end up being chaotic at times. > > I see how some people may like seeing images along the profiles. I also > see the benefit of (configurable) multiple sources for that. > > For example, Microsoft Outlook shows the profile images from Active > Directory. This can be useful for instance for sorting out which guy > was each one in a meeting, and makes much more sense to prioritize that > over a BIMI logo of your own company, which would be relatively > pointless to shown on pretty much every email. > > But if I have set a photo for that Contact (e.g. a Clown face for my > boss), it should be showing *that* (albeit I might face some pushback > from my boss or HR if they figure out). > > It can be useful to show X-Face or Gravatar from certain mails, such as > those coming from a (trusted) forum (hint to Louis: it may be useful to > be able to configure the images to show for specific senders), > > But, as Laurent mentioned, this is going to be prone for impersonation, > with a goal of leading uers to phishing, BEC fraud, etc. > > A really important point here is that the BIMI logos themselves *must > be validated* by the MUA. I have been looking at the draft [1], and > while there are references to a "BIMI Evidence Document", which is > supposed to validate whether I am allowed to use a trademarked logo (at > an undefined jurisdiction, I was unable to find its specification, it > simply says that "These are defined in a separate document". > > Perhaps Seth can bring some light on this. I think that is an integral > part of the BIMI security properties, that it MUST contain both a hash > of the allowed logo (or logos), the jurisdiction(s) where it was > validated (see below) and the linked sender domains (plus whatever > properties that are needed for validate that through PKI). > > And the receiver steps miss that they MUST compare the logo with the > Evidence Document, and reject it if it mismatches. > > Otherwise, I could register a trademark IOCBYHZ with a random logo, and > switch the contents of the url to a PayPal one. People are already > registering ludicrous names as trademarks to enter the Amazon Brands > program [2]. Registering a trademark and logo, plus acquiring a > certificate, for a targeted attack to a company has an higher bar. But > a successful CEO fraud could easily make it worth. Not to mention if > the goal were to compromise the company, exfiltrate its trade secrets > or launch a supply-chain attack. > > Having the certificate specify on which jurisdiction is the trademark > registered would at least palliate “a bit” the known issue of colliding > names/trademarks on separate jurisdictions[3][4] by allowing the > clients to ignore (by policy) those in shady offshore jurisdictions > and, ideally, showing only those pertinent to the user... if the MUA is > somewhat able to figure out what "pertinent" means. > > Would that mean that companies may need to register an international > trademark or apply for the same one in different jurisdiction for BIMI > to show to their different users around the globe? (along the > associated registration and certificate costs). I'm afraid that may end > up being the case. > > Maybe some MUA will overlap a flag onto
Re: [mailop] BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
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] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
On Thu, Jan 11, 2024 at 5:14 PM Jay Hennigan via mailop wrote: > Attempting to legally prevent MUA developers from displaying logos > competing with BIMI's > approved logos, likewise. > Nobody is doing or expecting this. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
On 1/11/24 15:27, Jaroslaw Rafa via mailop wrote: As I wrote previously, the only method to prevent this is a (totally unrealistic) *legal prohibition* for MUA developers to display any other images than certified BIMI logos. Not possible. Wasn't there an idea similar to BIMI a while back that involved some sort of haiku in the header? IMNSHO, expecting spammers to abide by legal prohibitions and intellectual property laws is a non-starter. Attempting to legally prevent MUA developers from displaying logos competing with BIMI's approved logos, likewise. -- Jay Hennigan - j...@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
Dnia 11.01.2024 o godz. 17:02:01 Tim Starr via mailop pisze: > The image has to be specified in the DNS, and it has to be certified w/ a > VMC. The VMC certification process includes checking if it's trademarked. > So, in order for a trusted brand's BIMI logo to get spoofed, the email > would have to be DMARC-authenticated and the logo specified in the DNS > would be the one presented to the mailbox provider when they do DNS lookups > on the authentication domains. Under the assumption that that he MUA will display *only certified BIMI logos* and not any other "avatars" with the emails, ever. How are you going to force MUA developers to do that? Assume the recipient uses a MUA that displays not only BIMI logos, but eg. avatars from Gravatar service as well. The attacker just sets as his Gravatar picture the logo he wants to spoof. Then sends mail to the recipient. Recipient sees a familiar logo (without BIMI being used at all!) and assumes the mail is genuine. As I wrote previously, the only method to prevent this is a (totally unrealistic) *legal prohibition* for MUA developers to display any other images than certified BIMI logos. Not possible. -- 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] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
The image has to be specified in the DNS, and it has to be certified w/ a VMC. The VMC certification process includes checking if it's trademarked. So, in order for a trusted brand's BIMI logo to get spoofed, the email would have to be DMARC-authenticated and the logo specified in the DNS would be the one presented to the mailbox provider when they do DNS lookups on the authentication domains. IOW, the only real way to do it would be with account takeovers. If you can hack into the ESP account of a trusted brand, then you can send fully-authenticated email for that brand, with its BIMI logos. The biggest spoofing risk here is with really inclusive SPF records that include an entire cloud SMTP provider's IP ranges, where other senders also send from those ranges, and they can then send SPF-authenticated email w/ a trusted brand's return-path domain, which would then pass DMARC and BIMI. But that's a security risk already, BIMI doesn't make it worse. Cloud SMTP providers need to do a better job of locking down the sending domains their clients can use to prevent that. However, even there, if the DNS accounts of domain owners can be hacked into, authorization of domains can be faked, too. But, again, that's an existing risk, which BIMI doesn't make any worse. -Tim On Thu, Jan 11, 2024 at 2:35 PM Bastian Blank via mailop wrote: > On Thu, Jan 11, 2024 at 01:45:19PM -0600, Tim Starr via mailop wrote: > > To elaborate on Marcel's answer, so he doesn't have to waste time > > explaining it all over again, the "different logo" won't be displayed by > > the mailbox providers, because it's not the authenticated one. > > What prohibits them from making it authenticated? A trademark check? > > Bastian > > -- > Extreme feminine beauty is always disturbing. > -- Spock, "The Cloud Minders", stardate 5818.4 > ___ > 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] MUA images, avatars and icons
On 2024-01-11 at 17:43 +0100, Jaroslaw Rafa wrote: > 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? Every MUA must be able to show whatever it wants. And each one will have its own some design goals. Hopefully sane and consistent, albeit they might end up being chaotic at times. I see how some people may like seeing images along the profiles. I also see the benefit of (configurable) multiple sources for that. For example, Microsoft Outlook shows the profile images from Active Directory. This can be useful for instance for sorting out which guy was each one in a meeting, and makes much more sense to prioritize that over a BIMI logo of your own company, which would be relatively pointless to shown on pretty much every email. But if I have set a photo for that Contact (e.g. a Clown face for my boss), it should be showing *that* (albeit I might face some pushback from my boss or HR if they figure out). It can be useful to show X-Face or Gravatar from certain mails, such as those coming from a (trusted) forum (hint to Louis: it may be useful to be able to configure the images to show for specific senders), But, as Laurent mentioned, this is going to be prone for impersonation, with a goal of leading uers to phishing, BEC fraud, etc. A really important point here is that the BIMI logos themselves *must be validated* by the MUA. I have been looking at the draft [1], and while there are references to a "BIMI Evidence Document", which is supposed to validate whether I am allowed to use a trademarked logo (at an undefined jurisdiction, I was unable to find its specification, it simply says that "These are defined in a separate document". Perhaps Seth can bring some light on this. I think that is an integral part of the BIMI security properties, that it MUST contain both a hash of the allowed logo (or logos), the jurisdiction(s) where it was validated (see below) and the linked sender domains (plus whatever properties that are needed for validate that through PKI). And the receiver steps miss that they MUST compare the logo with the Evidence Document, and reject it if it mismatches. Otherwise, I could register a trademark IOCBYHZ with a random logo, and switch the contents of the url to a PayPal one. People are already registering ludicrous names as trademarks to enter the Amazon Brands program [2]. Registering a trademark and logo, plus acquiring a certificate, for a targeted attack to a company has an higher bar. But a successful CEO fraud could easily make it worth. Not to mention if the goal were to compromise the company, exfiltrate its trade secrets or launch a supply-chain attack. Having the certificate specify on which jurisdiction is the trademark registered would at least palliate “a bit” the known issue of colliding names/trademarks on separate jurisdictions[3][4] by allowing the clients to ignore (by policy) those in shady offshore jurisdictions and, ideally, showing only those pertinent to the user... if the MUA is somewhat able to figure out what "pertinent" means. Would that mean that companies may need to register an international trademark or apply for the same one in different jurisdiction for BIMI to show to their different users around the globe? (along the associated registration and certificate costs). I'm afraid that may end up being the case. Maybe some MUA will overlap a flag onto the trademark, or allow choosing which countries / trademarks it will honor. Although I doubt the users that the feature intends to protect would notice the small differences due, anyway. It's a complex issue with no easy solution. I feel we are back at the all EV Certificates scenario, with all the same unsolved problems. We just replaced names with logos. 1- https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification 2- https://nymag.com/intelligencer/2023/01/why-does-it-feel-like-amazon-is-making-itself-worse.html 3- https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/ 4- https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
On Thu, Jan 11, 2024 at 01:45:19PM -0600, Tim Starr via mailop wrote: > To elaborate on Marcel's answer, so he doesn't have to waste time > explaining it all over again, the "different logo" won't be displayed by > the mailbox providers, because it's not the authenticated one. What prohibits them from making it authenticated? A trademark check? Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
> To elaborate on Marcel's answer, so he doesn't have to waste time > explaining it all over again, the "different logo" won't be displayed by > the mailbox providers, because it's not the authenticated one. You're right -- I was in error on that because I forgot about that point. Thanks, Tim, for reminding me of this. > -Tim > > On Thu, Jan 11, 2024 at 1:11PM Marcel Becker via mailop > wrote: > > > On Thu, Jan 11, 2024 at 10:58AM Randolf Richardson, Postmaster via mailop > > wrote: > > > >> > >> They could > >> easily afford set up a company, get a Trademark, and then use a > >> different logo image when sending their junk eMails. > >> > > > > No, that's not how VMCs and BIMI set ups at participating mailbox > > providers work. > > ___ > > 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] Contact for TWC
Thanks, we were able to resolve the issue. Is there anyone here from Mediacom? We are seeing similar issue with their domains. From: mailop On Behalf Of Tarun Singh via mailop Sent: Wednesday, January 10, 2024 12:11 PM To: mailop@mailop.org Subject: [EXTERNAL] [mailop] Contact for TWC Importance: High Hello All, Do we have folks from TWC (Time Warner Cable) on this distro? Can you please reach out to me offline? Thanks -Tarun ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
To elaborate on Marcel's answer, so he doesn't have to waste time explaining it all over again, the "different logo" won't be displayed by the mailbox providers, because it's not the authenticated one. -Tim On Thu, Jan 11, 2024 at 1:11 PM Marcel Becker via mailop wrote: > On Thu, Jan 11, 2024 at 10:58 AM Randolf Richardson, Postmaster via mailop > wrote: > >> >> They could >> easily afford set up a company, get a Trademark, and then use a >> different logo image when sending their junk eMails. >> > > No, that's not how VMCs and BIMI set ups at participating mailbox > providers work. > ___ > 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
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] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
> On Thu, Jan 11, 2024 at 10:58AM Randolf Richardson, Postmaster via mailop < > mailop@mailop.org> wrote: > > > > > They could > > easily afford set up a company, get a Trademark, and then use a > > different logo image when sending their junk eMails. > > > > No, that's not how VMCs and BIMI set ups at participating mailbox > providers work. Come to think of it, trademarks can also be registered by individuals in at least some jurisdictions, so setting up a company is just one step that could be avoided. (A scammer could use a stolen ID to register the trademark, or get one of their employees to sign the necessary paperwork, etc.) Are the participating mailbox providers not offering any services where a customer manages their own domain and DNS? -- 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? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
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] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
On Thu, Jan 11, 2024 at 10:58 AM Randolf Richardson, Postmaster via mailop < mailop@mailop.org> wrote: > > They could > easily afford set up a company, get a Trademark, and then use a > different logo image when sending their junk eMails. > No, that's not how VMCs and BIMI set ups at participating mailbox providers work. ___ 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
> 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?
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] [EXTERNAL] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations
Adding to Udeme's comment. There could be other criteria the MBP could use to determine if the message should display BIMI-associated imagery. This could be domain reputation, spaminess, manual validation, and so on. Just because a domain says it wants to use the Paypal logo doesn't mean it will automatically happen, even if they are actually Paypal. I'm not sure we should try to cover the case where the MUA does something outside of spec and/or recommended practices. Slippery slope and all that. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -Original Message- > From: mailop On Behalf Of Laurent S. via mailop > Sent: Thursday, January 11, 2024 9:34 AM > To: mailop@mailop.org > Subject: [EXTERNAL] 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://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!CQl3mcH > X2A!AlCoE6X5OSgmkeerA4AeCyCJjGJBF4- > 2cJsrAnATCK1y6uqMECI5MpRlPlonIaxicOQK-EIw2c2PfKqxHSY$ ___ 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
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?
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?
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
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
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
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
[mailop] [ADMIN] Re: BIMI boycott?
I'm back, and I want people to play nicely. Whilst differences of opinion are fine, this thread (as it did in 2020) is rapidly veering very close the line of acceptability. Remember, please, that whilst we have a mix of members from single users running their own system, thru enthusiasts running small systems for a few people, companies with a few thousand customers, academic institutions with tens or hundreds of thousands, the 500lb gorillas with millions or billions - we also have members whose job it is to SEND email rather than ensure their users receive it. You may not like this. You may think they're the reason for all your ills. Articulate it nicely, or... *plonk* Thanks! And a Hippy New Year to you all :) Graeme ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] Re: BIMI boycott?
Dnia 10.01.2024 o godz. 14:05:26 Marcel Becker via mailop pisze: > > https://bimigroup.org/mailbox-providers/ Marketing blah-blah only. No actual explanation. -- 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?
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?
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
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
> > 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?
> > 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]
