Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Steven M Jones]

On 6/14/21 10:09, Brotman, Alex wrote:
> Does this make everyone cringe, or perhaps worth a larger discussion?


This was considered (repeatedly) during the original DMARC work, and I
believe again while it was being put into RFC7489 form.

It was rejected because it increased the likelihood of broken/invalid
records for the overwhelming majority, while providing complexity that
relatively few senders wanted. And they could usually get what they
wanted by other means.

I would not be in favor of adding more complex policy expressions.

--S.



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

[Douglas Foster]

Thank you for asking.

OK.,  I will use the term "email suffix" for the part of an email address
that follows the @ character,  and "DNS domain" for a name that appears in
DNS as a domain object.

An email suffix can legitimately be associated with an A/
resource record that is not a DNS domain.   For example, an alarm
monitoring system might send alarms using the server's host name as the
email suffix (e.g. ala...@monitore.xample.com).   MX and SPF can also be
configured for Monitor.Example.Com even though it is not a  DNS domain.
This is specifically authorized by RFC 5321.

A spoofed email address could use any email suffix, such as
nots...@trickedyou.example.com.   Our interest must extend beyond names
that are in DNS.

In my mailstream, most messages sent from mailing services use the mailing
service domain for the SMTP address.  This insures that the message
produces SPF PASS.  It also means that the FROM domain name has no
necessary dependence on any DNS entry.   It took me only one day to find
examples of this;,non-existent subdomains used on legitimate messages sent
by mailing services.  The FROM suffix correctly reflects the parent
organization, but the full email suffix does not appear in DNS.   This
situation means that we cannot distinguish between valid and invalid email
suffixes using DNS alone, we must require domain owner signalling.

How does a domain owner signal that @bounce.e.example.com is valid as a
FROM domain, even though the name is only used for mailing service
messages?Under the current draft, the domain owner must associate the
name with an IP address using an MX, A, or SPF record, even though the name
has no legitimate connection to the chosen IP address.  I do not consider
this acceptable.   In the real world, I fear that implementing such a
requirement will have unexpected consequences, and network administrators
who share my fear will be reluctant to comply with our draft.

I focused on SP and NP because it is the SP or NP policy which provides
inheritance,  Inheritance has to be the primary way that we defend against
abuse of unused and non-existent email suffixes

You asked a lot of questions.   I think I should stop there and give you a
chance to respond before going further.

Doug Foster


On Mon, Jun 14, 2021 at 7:12 AM Alessandro Vesely  wrote:

> Doug,
>
> maybe it's me, but I have problems understanding your proposal.  Let me
> quote
> what seems to hamper my comprehension.
>
> Besides, #11 in the Subject: is obviously a typo.
>
>
> On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote:
> > ties the design directly to the mailing list problem.
>
>
> I couldn't see where mailing lists are taken into account.
>
>
> >However,this authentication can be lost in transit if message
> modification
> > occurs in transit, as discussed in RFC 7960.  This possibility can make
> domain
> > owners reluctant to move beyond sp=none.
>
>
> Why do you consider SP irrespective of P?  Actually, SP could be used by
> "simple" mail sites, those which make no use of subdomains for email.  In
> such
> cases, setting sp=reject can safely prevent generic abuses even for
> domains
> having p=none.  It sounds similar to null SPF records for non-mail hosts.
>
>
> > x.1 Implement mail domains as DNS domains with domain-level DMARC
> policies.
> >
> > Mail domains are often implemented as DNS domains, but this is not
> required.
>
>
> Please, stick to well established jargon.  Tim made a good synthesis in
> section
> 2.2 and ensuing ones.  A /DNS domain/ is defined by RFC 1034:
>
>  A domain is identified by a domain name, and consists of that part of
>  the domain name space that is at or below the domain name which
>  specifies the domain.
>
> In this sense, the concept of non-existing domain names that are
> legitimately
> used sounds like a contradiction in terms.
>
>
> > Once all used mail domain names are configured as DNS domains, they can
> be
> > configured with DMARC policies.
>
> AFAICS, a /used mail domain name/ which is not a DNS name is a
> /non-existent
> domain/ found in some (forged) email addresses.  I agree that such
> practice
> should be discouraged.  Yet, that doesn't seem to be the point here...
>
> BTW, are there organizations that use non-existent (sub) domains during
> the
> delivery of legitimate messages?  Years ago I saw sporadic mailing list
> authors
> forged like john@nospamexample.com.  Is that what you're talking
> about?
>
>
> > - For mail domain names that are not used with SMTP, a new TXT record is
> > defined, with content "DMARCFROMv1".   The presence of this TXT record
> > indicates that the associated DNS domain, named DNS resource record, or
> > wildcard DNS record should be considered as potentially in use as an
> > RFC5322.From domain name.
>
>
> Ok, that is clear, but, IMHO, won't work.  Working MXes or IP addresses
> are a
> necessary condition to receive mail.  Thus, a purist receiver has to
> accept
> such domains as 

Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[John Levine]

It appears that Brotman, Alex  said:
>Does this make everyone cringe, or perhaps worth a larger discussion?

Cringe.  If others have said, if you want DKIM to pass, sign everything with 
DKIM.  I can promise you
that anyone who says "all of our mail will always pass SPF" doesn't know where 
his mail is going.

For other reasons it would be a good idea to publish SPF records and have them 
usually pass, but they don't
have to be the same domain as the DKIM or DMARC.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[John Levine]

It appears that Brotman, Alex  said:
>To summarize,
>
>We'd like to see extensions available both below the "feedback" and "record" 
>elements.  The -02 draft only has it below the "feedback" element.  I agree 
>that all
>elements, each time they are utilized, should mention a reference as to how 
>they are to be utilized.
>
>We'd also like to have extensions go through an IETF process, however, we also 
>understand that we cannot exclude third parties from defining/deploying their 
>own
>extensions.  I suppose we could tell report receivers they "MUST" ignore any 
>extensions which are not IETF-approved, though that seems a bit heavy-handed.

Remember, IETF standards are about how to interoperate.  If people want to 
interpret private extensions,
that is fine so long as the private ones don't interfere with public ones.

While we would like it if people published the details of their private 
extensions, just knowing the
names is useful since that keeps names from colliding.  So we should set up a 
FCFS registry for
extensions, specification would be nice but not required.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Ken O'Driscoll]

I think this is a bad idea as it adds unnecessary additional complexity. 
Currently, a domain owner can choose to only implement DKIM or SPF on a mail 
stream if they only wish one mechanism to be evaluated.

Further, if there is a (renewed?) desire to apply a policy layer to DKIM signed 
messages, then isn't that what ADSP (RFC 5617) was intended for?

Ken.


From: dmarc  on behalf of Brotman, Alex 

Sent: Monday 14 June 2021, 18:10
To: dmarc@ietf.org
Subject: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

Hello,

I was talking to some folks about DMARC, and a question came as to suggest as 
the domain holder that your messages should always pass DKIM.  Effectively, the 
asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign 
my messages with DKIM."  So the obvious answer may be "Just only use DKIM", but 
I'm not sure that completely answers the question.  While discussing with 
someone else, "Tell me when DKIM fails, but SPF is fully aligned".  There was 
recently an incident at a provider where they were allowing any sender to send 
as any domain (and I'm aware that's not specifically a DMARC issue).  We all 
know brands that have just dumped in a pile of "include" statements without 
fully understanding the implications.  In this case, other users could send as 
other domains, but perhaps they would not have been DKIM signed.  Should there 
be a method by which a domain holder can say "We want all message to have both, 
or be treated as a failure", or "We'll provide both, but DKI
 M is a must"?

>From a receiver side, it makes evaluation more complex.  From a sender side, 
>it gives them more control over what is considered pass/fail.

How does this look in practice?  Maybe 
"v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
(pm=Policy Matrix)

Does this make everyone cringe, or perhaps worth a larger discussion?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-15.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting 
& Conformance WG of the IETF.

Title   : Experimental DMARC Extension For Public Suffix Domains
Authors : Scott Kitterman
  Tim Wicinski
Filename: draft-ietf-dmarc-psd-15.txt
Pages   : 15
Date: 2021-06-14

Abstract:
   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) permits a domain-controlling organization to express domain-
   level policies and preferences for message validation, disposition,
   and reporting, which a mail-receiving organization can use to improve
   mail handling.

   DMARC distinguishes the portion of a name that is a Public Suffix
   Domain (PSD), below which organizational domain names are created.
   The basic DMARC capability allows organizational domains to specify
   policies that apply to their subdomains, but it does not give that
   capability to PSDs.  This document describes an extension to DMARC to
   fully enable DMARC functionality for PSDs.

   Some implementations of DMARC consider a PSD to be ineligible for
   DMARC enforcement.  This specification addresses that case.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-15


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Tobias Herkula]

This risks sendability with the fact that there are a lof of receivers that 
require SPF-RRs. So not providing SPF-RRs also fails with such an requirement. 
Besides that does SPF not help with any kind of 5322.From spoofing, but this 
ist he most important identifier for an enduser.

/ Tobias Herkula

Senior Product Owner Mail Security
Mail Application Security

1&1 Mail & Media GmbH | Mitte | 10115 Berlin | Deutschland
E-Mail: tobias.herk...@1und1.de | Web: 
www.1und1.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 7666

Geschäftsführer: Alexander Charles, Thomas Ludwig, Jan Oetjen, Sandra Vollmer

Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen 
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten 
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, 
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise 
auch immer zu verwenden.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient of this e-mail, you are hereby notified that saving, 
distribution or use of the content of this e-mail in any way is prohibited. If 
you have received this e-mail in error, please notify the sender and delete the 
e-mail.



Von: dmarc  Im Auftrag von Seth Blank
Gesendet: Montag, 14. Juni 2021 19:45
An: Brotman, Alex ; dmarc@ietf.org
Betreff: Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

HUGE cringe ;-) DMARC has an explicit policy that either SPF or DKIM must pass 
aligned. This proposal breaks that foundationally.

This is suggested quite frequently, but fails to understand just how few 
senders of email actually send with DKIM. Most email is sent from services that 
have a core business that's not in email, and when we're lucky, they manage to 
publish an SPF record for their customers to use. Only large volume 
sophisticated services tend to do DKIM.

A domain owner that requires everything that sends on its behalf to use DKIM 
basically shoots itself in the foot, and makes most of the services they'd need 
to use unavailable to themselves.

The correct answer is what you said: domain owners who want this should only 
authenticate services using DKIM.

Seth


On Mon, Jun 14, 2021 at 10:10 AM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
Hello,

I was talking to some folks about DMARC, and a question came as to suggest as 
the domain holder that your messages should always pass DKIM.  Effectively, the 
asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign 
my messages with DKIM."  So the obvious answer may be "Just only use DKIM", but 
I'm not sure that completely answers the question.  While discussing with 
someone else, "Tell me when DKIM fails, but SPF is fully aligned".  There was 
recently an incident at a provider where they were allowing any sender to send 
as any domain (and I'm aware that's not specifically a DMARC issue).  We all 
know brands that have just dumped in a pile of "include" statements without 
fully understanding the implications.  In this case, other users could send as 
other domains, but perhaps they would not have been DKIM signed.  Should there 
be a method by which a domain holder can say "We want all message to have both, 
or be treated as a failure", or "We'll provide both, but DKI
 M is a must"?

>From a receiver side, it makes evaluation more complex.  From a sender side, 
>it gives them more control over what is considered pass/fail.

How does this look in practice?  Maybe 
"v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
(pm=Policy Matrix)

Does this make everyone cringe, or perhaps worth a larger discussion?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--
Seth Blank | VP, Product
e: s...@valimail.com
p: 415.273.8818
[https://hosted-packages.s3-us-west-1.amazonaws.com/Valimail+Logo.png]

This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Seth Blank]

HUGE cringe ;-) DMARC has an explicit policy that either SPF or DKIM must
pass aligned. This proposal breaks that foundationally.

This is suggested quite frequently, but fails to understand just how few
senders of email actually send with DKIM. Most email is sent from services
that have a core business that's not in email, and when we're lucky, they
manage to publish an SPF record for their customers to use. Only large
volume sophisticated services tend to do DKIM.

A domain owner that requires everything that sends on its behalf to use
DKIM basically shoots itself in the foot, and makes most of the services
they'd need to use unavailable to themselves.

The correct answer is what you said: domain owners who want this should
only authenticate services using DKIM.

Seth


On Mon, Jun 14, 2021 at 10:10 AM Brotman, Alex  wrote:

> Hello,
>
> I was talking to some folks about DMARC, and a question came as to suggest
> as the domain holder that your messages should always pass DKIM.
> Effectively, the asker wants to say "I intend to deploy SPF and DKIM, but I
> will *always* sign my messages with DKIM."  So the obvious answer may be
> "Just only use DKIM", but I'm not sure that completely answers the
> question.  While discussing with someone else, "Tell me when DKIM fails,
> but SPF is fully aligned".  There was recently an incident at a provider
> where they were allowing any sender to send as any domain (and I'm aware
> that's not specifically a DMARC issue).  We all know brands that have just
> dumped in a pile of "include" statements without fully understanding the
> implications.  In this case, other users could send as other domains, but
> perhaps they would not have been DKIM signed.  Should there be a method by
> which a domain holder can say "We want all message to have both, or be
> treated as a failure", or "We'll provide both, but DKI
>  M is a must"?
>
> >From a receiver side, it makes evaluation more complex.  From a sender
> side, it gives them more control over what is considered pass/fail.
>
> How does this look in practice?  Maybe
> "v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
> (pm=Policy Matrix)
>
> Does this make everyone cringe, or perhaps worth a larger discussion?
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank* | VP, Product
*e:* s...@valimail.com
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Zachary Aab]

This rings to me like something that would look like the simple/relaxed
alignment option currently in DMARC.  "Require aligned DKIM" being
something along the lines of "rdkim=y; rspf=n;" with the
not-included/default value being "n."
If you agree that adding it is simple enough, the real question is what
value does this really add to DMARC and/or will it improve DMARC adoption?
Personally, I think it would be generally welcomed among senders who like
really granular control over their authentication or who don't fully
understand DMARC's "defaults" (for example, senders who use "p=reject;
pct=100;").

On Mon, Jun 14, 2021 at 1:10 PM Brotman, Alex  wrote:

> Hello,
>
> I was talking to some folks about DMARC, and a question came as to suggest
> as the domain holder that your messages should always pass DKIM.
> Effectively, the asker wants to say "I intend to deploy SPF and DKIM, but I
> will *always* sign my messages with DKIM."  So the obvious answer may be
> "Just only use DKIM", but I'm not sure that completely answers the
> question.  While discussing with someone else, "Tell me when DKIM fails,
> but SPF is fully aligned".  There was recently an incident at a provider
> where they were allowing any sender to send as any domain (and I'm aware
> that's not specifically a DMARC issue).  We all know brands that have just
> dumped in a pile of "include" statements without fully understanding the
> implications.  In this case, other users could send as other domains, but
> perhaps they would not have been DKIM signed.  Should there be a method by
> which a domain holder can say "We want all message to have both, or be
> treated as a failure", or "We'll provide both, but DKI
>  M is a must"?
>
> >From a receiver side, it makes evaluation more complex.  From a sender
> side, it gives them more control over what is considered pass/fail.
>
> How does this look in practice?  Maybe
> "v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
> (pm=Policy Matrix)
>
> Does this make everyone cringe, or perhaps worth a larger discussion?
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Brotman, Alex]

Hello,

I was talking to some folks about DMARC, and a question came as to suggest as 
the domain holder that your messages should always pass DKIM.  Effectively, the 
asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign 
my messages with DKIM."  So the obvious answer may be "Just only use DKIM", but 
I'm not sure that completely answers the question.  While discussing with 
someone else, "Tell me when DKIM fails, but SPF is fully aligned".  There was 
recently an incident at a provider where they were allowing any sender to send 
as any domain (and I'm aware that's not specifically a DMARC issue).  We all 
know brands that have just dumped in a pile of "include" statements without 
fully understanding the implications.  In this case, other users could send as 
other domains, but perhaps they would not have been DKIM signed.  Should there 
be a method by which a domain holder can say "We want all message to have both, 
or be treated as a failure", or "We'll provide both, but DKI
 M is a must"?

>From a receiver side, it makes evaluation more complex.  From a sender side, 
>it gives them more control over what is considered pass/fail.

How does this look in practice?  Maybe 
"v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
(pm=Policy Matrix)

Does this make everyone cringe, or perhaps worth a larger discussion?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Alessandro Vesely]

On Mon 14/Jun/2021 14:41:44 +0200 Brotman, Alex wrote:


I agree that all elements, each time they are utilized, should mention a 
reference as to how they are to be utilized.

[...]

So, a sample report may look something like:


  2.0
  
2



So why doesn't  mention a reference to how it is utilized?

About that overabundance of 's, the 1st entry, right below , is the aggregate report 
version.  Thus far, we agreed that it is useless as a grammar indication if  contains its namespace 
declaration.  However, Matt noted that there may be parsers that consider reports to be pre-IETF drafts if they 
miss the  element.  In this case, it makes sense to keep 1.0 for 
backward compatibility, especially if we try not to break existing parsers.

The second  entry, inside , had better wear a 
different name, to avoid confusion.  I assume it's meant to be the report reference 
version.  A couple of alternative examples:


  
https://github.com/trusteddomainproject/OpenDMARC/releases/tag/rel-opendmarc-1-4-1

or


  
http://www.trusteddomain.org/opendmarc/
1.4.1
  


Best
Ale
--
























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Trent Adams]

+1


On 6/14/21, 6:42 AM, "dmarc on behalf of Brotman, Alex" 
 
wrote:

To summarize,

We'd like to see extensions available both below the "feedback" and 
"record" elements.  The -02 draft only has it below the "feedback" element.  I 
agree that all elements, each time they are utilized, should mention a 
reference as to how they are to be utilized.

We'd also like to have extensions go through an IETF process, however, we 
also understand that we cannot exclude third parties from defining/deploying 
their own extensions.  I suppose we could tell report receivers they "MUST" 
ignore any extensions which are not IETF-approved, though that seems a bit 
heavy-handed.

So, a sample report may look something like:

   
 2.0
 
   2
   Sample Reporter
   report_sen...@example-reporter.com
   ...
   3v98abbp8ya9n3va8yr8oa3ya
   
 161212415
 161221511
   
 
 
   example.com
   quarantine
   none
   100
 
 
   
 192.168.4.4
 123
 
   quarantine
   pass
   fail
 
   
   
 example.com
   
   
 
   example.com
   pass
   abc123
 
 
   example.com>
   fail
 
   

  
 .
  
   
 

   

   

   

The goal being to allow extensions to live either at the reported-IP level, 
or at the domain level.

Does this seem reasonable?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Saturday, June 5, 2021 7:56 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback
> Requested
>
> Alessandro Vesely wrote on 2021-06-04 11:26:
> > Second, I'm not sure we need an  container.
> > I'd go for an example like, say, so:
> >
> > [...]
> >  > 
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?*1.0__;Lw!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLOwusINU$
 ">
>  > [...]
> > > 
xmlns="https://urldefense.com/v3/__http://ietf.org/xml-namesapaces/bimi-xml?**A1.0__;Py8!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLNemKNFV$
 ">
>
> If we use an attribute for the extension name, then we don't the container
> section.
> As the current schema does not use attributes at all, I'm more inclined 
to define
> the extension name in a different way for consistent non-use of 
attributes. But
> that's a minor detail.
>
> >> 1) Extensions in their own section (as it is now) or within each
> >>  element
> >
> >
> > Both, and both optional.  An extension can have some data to add in
> > some , but not necessarily in all of them.
>
> +1
>
> Regards,
> Matt

___
dmarc mailing list
dmarc@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!5jPsNDxnYoaeo_HCTDHZOSs5McSKUik5frtgdFxHB_wL9O6VDywrZhokLIcIrQ-o$
 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Brotman, Alex]

To summarize,

We'd like to see extensions available both below the "feedback" and "record" 
elements.  The -02 draft only has it below the "feedback" element.  I agree 
that all elements, each time they are utilized, should mention a reference as 
to how they are to be utilized.

We'd also like to have extensions go through an IETF process, however, we also 
understand that we cannot exclude third parties from defining/deploying their 
own extensions.  I suppose we could tell report receivers they "MUST" ignore 
any extensions which are not IETF-approved, though that seems a bit 
heavy-handed.

So, a sample report may look something like:

   
 2.0
 
   2
   Sample Reporter
   report_sen...@example-reporter.com
   ...
   3v98abbp8ya9n3va8yr8oa3ya
   
 161212415
 161221511
   
 
 
   example.com
   quarantine
   none
   100
 
 
   
 192.168.4.4
 123
 
   quarantine
   pass
   fail
 
   
   
 example.com
   
   
 
   example.com
   pass
   abc123
 
 
   example.com>
   fail
 
   

  
 .
  
   
 

   

   

   

The goal being to allow extensions to live either at the reported-IP level, or 
at the domain level.

Does this seem reasonable?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Saturday, June 5, 2021 7:56 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback
> Requested
>
> Alessandro Vesely wrote on 2021-06-04 11:26:
> > Second, I'm not sure we need an  container.
> > I'd go for an example like, say, so:
> >
> > [...]
> >  > xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0;>
>  > [...]
> > > xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0;>
>
> If we use an attribute for the extension name, then we don't the container
> section.
> As the current schema does not use attributes at all, I'm more inclined to 
> define
> the extension name in a different way for consistent non-use of attributes. 
> But
> that's a minor detail.
>
> >> 1) Extensions in their own section (as it is now) or within each
> >>  element
> >
> >
> > Both, and both optional.  An extension can have some data to add in
> > some , but not necessarily in all of them.
>
> +1
>
> Regards,
> Matt

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

[Alessandro Vesely]

Doug,

maybe it's me, but I have problems understanding your proposal.  Let me quote 
what seems to hamper my comprehension.


Besides, #11 in the Subject: is obviously a typo.


On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote:

ties the design directly to the mailing list problem.



I couldn't see where mailing lists are taken into account.


   However,this authentication can be lost in transit if message modification 
occurs in transit, as discussed in RFC 7960.  This possibility can make domain 
owners reluctant to move beyond sp=none.



Why do you consider SP irrespective of P?  Actually, SP could be used by 
"simple" mail sites, those which make no use of subdomains for email.  In such 
cases, setting sp=reject can safely prevent generic abuses even for domains 
having p=none.  It sounds similar to null SPF records for non-mail hosts.




x.1 Implement mail domains as DNS domains with domain-level DMARC policies.

Mail domains are often implemented as DNS domains, but this is not required.



Please, stick to well established jargon.  Tim made a good synthesis in section 
2.2 and ensuing ones.  A /DNS domain/ is defined by RFC 1034:


A domain is identified by a domain name, and consists of that part of
the domain name space that is at or below the domain name which
specifies the domain.

In this sense, the concept of non-existing domain names that are legitimately 
used sounds like a contradiction in terms.




Once all used mail domain names are configured as DNS domains, they can be
configured with DMARC policies.


AFAICS, a /used mail domain name/ which is not a DNS name is a /non-existent 
domain/ found in some (forged) email addresses.  I agree that such practice 
should be discouraged.  Yet, that doesn't seem to be the point here...


BTW, are there organizations that use non-existent (sub) domains during the 
delivery of legitimate messages?  Years ago I saw sporadic mailing list authors 
forged like john@nospamexample.com.  Is that what you're talking about?



- For mail domain names that are not used with SMTP, a new TXT record is 
defined, with content "DMARCFROMv1".   The presence of this TXT record 
indicates that the associated DNS domain, named DNS resource record, or 
wildcard DNS record should be considered as potentially in use as an 
RFC5322.From domain name.



Ok, that is clear, but, IMHO, won't work.  Working MXes or IP addresses are a 
necessary condition to receive mail.  Thus, a purist receiver has to accept 
such domains as valid.  Therefore traditionalist domain operators will not see 
a compelling need to define any auxiliary TXT records.  A new RR type of this 
kind would most probably be going to characterize mass mailers who hasten to 
adopt any new trick that seems to offer a chance to increase deliverability. 
Undoubtedly, someone would be tempted to discard senders based on that (as it 
happened to DKIM...)


An organization which wants to say sp=reject but does use some email subdomains 
had better define plain DMARC records for them.  Records can be easily 
duplicated by CNAMEs.  If we needed to vary some parts but not others, for 
example a different policy but the same aggregate reporting address, we should 
define something equivalent to SPF's include.




- For used domain names that are not in DNS at all, a DMARCFROMv1 TXT record
is needed to indicate that the name is used for mail.


Actually, /any/ record definition will turn a domain into an existing one. 
However, by Section 2.7 of PSD, which defines the MX/A/ test, such domain 
would still be non-existing.  In that sense, DMARCFROMv1 conflicts with PSD.




x,3 Implement SPF -ALL policies on unused names.

Organizations that have configured SPF to protect their valid RFC5321.MailFrom 
domains may not have taken the extra measure of using SPF to obstruct names 
that are not used for mail.  While not directly part of DMARC, an 
authentication result of "DMARC=NONE SPF=FAIL" is a more meaningful result than 
"DMARC=NONE, SPF=NONE".  Consequently, it is desirable to  ensure SPF=FAIL for 
any names that are never used as RFC5321.MailFrom domain names.   Since SPF has 
no inheritance, this requires many entries.



That's a well known SPF issue:
http://www.open-spf.org/FAQ/Common_mistakes/#all-domains

There used to circulate scripts to generate null SPF records.  It would help if 
DNS hosting services implemented a checkbox to carry out such task.  But this 
if far OT.



Best
Ale
--
























___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc