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.s
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 InternetWo
h a fair amount of
participation in the IETF.
Besides Google, Microsoft already has a similar faciliaty in email.
Sure would be nice for them to adapt to the RFC specification...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bluesky: @dcrocker.bsky.social ***
mast: @dcrocker@
waying, is to look for what
information is lost in the transition.
If the two mail services really are different -- and hence need
gatewaying rather than just relaying -- some information will be lost in
one or both directions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
**
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
to permit.
Collateral damage abounds.
DMARC has turned the From field into what the Sender field was intended
to provide; it now primarily servies to specify the handling platform.
If the author address survives in the From: field, that is merely a
collateral benefit, but not required.
d/
--
Da
can be assumed to have no 'outside' sources. This
let's you evaluate the stream as if there is no 'noise' to the stream.
What it does not tell you is whether the actor associated with the
identifier is good or bad.
d/
--
Dave Crocker
Brandenburg InternetWorkin
about practice, rather than theory. Where are
the numbers that show this utility to be actually significant?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https
with DMARC's goal.
Perhaps eep simple SPF as an independent capability, but definitely
remove it from DMARC.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
the sender, but a) it
ignores issues with receivers, and b) it ignores multi-hop scenarios.
3. DKIM -- right. So difficult, almost no one uses it. And it's not as
if the rest of email operations have gotten complicated, right?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
he network layer.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
orate?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
ncremental
benefit is real and substantial, never-mind enough to warrant adding its
complexity to the mix of email operations challenges.
Please consider: If SPF were deprecated, was would be the actual,
significant effects on email anti-abuse processes?
d/
--
Dave Crocker
Brandenburg Inter
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
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
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
work is trivial, where fully considering the
details and implications actually are quite far from trivial.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mail
fragile and its use more restricted.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
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
tions they develop.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
avoided is
still a threat.
Do you have any indication that the use of x= is actually effective for
reducing replay attacks?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop
ttack discussions on the DKIM list, this point was
noted.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
t just how useful it is.
Including it adds to DMARC's operational complexity and when SPF is
relied on, it makes DMARC's scope of use smaller, given the path
limitations.
If SPF support were eliminated from DMARC, what actual change in DMARC
utility would this have?
d/
--
Dave
systems do to the messages they handle.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
complexity and complexity breeds errors.
No?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
field domain would seem to be secondary, at best.
So while the facts you list are no doubt accurate, calling this a
'limitation' seems problematic.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mail
't recall any controversy about it. The
larger lesson to take from it is to think very hard about longer-term
transitions that it might require. In this case, going from
'non-standard' to 'standard' rendered the construct significantly
problematic.
--
Dave Crocker
B
ces. it's
not fine to think they will apply to others, at any scale.
It's also not fine to think it will be cost effective for a mass-market
product to cater to your unrepresentative preferences. They might, but
they also might not.
d/
--
Dave Crocker
Brandenburg InternetW
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
nts. As a small example, some originators set
p=reject inappropriately. That is, the originating sites are not
configured or operated well enough to make reject that right choice.
So, yes, your DMARC 'policy' can be ignored or adjusted.
d/
--
Dave Crocker
Brandenburg InternetW
ant to the current topic.
The current topic is about defining timeouts based on expected
distance-related performance. The story is, instead, about sometimes
having a bug depend on distance.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@masto
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
-sensitive assumptions might make sense is when
the interaction is known to be -- and must be --- part of a LAN that
both parties are on. Maybe.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing
there has been community demand for a change, it's been added
to the existing service. No doubt, at some point, that won't be
possible. But don't demand replacement until /after/ the enhancement
effort has failed. It's happen. It just hasn't, yet.
--
Dave
DMARC has broken the From: field, so it now
serves as what the Sender: field was designed for.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
community-wide pressure to
deprecate it. First through operational pressure and then with an
update to the spec.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://
community-wide pressure to
deprecate it. First through operational pressure and then with an
update to the spec.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://
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.s
meter. 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
means 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@mailo
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
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
d postal use
IRL 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 1
long time, 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:@dc
g 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/lis
s to 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@m
.
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
ver operational 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.mail
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
er to identify 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 hou
gmatically 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
t 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.s
ust to document it explicit;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 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
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. 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
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 146 matches
Mail list logo
