s worth
the trouble. At this point I think the answer is "no".
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
serve access to it.
Registration is a process of signing up. That's all. And it says
nothing about the role or relationship of the entity the registration is
with.
Yep.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
ns out to be one of
these things.
I've probably missed a bunch, and this may not be the best way to compose the
list.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote:
>
>> I still think it'd be a good idea to mention RFC 6590...
>
> Why? RFC 6590 documents a generic approach to partial information hiding. It
> does not specify how to apply this technique to DMARC failure reports, and
rting types smells a lot like "further" to me.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote:
>> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote:
>>> I Believe I agree with the current version, but can someone post what we
>>> think is the final text?
>
> See below, with the two changes mentioned before and Mr Copy Edit's minor
>
> On Wed, Dec 23, 2020 at 10:10 AM John R Levine wrote:
> > On Wed, 23 Dec 2020, Ned Freed wrote:
> > > Failure reports provide detailed information about the failure of a
> > single
> > > message or a group of similar messages failing for the same reason. They
> > > are meant to aid in cases
orts provide detailed information about the failure of a single
message or a group of similar messages failing for the same reason. They
are meant to aid in cases where a domain owner is unable to detect why
failures reported in aggregate form did occur. It is important to note
these reports
subject to what I'll now call the fiefdom problem, where
you're required to use a DNS service operated by someone else in your org and
they are ... problematic.
Of course DNS use is unavoidable. Even so, the fiefdom problem has led to
requests to minimize DNS usage by any means possible.
The HRE pr
ed away the toolbars' warnings if the
content of web pages looked legitimate. We found that
many subjects do not understand phishing attacks or realize
how sophisticated such attacks can be.
Ned
___
dmar
The MIME document split was, in hindsight, partly successful (separation of
media types registration was a really good thing), partly unsuccessful (part
five should not have been pulled out of part two), and partly a wash (the
cost/benefit of separating parts one and two ended up pretty much equal
ns this document deals with done in ways other
than what the document describes. So in order to make use of this document
you're basically talking about a fairly major rewrite.
I think that's unlikely to happen.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
ad.
HA! RS232 on my mind, helping an enterprise customer with his 32 modem
server setup. Of course, I meant RFC5322.
Good to know I'm not the only one who confuses those.
Ned
___
dmarc mailing list
dmarc@ietf.
sability in this regard. I have dozens of
channels I need to monitor, the breakdown of same is not remotely aligned with
how I would prefer to consume them. Add in a complete crap UI, and I honestly
can't think of a mail UI I've used that's worse. Not ever.
This is done all the time, and not just by Sendmail and Postfix.
Other projects do it all in one milter (rspamd?)...
Yes, but when you do it all in one go it's more difficult to customize.
Ned
___
dmarc mailin
r DMARC validation and for
> visual representation is usually made by different pieces of code with
> different behavior.
Exactly. This is a security protocol and there are real security implications
of doing stuff like this. Another reason to Just Say No.
N
es, and interoperability suffers as a result.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
>>
> >
> > Right, that's a property of SPF: It only evaluates the latest
> > ("connecting" in that paragraph) hop, while DKIM often survives end-to-end
> > irrespective of who's relaying it in to the local ADMD.
> >
> Hmm.. I think I'm making a different argument here. If the evaluating ADMD
> trust claims made by a relaying hop, then it is able to do its own SPF
> evaluation by having the relaying hop supply the IP address of the
> originating MTA, even if the relaying hop didn't itself do SPF validation.
> In this sense, it's not tied to the incoming connection.
Quite right. And these sorts of arrangements where IP address information
is derived not from the connection but from a Received: field, XCLIENT
command, etc. are actually pretty common.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
WFM.
Ned
> On Thu, Mar 22, 2018 at 4:08 PM, Ned Freed wrote:
> > On 3/22/2018 7:49 AM, Kurt Andersen (b) wrote:
> >> > For the sake of people browsing the IETF RFCs, what would it take to
> >> > make 4406 historic?
> >>
> >
> > +1
> >>
> >
> > Yes, cleaning this
On 3/22/2018 7:49 AM, Kurt Andersen (b) wrote:
> For the sake of people browsing the IETF RFCs, what would it take to
> make 4406 historic?
+1
Yes, cleaning this up would be good. It doesn't come up often, but it does
come up.
This would need to be coordinated with the EAI people/list, but as long
as it isn't controversial I don't see a reason not to put it in.
Ned
> If I may budge in here, any chance we could put in a few tweaks for
> EAI mail?
> I think the main changes would be that
Given that this work is specificall for the benefit of DMARC/ARC, it
makes sense to me to do the work on this list/in this group.
Ned
> On Fri, Jan 19, 2018 at 10:49 AM, Dave Crocker wrote:
> > On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote:
> >
> >> -01 will b
Normally I'm not a stickler for avoiding side discussion of related items
on working lists. But this case I'm going to have to agree with Dave: This
group is not making sufficient progress on its core work, which currently
is to review and progress the ARC specifications. This needs to happen
> What's the best way to proceed from here for the working group?
That's easy: The way to proceed is by describing the actual interoperability
problem that came up. In detail.
What you have done so far, AFAICT, is propose a change that at most facilities
a type of testing decades of experience ha
g
> has already brought. This is what automated tests do - bring problems to
> light quickly.
> So yes, I think this approach works better. Much better.
Simply put, I don't. I'm strongly opposed to this, to the point where I'm
likely to significantly deprioritize implementation of this proposal because of
it.
I have better things to do that waste my time watching the sorts of bugs this
is going to cause get shaken out.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
why it will
work better.
And note that "this kind of test becomes possible" is not sufficient. All
kinds of tests become possible when you add constraints - the question is
what sort of real world problem will those additional tests find.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
so simple
that it merits serious consideration.
The big problem I see with (0)(b) is the overhead it imposes downstream. But as
I noted previously, so many messages are already sent separately to different
recipients it's unclear to what extent this is a factor.
elope, is complex
and loaded with pitfalls. (Just look at these two messages...) And at least
some of this spills over to both implementations and operational policy.
Can we really expect people to get this right?
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
ch a basic email
feature...
RFC 6854 can speak for itself as to the rationale for allowing no address.
The EAI connection was, as I recall, for use in downgrade formats used to
present EAI messages to non-EAI clients via POP3 and IMAP4.
ded, when in fact doing so almost always has an adverse
impact on the overall functionality of the mail system.
IMO Stephen's suggestion is a good one and should be implemented.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
> >
> Agreed.
Agreed as well.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
t /limited/ to DMARC. But again, that's merely a writing
artifact.
So, my reading of the charter says that the proposed spec falls under
the first item of Phase two and the second sub-bullet of Track 1.
As does my own reading.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
s by no means essential to do that.
> Thank you for the fine-tooth comb treatment!
No problem!
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
In my capacity as document shepard, I've now done fairly careful review of the
document. The results of that review are attached below.
Almost all - but not all - of the issues I found were editorial, not technical,
in nature, which is as it should be for a document that this stage. However, we
ar
gt; >>* Completion of Guide on DMARC Usage
> >
> > I think that we need to update our target milestones a bit since they still
> > call for everything to be completed by May 2015.
> That would be great!
> Alexey,
> Who would become the responsible AD for th
> On Mon 09/Nov/2015 23:16:42 +0100 ned+dmarc wrote:
> >> On Fri, Nov 6, 2015 at 1:37 PM, Franck Martin wrote:
> >
> >>> While the I-D will likely expires they will not be removed from the
> >>> website, so references will still work, so I don'
to RFC status anyhow.
And yes, this does leave the door open for something that doesn't make it to
RFC but does achieve some degree of deployment. But I think we have enough
current issues to cover without trying to detail the nature of future ones.
Ned
__
ent field.
Such reports have not appeared AFAIK.
> If the signer wants legacy folk who only understand older DKIM to also
> be able to evaluate a signature, then the signer needs to create two
> signatures.
That's not an argument for using a different field.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
MARC.
I am going to look at adding support for this in our Wildcat! List
Server package. Seems simple enough via a template system. Lets see
how it works.
Thanks for keeping it alive.
FWIW, I agree that this is technology we should pursue.
tly. This is why I guess you have operational testing before an RFC
> get
> the standard status...
I don't think "cannot be transformed" is in any way ambiguous.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Our list server supports it as well, and it is being used this way. So: Agreed.
> Take
> out .invalid, nobody does that because (as I discovered and you
> mention) many spam filters dislike From: addresses with domains that
> don't resolve.
I don
> >In the latter case, it's really an entirely new protocol, which should
> >be identified by the next-lower protocol, rather than by using the
> >version field as an in-bred demultiplexing field.
> I suppose, but if the two procols are 99% the same, and the new one is
> upward compatible with the
not another.
The "running code" that comes to mind is the MIME specification, which
originally had a bunch of repeated and overlapping syntax definitions. In this
case it only took one revision for it to get out of sync and cause confusion.
Ned
___
at this is obsolete, but do we really want to open this
particular can of worms in this document?
And on a similar note, try selling what 4.4.1.2 says to a financial institution
that is bound by laws saying what must be and cannot be in the messages it
emits as well as what's inbound message
is allowed to do. As such, I believe the best outcome
you can get here would be "held for document update".
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
nly complete and yield a "pass" result when one
> of the underlying authentication mechanisms passes for an aligned
> identifier. If neither passes and one or both of them failed due to a
> temporary error, the Receiver evaluating the message is also unable to
> conclude that the DMARC mechanism had a permanent failure and thereby
> can apply the advertised DMARC policy.
This looks good to me.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
as long as my mailbox appears
> > in From, too. Am I misunderstanding your proposed algorithm?
> No, because in (6) the strictest rule applies. Your throwaway domain might
> pass, but the other advertised author's would not.
Agreed.
> > >All other conditions (authentication
> > >failures, identifier mismatches) are considered to be DMARC
> > >mechanism check failures.
> > Bottom line, I think both messages where no Authenticated Identifiers can
> > be extracted and those where multiple Authenticated Identifiers can be
> > extracted should be defined to be mechanism check failures. In the former
> > case, policy discovery is impossible, in the latter, the strictest policy
> > should be applied.
> Right, I think that's what Trent is also saying.
> And everyone seems to agree on just dropping STARTTLS as well.
Good.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
syntax, or whatever, fine. Local policy choices always win.
But DMARC should not be saying that valid things should be rejected when
there's no DMARC records in sight.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
SMTP session rather than
doing anything that would require sending a DSN later, but doesn't come out and
say that the reason for doing this is to avoid blowback spam. I think it would
be clearer to be explicit about why these policies are a good idea.
That's it!
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
27;m asking for reviews of the current work:
> http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki
> Anything else right now is simply a distraction.
> 1/2 of the WG Chair,
+1 from the other 1/2.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
g else, that you instead do what countless
others have done before you, and start by writing a draft that describes your
proposal in detail so participants can assess it?
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
ope of the WG. I received one private response
to that agreeing that it isn't in scope and notihng on the list. And since
public discussion of that point has ceased, further consideration of the matter
seems moot.
Finally, in regards to the implement
quot;mail
that does not flow from operators having a relationship with the domain owner,
directly to receivers operating the destination mailbox". I don't see how this
fits within that scope.
So, while I'm sympathetic to the difficulties using SPF in this way,
I don't think it's in scope for the present effort.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
fit into the overal
theory of reply codes.
This sort of thing has been done many times.
So, shouldn't a 554 code be used here? Or does RFC 5321 need an update?
Neither. See above.
Ned
___
dmarc mailing list
dmarc
are going to spend time drawing conclusions from reading the milestones
in isolation, and in the unlikely event they do, why we should care.
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
vocation
> * valid if the body has this S/MIME signature, to allow for list
> software that reformats the message but keeps the signed body part
> (mailman and mj2, for example) or that resigns with its own S/MIME
> signature (sympa)
> * valid if the body has this PGP si
If a signature has an rsf= tag, verifiers ignore it unless there's a
matching signature from a domain the rsf= points to. ...
> If you're going to bump the version, you need to use the opportunity to
> solve the more general underlying problem.
>
> I'm not sure I can completely charac
eed to be some way to state the intention behind this
particular signature. Is this a signature tied to use by third parties?
Whitelisting? Something else?
Ned
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
58 matches
Mail list logo
