Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
Scott Kitterman writes: > Also, doing anything based on an ARC header field from anything other > than a trusted source is a recipe for failure. I've already seen > cases where spoofed email got accepted due to ARC from an untrusted > source. Don't forget the limitations of ARC. I am not particularly worried about spoofing of domains under my control. They are at p=none and cannot change to quarantine or reject due to the mailing list issue. In the past, the stance of DMARC has been clear, saying that use cases like mine cannot be handled by DMARC policies and therefore p=none is the only option. p=validate offers me a chance to get on board, at least some of the way. At present, I DKIM sign outgoing mail, but since p=none, the recipients are unlikely to find the DKIM signatures particularly helpful. /Benny ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
Scott Kitterman writes: > How do you define "First Hop" without enabling spoofers to trivially > bypass DMARC checks by forging more than one hop of headers? It wouldn't matter. Sensible mailing lists would reject non-first-hop mails for domains with p=validate. Spoofers can still spoof directly, but they cannot use mailing lists to spread their spoofed mails. This is a marked upgrade from p=none which most domains are forced to use at the moment. Then as infrastructure improves, recipients will start to reject incoming non-first-hop mail with p=validate if it does not have a valid ARC header. /Benny ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
Dotzero writes: > p= DID NOT mistakenly choose to use the language of receiver > actions. p= represents the domain-owner request to the receiver as to > the disposition of messages which fail to validate. Any reading of > "concern" is supposition on the part of yourself or other self > appointed interpreters of the mind of the domain-owner or > administrator. [..] This is an interoperability standard, not a > seance. Am I particularly thin-skinned for considering this language inflammatory? The thing is, domain owners can request anything they want, but why should anyone listen? Particularly if they are rude about it instead of asking nicely. When someone brings up a concern they have and explain why it is of benefit to either the recipient or the community to take certain actions, that will likely be heard. However, unexplained edicts are unlikely to be taken very seriously. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
Dave Crocker writes: > p: Domain Owner Assessment Policy (plain-text; REQUIRED for policy > records). Indicates the severity of concern the domain owner has, for > mail using its domain but not passing DMARC validation. Policy > applies to the domain queried and to subdomains, unless subdomain > policy is explicitly described using the "sp" tag. This tag is > mandatory for policy records only, but not for third-party reporting > records (see Section 7.1). Possible values are as follows: > > 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. Perhaps, in retrospect, the p= should have had something like the following values: none untrustworthy invalid p= mistakenly chose to use the language of receiver actions to describe what is actually domain-owner judgements. This is unfortunate, since it risks making the sender believe that it is possible to dictate receiver policy. Perhaps new names can be found, and the old ones kept as historical aliases? /Benny ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
Dotzero writes: > One might point to the fact that DMARC was just such an effort before > it was publicly published. While there was much criticism of this when > it was submitted to the IETF - "You just want us to rubber stamp this" > - there was no such intent. It had worked well within the group of > senders and receivers implementing it through private peering that the > effort was made so that any domain of any size, both senders and > receivers, could implement it if so desired. I think the adoption rate > in the wild speaks for itself (volume of mail covered by DMARC). Volume of mail covered by DMARC seems to be rather unimpressive unless you count p=none as covered. > You have left out one significant way of convincing receiver domains > and their admins. We used to have our CSRs (customer service) tell > people who received spoof emails (resulting in phishing, malware > compromise, etc.) from emails claiming to be from our domains that > they should contact their mail provider or email admin because the > problem could have been avoided if DMARC were being checked. We would > even provide them with the details and a form with all the information > in non-technical terms. It is amazing how quickly a provider pays > attention when their customers/users are complaining to them that the > provider could have prevented the heartache and grief but chose not > to. Again, this was for domains sending transactional mail with only a > limited number (intentionally) of role and support accounts. You can obviously do all that, but that is not what Douglas E. Foster advocated. > While IETF is not a lawmaking body, it has an impact on the decisions > of lawmaking bodies just as the decisions of lawmaking bodies can > impact the implementation of standards. Using the IETF as a way to get laws passed favouring ones business seems at best underhanded. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
"Douglas E. Foster" writes: > Ultimately, this becomes a question of power. Do domain owners have > the right, with the help of their correspondents, to prohibit spoofing > (unauthorized use) of their digital identity? Domain owners are free to use the court system to assert trademark rights and copyright. They are also free to apply whichever seals of digital identity that they want, of course. > Or since they are technically leaseholders, not owners, are their > rights conditional? You seem to be laboring under the impression that domain owners have a right to compel mail recipients to respect a DRM scheme. This is not the case. You can try to sue Google to force them to reject incoming email with your domain in the From: field and no valid DKIM (or whatever) signature, of course, but I have a hard time imagining which right you would assert to make the suit successful. > Specificslly, do Internet insiders have the right to declare their > spoofing control efforts to be based on foolish premises, both > unnecessary and inconvenient, and therefore not allowed? No one, certainly not "Internet insiders" of which I am certainly not one, is stopping you from doing whichever spoofing control efforts you want on your systems. Feel free to keep p=reject on your domains. Many mail servers will keep using that as a signal among many others, rather than as a blanket reject. If you want recipient mail servers to change that policy you can either do it by convincing their administrators or by getting a law passed. So far you appear to favour the latter approach, with your focus on "prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking body, so it appears there are better venues for you. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
Jeremy Harris writes: > On 15/07/2020 10:25, Benny Lyne Amorsen wrote: >> At the other end of the spectrum, domains which never ever >> participate in mailing lists or mail forwarding need some kind of >> "p=reject-yes-really-I-mean-it", to stop recipients from ignoring the >> policy. > > The domain owner doesn't know. It's his users that want to sign up > for, and send to, MLs. Who should be in control? The domain owner is already (mostly) in control. They will generally have authority over the email servers, which allows e.g. blocking all mail with a mailing list header. If the users do not like that policy, they will have to vote with their feet and send mail from a different domain. I do not imagine that any of the major "free" email domains will post "p=reject-yes-I-really-mean-it" policies, so it is not a terrible hardship. I checked a few of the major free email domains, they post p=none at present. When that is the case and when they apply their own judgement to p=reject and p=quarantine, what is the actual value of current DMARC? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Use of the RFC5322.Sender Header Field
Alessandro Vesely writes: > Perhaps we could formalize Sender:'s role by inventing some kind of > p=some, which requires Sender: alignment. The From: domain has to > remain the consumer of aggregate reports. That way it can learn which > senders redistribute its mail. This proposal seems spot on. Some domain owners believe they have a magic switch called p=reject that prevents unauthorized third parties from sending mail with From: field that has their @domain. This is not so, and mailing lists are one of the reasons why major email providers do not respect their policy. I have switched the domains I control from p=quarantine to p=none. I would use "p=sender-quarantine" or even "p=sender-reject" if it was available. At the other end of the spectrum, domains which never ever participate in mailing lists or mail forwarding need some kind of "p=reject-yes-really-I-mean-it", to stop recipients from ignoring the policy. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
