On Sat, Aug 12, 2023, at 11:48 AM, John Levine wrote:
> It appears that Jesse Thompson said:
> >> This of course requires that the recipient SMTP server can't simply
> >> reject the incoming email after the MAIL FROM because SPF checks do
> >> not match, they actually need to receive the email so
It appears that Jesse Thompson said:
>> This of course requires that the recipient SMTP server can't simply
>> reject the incoming email after the MAIL FROM because SPF checks do
>> not match, they actually need to receive the email so they can check
>> ARC and DKIM headers...
>
>During my 19 ye
I'm woefully behind on this list. Apologies if these points have already been
made.
On Wed, Jul 19, 2023, at 4:42 PM, Tero Kivinen wrote:
> Wei Chuang writes:
> > 2) The proposed language calls out "“alumni forwarders”, role-based email
> > aliases, and mailing lists" for consideration by receive
I have stumbled into the same position as Barry, or maybe a more extreme
one. I send no bounce messages, and very few 5xx responses.
In my environment, one of the more common causes of non-delivery is a
terminated employee. It has not seemed like automated messages sources
pay much attention t
On Sun 23/Jul/2023 22:12:55 +0200 Barry Leiba wrote:
Without bounces the sender is in the dark.
Yes, if the sender is a human.
Not so, if the sender is a mailing list and that sender will then
unsubscribe the intended recipient.
Also not so, if the sender is a malfeasant who may use the bounce
Yes sir, I’m convinced. Some of my more conservative customers who take
security deadly serious won’t even bounce a DMARC failure with a helpful
message. It’s discard. I respect the person I’m thinking of who hates bouncing.
He’s appropriately paranoid for a InfoSec manager.
> On Jul 23, 2023,
> Without bounces the sender is in the dark.
Yes, if the sender is a human.
Not so, if the sender is a mailing list and that sender will then
unsubscribe the intended recipient.
Also not so, if the sender is a malfeasant who may use the bounce
message for bad purposes.
It's very clear to me that
> On Jul 7, 2023, at 8:48 AM, John Levine wrote:
>
> It appears that Barry Leiba said:
>> I, too, prefer MUST to SHOULD there, but it was clear to me that we
>> will not reach rough consensus on MUST, but that we can reach rough
>> consensus on SHOULD.
>>
>> I do like your suggestion of sil
> On Jul 6, 2023, at 12:04 PM, Barry Leiba wrote:
>
> As I've said before, I think we should specify what we think is right,
> and allow implementers to make their decisions. We can't and won't
> police them.
No way. It wouldn’t be possible even if we all made it our life’s work to be
stand
On Fri 21/Jul/2023 17:18:50 +0200 Scott Kitterman wrote:
On July 21, 2023 3:14:58 PM UTC, Alessandro Vesely wrote:
Maybe one day there will be a DMARC with batteries included, where implementers
ship default configurations which are effective out of the box. While I don't
know how to get th
On July 21, 2023 3:14:58 PM UTC, Alessandro Vesely wrote:
>On Fri 21/Jul/2023 10:22:06 +0200 Matthäus Wander wrote:
>> Murray S. Kucherawy wrote on 2023-07-08 02:44:
>>> "SHOULD" leaves the implementer with a choice. You really ought to do what
>>> it says in the general case, but there might
On Fri 21/Jul/2023 10:22:06 +0200 Matthäus Wander wrote:
Murray S. Kucherawy wrote on 2023-07-08 02:44:
"SHOULD" leaves the implementer with a choice. You really ought to do what
it says in the general case, but there might be circumstances where you could
deviate from that advice, with some p
On Fri, Jul 21, 2023 at 1:22 AM Matthäus Wander wrote:
> > "SHOULD" leaves the implementer with a choice. You really ought to do
> > what it says in the general case, but there might be circumstances where
> > you could deviate from that advice, with some possible effect on
> > interoperability.
Murray S. Kucherawy wrote on 2023-07-08 02:44:
"SHOULD" leaves the implementer with a choice. You really ought to do
what it says in the general case, but there might be circumstances where
you could deviate from that advice, with some possible effect on
interoperability. If you do that, it i
On Wed 19/Jul/2023 23:42:55 +0200 Tero Kivinen wrote:
Wei Chuang writes:
2) The proposed language calls out "“alumni forwarders”, role-based email
aliases, and mailing lists" for consideration by receivers. How should
receivers be aware that traffic failing authentication should be reconsidere
Wei Chuang writes:
> 2) The proposed language calls out "“alumni forwarders”, role-based email
> aliases, and mailing lists" for consideration by receivers. How should
> receivers be aware that traffic failing authentication should be reconsidered?
> Mailing-lists sometimes uses RFC2919 List-id
FWIW I think this language is an improvement over the prior language but I
would like to point out two concerns:
1) Specifying receivers with "MUST NOT reject" in Section 8.6
"Interoperability Considerations" presumably to to downgrade a p=reject to
quarantine with does carry new security risk. I
> The issue is not about lists being second class. What lists do to a message
> is a privileged function, because
> modifying a message can be done maliciously as easily as it can be done
> innocently. So the real problem
> is that DMARC demoted them from privileged to non-privileged by exposi
On Thu, Jul 13, 2023 at 6:11 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I did not say "life isn't fair" to be rude, but as a call to acknowledge
> the reality that exists rather than the reality you wish you had.
>
So what I'm hearing, again, is "Lists should get with the t
I did not say "life isn't fair" to be rude, but as a call to acknowledge
the reality that exists rather than the reality you wish you had.
We know that a large portion of email is unsolicited, unwanted, or
malicious. Consequently, there is no right or certainty of delivery. To
get delivery, yo
On Thu 13/Jul/2023 10:20:00 +0200 Murray S. Kucherawy wrote:
On Wed, Jul 12, 2023 at 6:20 AM Douglas Foster
wrote:
Does anyone believe that things will change if we publish an RFC which
says "Verizon Media MUST change to p=none"? I don't.
It would be absurd to make such a directed statemen
On Wed, Jul 12, 2023 at 6:20 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Does anyone believe that things will change if we publish an RFC which
> says "Verizon Media MUST change to p=none"? I don't.
>
It would be absurd to make such a directed statement. I trust you're
sim
Does anyone believe that things will change if we publish an RFC which says
"Verizon Media MUST change to p=none"? I don't.
Lists have been hurt by the move to authenticated email. Point taken.
However, the world is not going back to the good old days,.
There is no hope for a list solution to a
Hi,
Le 07/07/2023 à 23:58, John R Levine a écrit :
>
> Why is it up to the recipient systems (the ones that do not care) to
> make life easier for lists? Mailing list packages already do lots of
> analysis of bounce messages. How about if they fix their bounce
> processing to recognize DMARC fa
Hi,
Le 08/07/2023 à 20:24, Scott Kitterman a écrit :
>
> You can equally argue that these receivers are merely following the policy
> advice provided by the sending domain (it has reject right in the name) and
> this problem is entirely generated by sender's inappropriate use of p=reject.
>
>
Hi,
Le 07/07/2023 à 21:09, Scott Kitterman a écrit :
> Doesn't sieve happen during delivery, after the message has been accepted?
> Is so, I don't think it's a useful comparison to make.
>
> The lack of bounce/rejection messages results in messages that vanish and
> undermines the reliability
It's actually not even enough to check when you subscribe, though that
will help keep the user from being surprised later. But you also have
to check every time a message is posted to the list, because anyone's
domain could have changed to p=reject recently.
And anyway, yes, the IETF considered t
Barry Leiba writes:
> > 2) As others have observed, the mailing list problem is
> > exclusively an evaluator error. An evaluator's job is to allow
> > safe and wanted messages while blocking unsafe or unwanted
> > messages.
>
> I disagree. As I and others have observed, those creating the problem
> To Murray's observation about fairness, my thoughts:
I don't see any use of the word "fair" in the message from Murray that
you quote.
> 1) Life is not fair.
This is impolitely dismissive. Please don't do that.
> 2) As others have observed, the mailing list problem is exclusively an
> evalu
To Murray's observation about fairness, my thoughts:
1) Life is not fair.
2) As others have observed, the mailing list problem is exclusively an
evaluator error. An evaluator's job is to allow safe and wanted messages
while blocking unsafe or unwanted messages.
3) The problem can be solved by s
On Mon 10/Jul/2023 17:50:54 +0200 John Levine wrote:
FYI, the IETF's mail relay for role accounts like WG chairs breaks
DKIM signatures. It's a bug, but it took quite a while to realize what
the problem was, since some signatures get through OK. It's an old
python library helpfully tidying up th
> Another consideration is that a non-standard, internal blocking would have
> been
> effective only for their users. Perhaps they though they were doing the rest
> of the world a favor by following standard protocols. Had that MUST NOT been
> in place then, /perhaps/ we'd have spared ourselves
It appears that Barry Leiba said:
>> Is “generally” true here? I think I have seen exceptions to DKIM signatures
>> being valid on relayed
>> messages, although I can’t dig up any examples right now.
>
>You seem to be answering the question you're asking. I know of none
>of these relays that br
On Sat 08/Jul/2023 20:13:44 +0200 John Levine wrote:
It appears that Richard Clayton said:
They then moved on to just using random identities from the same domain
as the recipient. This led a great many Yahoo users to believe that a
great many other Yahoo users had been compromised, leading t
> I’m one of those people who prefer for “xxx considerations” sections to be a
> descriptive discussion
> of the xxx issues and not contain new normative requirements.
I disagree, and certainly the Security Considerations sections are
normative and often use BCP 14 key words.
> the statement abo
Murray S. Kucherawy writes:
> On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> Consequently, the problem remains: How does an evaluator distinguish
> between a legitimate list and a malicious attack?
>
> If we had a reliable answer to that,
The point isn't to place blame. The point is to specify how to
maintain interoperability, and in the case of DMARC p-reject there are
two places where we can lessen the interop problems: telling the
senders not to use p=reject in inappropriate conditions, and telling
the receivers to consider the
On 7/8/2023 3:22 PM, Tero Kivinen wrote:
Scott Kitterman writes:
You can equally argue that these receivers are merely following the
policy advice provided by the sending domain (it has reject right in
the name) and this problem is entirely generated by sender's
inappropriate use of p=reject.
T
Our solution approach is binary: either we fix the list problem by doing
less authentication, which is Barry's proposal, or we fix the list problem
by doing alternate authentication.Alternate authentication is the one
we need to pursue, because the other approach has already been rejected by
On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Malicious impersonation creates a need for authentication. If the list
> makes changes that disable the originator's authentication, then it is the
> list's problem to find a way to convince the recipie
On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Consequently, the problem remains: How does an evaluator distinguish
> between a legitimate list and a malicious attack?
>
If we had a reliable answer to that, this would've been over ages ago.
Unfortuna
Scott Kitterman writes:
> You can equally argue that these receivers are merely following the
> policy advice provided by the sending domain (it has reject right in
> the name) and this problem is entirely generated by sender's
> inappropriate use of p=reject.
True, thats why the proposed text al
On July 8, 2023 6:16:46 PM UTC, Tero Kivinen wrote:
>Brotman, Alex writes:
>> I suspect the portion that instructs receivers to not act solely on
>> p=reject may be ignored by a fair set of receivers. I'm not
>> necessarily opposed to the language below, just that it seems odd to
>> create lan
Brotman, Alex writes:
> I suspect the portion that instructs receivers to not act solely on
> p=reject may be ignored by a fair set of receivers. I'm not
> necessarily opposed to the language below, just that it seems odd to
> create language that we know will be ignored.
If receivers ignore that
It appears that Richard Clayton said:
>They then moved on to just using random identities from the same domain
>as the recipient. This led a great many Yahoo users to believe that a
>great many other Yahoo users had been compromised, leading to a
>significant loss of faith in the integrity of the
*Note: The following is a general rule of thumb for me.*
From my functional specification protocol language coding standpoint:
MUST --> NO OPTION. Technically enabled with no switch to disable.
SHOULD -> OPTIONAL, Default is ON, enabled
MAY --> OPTIONAL, Default is ON or OFF depending on implem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Murray S. Kucherawy writes
>Some of my IETF mentors (ahem) taught me some stuff about the use
>of SHOULD [NOT] that have stuck with me, and I'm going to pressure
>test this against that advice. Let's see how this goes. :-
On Sat 08/Jul/2023 02:44:19 +0200 Murray S. Kucherawy wrote:
On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote:
It is therefore critical that domains that host users who might
post messages to mailing lists SHOULD NOT publish p=reject.
Domains that choose to publish p=reject S
Start with the underlying objective:
Evaluators SHOULD accept mailing list traffic.
Google's requirement: Given whatever standards-track DMARCbis rules we
produce, these rules MUST be something that can be fully automated.
Consequently, the problem remains: How does an evaluator distinguish
be
Still no hat on.
I can see the compromise in language that's been proposed here, and I
appreciate the effort by the chairs.
Two things I'd like to raise. First:
On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote:
> It is therefore critical that domains that host users who might
> po
I do like your suggestion of silent discard rather than bounce, and I
would want to see that change made -- perhaps with a note that
aggregate reports will still include information about those discards.
Having thought about it for a minute, I have a better question.
We already know that sites
Doesn't sieve happen during delivery, after the message has been accepted? Is
so, I don't think it's a useful comparison to make.
The lack of bounce/rejection messages results in messages that vanish and
undermines the reliability of the email ecosystem. I agree that silent discard
between MT
It's not a question of the bounces being annoying: it's a question of
the bounces harming mailing list operation by causing unsubscribes.
Given the choice of "breaking 5321" (which I don't buy, as Sieve
already has a silent discard option, for example) and "breaking normal
mailing list operation",
Barry,
I did a quick review and comparison for changes.
Overall, it appears this document is more clear in key specific areas but also
more complex. At this point, DMARCbis is about Local Policy, System
Administrative choices and suggested guidelines, codified and/or new. As such,
I don’
It appears that Barry Leiba said:
>I, too, prefer MUST to SHOULD there, but it was clear to me that we
>will not reach rough consensus on MUST, but that we can reach rough
>consensus on SHOULD.
>
>I do like your suggestion of silent discard rather than bounce, and I
>would want to see that change
I, too, prefer MUST to SHOULD there, but it was clear to me that we
will not reach rough consensus on MUST, but that we can reach rough
consensus on SHOULD.
I do like your suggestion of silent discard rather than bounce, and I
would want to see that change made -- perhaps with a note that
aggregat
Baptiste,
Your comments assume uniform agreement that mailing lists have no role in
the problem or it's solution. I do not agree.
Malicious impersonation creates a need for authentication. If the list
makes changes that disable the originator's authentication, then it is the
list's problem to f
Hi,
I consider this a step backwards. The MUST requirement on the author
domain finally made it clear, after a lost decade, *who* is responsible
for solving the breakage of indirect mailflows. Problem solving starts
with acknowledging one's responsibilities.
This proposal goes back to a muddy sha
Barry, in my previous note, I used MTA generically, but was particularly
thinking of forwarders. I assume that senders and their outbound filtering
services will be smart enough to not undermine their own signatures.
I have tried unsuccessfully to accept your assertion that a forwarder is
not a p
On Thu, Jul 6, 2023 at 3:00 PM Barry Leiba wrote:
> That's fine, as long as we're all understanding that it's still just a
> proposal and we'll be discussing it at IETF 117 and on the mailing list.
>
Absolutely. I just wanted to have a fresh draft in place before the cut off
date, and today was
s to avoid this situation, but we will tell receivers how
> to avoid this situation.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
>
> > -Original Message-
> > From: dmarc On Behalf Of Barry Leiba
> > Sent: Thursday
That's fine, as long as we're all understanding that it's still just a
proposal and we'll be discussing it at IETF 117 and on the mailing list.
Barry
On Thu, Jul 6, 2023 at 2:07 PM Todd Herr wrote:
> I'll prepare a new rev incorporating this proposed text (and some other
> unrelated stuff that
y 6, 2023 10:55 AM
> To: IETF DMARC WG
> Subject: [dmarc-ietf] Another p=reject text proposal
>
> I had some off-list discussions with Seth, who was very much against my
> original
> proposed text, and he suggested an alternative organization that would be more
> palatable t
I'll prepare a new rev incorporating this proposed text (and some other
unrelated stuff that's been lying fallow for a few months) and release it
today.
On Thu, Jul 6, 2023 at 12:02 PM John Levine wrote:
> It appears that Barry Leiba said:
> >This makes it explicitly clear that any MUST/SHOULD
It appears that Barry Leiba said:
>This makes it explicitly clear that any MUST/SHOULD stuff with regard
>to using and honoring p=reject is an issue of interoperating with
>existing Internet email features. I can accept that mechanism also,
>and so, below is my attempt at writing that proposal u
I don't think this is the place to tell mailing lists what to do, and
that's all discussed in Section 4.1.3 of RFC 7960.
Barry
On Thu, Jul 6, 2023 at 11:48 AM Alessandro Vesely wrote:
>
> Hi,
>
> the only issue I'd put about the new section is that it doesn't mention From:
> munging. Isn't that
Hi,
the only issue I'd put about the new section is that it doesn't mention From:
munging. Isn't that practice widespread enough that it deserves being considered?
Best
Ale
On Thu 06/Jul/2023 16:55:02 +0200 Barry Leiba wrote:
I had some off-list discussions with Seth, who was very much ag
Whatever works within our constraints. It is certainly an
interoperability consideration, and evaluators will have a hard time
reverse engineering why the signature fails verification.
df
On Thu, Jul 6, 2023, 11:25 AM Barry Leiba wrote:
> > This language works well for me.
>
> Excellent; than
> This language works well for me.
Excellent; thanks.
> I suggest adding some language about why MTAs should not rearrange message
> headers or MIME
> sections, even though earlier documents grant permission to do so.
>
> Additionally, when adding headers, an MTA must add them at the top if (a)
This language works well for me.
I suggest adding some language about why MTAs should not rearrange message
headers or MIME sections, even though earlier documents grant permission to
do so.
Additionally, when adding headers, an MTA must add them at the top if (a)
the header type is included in a
I had some off-list discussions with Seth, who was very much against
my original proposed text, and he suggested an alternative
organization that would be more palatable to him. I've attempted to
set that out below. The idea is to remove the normative requirements
about using p=reject from Sectio
71 matches
Mail list logo
