Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[John Levine]

In article  you write:
>Maybe _discardable_ should be used instead.
>
>Why do I have a feeling of deja vu?

Gee, I can't imagine.

R's,
John

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[John R Levine]

I'm sorry but this makes no sense at all.


I said so because you said https is faster.  The spec is unclear about 
intervals, but this is matter for another ticket.


For any given report, stuffing it into a web server with a PUT or POST 
will be faster than base64 encoding it and relaying it through mail 
servers.  This is just arithmetic.



Why do you believe that people would not send reports by mail and by https
at the same time?


Oh my.  Hadn't thought about that.  It will certainly cause duplicates.


I meant "at the same time" as in during the same reporting run.  As Dave 
noted, if you sent any particular report by https, there's no need to send 
it again by mail.


Systems receiving reports have to be prepared for duplicates anyway since 
double deliveries of mail messages happens.  That's the point of the 
filename on the report, to provide a unique name for each report so it's 
easy to tell if you've seen a report before.



$ gpg -u 500982D49712C507C236B2D6B8ABBBF9A091CC0D --clearsign < this text

Can you verify it?  I cannot find how to transform the delta selector public 
key into a pgp public key block.


It says it can't find a public key which is not surprising.  I still don't 
think this is a productive direction to go.


If people really are worried about fake reports, there is a well defined 
way to put a signature in an XML document.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Dave Crocker]

On 12/3/2020 11:30 AM, Alessandro Vesely wrote:

Why do you believe that people would not send reports by mail and by https
at the same time?

Oh my.  Hadn't thought about that.  It will certainly cause duplicates.


Rather than meaning the same report will be sent by both mechanisms, 
perhaps he merely meant that either mechanism could be used at any 
time.  That is, there is no need for the choice of the mechanism to make 
any difference in when they get used.



That is, your:

However faster, an https PUT/POST at midnight arrives later than a 
mailto at midday.

established a false point of distinction.

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

[Alessandro Vesely]

On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote:
> 
>> -Original Message-
>> From: dmarc  On Behalf Of Alessandro Vesely
>> Sent: Thursday, December 3, 2020 6:24 AM
>> To: dmarc@ietf.org
>> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
>>
>> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote:
>>>
>>> While this ticket/enhancement specifically mentions ARC, I could
>>> perhaps see the usefulness in other places.  It seems like it would be
>>> more beneficial to create a method by which other documents could
>>> provide XML- based "extensions" to the report.  This would allow
>>> mechanisms relying on DMARC to independently define their reporting
>>> schema to be included in DMARC aggregate reports.  Alternately, we could
>>> focus specifically on ARC, and work to include that in the base XML.
>>> This means that any later reporting requirements could again require
>>> changes to the core drafts.>>>
>>
>>
>> Another possibility is for ARC to define its own report format.  Hijacking
>> rua= targets to send a different kind of report should be allowed.
>> Otherwise, we could define a new tag, e.g. rue= (e for Extension).>>
>> In either case, as we're introduce variations in aggregate report content,
>> we have to devise a method for determining what version/kind of report is 
>> attached to a given message.>>
> 
> We could add an element called "", and we allow ARC or whatever
> it may be to exist under that element.  The Aggregate Reporting document
> needs to specify that any extensions are expected to be proper XML, and if
> there are no extensions, an empty element is sufficient.  We could create a
> bit more structure as a requirement if we wanted:> 
> 
>
>  ... (as defined in referenced standard)
>
> 
> 
> If a report parser doesn't know what ARC is (or any of the extensions), it 
> could skip the processing.  I do understand this means that  
> element may break existing parsers, even when empty, though, I expect many of 
> the things we're proposing may fracture the expected XML.


We can do a better job at producing aggregate reports with an automatically 
verifiable content.  For example, prepending stuff like this:


http://www.w3.org/2001/XMLSchema-instance";
xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1";
xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1 rua.xsd">

...

(Perhaps something better than "http://dmarc.org/dmarc-xml/0.1"; for the version)

But then, would the  imply dmarc-xml grammar should be upgraded 
every time ARC (or whatever) is upgraded?

Separate reports sounds simpler.


Best
Ale
-- 

















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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Alessandro Vesely]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu 03/Dec/2020 18:08:50 +0100 John R Levine wrote:
>>> When this came up before someone said that reports can be extremely
>>> large, many megabytes.  An HTTP POST or PUT is a much better way to send 
>>> that.
>>
>> However faster, an https PUT/POST at midnight arrives later than a mailto at 
>> midday.
> 
> I'm sorry but this makes no sense at all.

I said so because you said https is faster.  The spec is unclear about 
intervals, but this is matter for another ticket.


> Why do you believe that people would not send reports by mail and by https
> at the same time?

Oh my.  Hadn't thought about that.  It will certainly cause duplicates.


>> Yes, PUT is better than POST.
>>
>> How about pgp-signing the file with the dkim key?
> 
> Sorry, that doesn't make any sense either.  DKIM keys and PGP keys are 
> different.

Hm... let me try and sign this message.

$ cat delta.private | PEM2OPENPGP_USAGE_FLAGS=sign pem2openpgp "Delta selector 
" | gpg --import

Now I have:
sec   rsa1148 2020-12-03 [SC]
  500982D49712C507C236B2D6B8ABBBF9A091CC0D
uid   [ unknown] Delta selector 

$ gpg -u 500982D49712C507C236B2D6B8ABBBF9A091CC0D --clearsign < this text


Can you verify it?  I cannot find how to transform the delta selector public 
key into a pgp public key block.

That is to transform this:

$ eval $(digs delta._domainkey.tana.it txt |sed -rn -e 's/^"//' -e 's/" *"//g' 
-e 's/"$//p') && printf -- '-BEGIN PUBLIC KEY-\n%s\n-END PUBLIC 
KEY-\n' "$(echo $p |base64 -d |base64)"
- -BEGIN PUBLIC KEY-
MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkA5YMrfcQD3kzCQJFRXLatbXbl6h07EE1TrJOVp9
4EeBV50QFuBIk0igZgPTA39O77mUyNii81hD4q2g9/Hoj9asqQHTTKjqk+gwZWC+X46K5BYSRPTC
C9sidg20Laubyn0ATGaz+OyIl4JcE2rsEXwXLJ98OFEaa3gWyUVO9+lNwebs932bOtHbM2YpzJzE
PQIDAQAB
- -END PUBLIC KEY-

To this:

$ gpg  --export --armor 500982D49712C507C236B2D6B8ABBBF9A091CC0D\!
- -BEGIN PGP PUBLIC KEY BLOCK-

mJ0EX8kn8gEEfA5YMrfcQD3kzCQJFRXLatbXbl6h07EE1TrJOVp94EeBV50QFuBI
k0igZgPTA39O77mUyNii81hD4q2g9/Hoj9asqQHTTKjqk+gwZWC+X46K5BYSRPTC
C9sidg20Laubyn0ATGaz+OyIl4JcE2rsEXwXLJ98OFEaa3gWyUVO9+lNwebs932b
OtHbM2YpzJzEPQARAQABtCNEZWx0YSBzZWxlY3RvciA8cG9zdG1hc3RlckB0YW5h
Lml0PojgBBMBCAA6FiEEUAmC1JcSxQfCNrLWuKu7+aCRzA0FAl/JJ/ICGwIGCwkI
BwMCBxUKCQgLAwIEFgIDAQIeAQIXgAAKCRC4q7v5oJHMDfCfBHwKlNsrYbL+8uyb
y1RBhP/epV0M9xTji9J4Tg2dHcZLgkq9odH7LbOBMuVlZxQ6ksJEVmh131CHHPCr
/GmmQpsrxvpo0b5hXKRYTDqemwyvqNtWAMJpW4bLZ4XAy9c6fSICsXdfm8azKE8J
jZeHlnxMnvqhctQXTFSeJ+Ijnyn2ZC31V5J2ZzCfXSpY/fxoteo=
=KJkG
- -END PGP PUBLIC KEY BLOCK-

> It is hypothetically possible to sign an http transaction with DKIM

Any example?

 
> but that would be a giant distraction from what we're doing here.

Should be optional, like DKIM-signing aggregate reports sent by mailto.


Best
Ale
- -- 


-BEGIN PGP SIGNATURE-

iMMEAQEKAB0WIQRQCYLUlxLFB8I2sta4q7v5oJHMDQUCX8k7GgAKCRC4q7v5oJHM
DbyaBHwJ7JddtR6f9mAEF22QdZVX01ZQZagggwaqvHfXPWlD+wPafGH7Hi4dm4B+
Bh1BO/mevC5l0wYdLg5X2mTPhqNMzU+aCWz2MwdYK1iU2JQ6/KQOXpGZuhf597N0
BmRMpe56UDWt06wsE8cNUKmNiaVlJ6yaHXHSV5tUmcqXpXtGaqheAYxyY1BXepd5
KmcpmQg=
=+5y4
-END PGP SIGNATURE-

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Дилян Палаузов]

Post Scriptum: DMARC can say one of two things:
-- all mails for a domain are DKIM-signed and aligned, according to the
domain owner
-- not all mails for a domain are DKIM-signed and aligned (e.g. when
the DMARC policy is absent, or p=none) according to the domain owner

Does the DMARC specification need to propose what to do with emails in
the first case above, when the DKIM-signature is not-valid/aligned? 
Some people will say yes.  I say no: there is no need to give one of
two possible advices on this (and there is no means to enforce the
advice)

Anyway, as I said I do not expect any consensus on this.

Please consider including in the DMARC specificaiton a discussion on
what is reasonable, e.g as outlined in the email below, and elaborate
pros and cons on r=reject and r=quarantine.

As the topic is controversal, it shall be presented as controversal in
the specification.

I do not follow the discussions here, I suppose that by now is
addressed, that „p=quarantine;pct=0“ should be interperted as „do MLM-
mungling”, and p=none to mean „no MLM mungling”.

⇐
From: Vladimir Dubrovin 
To: Dotzero , Vladimir Dubrovin

CC: IETF DMARC WG , Дилян Палаузов

Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Date: Fri, 14 Jun 2019 19:25:02 +0300

Nope, I mean 2 different things. 

1. Why quarantine is useful (with pct=0).  

For example this mailing list (dmarc@ietf.org) performs From rewrite
(aka From munging), e.g. dubro...@corp.mail.ru is replaced with
dubrovin=40corp.mail...@dmarc.ietf.org. It's because corp.mail.ru has a
strict DMARC policy (reject). dotz...@gmail.com is not overwritten,
because gmail.com has p=none and ietf.org only overwrites From only for
domains with "quarantine" and "reject" policies. It's quite common
behavior.

If you are implementing DMARC for a new domain (let's say example.org),
you usually start with "p=none". With p=none you receive reports for
failed DMARC for different lists, like ietf.org. Before switching to
stronger policy (p=reject), you may want to know which mailing list
will still fail DMARC, and which lists perform From munging and, as a
result, do not fail DMARC. For this purpose, before switching to
"p=reject" it's useful to switch to "p=quarantine;pct=0". After this,
you will only see mailing lists without From munging in DMARC reports.

2. Why quarantine should not be used with pct different from 0

If you start enforsing strong DMARC policy with "p=reject" and you have
some previously uncatched misconfiguration (e.g. wrong envelope-from
address in some once-in-the-month mailing), you see DMARC failures  in
your logs and you can react to this failures and even re-send the
messages affected. 
If you start with "p=quarantine" you have no feedback except reports,
and reports are received with a huge lag (up to 2 days) and do not
provide sufficient information to catch the exact problem and you can
not re-send the quarantined messages.

⇒⇒





On Wed, 2020-12-02 at 13:15 +0200, Дилян Палаузов wrote:
> Hello,
> 
> On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote:
> > On 12/1/2020 3:17 PM, John R Levine wrote:
> > > #39 proposes that we remove p=quarantine.  I propose we leave it
> > > in, 
> > > even if it
> > > is not very useful, because trying to remove it would be too
> > > confusing. 
> > 
> > process, I suggest this issue gets some meaningful discussion.  My
> > email 
> > archive indicates it hasn't gotten any discussion at all.
> 
> This was discussed under the subject “Abolishing DMARC policy
> quarantine” in June 2019.  There was no consensus.  SMTP offers this
> distinciton and this is mirrored in DMARC.  In particular, senders
> are
> free to publish p=quarantine and receipients are free to interpret it
> as p=reject.  Senders can publish p=reject and receivers are free to
> interpret it as p=quarantine.
> 
> Moreover, some destination addresses do not have the concepts of a
> quarantine.  E.g an address that accepts commands for mailing lists
> managements.  Such addresses can either accept or reject the message
> -
> there is no quarantine, so interpreting published p=quarantine as
> p=reject is feasible.
> 
> Recalling the discussion from June 2019 I do not count on any
> different
> consensus, if it the discussion happens here again now.
> 
> Greetings
>   Дилян


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

Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

[Brotman, Alex]

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Thursday, December 3, 2020 6:24 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
>
> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote:
> >
> > While this ticket/enhancement specifically mentions ARC, I could perhaps
> see the usefulness in other places.  It seems like it would be more beneficial
> to create a method by which other documents could provide XML- based
> "extensions" to the report.  This would allow mechanisms relying on DMARC
> to independently define their reporting schema to be included in DMARC
> aggregate reports.  Alternately, we could focus specifically on ARC, and work
> to include that in the base XML.  This means that any later reporting
> requirements could again require changes to the core drafts.
> >
>
>
> Another possibility is for ARC to define its own report format.  Hijacking 
> rua=
> targets to send a different kind of report should be allowed.  Otherwise, we
> could define a new tag, e.g. rue= (e for Extension).
>
> In either case, as we're introduce variations in aggregate report content, we
> have to devise a method for determining what version/kind of report is
> attached to a given message.
>

We could add an element called "", and we allow ARC or whatever it 
may be to exist under that element.  The Aggregate Reporting document needs to 
specify that any extensions are expected to be proper XML, and if there are no 
extensions, an empty element is sufficient.  We could create a bit more 
structure as a requirement if we wanted:


  
... (as defined in referenced standard)
  


If a report parser doesn't know what ARC is (or any of the extensions), it 
could skip the processing.  I do understand this means that  
element may break existing parsers, even when empty, though, I expect many of 
the things we're proposing may fracture the expected XML.

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

Re: [dmarc-ietf] ARC questions

[Benny Pedersen]

Michael Thomas skrev den 2020-12-03 03:58:

if you're trying to make a point about the bloat, you might actually
get your facts straight. ARC adds an additional DKIM signature and a
Seal. i have no idea what a X-Google-DKIM-Signature is and is not
relevant.


would you show an example on that openARC adds openDKIM signature ?

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Michael Thomas]

On 12/2/20 10:12 PM, Jim Fenton wrote:


On 2 Dec 2020, at 6:09, Dave Crocker wrote:

*none*: The Domain Owner offers no expression of concern.

*quarantine:* The Domain Owner considers such mail to be
suspicious. It is possible the mail is valid, although the
failure creates a significant concern.

*reject: *The Domain Owner considers all such failures to be a
clear indication that the use of the domain name is not valid.
See Section 10.3
> for some
discussion of SMTP rejection methods and their implications.

The problem is that /quarantine/ and /reject/ are imperative verbs. 
The specification can use any definition, but if it uses imperative 
words, they are going to be taken as imperative.


Maybe /discardable/ should be used instead.

If it's not clear that it's "this is what I'd do" rather than some 
requirements language imperative then maybe that could be made more clear.




Why do I have a feeling of deja vu?



No comment.

Mike

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[John R Levine]

When this came up before someone said that reports can be extremely
large, many megabytes.  An HTTP POST or PUT is a much better way to send 
that.


However faster, an https PUT/POST at midnight arrives later than a mailto at 
midday.


I'm sorry but this makes no sense at all.  Why do you believe that people 
would not send reports by mail and by https at the same time?



Yes, PUT is better than POST.

How about pgp-signing the file with the dkim key?


Sorry, that doesn't make any sense either.  DKIM keys and PGP keys are 
different.  It is hypothetically possible to sign an http transaction with 
DKIM but that would be a giant distraction from what we're doing here.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Todd Herr]

On Thu, Dec 3, 2020 at 4:28 AM Laura Atkins  wrote:

>
>
> On 3 Dec 2020, at 06:03, Jim Fenton  wrote:
>
> On 2 Dec 2020, at 1:47, Laura Atkins wrote:
>
> p=quarantine is quite useful, particularly for those folks who are trying
> to get to a p=reject state.
>
> In practice, senders who publish p=none don’t find all of the indirect
> mail flows as some mailing lists do nothing to transform the 5322.from
> address for a p=none policy. Senders have found that when they switch from
> p=none to p=quarantine pct=0 they regularly find mail that was not failing
> for a p=none.
>
>
> I’m really confused by this. It sounds like the 5322.from address
> rewriting is creating additional errors that didn’t exist beforehand, and
> that’s the opposite of the intended purpose. Isn’t the purpose of rewriting
> the 5322.from address to change the domain to that of the mediator, which
> should redirect reporting to the mediator rather than the original sender?
>
>
> What I am trying to say is that as I understand it from the folks who
> professionally deploy DMARC, they regularly use p=quarantine pct=0 as part
> of the deployment process. There are DMARC failures that go undetected in a
> p=none situation but that is detected in a p=quarantine  pct=0 situation.
> My understanding was this was related to indirect flows through mailing
> lists and how mailing lists are handling the header transformation but it’s
> possible I got that piece incorrect.
>
>
Time was (and may still be) that there was a very specific type of mailing
list for which p=quarantine, pct=0 was required to get accurate DMARC
reporting, and that was for mail that transited Google groups. There've
been a couple of public discussions of the topic over on mailop, including
a thread from April 2018 with the subject of "DMARC p=quarantine pct=0".


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


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] Ticket #39 - remove p=quarantine

[Dave Crocker]

On 12/2/2020 10:12 PM, Jim Fenton wrote:

The problem is that /quarantine/ and /reject/ are imperative verbs.


As I said, I suspect that changing the vocabulary is not operationally 
practical  at this point.  It would be great for the folk already using 
DMARC to state a willingness to employ alternative vocabulary; but I'm 
not expecting them to.


If we get feedback to the contrary, we can have a vocabulary debate.  My 
own advice would be to avoid vocabulary that is directive about 
disposition and more declarative about status.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Alessandro Vesely]

On Thu 03/Dec/2020 00:34:32 +0100 John Levine wrote:

In article  you write:

A better means to control report size is to gauge the reporting interval.


When this came up before someone said that reports can be extremely
large, many megabytes.  An HTTP POST or PUT is a much better way to send that.



However faster, an https PUT/POST at midnight arrives later than a mailto at 
midday.




Here's another nit: POST doesn't pass the report's filename. There
should be a copy of the name in the header of the gzip data, but
semantically it would be better to do an https PUT to
/. That also has the advantage of being idempotent so
if it puts the same file twice the server can tell it's a duplicate.



Yes, PUT is better than POST.

How about pgp-signing the file with the dkim key?


Best
Ale
--












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

Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

[Alessandro Vesely]

On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote:


While this ticket/enhancement specifically mentions ARC, I could perhaps see the 
usefulness in other places.  It seems like it would be more beneficial to create a method 
by which other documents could provide XML- based "extensions" to the report.  
This would allow mechanisms relying on DMARC to independently define their reporting 
schema to be included in DMARC aggregate reports.  Alternately, we could focus 
specifically on ARC, and work to include that in the base XML.  This means that any later 
reporting requirements could again require changes to the core drafts.




Another possibility is for ARC to define its own report format.  Hijacking rua= 
targets to send a different kind of report should be allowed.  Otherwise, we 
could define a new tag, e.g. rue= (e for Extension).


In either case, as we're introduce variations in aggregate report content, we 
have to devise a method for determining what version/kind of report is attached 
to a given message.



Best
Ale
--















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

Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions

[Alessandro Vesely]

On Tue 01/Dec/2020 14:27:04 +0100 devel2020 wrote:

Le 01/12/2020 à 11:37, Alessandro Vesely a écrit :


[...] a meagre set of old-fashioned individuals who still dislike mass social 
media [...]


Can decisions please be made based on sound technical reasons rather
than intolerance and zealotry?



That was not meant to prompt the making of any decision.  It is a fact that 
mailing lists are not among the most popular communication tools.




Setting aside the form of your argument: no, contracting with Facebook
et al should not be a prerequisite for using the Internet for any
purpose. By the very definition of "open network".



I agree with that "should".


Best
Ale
--




















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

Re: [dmarc-ietf] Ticket #39 - remove p=quarantine

[Laura Atkins]

> On 3 Dec 2020, at 06:03, Jim Fenton  wrote:
> 
> On 2 Dec 2020, at 1:47, Laura Atkins wrote:
> 
>> p=quarantine is quite useful, particularly for those folks who are trying to 
>> get to a p=reject state.
>> 
>> In practice, senders who publish p=none don’t find all of the indirect mail 
>> flows as some mailing lists do nothing to transform the 5322.from address 
>> for a p=none policy. Senders have found that when they switch from p=none to 
>> p=quarantine pct=0 they regularly find mail that was not failing for a 
>> p=none.
> 
> I’m really confused by this. It sounds like the 5322.from address rewriting 
> is creating additional errors that didn’t exist beforehand, and that’s the 
> opposite of the intended purpose. Isn’t the purpose of rewriting the 
> 5322.from address to change the domain to that of the mediator, which should 
> redirect reporting to the mediator rather than the original sender?

What I am trying to say is that as I understand it from the folks who 
professionally deploy DMARC, they regularly use p=quarantine pct=0 as part of 
the deployment process. There are DMARC failures that go undetected in a p=none 
situation but that is detected in a p=quarantine  pct=0 situation.  My 
understanding was this was related to indirect flows through mailing lists and 
how mailing lists are handling the header transformation but it’s possible I 
got that piece incorrect. 

p=quarantine is valuable for other reasons as well, and I think it should be 
kept. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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