Re: [dmarc-ietf] Request for feedback: draft-ser-authentication-results-openpgp

[John Levine]

[ Replies sent to ietf-822 since this is unrelated to DMARC ]

In article 

 you write:
>I've submitted a draft for a new Authentication-Results method a while
>back [1]. I'd like to get some feedback.
>
>My use-case is: on a mailing list system [2], I'd like to display PGP
>signature status, if a PGP signature is present. ...

>[1]: https://datatracker.ietf.org/doc/draft-ser-authentication-results-openpgp/
>[2]: https://lists.sr.ht

>Does this sounds like something worth doing?

Maybe, but probably not.

DKIM is intended as a signature for messages in transit, applied as a
message leaves its sending system and verified as it arrives at the
recipient system. The sorts of changs made by list managers often
break DKIM signatures, causing all sorts of excitement when DMARC
is involved.

PGP signatures (and S/MIME signatures) are normally applied and
verified by the end-user mail programs. They're in the message body
and the changes that list managers typically make, tagging the
signature or adding body headers or footers, are unlikely to break a
PGP signature.

Or to put it another way, if your A-R header said the PGP signature on
the message contents was good, but the end user found it was bad, that
would suggest something was screwed up, not normal mailing list
processing.

R's,
John

PS: It's not unreasonble for a list manager to use a PGP signature to
verify that it should forward a message, but there's not much use to
adding a header saying it did so.

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

[dmarc-ietf] Request for feedback: draft-ser-authentication-results-openpgp

[Simon Ser]

Hi all,

I've submitted a draft for a new Authentication-Results method a while
back [1]. I'd like to get some feedback.

My use-case is: on a mailing list system [2], I'd like to display PGP
signature status, if a PGP signature is present. I'd like the
verification to happen once in a mail filter. Having a standardized
Authentication-Results method that mail filters can generate and mail
user agents can display would be helpful. A very similar thing is
already implemented for DKIM.

Does this sounds like something worth doing?

Thanks,

Simon

[1]: https://datatracker.ietf.org/doc/draft-ser-authentication-results-openpgp/
[2]: https://lists.sr.ht

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

Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

[Brotman, Alex]

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

> -Original Message-
> From: Jesse Thompson 
> Sent: Monday, October 19, 2020 9:51 AM
> To: Brotman, Alex ; dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
>
> On 10/19/20 7:17 AM, Brotman, Alex wrote:
> > Sure, I think Masaki Kase is suggesting roughly the same thing (along with
> IP address).  Tell the domain who is the entity responsible for attempting 
> this
> delivery?  This might need to be a hash of some sort.
>
> > I think this sort of data would benefit both the domain holder, but as you
> suggested, also the ESP.  They could aggregate their own data to show
> drift/misconfiguration.  And yes, as you also suggest, sometimes the DNS
> guys change things that the MarComm team doesn't know about, believing
> they're doing the proper thing.
>
> ESPs who hash/obscure the customer ID may want to consider a special
> support portal for mailop->ESP questions.  It would be frustrating to be sent
> to front-line agents and given the stiff arm.
>
[Brotman, Alexander]

There are likely a few ways to address supporting a hashed sender, but yes, 
something to consider.

>
> >> 3) Domains that don't have a DMARC record
> > [Brotman, Alexander]
> >
> > It might be possible, depending how this were created, to have a "Senders
> DMARC" Policy, without a proper DMARC policy.  Perhaps marginally useful
> to the domain.
>
> Sent to where, postmaster?
[Brotman, Alexander]

If you didn’t' want a regular DMARC policy, you still might be able to do 
something akin to:

_dmarc.example.com TXT "v=DMARC1 ; ps=none ; 
srua=mailto:sender-repo...@example.com;

So the senders maybe should not take action if the dkim/spf were not going to 
pass, and sender reports of such data would be send to the address specified.  
They would not be creating DMARC policy for receivers at that point.




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

Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

[Jesse Thompson]

On 10/19/20 7:17 AM, Brotman, Alex wrote:
> Sure, I think Masaki Kase is suggesting roughly the same thing (along with IP 
> address).  Tell the domain who is the entity responsible for attempting this 
> delivery?  This might need to be a hash of some sort.

> I think this sort of data would benefit both the domain holder, but as you 
> suggested, also the ESP.  They could aggregate their own data to show 
> drift/misconfiguration.  And yes, as you also suggest, sometimes the DNS guys 
> change things that the MarComm team doesn't know about, believing they're 
> doing the proper thing.

ESPs who hash/obscure the customer ID may want to consider a special support 
portal for mailop->ESP questions.  It would be frustrating to be sent to 
front-line agents and given the stiff arm.


>> 3) Domains that don't have a DMARC record
> [Brotman, Alexander]
> 
> It might be possible, depending how this were created, to have a "Senders 
> DMARC" Policy, without a proper DMARC policy.  Perhaps marginally useful to 
> the domain.

Sent to where, postmaster?

Jesse

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

Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

[Brotman, Alex]

I think that could be reasonable.  It could make reports noisy though?

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

From: dmarc  On Behalf Of Masaki Kase
Sent: Thursday, October 15, 2020 7:34 PM
To: Brotman, Alex 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

Hello Alex,

This would not be meant just for ESPs, but also for MBPs/ISPs as well.

Does this sound like a reasonable idea?  Report overload?  Not a helpful data 
set for a domain holder?

With the perspective of MBPs, I imagined these 3 things:

(a) Identify the E/U’s IP address
The MBPs can receive aggregate reports and can easily identify E/U’s IP 
addresses. I wonder that information would be useful for EAC issues.

(b) Gather the MSAs information
Some MSAs will overwrite RFC5322.From before sending and others won’t. In the 
latter cases, DMARC results might be reported as “dmarc=fail” but MBPs can make 
sure these MSA’ behavoir or specification via aggregate reports. Hopefully, 
MBPs may allow to use 3rd party DKIM signatures to save the messages.

(c) Leverage “comment" field on XML
If MSAs overwrote RFC5322.From the aggregate reports could imply it, for 
example using “comment” or generating new field.

Best regards,



--
加瀬　正樹
  株式会社TwoFive
  103-0027 東京都中央区日本橋3-1-4 画廊ビル3F
  Mail: k...@twofive25.com
  Tel: 03-5704-9948
  Tel: 080-9805-0025
  URL: 
https://www.twofive25.com

Masaki Kase
TwoFive, Inc.
k...@twofive25.com



2020/10/15 3:17、Brotman, Alex 
mailto:Alex_Brotman=40comcast@dmarc.ietf.org>>のメール:

During a session at M3AAWG50, one of the other participants proposed an idea 
where a sender could optionally send reports to a domain holder when they send 
messages on behalf of that domain.

Let's consider the idea that 
example.com
 has properly created SPF/DKIM/DMARC reports for themselves, and are enforcing 
at p=reject.  And 
example.com
 has permitted ESP-A to deliver messages on their behalf, and they're properly 
setup in the SPF, and properly sign with DKIM.  ESP-B has no such 
authorization, but some entity has asked that ESP-B send messages on behalf of 
example.com,
 but is targeting a mailbox provider who does not support DMARC, nor send 
reports.  Both entities participate in this "Senders DMARC", and now 
example.com
 knows that ESP-A is acting properly, while ESP-B may need some contact to 
understand more about what is going on.  I'd suggest that the policy be 
separate from the receiving policy ("p=" and "ps=" (policy-senders) for 
example, though, that may also lend itself to "psp="), but residing in the same 
DNS TXT record.

This would not be meant just for ESPs, but also for MBPs/ISPs as well.

Does this sound like a reasonable idea?  Report overload?  Not a helpful data 
set for a domain holder?

Thank you for your time.

--
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

Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports

[Brotman, Alex]

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

> -Original Message-
> From: dmarc  On Behalf Of Jesse Thompson
> Sent: Wednesday, October 14, 2020 6:59 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Thoughts on "Senders DMARC" Reports
>
> On 10/14/20 1:17 PM, Brotman, Alex wrote:
> > During a session at M3AAWG50, one of the other participants proposed an
> idea where a sender could optionally send reports to a domain holder when
> they send messages on behalf of that domain.
> >
> > Let's consider the idea that example.com has properly created
> SPF/DKIM/DMARC reports for themselves, and are enforcing at p=reject.
> And example.com has permitted ESP-A to deliver messages on their behalf,
> and they're properly setup in the SPF, and properly sign with DKIM.  ESP-B
> has no such authorization, but some entity has asked that ESP-B send
> messages on behalf of example.com, but is targeting a mailbox provider who
> does not support DMARC, nor send reports.  Both entities participate in this
> "Senders DMARC", and now example.com knows that ESP-A is acting
> properly, while ESP-B may need some contact to understand more about
> what is going on.  I'd suggest that the policy be separate from the receiving
> policy ("p=" and "ps=" (policy-senders) for example, though, that may also
> lend itself to "psp="), but residing in the same DNS TXT record.
> >
> > This would not be meant just for ESPs, but also for MBPs/ISPs as well.
> >
> > Does this sound like a reasonable idea?  Report overload?  Not a helpful
> data set for a domain holder?
>
> I would assume that any additional information sent to domain owners
> would be useful for identifying ESPs using a domain without permission or
> mis-configuration/drift.  It also sends a positive signal that the ESP is 
> acting
> more responsibly than the ESPs that don't send the reports, which could be
> seen as good for business.
>
> Permission:  Currently, with the reports we get, we already have a very good
> picture of which ESPs are using our domains, and we don't know why.  So, in
> order to make this idea more than a lateral change, I'd want to see
> information about who the ESP's "customer" is (or some customer ID we can
> reference), since with a large institution it's currently hard to figure out 
> who
> these people are without drinking from the forensics firehose and inferring.
> Domains that have a quarantine|reject DMARC policy would expect ESPs to
> not send mail as that domain unless authorized, but they've probably
> succumbed to the fact that it happens anyway.  So, in these respects, the
> idea would be an improvement especially for domains that are at p=none
> during the inventory phase of their DMARC deployment to help them
> identify who within their organization is using which ESPs.
[Brotman, Alexander]

Sure, I think Masaki Kase is suggesting roughly the same thing (along with IP 
address).  Tell the domain who is the entity responsible for attempting this 
delivery?  This might need to be a hash of some sort.

>
> Mis-configuration/drift:  I assume that the ESP would have to maintain a
> record of prior properly configured SPF/DKIM setups.  From there, the ESP
> could send reports indicating that something needs to be updated in the
> domain's DNS records.  Is that what you're suggesting?  That seems like a
> positive, since I assume that ESPs' customers have a hard time relaying
> technical information to their DNS admins.
>
[Brotman, Alexander]

I think this sort of data would benefit both the domain holder, but as you 
suggested, also the ESP.  They could aggregate their own data to show 
drift/misconfiguration.  And yes, as you also suggest, sometimes the DNS guys 
change things that the MarComm team doesn't know about, believing they're doing 
the proper thing.

> Other scenarios, which I don't think this idea has much benefit:
>
> 1) The recipients are all local and there is a prearranged local override, and
> the domain owner doesn't want to authorize the ESP to use the domain in
> other contexts via DMARC
>
> 2) Domains that have very broken DMARC/SPF/DKIM probably aren't paying
> attention to the reports anyway
[Brotman, Alexander]

Perhaps not, but as you alluded above, the ESP could potentially use the data 
to understand more about their platform.

>
> 3) Domains that don't have a DMARC record
[Brotman, Alexander]

It might be possible, depending how this were created, to have a "Senders 
DMARC" Policy, without a proper DMARC policy.  Perhaps marginally useful to the 
domain.

>
> 4) Domains like gmail.com who can't/won't authorize every ESP at the
> domain-wide level.  This also applies to the org domain at large institutions,
> which is typically the domain that houses users, which also happens to be the
> domain that users want to use as a customer of an ESP.
>
> * Could we publish something that says:  ESPs: please don't try to use this
> domain :-)
>
> Hope this helps!  It sounded like a great