Re: Would anyone be interested in a SA enhancing service?
Mark, This certainly does not add confidence in the "techniques no one else is using": ``` ⋮ supp...@junkemailfilter.com host darwin.ctyme.com [184.105.182.171] SMTP error from remote mail server after end of data: 550-FAKE-REJECT - TLD-FROM [click] is blocked - X=darwin ⋮ ``` Best regards -lem On 22 Sep 2017, at 8:40, Marc Perkel wrote: This is something I'm thinking about doing - providing a service that integrates into SA as a plug in and communicates with my servers to return a useful score enhancer. If there is interest my initial demo test will be just stuffing the subject line into a IP/port and returning a number where positive is spam and negative is ham. This would just be a proof of concept. The next level would be sending the message headers and eventually - the full message. Would need someone to write a simple plugin - not a perl guy - but how hard can that be? Would eventually need to be encrypted though. Starting with just the subject won't return a result all the time. Many request will return a 0 if it can't figure it out. If it does return a result that is significantly away from 0 it's probably right. And it is more likely to return a result from ham than spam confirming good email as good. Obviously - using the header and then the whole message will be more accurate. I'm using new techniques no one else is using. So - any interest? -- Marc Perkel - Sales/Support supp...@junkemailfilter.com http://www.junkemailfilter.com Junk Email Filter dot com 415-992-3400
Re: Would anyone be interested in a SA enhancing service?
On 22 Sep 2017, at 10:43, John Hardin wrote: He was only proposing the subject. Essentially it sounds like a subjectBL service. In the same message he said "The next level would be sending the message headers and eventually - the full message." Best regards -lem
Re: URI parser problems
On 5 Dec 2017, at 14:59, John Hardin wrote: How often would we see a valid registered domain name like "x.info" for example? This is not as rare as you would think. Those names are more expensive, but not insanely so. https://uniregistry.link/premium-domain-names/ Best regards -lem
Re: IADB whitelist - again
On 1 Mar 2018, at 10:29, Sebastian Arcus wrote: I know I have brought up this issue on this list before, and sorry for the persistence, but having 7 different rules adding scores for the IADB whitelist still seems either ridiculous, or outright suspect: (Disclaimer, I have inner visibility into IADB and its processes) I'm sorry, but it only seems "ridiculous" if you don't know how IADB works. Hopefully the details below will be helpful to assuage your worries. -0.2 RCVD_IN_IADB_RDNS RBL: IADB: Sender has reverse DNS record [199.127.240.84 listed in iadb.isipp.com] -0.1 RCVD_IN_IADB_SPF RBL: IADB: Sender publishes SPF record -0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in -0.0 RCVD_IN_IADB_SENDERID RBL: IADB: Sender publishes Sender ID record -0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system -0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record -0.1 RCVD_IN_IADB_VOUCHED RBL: ISIPP IADB lists as vouched-for sender It really raises some very uncomfortable questions regarding the impartiality of SA and/or its anti-spam capabilities. IADB provides a number of "signals" associated with the (vetted) practices of senders participating in its certification program. The purpose of the DNS data is to allow receivers to use those signals to augment their local anti-spam systems or to tweak the rules that are applied for filtering. Claiming that IADB is an "anti-spam" resource is inaccurate, as this is not its intended purpose. Rather, IADB allows for more precise filtering. Something that is also indirectly achieved, is that complaints sent to IADB's administration are escalated, researched and tracked until resolution, which can (and has!) include termination of the accreditation in the IADB. And by the way, this message is definitely unsolicited, and in now way we gave any sort of permission or consent to this company or its "affiliates" to email us - so the whole "All mailing list mail is opt-in" is nonsense. Then by all means, include ab...@isipp.com in your complaint -- They'll follow up with their customer and if applicable revoke their IADB membership. This is no different from an ESP sending to an "imported" email address. A complaint would be more helpful than this posting, as it would provide for more data to track the actual campaign that caused the issue, again, much like in the case of an ESP. From memory, I haven't seen a single complaint against the organization 199.127.240.84 is accredited under in more than two years. And why have "Sender has reverse DNS record" and "Sender publishes SPF record" as separate IADB rules - when SA itself already checks for these? Isn't this just a glaring way of pumping up SA scores for the IADB subscribers? In this case the IADB is confirming that at the time of their customer's accreditation, he claimed that his IP address should always have a valid rDNS and be covered by a valid SPF record. I happen to know of receivers that use lack of SPF/rDNS + these IADB records to bounce email. As I'm sure it was mentioned before, the default scores are (or try to be) a balance useful for general cases. I've been running with defaults for these particular rules for years with no ill effect. Best regards -lem
Re: Can't Get Removed From List
On 1 Mar 2018, at 11:54, Miles Fidelman wrote: [...] and sometimes turn on VERP to narrow things down to an individual. It's all made so much worse by morons who confuse the "spam" button with their "delete" key when using webmail from a big provider. Sigh...) Out of curiosity, why turn off VERP? Having it on all the time makes it much easier to deal with bounces. Best regards -lem
Re: IADB whitelist - again
On 2 Mar 2018, at 0:48, Sebastian Arcus wrote:
But why does SA have to expose a rule for each and every code IADB
provides?
So that users can implement their own policies if desired? So that
different rules can have a more granular effect on the inbound email
flow, without this being a simply binary affair (present, not present)?
More reasons come to mind, but it all boils down to exposing all the
available information to the users in order for them to make better
decisions.
As I mentioned in one of my prior responses, I personally know of
operations that use that data granularity to their advantage.
SA is an antispam solution, IADB is a facilitator for the marketing
industry (in spite of their continuous protestations on this list).
The goals of the two are not the same. Surely SA can decide by itself
what is really useful from a spam filtering point of view - not churn
out whatever it gets passed by marketing whitelists? SA uses other
whitelists (some may I say a lot more useful than IADB), and it only
exposes one or two rules for each.
I doubt IADB is in a position to dictate to anyone how to use (or not)
the data it provides. Not SA, not anybody else. Participants in IADB
(listees and users) voluntarily act so. As someone else in this thread
pointed out, IADB provides a useful ham signal.
I think the goals of both are fairly aligned. An antispam solution is
not good if it blocks wanted email. IADB is conveying information about
the stated policies / practices of the sending organization. Assisted
with this information, SA can take better decisions about specific
pieces of email.
Also, there is RCVD_IN_IADB_DOPTIN, so RCVD_IN_IADB_OPTIN may be
"someone somehow gave us your name somewhere" (i.e. "single opt-in")
rather than "we confirmed you actually want to receive our garbage"
("double opt-in").
So effectively pretty useless, as if you ever made the mistake of
forgetting to untick the "receive email from our carefully selected
partners" in the past, you will never be able to take that consent
back as your email address gets passed from entity to entity. Consent
to be emailed marketing material is a joke - and SA shouldn't be a
facilitator - otherwise its value as a spam filter is gone.
I fail to see how SA is acting as a facilitator in this case. SA ships
with rules that look up all the available information about a piece of
email and then, hands this information to a set of rules that decide
what should happen to that email. You're objecting to the scores being
applied to those rules because you received one email that you believe
doesn't align with the results of one of those rules and want to drop
those rules from the distribution.
What would happen if the email you wanted came from a mail server listed
in Spamhaus? Would you then argue for removing rules using Spamhaus from
SA altogether?
I would urge you to follow the advice of other list members and actually
report the misclassified spam so that involved parties can take action.
The scores appear hardcoded (50_scores.cf) vs. from masscheck
(72_scores.cf) so they may be *very* stale.
In that case maybe at least some of the rules should be removed then
In this case it seems to me that you already have a desired outcome and
will grasp at any shred of argument to justify it.
Best regards
-lem
Re: IADB whitelist - again
On 3 Mar 2018, at 3:54, Noel Butler wrote: On 03/03/2018 11:40, John Hardin wrote: On Sat, 3 Mar 2018, Noel Butler wrote: On 03/03/2018 04:40, John Hardin wrote: On Fri, 2 Mar 2018, Sebastian Arcus wrote: -0.2 RCVD_IN_IADB_RDNS RBL: IADB: Sender has reverse DNS record [199.127.240.84 listed in iadb.isipp.com] -0.1 RCVD_IN_IADB_SPF RBL: IADB: Sender publishes SPF record -0.1 RCVD_IN_IADB_OPTIN RBL: IADB: All mailing list mail is opt-in -0.0 RCVD_IN_IADB_SENDERID RBL: IADB: Sender publishes Sender ID record -0.0 RCVD_IN_IADB_LISTEDRBL: Participates in the IADB system -0.1 RCVD_IN_IADB_DKRBL: IADB: Sender publishes Domain Keys record -0.1 RCVD_IN_IADB_VOUCHED RBL: ISIPP IADB lists as vouched-for sender I am concerned when the default settings in SA effectively facilitate marketing companies to stuff my Inbox full of junk. -0.6 points makes the difference? Perhaps the default scores need to be reviewed, but simply having the rules isn't problematic. Have to agree with him, it can make all the difference in some cases, I'd prefer to see the rules stay, but all at score 0 -0.001 surely... 0 = disabled = breaks dependencies. I would argue that the current scores work very well for default installs. Likely, many users of SA lack the skills and data required to optimize their setups, so they benefit from receiving an install that will work well enough out of the box. That would be acceptable :) I disagree. Knee-jerk changes to rule scores based on a single report that contradicts what others are seeing is detrimental to the stability of SA. I'm either responsible or consult for filters that process ~10 million messages per day at a few corporate organizations where SA is used extensively in both the inbound and outbound. Not a particularly large number nor more than a few samples. Yet in all those cases I keep the default IADB scores in place as they work well with our rule sets. The only message that was marked as spam and triggered one of the IADB rules in my archive was sent by an ex-customer of the IADB. Based on my data, I'm seeing more false positives from other rules -- yet I'm not proposing to change the default SA configuration because of this. I understand that factors such as geography or my user base change effectiveness. Some rules are more or less effective due to bias https://esmtp.email/blog/2017/09/06/blacklist-bias/ At some point I did consider using the IADB rules as part of a metarule, but that proved not more useful than leaving the rules as they were, so I chalked that as a learning exercise and moved on. (I usually disable all whitelists anyway, especially those scoring influentially) And this is sound advice to anyone with the skills to tune their SA installation according to their specific needs. However this is probably not so true for people that installs SA and leaves the default configuration in place. Be it the one that SA ships or the one their preferred linux distribution provides. Best regards -lem
Re: [Offtopic] List From and Reply-To
On 30 May 2018, at 13:54, Bill Cole wrote: On 30 May 2018, at 14:51 (-0400), Grant Taylor wrote: Since Qualcom transferred the Eudora IP to the Computer History Museum and open sourced the source code, I expect that we will be seeing movement there in. I think I've seen some references to projects to resurrect the code base within days of the announcement. I wouldn't bet on a successful reanimation of the Eudora corpse for MacOS. My understanding from its developers at the time Qualcomm killed it in favor of re-skinning TBird (which also fizzled) is that the code was unmaintainable and required essentially a full rewrite to keep working on MacOS X given the ongoing rot in the Carbon APIs. Also, IIRC, messages were kept in mbox-like files. That would certainly not scale well. Best regards -lem
Re: [Offtopic] List From and Reply-To
On 30 May 2018, at 14:30, Bill Cole wrote: And if you can imagine this, both Thunderbird and MailMate choke on large mailboxes *even more* than Mail.app does. I haven't had MM "choke" on large mailboxes in recent years. I wish Benny would just declare a 2.0 release to make it clear that MM today is much more solid than it was in 2015. To further the point, one of the mailboxes I manage on this box has 95K+ messages. Apple Mail would choke to dead on this one. MM seems happy. I would give it another try as this is precisely the reason why I switched ~2 years ago. Best regards -lem
Re: List From and Reply-To
On 1 Jun 2018, at 5:12, @lbutlr wrote: On 30 May 2018, at 15:34, Luis E. Muñoz wrote: To further the point, one of the mailboxes I manage on this box has 95K+ messages. Apple Mail would choke to dead on this one. Not at all. I have folders in mail.app with more than twice that number of messages. Perhaps you were lucky. Those "chokes" where my main reason to move to MailMate. YMWV I suppose. Best regards -lem
Re: Help with own RBL
On 23 Jul 2018, at 23:40, Pedro David Marco wrote: On Tuesday, July 24, 2018, 12:07:52 AM GMT+2, David B Funk wrote: What kind of 'calculations with that IP' ? Thanks Dave... calculations are complex and done with a an external script that reads some files parsing them... Depending on how you intend your service to work, you could be creating a trap for your users. Feel free to fill the gaps in my understanding of what you intend, as after all I'm only working with the little you have shared in this thread so far. Normally, content scanners / MTAs will perform their DNS queries from behind a caching name server. The idea is that once a response to a particular question is known, that information can be kept around and reused at a much faster rate. This is (and has been) the recommended architecture since forever, with minor variations on where / how many caching name servers to deploy. On 23 Jul 2018, at 13:49, Pedro David Marco wrote: i am planning to run my own RBL with a nameserver, that when queried for an IP that is not in its database, does some calculations with that IP and replies accordingly [⋯] This means that the caching name server that is querying you will have to wait for _most_ answers. Without a way to know how long that process will take, it's possible that DNS clients will retry their questions, caching name server will as well and the whole thing becomes a tarpit that ends up wasting DNS resolver resources and generally slowing down mail delivery. Under that scenario, I would not recommend usage of the service you propose, but again feel free to any gaps in the above reasoning. The reason that in the traditional DNS list model you do all your calculations in advance and produce a zone is precisely to ensure that your service can respond quickly. Also note that DNS is designed to aggressively cache responses, so that repeated queries can be satisfied from a nearby cache. Wildcard DNS records could be leveraged to some extent, so as to have better control over caching of results. There are variations to the DNS list architecture that include pushing dynamic updates to keep the zone data updated as more / newer data is available. This could work for your use case -- you could consume a query log from your authoritative DNS servers, perform the required calculations and then push the updated response when the results are available. In the meantime, the DNS server would return NXDOMAIN (or perhaps something else if wildcard records are an option). Without knowing more about these calculations you intend to perform, this dynamic update approach would seem like a workable plan which might or might not fall within your expertise. In a distant past I built something like what you're describing although for a very different purpose. I ended up writing a name server in Perl (https://metacpan.org/release/Net-DNS-Method). This won't come near the required performance or behavior for a public facing DNS list with any sort of meaningful usage. Also consider that your DNS traffic will only go up, because if your DNS list gets mentioned around, people is going to add it to their configuration and forget about it. So, while this is likely not an ideal forum for this topic, I don't mind beating this horse for a little while. Best regards -lem
Re: Spam rule for HTTP/HTTPS request to sender's root domain
On 28 Feb 2019, at 11:53, Mike Marynowski wrote: There are many ways to determine what the root domain is. One way is analyzing the DNS response from the query to realize it's actually a root domain, or you can just grab the ICANN TLD list and use that to make a determination. What I'm probably going to do now that I'm building this as a cached DNS service is just walk up the subdomains until I hit the root domain and if any of them have a website then it's fine. This is more complicated than it seems. I have the t-shirt to prove it. I suggest you look at the Mozilla Public Suffix List at https://publicsuffix.org/ — it was created for different purposes, but I believe it maps well enough to my understanding of your use case. You'll be able to pad the gaps using a custom list. Best regards -lem
Re: Bug or feature? ;-)
On 25 Mar 2019, at 13:02, David B Funk wrote: For example, I've seen increasing amounts of spam which contain cloud based URLs in the body of the message (worthless for URIBL filtering) which may also contain URLs in the headers that are specific to the spammer source (thus viable targets for URIBL filters). A blanket prohibition against header URI mining would miss out on that data. +1
Re: Two types of new spam
On 3 Jan 2020, at 8:02, Kris Deugau wrote: I have a local rule adding a couple of points for anything coming direct-to-MX from any Amazon compute node, period. ⋮ Reality has intruded and there are in fact static IP assignments in the .compute.amazonaws.com tree (as well as ISP customers of ours who have websites with webforms on AWS, which send mail to their ISP mailbox - or sometimes their domain mailbox that's hosted with us) - otherwise I'd have scored the rule a lot higher. AWS offers the option to customize the PTR for elastic IPs. I very rarely see spam coming in from AWS ranges, having non-default PTRs. I use this to dial back my scoring a bit. Best regards -lem
Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
I am having a hard time reconciling the statements below. On 10 Jul 2020, at 13:21, Bill Cole wrote: We have no way of knowing how many people have thought less of SA because of terminology or whether any of those people might have otherwise become involved enough in the project to be contributors. [⋯] [⋯] We cannot do much for the bigger Real Problems that intersect with ours tangentially, [⋯] Changing a few labels in the code is something we CAN do. If ASF or the SA Project does not know "how many people have thought less of SA" – and I venture to say, doesn't know if _any_ people has – then deciding to engage in an activity that by your own admission does nothing for the "real problems" just because you can, makes little sense. This effort is simply wasting resources – and judging from recent events, breaking code – to gain what? To claim that ASF or the SA Project are somewhat sensitive because they changed a term that has been in use for 20+ years, but still has no non-whites or women or whatever the demographic de jure is in the board? I lived in a country where we allowed politics to interfere with technology. Things did not end well for either. Best regards -lem
Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
On 10 Jul 2020, at 12:29, @lbutlr wrote: If people are so fragile that they have to hold on to terms that are extremely offensive to some of their peers, they will get more spam. Oh noes. I keep hearing about this mythical people that get terribly offended by the use of these words. I've been working in IT since the 90s, and I've never actually seen one in real life. Do they really exist? -lem
Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
On 10 Jul 2020, at 23:51, Bill Cole wrote: "Terribly offended" is not what I've heard from anyone but the issue has been raised by Black colleagues a few times in multiple contexts, as Yet Another Minor Annoyance in a world stuffed full of such little things. Reminds me of left-handed people back when I grew up. In my time children would use chairs with integrated tables that would be fit for _either_ right- or left-handed people. Since there were more right-handed children, left-handed people would have to be more creative to adapt. So far we know: * Terms such as blacklist are a minor annoyance * There's no evidence of "how many people have thought less of SA" because of the use of the term "blacklist" * The change has a very non-zero impact _everywhere_ the software is deployed, as explained by other contributors to this ML If you want a direct first-hand explication, hunt down the recent extended rant on Twitter by Jackie Singh (@find_evil) triggered by the suggestion that the Black Hat conference was considering a name change and the blowback from that. Sure, are you talking about this? https://twitter.com/find_evil/status/1279945071371128834 – "The only person on that list who looks anything like me is the head of infosec at Fb" In here she posts a poll asking whether you would apply to be part of a board composing by people that don't look like you – https://twitter.com/find_evil/status/1279948068411052045 I can't answer for everybody of course, but I would not care how the current members of a group I wanted to join look. I have been part of many groups that contained people that did not look like me – professional and otherwise. Up to that point in the thread, it seems to me as someone looking for excuses. If I missed something, please point me to it. If I continue to look at her tweets, I find examples such as this: https://twitter.com/find_evil/status/1281735488437727233 – she seems surprised that someone would want to choose compatible people to work with. I don't know her or the context, and it is not my place to pass judgement, but I sincerely hope that whomever is in charge has better justification for this change than this lady's tweet rant. I do not know the rules under which ASF and SAP operate, but this thread is evidence that the position you are defending is far from widely shared, and to me, looks very poorly justified. Future software? Sure. Get rid of anything remotely offensive _the next time around_. Start by not using Assassin in the name, Apache in your organization and not mentioning any colors or university degrees. For existing, deployed, critical code? Don't change things to win cookie points. Best regards -lem
Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
On 14 Jul 2020, at 9:24, Kevin A. McGrail wrote: Here's a well researched and documented article from a medical journal on the topic with expert citations: https://jmla.pitt.edu/ojs/jmla/article/view/490 The abstract says it very well: "This commentary addresses the widespread use of racist language in discussions concerning predatory publishing. Examples include terminology such as blacklists, whitelists, and black sheep. The use of such terms does not merely reflect a racist culture, but also serves to legitimize and perpetuate it." You might want to note that it was included in JMLA Vol 106, No 4 (2018) in the **Commentary** section, along with pieces such as "Using Slack to communicate with medical students" "The relative citation ratio: what is it and why should medical librarians care?" "Transforming the systematic review service: a team-based model to support the educational needs of researchers" and "How to earn a reputation as a great partner" So yeah, quoting a magazine article on a scientific-sounding source is great and all, but perhaps the citation is not as authoritative as you think it is. If you actually go and read the paper, you will see that the "evidence" the authors present is based on other people's similarly sourced lists. There are no surveys, polls or other mechanisms to query the actual sentiment of the allegedly affected population. I also have to note that this piece was not peer reviewed, so there was no checks for methodology or accuracy – why would there need to be one, it's commentary after all. The quote provides proof that the topic is controversial. Not surprising judging by the length of the threads. I think it is also clear that there are two well defined poles on the issue. Dismissing those that oppose this change as "socially insensitive" or "racists", as has been seen in previous messages, is a transparent attempt to demonize the opposition. The same can be said of those dismissing the group that wants to edit the terms. Both group have their own motivations and I am pretty sure that each believe their motivations to be good. I believe so about my own and I'm sure you are the same. The vote of the PMC is being presented as an unsurmountable, immovable design from the gods that need to be followed by all. I think the PMC would be very wise to recognize that their prior vote lacked in consideration to all the positions and should be reconsidered after an appropriate opportunity to internalize the arguments that have been presented. After all, it has been recognized by some defenders of the term replacement, that this action is a mere gesture devoid of actual ability to change the real underlying problem – which is not constrained to the US, as some mentioned. Best regards -lem
Re: spamhaus enabled by default
On 14 Jul 2020, at 9:53, Kevin A. McGrail wrote: I agree with you about the idea of turning off everything and just delivering 100% commented configuration files.. I believe SA is a framework that must have walls & paint added to make it a house. Others want it ready to go as a pre-fab house aka a drop-in spam filter. As a project, the majority supports the drop-in model so I support the will of the PMC. The DNSBlocklist inclusion policy from 2011 has served us well with a lot of users and very few complaints. But if you think of edits it might need, we can always improve it. DNS Blocklists and the free for some model really help the drop in spam filter be effective. Are there any sort of numbers regarding how are the SA instances being installed? Is it mostly for distros? Direct installs? SA could ship the walls & paint as you describe, and leave to the distros the activation of such features they think their users will need, perhaps? In my case, it is helpful to pull SA from a Debian package and have it ready to go, with a reasonably complete configuration I can tweak. Starting from an empty config would be more complex to my average use case. Best regards -lem
Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave
On 14 Jul 2020, at 10:10, Kevin A. McGrail wrote: Kevin, If my words or position had any chance of modifying course, I would certainly do so again. But as you say further down, the "hullabaloo" of people trying to present other points of view, is pointless. Luis, the article I quoted was well research and included expert citations. I'd be interested if you can find me one that says it isn't racially-charged with expert citations, please. Especially one that has citations almost 50 years old that mention the problem. I meant actual research, where they reach out to affected populations, poll them and actually go through data to reach a conclusion. I am biased here with being an engineer and all, but that is the kind of evidence I would like to see. Quoting editorial pieces will lead us nowhere. The PMC voted to make the changes and make the changes 100% backwards compatible for no less than a year. They also won't be considered for removal until SA 4.1 is released. Therefore, to me the hullabaloo is fairly pointless. People stuck in the past who insist on not changing have that choice. The ONLY technical battle worth discussing is way down the road and that's whether enough movement has been made by 4.1 that delaying the removal of backwards compatibility. Understood. I will shut up now. Thanks for your time. -lem
Re: Screwed-up scoring
On 19 Jul 2020, at 10:54, Kevin A. McGrail wrote: Great question. That's really a third party rule. I would like to see it change eventually but maybe that's another phase. Thoughts? My thoughts are to delay any further social/political motivated name changes until after the extents of the current process are fully completed and understood. At that time, I would also suggest bringing in the opinions of the people who will bear the larger extent of the implementation – the users themselves – as well as the allegedly aggravated people on whose behalf you seem to favor the change. Best regards -lem
Re: BIMI pilot at Google
On 22 Jul 2020, at 23:14, Kevin A. McGrail wrote: However, I have questions of adoption rate, impersonation concerns, anticompetitive concerns, and privacy concerns. This just sounds like a commercial tracking pixel but the devil is in the details. The pilot will shake things out more I imagine. Money is of course a motivation here. This breathes some fresh air to CAs and opens the possibility to a few new interesting revenue streams for all the parties. I'm not sure on the potential for user tracking although I haven't read the material deep enough. The adoption will depend greatly on the price for the new certificates that will have to go with this service. I think a wait-and-see approach is the right thing to do here. This is what I'm advising others to do on this topic. Impersonation will of course be a very interesting topic. Best regards -lem
Re: BIMI pilot at Google
On 23 Jul 2020, at 0:56, Laurent S. wrote:
BIMI requires DMARC, which is much easier to implement if you are a
phisher creating a brand new domain .xyz with all the right SPF, DKIM,
DMARC and BIMI. Putting the paypal logo on that .xyz domain and there
you go. Your regular legit company will often struggle to implement
all
those correctly.
So either you display any BIMI and it's a phisher's wet dream (also a
nightmare to catch for a spam filter), or you only use a exhaustive
list
which will leave out most companies that don't have the (financial)
resources.
At some point, there is an entity that sanctions the relationship
between a domain name and the logo to be displayed. That entity is a CA
which will produce a new kind of certificate ("VMC").
This means that the trust model does include a number of CAs just as in
the browser PKI model.
Best regards
-lem
Re: BIMI pilot at Google
On 24 Jul 2020, at 12:22, John Hardin wrote: Does that certificate include some kind of checksum of the logo image itself? If not, what is to prevent a spammer from obtaining all the needed certificates, and then changing the logo image they are hosting to match the entity they are spoofing? Don't know yet, but probably the certificate will include a signature for the SVG file. I'm speculating at this point. Best regards -lem
Re: Possible spam sign
On 8 Dec 2020, at 12:47, Grant Taylor wrote: I think that the strict RFC specification does allow for multiple senders, but I don't remember how it's done and it's so rare that I'd accept the false positive. Yes to both. -lem
