On 5/5/2024 9:49 AM, Andrew C Aitchison via mailop wrote:
DKIM proves that you did send it.
No it doesn't.
But that certainly is a common misconception about DKIM.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
. The alignment with the From: domain is a DMARC requirement,
not DKIM.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
sometimes they will work and
sometimes they won't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
. Also
note the reference to mailing lists, as being discussed here.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
DKIM policy is
reject or quarantine.
That's DMARC, not DKIM.
DKIM does a signature. DMARC uses it (and/or SPF).
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
the string there --
that's the problem, not the choice of a semantic character.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
the string there --
that's the problem, not the choice of a semantic character.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
to mean "in care of", as well as to use a character that was not yet
a 'special' for any (or at least most) operating system command interfaces.
Note that @, for Arpanet mail, and !, for UUCP, were already taken. So
the range of choices was limited in 1979...
d/
--
Dave Crocker
B
, and yet a thread like this one here continues to
happen.
Universal Acceptance (UA) - ICANN <#>
https://www.icann.org/ua <https://www.icann.org/ua>
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mas
the nature of the choices, the
tradeoffs they have, and why there are preferences for each.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo
be helpful for the Subject field
to show that a mailing list is involved, though that will typically
break DKIM...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop
.
You want to mitigate that assessment. Don't. Because it doesn't mitigate it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On 2/12/2024 7:13 PM, Mark Milhollan via mailop wrote:
On Mon, 12 Feb 2024, Dave Crocker wrote:
Certificates are not magic symbols of safety.
I never said they were. I said, paraphrasing though I see I should
have been explicit, that Google could increase the number of people
using S/MIME
practice makes it a reasonable assessment, at least
for mail signed by some platforms.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo
On 2/12/2024 4:37 PM, Mark Milhollan via mailop wrote:
On Mon, 12 Feb 2024, Dave Crocker wrote:
1. S/MIME has been around for 25 years. While it has gained
respectable amounts of implementation in MUAs, it has achieved use
only in specialized environments.
Google could greatly
s with its use, and how
exactly do you believe it will achieve that?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
their crappy email.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
like people changing email addresses to get around filters.
This is exactly the type of breakage, caused by From field re-writing,
that has been entirely ignored, in spite of being cited with some
frequency. It is, to coin a phrase, an inconvenient truth.
d/
--
Dave Crocker
Brandenburg
On 7/14/2023 11:20 AM, Paul Smith wrote:
On 14 July 2023 18:24:45 Dave Crocker via mailop
wrote:
We need to 'encourage' people to run their own mail servers, not scare
them away..
We also need to encourage people to do all the servicing for their car,
to build their own house
with the realities of the division of labor.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
of them are not well cooperative
+ outdated or incomplete/wrong guides
+ lack of (open source) tools to work with eg. MIME mails
In case this helps:
RFC 5598: Internet Mail Architecture
https://www.rfc-editor.org/rfc/rfc5598
<https://www.rfc-editor.org/rfc/rfc5598>
d/
--
Dave C
but are no longer worth the effort (or that might actually be
counter-productive.)
The likely benefits will be simplification on the technical and
operations side, and possibly better outcomes.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
it;y in this
thread: The blank line means that the From field is in the body, not
the header.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On 9/19/2022 11:59 AM, Brandon Long wrote:
On Sat, Sep 17, 2022 at 11:10 AM Dave Crocker via mailop
wrote:
On 9/16/2022 7:35 PM, Brandon Long via mailop wrote:
> So, while AOL & Yahoo were the vanguard for mass consumer
providers, the problems were already being expe
On 9/19/2022 8:07 AM, Alessandro Vesely via mailop wrote:
ARC is the authentication of choice in this case because, being
devised for this task, it is supposedly straightforward to configure
for it, whereas whitelisting after SPF or DKIM smells like a hack.
ARC is moderately complicated
On 9/17/2022 8:12 AM, Jim Popovitch via mailop wrote:
and DMARC was to fix what DKIM broke,
and DKIM was to fix what SPF broke, and SPF was to fix (what was SPF
suppose to fix, oh yeah... provider greed and irresponsibility).
DKIM didn't break anything. It has limitations, as do all
On 9/16/2022 7:35 PM, Brandon Long via mailop wrote:
For 30 years, we allowed mailing lists to modify messages and take
partial "ownership" of them (the mailing list gets the
* Small factual nit: Networked email was 50 years old, last year.
Mailing lists appeared almost immediately
On 9/14/2022 7:49 AM, Thomas Walter via mailop wrote:
If I have to check a spamfolder for false positives every day, I can
just have them delivered to my inbox. The spamfolder does not have an
advantage then.
Actually, it does, depending on how bad the false-positive and
false-negative
-
On 9/12/2022 7:01 PM, Al Iverson via mailop wrote:
Because I disagree with the whole premise
that self hosting mail is impossible today
I believe 'impossible' is not the prevailing sentiment. If it were, the
various folk who run such services probably would be doing something else.
I
On 8/26/2022 3:38 AM, Laura Atkins via mailop wrote:
Signing with 2 identical d= but different s= is unusual, but I don’t
think it’s prohibited anywhere.
It's certainly not prohibited in the DKIM specification.
I also don’t think the RFC addresses anything about mail disposition
in case of
On 7/23/2022 1:17 AM, Laura Atkins via mailop wrote:
On 23 Jul 2022, at 05:18, Bill Cole via mailop wrote:
On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400)
Luis E. Muñoz via mailop
is rumored to have said:
On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote:
I
On 6/28/2022 3:32 AM, Alessandro Vesely via mailop wrote:
I agree that would've been better than ARC. However, it'd still need
to know which recipients are mailing list supporting DKIMv2 and
operate accordingly. For example, on a reply-all the MSA should split
the message and sign it
On 6/22/2022 4:21 PM, Rob Nagler via mailop wrote:
On Tue, Jun 21, 2022 at 9:54 PM Dave Crocker wrote:
> None of the relevant systems have C-R as a component, so I'm guessing
> you mean this as an exemplar of the background stuff that happens
> magically, to get an actor to be a
On 6/21/2022 8:25 PM, Rob Nagler via mailop wrote:
Dave Crocker continues:
> The existing repertoire of relevant email tech specs are for
> authentication, except for SPF, which includes authorization of SMTP
> client engines, and DMARC, which include rfc5321.From field do
On 6/20/2022 8:59 AM, Rob Nagler via mailop wrote:
IMHO, the problem is a lack of a public trust model. ARC, SPF, and DKIM
do not solve the trust problem. There should be some FOSS that
implements the model (just like certbot implements ACME).
We still need virus/spam detection algorithms.
On 6/21/2022 9:20 AM, Alessandro Vesely via mailop wrote:
Mail forwarded by gmail, for example, has an X-Google-DKIM-Signature but
is not otherwise DKIM-signed. It is ARC-sealed. (Brandon Long
explained why a couple of years ago[*]).
Hmmm. Sorry I missed his message when it originally
On 6/21/2022 12:07 AM, Alessandro Vesely via mailop wrote:
RFC 5321, sect. 3.9 Mailing Lists and Aliases
...
When a message is delivered or forwarded to each address of an
expanded list form, the return address in the envelope ("MAIL
FROM:")
MUST be changed to be the
On 6/20/2022 9:05 AM, Paulo Pinto via mailop wrote:
>ARC is motivated by the cases where DKIM/SPF/DMARC information about the
>author/originator get broken.
I'm truly trying to find a justification to break DKIM/SPF on a message
after it is sent.
SPF is designed to be extremely fragile.
On 6/19/2022 7:04 PM, Ángel via mailop wrote:
Mailing lists must use their own envelope from when injecting list
messages to the subscribers.
Should and do. Not must. There's no formal requirement, just practical
choice.
But, yeah, changing the rfc5321.mailfrom to an addresss of the
It occurred to me that it might help for me to provide more context to
the questions I asked. I was possibly relying too much on the thread
context...
On 6/18/2022 3:40 PM, Noel Butler via mailop wrote:
I was a very early (even in testing) user of SPF, It's rather commical
reading these
On 6/17/2022 6:17 AM, Paulo Pinto via mailop wrote:
tldr; what ARC tries to address is already correctly handled by
DKIM/SPF/DMARC if used as designed.
None of those provide an authenticated handling record in the message.
ARC is motivated by the cases where DKIM/SPF/DMARC information about
On 6/17/2022 9:35 PM, Brandon Long via mailop wrote:
DKIM implies ownership that one doesn't want to use for relaying.
FWIW, that interpretation of DKIM semantics goes beyond the DKIM
specification, which, instead says:
"DomainKeys Identified Mail (DKIM) permits a person, role, or
On 6/19/2022 12:02 AM, Noel Butler via mailop wrote:
I dont respond to smart arse trolls who have nothing better to do than
try bait people, youve been around long enough to know exactly what I
was talking about its nothing to do with lists its email standards if
you dont understand that put
On 6/18/2022 3:40 PM, Noel Butler via mailop wrote:
As for forwarding, SPF is only a problem if you dont follow standards
and re-write
Hi.
You don't indicate what kind of rewriting you mean. It probably doesn't
matter, since you seem to feel that mailing lists have to follow some
On 5/19/2022 7:57 AM, Luis E. Muñoz via mailop wrote:
In this case, not really.
oh. gosh. we've been wrong about this. for 20 years.
d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On 5/19/2022 6:58 AM, Luis E. Muñoz via mailop wrote:
On 19 May 2022, at 9:41, Dave Crocker via mailop wrote:
So, sure. We haven't been able to do individual-level blocking, so let's add a
requirement for an additional bit of complexity. That will probably make this
mechanism work a lot
On 5/19/2022 6:30 AM, Luis E. Muñoz via mailop wrote:
On 19 May 2022, at 8:42, Dave Crocker via mailop wrote:
[⋯] Domain level is not sufficient.
But is it though? A corporate providing email to its own users should certainly
be able to express a policy that it does not want to allow any
On 5/18/2022 11:01 AM, John R Levine wrote:
but even though both are technically sound, nobody uses them outside of a
few specialized communities which suggests that it's not going to happen.
btw, neither does cert management in a way that has been shown to scale
across the open,
On 5/17/2022 8:44 PM, Luis E. Muñoz wrote:
I wonder if this one
( ) Public reluctance to accept weird new forms of money
should be complemented with a crypto version, to avoid triggering those that
hate cryptos being compared with money?
Indeed. In fact it seems clear to me that this is
On 5/18/2022 11:01 AM, John R Levine wrote:
Hm, your copy of the message appears to have been cut off. Here's the
rest which you presumably missed:
I didn't.
Your opening echoed my language, in a form casting it as taking
exception to it.
I was noting that your choice for interpreting
On 5/18/2022 10:32 AM, John Levine wrote:
> It appears that Dave Crocker via mailop said:
...
Note that, in spite of DMARC, we still do not have per-user
>> authentication.
We have at least two flavors in PGP and S/MIME,
When something exists for 30 years and has market pe
On 5/17/2022 4:40 PM, Anne Mitchell via mailop wrote:
"why we can't do that", culminating in "the Commission concludes that, under
present conditions, a National Do Not Email Registry in any form would not have any beneficial
impact on the spam problem. It is clear, based on spammers’
On 4/29/2022 10:55 AM, Brandon Long wrote:
On Thu, Apr 28, 2022 at 9:39 PM Dave Crocker via mailop
mailto:mailop@mailop.org>> wrote:
Perhaps:
An MTA that is relaying a message SHOULD NOT attempt to repair
problems it detects with the message.
If t
On 4/28/2022 1:52 PM, Dave Crocker via mailop wrote:
If writing a formal specification, yes, one needs careful language.
This isn't that exercise.
This prompted me to consider language that might be suitable for an RFC.
Perhaps:
An MTA that is relaying a message SHOULD NOT attempt
On 4/28/2022 10:54 AM, John Levine via mailop wrote:
It appears that Dave Crocker via mailop said:
So, rather than changing the message, do simply relaying of the
(unchanged) message, but also send a notification about the problem,
back to the SMTP Mail-From address.
Well, that's one
On 4/28/2022 1:25 PM, John R Levine via mailop wrote:
On Thu, 28 Apr 2022, Dave Crocker wrote:
Actually, for the current discussion, there is only a single issue:
Should an intermediate relay get fussy and modify the substance
of a message?
That is one way to look at it, but as I
On 4/27/2022 6:57 AM, Paul Vixie via mailop wrote:
i have a slight preference for "either relay it or bounce it but don't
do a little of both". and i must observe that in robotic e-mail,
mail-from is often deliberately unreplyable. the only reliable error
path is at the the end of DATA.
On 4/27/2022 6:30 AM, Michael Kliewe via mailop wrote:
Exactly. The best and easiest solution is to contact the sender and tell
them to fix the problem, by either using "relaxed/relaxed" or by
reducing the line length to <=998 bytes.
So, rather than changing the message, do simply relaying
On 4/26/2022 5:48 PM, Dan Mahoney via mailop wrote:
The pedantic* answer here might be to make postfix smart enough to not apply
this logic*if* there's a DKIM signature with simple/simple in the
canonicalization.
It is always tempting to react to a specific anomaly by adding a 'fix'
On 4/26/2022 10:37 AM, Brandon Long via mailop wrote:
Transforming messages for relay is not likely to go well.
This seems an essential point.
It would be worth pressing for some discussion on it, and if possible
develop as strong a rough consensus on as possible.
There is likely an easy
On 4/26/2022 2:49 PM, Robert L Mathews via mailop wrote:
I suppose the argument in favor of it is that some other places you
might forward to will reject a message solely because it has line
lengths longer than allowed, so you can't win either way.
This is an example of how it is useful to
On 4/14/2022 5:22 PM, John R Levine wrote:
On Thu, 14 Apr 2022, Dave Crocker wrote:
Without knowing what mail software your provider is running, there is
no way to tell.
The benefit of an over-the-wire approach to specification writing is
that all that matters is what goes... over the wire
On 4/14/2022 2:09 PM, John Levine wrote:
It appears that Dave Crocker via mailop said:
On 4/14/2022 1:27 PM, John Levine via mailop wrote:
Is anyone aware of any mail system that implements Delivered-To
the way this document describes,
Your query, to this list arrived at my inbox
On 4/14/2022 1:27 PM, John Levine via mailop wrote:
Is anyone aware of any mail system that implements Delivered-To
the way this document describes,
Your query, to this list arrived at my inbox with these header fields:
Return-Path:
Delivered-To: d...@dcrocker.net
Received: from
On 4/14/2022 8:19 AM, Michael Peddemors via mailop wrote:
One thing that isn't addressed in that Dave, is cases where the
Delivered To address exists, and the message is routed back out the
internet,. Still seeing cases in the wild where the Delivered To is
added, but it isn't really the
Folks,
This was just issued. It will aid in evaluating handling history of a
messsage, especially through aliasing and mailing list sequences.
d/
Forwarded Message
Subject: RFC 9228 on Delivered-To Email Header Field
Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT)
From:
On 4/10/2022 5:26 PM, Philip Paeps via mailop wrote:
They support +-addressing and also offer something called "subdomain
addressing":
Following Fastmail documentation, I just tried the subdomain scheme and
it was rejected.
(The + scheme works.)
d/
I tested it, before posting my note saying they supported it.
d/
On 4/9/2022 9:26 AM, Tara Natanson via mailop wrote:
FASTMAIL -
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On 4/8/2022 6:40 AM, Tara Natanson via mailop wrote:
Where would you recommend hosting your domain so that you can pop/imap,
use "+" addressing, isn't spammer friendly,
Fastmail seems to support + addressing.
Hostinger does not.
d/
___
mailop
I hope it is obvious that this represents a structural problem, not just
an odd occurrence.
I'm sure I'm not the only one who also has suffered this type of
inability to get incorrect use of my address fixed because I wasn't a
'member' of the sending organization.
d/
On 3/16/2022 7:40 AM,
On 2/2/2022 7:31 PM, Scott Mutter via mailop wrote:
Why is it impossible to take a look at what Instant Messaging protocols,
SMTP, SMS do that make them successful and then blend those together
into a new "email-like" system?
Because replacing widespread systems is vastly harder than one
On 1/31/2022 7:43 AM, Al Iverson via mailop wrote:
In this scenario, my mailing list manager strips the original DKIM
signature and applies its own, as I am now the party responsible for the
message. (I also rewrite the from address.) This has worked fine for me,
but not everyone is a fan of
On 1/31/2022 9:43 AM, Geoff Mulligan via mailop wrote:
1. If a recipient on an email message is both in the To: or Cc: and on
the mailing list, should the listserver send the message to the recipient:
a) By default
b) Not by default (but configurable)
c) Never
by default.
On 12/29/2021 4:40 AM, yuv via mailop wrote:
Unfortunately, e-mail walled gardens are a Well Known Bad Idea.
RFCs-based e-mail is a walled garden. We lawyers call this the Rule of
Law.
That's very creative. Not what is normally meant, and not even slightly
useful. But very creative.
FYI
sigh.
d/
Forwarded Message
Subject:Re: [IP] Bizarre GDPR/CCPA scam spam from Princeton researchers
Date: Tue, 21 Dec 2021 14:10:45 -0800
From: Edward Hasbrouck
Organization: The Practical Nomad
To: i...@ip.topicbox.com
I got through today to the
On 12/17/2021 6:40 AM, yuv via mailop wrote:
* On the big issue, the ENROLLMENT OF HUMAN SUBJECTS WITHOUT CONSENT
into the study, I have been told that "[t]he IRB determined that our
study does not constitute human subjects research."
I haven't gone through an IRB process. So I've no idea
On 12/11/2021 3:33 PM, Sebastian Nielsen via mailop wrote:
The idea here was that it would be easier kind of, to create DKIM validation
method, that only the sender and the sender's server need to be take part it,
and then any user can validate the email, regardless of lack of support in the
On 11/23/2021 6:11 PM, John Levine via mailop wrote:
On 11/22/21 12:25 PM, Michael Peddemors via mailop wrote:
...
I'm going to lump "Site Finder" in the malicious category. No NXDOMAIN
for you! Have this add instead!!!
That was ten years ago, you know.
2003. Closer to 20.
On 10/26/2021 9:56 AM, John Levine via mailop wrote:
On the one hand, historically the opt-out has been in the body of the message,
but a whole
lot of mail programs now recognize List-Unsubscribe and give you an option in
the frame of
the message which is easier to recognize
1. But others
On 10/18/2021 12:35 PM, Brandon Long wrote:
Anyways, I stand by that there is unlikely to be overlap between people
blocking your
smtp server and your customers accessing your imap server...
yup. and that's why I asked for a detailed explanation from anyone
claiming a linkage. Haven't
On 10/18/2021 10:56 AM, Brandon Long wrote:
On Sat, Oct 16, 2021 at 2:35 PM Dave Crocker via mailop
mailto:mailop@mailop.org>> wrote:
On 10/15/2021 5:40 PM, Grant Taylor via mailop wrote:
> The motivation for spreading service IPs across different /24
prefixes
On 10/15/2021 5:40 PM, Grant Taylor via mailop wrote:
The motivation for spreading service IPs across different /24 prefixes
is so that if
The issue here is not the generic one of using multiple IPs. It is
about using them to separate IMAP from SMTP. That's an entirely
different matter.
On 10/15/2021 6:44 PM, Grant Taylor via mailop wrote:
I can see a hypothetical scenario where a client is running a firewall
that is filtering connections based on IP reputation. So if an SMTP
server is erroneously listed, said firewall might block the IP, thereby
blocking the client's
On 10/15/2021 5:40 PM, Grant Taylor via mailop wrote:
On 10/15/21 5:37 PM, Dave Crocker via mailop wrote:
Yes, but... That's the point that is intuitively reasonable which
doesn't make real sense to me, after thinking about it.
What doesn't make real sense to you? The relation
On 10/15/2021 2:17 PM, Grant Taylor via mailop wrote:
The question of IP-based reputation intuitively seems like it might
make a difference, but I'm not seeing a practical sequence in which is
actually does.
I'd think that you would need the IPs to be in different /24 prefixes to
avoid any
On 10/15/2021 11:10 AM, Grant Taylor via mailop wrote:
That way when you want to migrate something, you can migrate it
independently of everything else and you aren't forced to migrate
everything at one time.
This has always been the preeminent reason for separate naming that I've
be
effective.
The much larger address space makes it too easy for a bad actor to jump
around and, therefore, not develop a bad reputation associated with the
address. So non-history features are made more strict.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ay of dealing
with this DMARC-generated issue:
Author Header Field
https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/
https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/
DMARC Use of the RFC5322.Sender Header Field
d/
--
Dave Crocker
Brandenburg InternetWor
On 1/28/2021 7:22 AM, Jaroslaw Rafa via mailop wrote:
Dnia 28.01.2021 o godz. 07:11:54 Dave Crocker via mailop pisze:
It's possible that a recipient's MUA could 'know' about this
convention and would be able to deconstruct it, possibly with the
goal of discerning the email address
I'm just guessing.
It might do this well or poorly, but it's still entirely outside of the
formal standards.
So it might be a bug, but not an RFC violation. Or it might be really
clever and useful, in spite of surprising you. But I did say 'might'.
d/
--
Dave Crocker
Brandenburg Inter
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
to hear the basis for
you assessment.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
be taken as 'marketing' of a new capability pretty much beg for
queries about the basis for its benefits.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop
On 7/27/2020 7:59 AM, Marcel Becker via mailop wrote:
On Mon, Jul 27, 2020 at 3:55 AM Dave Crocker <mailto:d...@dcrocker.net>> wrote:
My quote above did not claim that. I explained why we participate
in BIMI.
Perhaps you have data to support a claim of differential user
behavio
On 7/26/2020 7:31 PM, Marcel Becker via mailop wrote:
On Sat, Jul 25, 2020 at 11:12 AM Dave Crocker via mailop
mailto:mailop@mailop.org>> wrote:
On 7/22/2020 3:45 PM, Marcel Becker via mailop wrote:
> However the majority of our users prefer meaningful avatars and
data like this is mostly misleading.
You need to be able to demonstrate that there is efficacy for the
general user population.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https
. Whether it it will have an effect on
end-user deception is a different matter.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
On 7/25/2020 2:06 PM, Jaroslaw Rafa via mailop wrote:
Dnia 25.07.2020 o godz. 13:21:02 Dave Crocker via mailop pisze:
DKIM is intended for use by receiving filtering engines, not
end-user evaluation.
Apparently you believe that displaying security-related information
to end-users is helpful
like Gmail - that
displays DKIM verification result). Isn't this a better approach?
DKIM is intended for use by receiving filtering engines, not end-user
evaluation.
Apparently you believe that displaying security-related information to
end-users is helpful?
d/
--
Dave Crocker
Brandenburg
and substantial history that it isn't.
To the extent anyone disagrees with this assessment, it would be quite
helpful to see the data.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https
1 - 100 of 104 matches
Mail list logo
