I would have thought that was obvious.
Nice, the way this provided a mutual learning opportunity. One learns
why you did a thing. You learn that obvious to you isn't automatically
obvious to others.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
ma
On 12/9/2024 8:59 AM, John Levine via mailop wrote:
I ask because I've ben looking at a paper that asserts that the number
is about 50% and has been for a long time, which just seems wrong.
If the paper is published, what is the citation to it?
d/
--
Dave Crocker
Brandenburg InternetWorking
Does somebody have more insight if they tried to make it a standard, and
failed, so went on without one?
there is an "experimental" RFC9078. I understand, from discussions long
ago, that Google's messages do not conform.
The RFC was an ad hoc and independent effort, but with a fair amount o
On 11/22/2024 11:37 AM, Miles Fidelman via mailop wrote:
So, one answer to my problem is just to set up a copy of sendmail with
local delivery to an IPFS file. But, that leads me to wonder if
anybody is offering mail-gateways as a service - be they free gateways
or paid?
This thread has to
On 10/21/2024 4:39 AM, Alessandro Vesely via mailop wrote:
On Mon 21/Oct/2024 05:50:09 +0200 Dave Crocker wrote:
In other words, to get around DMARC fragility and false positive
damage, an intermediary must
1. Break DMARC, by changing the rfc5322.From address to be something
other
than
On 10/18/2024 7:38 AM, Bill Cole via mailop wrote:
The real original sender is preserved in the Reply-To here (and on
most lists using Mailman today.)
In other words, to get around DMARC fragility and false positive damage,
an intermediary must
1. Break DMARC, by changing the rfc5322.From
On 10/18/2024 6:16 AM, Paul Smith* via mailop wrote:
A valid SPF does not indicate it is not spam.
This is worth emphasizing. Some others have also pointed this out, but
it still is often missed:
If a an identifier is authenticated with a stream of messages, then that
stream of messages c
On 10/17/2024 10:00 AM, Alessandro Vesely via mailop wrote:
Missing a backup authentication method would make DMARC even less
reliable.
A backup method that adds complexity and breaks under significant,
common scenarios does not sound like a great backup method.
Hence my continuing query
On 10/16/2024 3:43 PM, Louis via mailop wrote:
DKIM+DMARC do not verify the return address. So backscatter spamming
would get more attractive to spammers,
From this sub-thread, I think I believe that simple use of SPF can be
useful for reducing back-scatter.
But this has nothing to do with
On 10/16/2024 11:22 AM, Michael Orlitzky via mailop wrote:
The killer feature of SPF is that I can tell somebody how to set it up
over the phone. Most small businesses send mail from one or two places,
and usually, I can google the appropriate "include:" for them. Once SPF
is passing, whitelistin
On 10/16/2024 11:13 AM, Brandon Long via mailop wrote:
he general theory is that a replay involves mail for a DKIM domain
coming from different sources/hops than it normally does. Having
spf/dkim both align
is usually a good indication that a message is not a replay,
ahh, that makes sense.
On 10/16/2024 10:55 AM, Brandon Long via mailop wrote:
The most meaningful utility of SPF at the moment I think is to help
identify DKIM replay cases.
I have tried to track the DKIM replay discussions, but do not recall
seeing a reference to SPF's being useful for this. Can you elaborate?
Folks,
Good morning. Take a breath and try this with a cup of coffee or tea...
1. The more features a specification has, the more opportunity for an
implementer to make an error, starting with the potential misreading or
ambiguities in the specification text. Also, the more expensive to do
On 10/14/2024 7:12 AM, Matus UHLAR - fantomas via mailop wrote:
"can be trivial"
For technology, (and most other contexts) "can be" is a code phrase for
"isn't". Especially when already deployed.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_
I wonder whether anyone has noticed that a thread like this demonstrates
that SPF is far from trivial?
d/
On 10/13/2024 2:47 AM, Gellner, Oliver via mailop wrote:
which denies everything as the redirect will never be reached.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocke
macros and the nesting/indirection, especially.
d/
On 10/11/2024 1:56 PM, Mark E. Mallett via mailop wrote:
The
macro handling, f
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mail
On 10/11/2024 12:49 AM, Matus UHLAR - fantomas via mailop wrote:
Yes, SPF has drawbacks. But it is still trivial to implement and
makes DMARC easier to implement as well.
Actually it isn't. And, really, it doesn't.
* It is trivial for a sender to generate an SPF record.
* It is also triv
On 10/11/2024 5:03 AM, Gellner, Oliver via mailop wrote:
The receiving system should validate DMARC at the edge, ie on the very
next hop after the signature has been applied, so the timeframe during
which the DKIM signature needs to be valid can be kept very short.
This would make DKIM more fr
On 10/9/2024 11:32 PM, Thomas Walter via mailop wrote:
On 09.10.24 21:59, Dave Crocker via mailop wrote:
Since the primary function of the SMTP Mail From command is to specify
an address for receiving email handling problem notices, alignment with
the rfc5322.From field domain would seem to be
On 10/10/2024 6:19 AM, Ralph Seichter via mailop wrote:
* Dave Crocker:
Longer-term use has, at least, operational import, for access to the
DKIM key and for access to the message in its signed form. Neither of
these is automatically cheap, given operational vagaries and given the
manipulations
On 10/10/2024 9:07 AM, Ralph Seichter via mailop wrote:
You call that attacking? 😂 Damn, but you're acting insecure. Also,
keep your ad hominem approach to yourself, I am not interested.
I just love how bullies respond to push-back. So interesting to see the
projections and contradictions the
On 10/10/2024 8:17 AM, Alberto Domenico Miscia via mailop wrote:
in a layered approach against messaging abuse, I think everything
plays its part.
In psychology, avoidance training is especially 'sticky' because the
subject does not test whether the thing that is (now) being avoided is
stil
On 10/10/2024 8:05 AM, Al Iverson via mailop wrote:
My answer to the question of why: To make it slightly harder for bad
guys to pick up and DKIM replay older messages.
My understanding is that the observed DKIM replay attacks have done the
replay very quickly -- maybe instantly -- upon origi
On 10/9/2024 11:57 PM, Matus UHLAR - fantomas via mailop wrote:
checking SPF is a fallback mechanism.
SPF is a fairly complex, fragile tool and it makes DMARC.. It's
inclusion in DMARC is always justified with language such as you used,
but I've never seen any data offered about just how us
On 10/10/2024 3:42 AM, Ralph Seichter via mailop wrote:
I love the idea of the X tag with DKIM to set an expiration date after
which the signature should no longer be considered valid.
Why is that, I wonder? A digital signature does not age, after all.
Either a signature matches the signed paylo
On 10/9/2024 3:47 PM, Al Iverson via mailop wrote:
I love the idea of the X tag with DKIM to set an expiration date after
which the signature should no longer be considered valid.
That feature is intuitively appealing. And I don't recall there being
any controversy about it when DKIM was dev
On 10/9/2024 12:49 PM, Al Iverson via mailop wrote:
this is a limitation
Al,
Perhaps I'm missing something basic. but...
Since the primary function of the SMTP Mail From command is to specify
an address for receiving email handling problem notices, alignment with
the rfc5322.From field dom
On 9/20/2024 11:57 AM, Michael Wise wrote:
Although ... if there is a standard header field that doesn't start
with an X-, would love to know what it would be.
I personally prefer the Comments: header, as documented in RFC-822 and
subsequent, but nobody else seems to use it.
As to the sys
On 8/29/2024 9:15 PM, Viktor Dukhovni via mailop wrote:
Rather, I'm saying that my
passwords are:
You are not representative of typical users. Anything that is designed
for you will be irrelevant for typical users.
It's fine to want features that are tailored to your preferences. it's
On 8/27/2024 3:59 PM, Michael Peddemors via mailop wrote:
hey should restrict MAIL FROM to only addresses on their email server?
why?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
m
On 8/23/2024 1:34 PM, Alex Shakhov via mailop wrote:
We are currently managing several domains that are experiencing
spoofing attacks, which led us to implement a p=reject policy.
In terms of the mechanical details, what exactly is the attack and how
is it affecting your email service?
We
On 8/15/2024 10:27 AM, Jaroslaw Rafa via mailop wrote:
Well... yes and no 🙂. The famous case of "500 mile email" is always worth
to mention...
https://www.ibiblio.org/harris/500milemail.html
The story is wonderful. I enjoy it every time it surfaces. However it
is also irrelevant to the curre
On 8/14/2024 3:17 PM, Slavko via mailop wrote:
Dňa 14. augusta 2024 13:48:38 UTC používateľ Dave Crocker via
mailop napísal:
Making a distance-sensitive assumption about traffic behavior is a suprisingly
bad idea for anything having to do with the Internet. Resources and their uses
can be
On 8/12/2024 1:20 AM, Viktor Dukhovni via mailop wrote:
For SUBMIT, the traffic is presumably from your own users, who are
rarely very far away,
Making a distance-sensitive assumption about traffic behavior is a
suprisingly bad idea for anything having to do with the Internet.
Resources and
On 6/5/2024 1:48 PM, Grant Taylor via mailop wrote:
I'll argue that SMTP is still simple.
Rather the language (protocol) that is spoken and the grammar (rules)
of how to speak SMTP are simple.
The language (protocol) is entirely separate from what is said using
said language (protocol).
On 5/18/2024 2:12 PM, Gellner, Oliver via mailop wrote:
Changing the existing DKIM specification is probably a big challenge.
Yes, but it can be done as a separate specification that is classed as
an 'update' to the DKIM spec.
fwiw, I've heard rumors of some industry folk wanting to produce
On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
Although some of these dangers have been known for a while (some parts
are even described in the RFC itself), things like the threat
landscape, our approach and the extent to which this can be abused
have changed. In our opinion previously sug
On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
Although some of these dangers have been known for a while (some parts
are even described in the RFC itself), things like the threat
landscape, our approach and the extent to which this can be abused
have changed. In our opinion previously sug
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
_
But In this case, envelope sender domain is different from domain in
header From: and then SPF checks don't apply to DMARC.
So, if you want to have proper DKIM, you must set From: to your domain
and DKIM-sign it.
To be finicky: DKIM does not care what domain is used in its d=
parameter.
On 3/21/2024 3:47 AM, Alessandro Vesely wrote:
Mailing lists modify messages in a de-facto standard way.
actually, they don't. or rather, there is more than one de-facto set of
modifications and therefore efforts to reverse the modifications is in
the realm of heuristics, which means someti
On 3/16/2024 1:31 PM, Slavko via mailop wrote:
And the same RCF clearly suggests to leave other (even invalid)
signatures untouched.
Which text in RFC 6376 says that?
Perhaps you are thinking of Section 6.1 which includes:
INFORMATIVE NOTE: The rationale of this requirement is to permit
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
https
On 3/8/2024 9:21 AM, Bill Cole via mailop wrote:
Yes: it is an old routing character
As such, some sites may misinterpret it in ways that are NOT
appropriate for SRS.
oh?
SRS is not a standard. If there are sites trying to do automated
interpretation -- other than the site that put the str
On 3/8/2024 9:21 AM, Bill Cole via mailop wrote:
Yes: it is an old routing character
As such, some sites may misinterpret it in ways that are NOT
appropriate for SRS.
oh?
SRS is not a standard. If there are sites trying to do automated
interpretation -- other than the site that put the str
On 3/8/2024 9:07 AM, Julian Bradfield via mailop wrote:
Is there any reason not to use the old routing character '%' instead?
Well, that's certainly a bit of ancient history. Fwiw, here's some
background on it:
I chose % for use in CSNet mostly because of its established postal use
IRL to
On 3/6/2024 10:13 AM, Bill Cole via mailop wrote:
support for SMTPUTF8 *in MTAs operating as MXs* is not widespread
enough to be useful except
Email has a long history of very poor compliance, coupled with recipient
demands that sender-side problems be dealt with using receiver-side
changes.
On 3/4/2024 4:50 AM, Andy Smith via mailop wrote:
but I don't relish trying to navigate inevitable issues
of disagreement between us all on what is actually best practice
Perhaps when there are significant constituencies for competing choices,
merely add a comment about it, explaining the natu
On 2/24/2024 5:25 PM, Philip Paeps via mailop wrote:
On the whole, I think not meddling with the body (and not breaking
DKIM) provides an improved mailing list experience. We don't have to
rewrite the From: header, and "reply" works the way the poster
intends. Neither the mailing list softwa
On 2/15/2024 1:36 PM, Robert L Mathews via mailop wrote:
not using COI and hitting spamtraps as a result, for messages that in other
respects are wanted by recipients and transactional
Not using COI, as well as hitting spamtraps are both solid, affirmative
indications of spam. Full stop.
Yo
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
On 2/12/2024 7:16 PM, John Levine via mailop wrote:
Right now if
you get a message from Gmail or Yahoo with a valid DKIM signature, you
can be quite confident that it came from whichever Gmail or Yahoo user
is in the From header.
By way of using this as an example of the need for larger syste
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 accelerat
On 2/9/2024 1:16 AM, Taavi Eomäe via mailop wrote:
My hope is that at some point we would be able to do "BIMI" with just
S/MIME signed mail at some point. Seems like a good combination.
1. S/MIME has been around for 25 years. While it has gained
respectable amounts of implementation in MU
On 2/9/2024 6:50 AM, Scott Mutter via mailop wrote:
I think the issue with SPF and DKIM is that it's becoming trivial for
ALL email to have SPF and DKIM that pass muster. At which point,
you're right back where you started.
At the start, we had no way to assess email streams. Good mixed wit
On 7/14/2023 11:21 AM, Grant Taylor via mailop wrote:
Suggest you might consider changing the topic, if you want to argue
the various nuances and complexities of SPF/DKIM/DMARC etc..?
And break existing threading and avoid any ignore thread filters that
people have put in place?
That seems
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 hou
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, and to grow their own food.
Or we might take a somewhat more modern view of life and deal
pragmatically with
On 7/11/2023 2:54 AM, Slavko via mailop wrote:
Setup and get it working is not different than other services,
not more easy nor more hard, just different. It requires to learn
how to setup particular SW as in other services. What i see as
more hard with email is:
+ it is not one protocol (SMTP
On 6/23/2023 9:13 PM, Al Iverson via mailop wrote:
What if we just got to the heart of the matter and admitted that
greylisting is useless 2023?
This prompts wondering whether it's time for the email anti-abuse
community to have a discussion about mechanisms that used to be useful
but are n
On 11/8/2022 2:03 PM, Mary via mailop wrote:
've seen this before, when the header above the From header is broken:
Authentication-Results: server;
dkim=blah reason="blah";
From: "Valid"
To: mailop
The parser thinks that the From: header is part of the previous header, thus
i
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 experie
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 tech
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 technolog
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 after
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 rate
-
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 be
On 9/12/2022 1:29 PM, Grant Taylor via mailop wrote:
I consider it self hosted if you run the MTA software on a system and
are responsible from there up the stack.
While that view has some logic to it, it probably isn't the most
practical view, especial in a forum like this and a topic like
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 ques
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 regularl
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 authorized
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 domain name
> author
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. W
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 cam
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 add
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 maili
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 FU
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 t
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
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
relevant
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
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/19/2022 2:41 AM, Alessandro Vesely via mailop wrote:
On Wed 18/May/2022 03:01:49 +0200 Dave Crocker via mailop wrote:
Note that, in spite of DMARC, we still do not have per-user
authentication.
The FTC report required *domain-level* authentication. They wrote:
...
They were assuming
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, hetero
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 m
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 penetra
On 5/17/2022 5:01 PM, Justin Scott via mailop wrote:
I seem to recall a list of "reasons your anti-spam proposal won't work"
http://craphound.com/spamsolutions.txt
Some of us send it pretty automatically to whatever the next proposal is.
Cory just told me that he got it from somewhere
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’ abiliti
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 attem
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'
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 sa
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.
A
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 o
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'
speci
1 - 100 of 141 matches
Mail list logo
