Re: [dmarc-ietf] New proposed wording for p=quarantiine
Hello John, I am really saying, that some addresses, like majordomo@ , which send answer to each received and accepted message, have no capability to perform a form of “quarantine”. It does not matter, whether this is an edge case. Once it is clarified how to act in this case, the same procedure can be applied to mailboxes, where users want to have no Spam folder. So mailboxes, which capability to quarantine messages is disabled and for users, who do not want to receive messages with SUSPICIOUS in the subject line or have any corresponding headers. Or for users who statistically never open their Spam folder. So it is a matter of clarifying what the domain owner wishes by publishing p=quarantine to happen to messages failing DMARC validation, when the receiving address, voluntary or not voluntary, does not offer quarantining capability. I have no problem, if the text "... reject at SMTP level" is not attached to the quarantine definition, but is implied by reading other passages. Then it does not make a difference. Regards Дилян On Fri, 2019-08-02 at 23:05 -0400, John Levine wrote: > In article <97b7d4320e77f9be84703677eba79686ec769f75.ca...@aegee.org> you > write: > > Hello John, > > > > the "... reject at SMTP level" is at least for messages, directed to an > > address, which does not support the > > concept of > > quarantining. > > > > Please propose what shall a site do, receiving a message, subject to > > quarantining, for an address, that does > > not support quarantining. > > It should do what RFC 7489 says: > > ... Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > > Are you really saying your mail system has no spam folders, no way to > adjust spam filtering, and no way to mark messages as suspicious > (e.g., add "PROBABLY SPAM" to the subject line)? > > If the problem is that it's an address that goes to some software > robot rather than being seen by people, do whatever you want. That's > an edge case for DMARC. > > R's, > John > > ___ > 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] New proposed wording for p=quarantiine
In article <97b7d4320e77f9be84703677eba79686ec769f75.ca...@aegee.org> you write: >Hello John, > >the "... reject at SMTP level" is at least for messages, directed to an >address, which does not support the >concept of >quarantining. > >Please propose what shall a site do, receiving a message, subject to >quarantining, for an address, that does >not support quarantining. It should do what RFC 7489 says: ... Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". Are you really saying your mail system has no spam folders, no way to adjust spam filtering, and no way to mark messages as suspicious (e.g., add "PROBABLY SPAM" to the subject line)? If the problem is that it's an address that goes to some software robot rather than being seen by people, do whatever you want. That's an edge case for DMARC. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New proposed wording for p=quarantiine
Hello John, the "... reject at SMTP level" is at least for messages, directed to an address, which does not support the concept of quarantining. Please propose what shall a site do, receiving a message, subject to quarantining, for an address, that does not support quarantining. Regards Dilyan On Fri, 2019-08-02 at 18:49 -0400, John Levine wrote: > In article you > write: > > Current wording for p=quarantine > > quarantine: The Domain Owner wishes to have email that fails the > > DMARC mechanism check be treated by Mail Receivers as > > suspicious. Depending on the capabilities of the Mail > > Receiver, this can mean "place into spam folder", "scrutinize > > with additional intensity", and/or "flag as suspicious". > > > > Amendment to the wording for p=quarantine: > > > > … or reject at SMTP level. ... > > No. We really, really, don't like changes that aren't backward > compatible. You can do what you want but there is no chance I would > ever make p=quarantine a signal to reject, and I think I am not > atypical. > > R's, > John > > PS: You can of course do whatever you want on your own system. > > ___ > 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] New proposed wording for p=quarantiine
In article you write: >Current wording for p=quarantine > quarantine: The Domain Owner wishes to have email that fails the > DMARC mechanism check be treated by Mail Receivers as > suspicious. Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > >Amendment to the wording for p=quarantine: > >… or reject at SMTP level. ... No. We really, really, don't like changes that aren't backward compatible. You can do what you want but there is no chance I would ever make p=quarantine a signal to reject, and I think I am not atypical. R's, John PS: You can of course do whatever you want on your own system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-ietf-dmarc-psd review
Is silence concurrence? Comments inline. Please let me know how to proceed
on updating the draft. I'd appreciate anyone else's feedback too.
Scott K
On Wednesday, July 31, 2019 8:28:17 PM EDT Murray S. Kucherawy wrote:
> Thanks for this, much better. Some additional feedback.
>
> Please note (everyone) that I'm offering these as clarifying contributions
> to text; I'm not prescribing or proscribing anything. If the text I'm
> proposing isn't worthy of consensus, please speak up.
>
> On Sat, Jul 27, 2019 at 1:45 PM Scott Kitterman
>
> wrote:
> > I updated the paragraph to start:
> >DMARC (Domain-based Message Authentication, Reporting, and
> >Conformance) is a scalable mechanism by which a mail-originating
> >organization can express domain-level policies and preferences for
> >message validation, disposition, and reporting, that a mail-receiving
> >organization can use to improve mail handling. DMARC policies can be
> >applied to individual domains or to all domains within an
> >organization. The design of DMARC precludes grouping policies for
> >domains based on policy published above the organizational level,
> >such as TLDs (Top Level Domains).
> >
> > Does that clear those comments up?
>
> That last sentence still puzzles me, and I think it's the term "grouping"
> that gives me trouble.
>
> How's this?
>
>DMARC (Domain-based Message Authentication, Reporting, and
>Conformance) is a scalable mechanism by which a mail-originating
>organization can express domain-level policies and preferences for
>message validation, disposition, and reporting, that a mail-receiving
>organization can use to improve mail handling. The design of DMARC
>presumes that domain names represent either nodes in the tree below
>which registrations occur, or nodes where registrations have occurred;
>it does not permit a domain name to have both of these properties
>simultaneously. Since its deployment in 2015, use of DMARC has shown
> a clear need for the ability to express policy for these domains as
> well.
>
>Domains at which registrations can occur are referred to as Public
>Suffix Domains (PSDs). This document describes an extension to DMARC
>to enable DMARC functionality for PSDs.
>
>This document also seeks to address implementations that consider a
> domain
>on the Public Suffix List (PSL) to be ineligible for DMARC enforcement.
>
>
> If we like this, I suggest it or language like it can also be used to
> rework the first paragraph of the Introduction section in -05. To
> import DMARC definitions into the introduction, you could say that
> DMARC presumes that a domain is either on the PSL or is an OD, and
> never both,.
I think this is generally fine, but it should be public suffix list (not
capitalized) as that's what's used in the main body of RFC 7489. Appendix A.
6.1 uses the PSL as an example, but it's only one possible source of such
data.
What would you (you = anyone) suggest for the introduction rewrite?
> > >As an example, imagine a country code TLD (ccTLD) which has public
> > >subdomains for government and commercial use (.gov.example and
> > >.com.example). Within the .gov.example public suffix, use of DMARC
> > >[RFC7489] has been mandated and .gov.example has published its own
> > >DMARC [RFC7489] record:
> > >
> > >"v=DMARC1;p=reject;rua=mailto:dm...@dmarc.service.gov.example;
> > >
> > > Can we add spaces after the semicolons? I know this is legal format
> > > but it would be more readable.
> >
> > Changed.
>
> Thanks. Now for the text right before the example; I suggest:
>
> As an example, ... Suppose there exists a registered domain
> "tax.gov.example" that is responsible for taxation in this imagined
> country. However, by exploiting the typically unauthenticated nature of
> email, there are regular malicious campaigns to impersonate this
> organization that use similar-looking ("cousin") domains such as
> "t4x.gov.example". These domains are not registered. Within the
> ".gov.example" public suffix, use of DMARC has been mandated, so
> "gov.example" publishes the following DMARC record:
>
> ...
>
> Defensively registering all variants of "tax" is obviously not a scalable
> strategy. The intent of this specification, therefore, is to enhance the
> DMARC algorithm by enabling an agent receiving such a message to be able to
> determine that a relevant policy is present at "gov.example", which is
> precluded by the current DMARC algorithm.
Looks good to me. Unless someone else suggests differently (soon), I'll do
that.
> > >There are two types of Public Suffix Operators (PSOs) for which this
> > >extension would be useful and appropriate:
> > >
> > >o Branded PSDs (e.g., ".google"): These domains are effectively
> > >
> > > Organizational Domains as discussed in DMARC [RFC7489]. They
> > > control all
[dmarc-ietf] New proposed wording for p=quarantiine
Current wording for p=quarantine quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". Amendment to the wording for p=quarantine: … or reject at SMTP level. The Domain Owner wishes in addition, that the sender of messages failing DMARC are notified about the suspicious handling with an appropriate rejection message. Senders not willing to be notified that their message is suspicious, shall use the NOTIFY=NEVER service extension. In the past, Domain Owner could express as wish either to reject or to quarantine. Considering that from the options: only reject; only qurantine; and quarantine, while notifying the sender about the suspicious handling of the message; nobody will choose only to quarantine, the interpretation of what the Domain Owner wishes by publishing quarantine was changed to include the rejection component. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Concerns for not Sending a Failure Report?
Hello, I just thougth once again on this. Some of the senders of aggregate reports offer free mailboxes. Aggregate reports show that emails from a host to a provider of free mailboxes sometimes do not validate DMARC. The one provider sending emails opens a free mailbox on the receiver and then sends a secret copy of each, otherwise ordinary delivered email, to that special mailbox. Then the mails from that mailbox are downloaded, and the A-R header is checked. By this way the sender finds out, which messages exactly have failed DMARC validation. At the end the same information is obtained, that can be obtained by exchanging a failure report: which messages have failed. Has somebody done this? Why does it have to be that complicated? Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ESC for Failed DMARC Validation
Hello, these are already now two ESC: 2.7.30 and 5.7.30. X.7.30 means in both cases, that DMARC validation failed. For a domain with policy p=reject; pct=0 the mail is delivered (250 2.7.30), despite failed DMARCр and for a domain with p=reject; pct=100 when DMARC failed and the mail is rejected (550 5.7.30). Please propose a different wording, I do not see a contradiction in my wording. Who will use it? I asked, why failure reports are not sent by some sites, and would the ones, who do not send failure reports, use the X.7.30 code. (Thus, if for failure reports there are concerns, while for ESC X.7.30 there are no concerns). I expect that at least parties who want to fix their DMARC/DKIM implementation will use it. The aggregate reports provide hints, that the DKIM implementation does not work. This ESC is not meant as a shortcut to collecting a lot of reports and analyzing them, it is a mean to act when no reports are sent. Regards Дилян On Fri, 2019-08-02 at 23:06 +0200, Rolf E. Sonneveld wrote: > On 02-08-19 22:54, Murray S. Kucherawy wrote: > > The wording you're using seems inconsistent to me.. Specifically, > > you're saying that x.7.30 means one thing when attached to a > > 200-series reply, but the opposite when attached to a 500-series > > reply. I would prefer to see two separate codes if you're going to do > > this. > > > > But the bigger question is implementation. Who would make use of > > this, either as a sender or a receiver? > > a receiver could assist a sender in adjusting its egress mail process > without the need for the receiver to collect a lot of DMARC reports and > analyse them. A sender could use it to improve its outbound mailflow. I > doubt however whether anyone will implement this as it assists possible > adversaries as well... > > /rolf > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ESC for Failed DMARC Validation
The wording you're using seems inconsistent to me. Specifically, you're saying that x.7.30 means one thing when attached to a 200-series reply, but the opposite when attached to a 500-series reply. I would prefer to see two separate codes if you're going to do this. But the bigger question is implementation. Who would make use of this, either as a sender or a receiver? -MSK On Fri, Aug 2, 2019 at 1:19 PM Дилян Палаузов wrote: > Hello Murray, > > ESC X.7.20, X.7.21 and X.7.22 are glued to return code 550, while I > propose an ESC, that works also with 250. > > Apart from this, X.7.20 and X.7.21 cannot be used instead of the proposed > X.7.30: > > If a site sees a valid DKIM signature, and previous experience with the > domain signing DKIM leads to increased trust in > this domain, then the signature is acceptable, but it does not have to > align with the From: address. > > With X.7.22: > > Description:This status code is returned when a message > contains one or more passing DKIM > signatures, but none are acceptable because > none have an identifier(s) > that matches the author address(es) found in > the From header field. This is a special > case of X.7.21. (This violates the advice > of Section 6.1 of RFC 6376.) > > If “none have an identifier that matches the author address found in the > From header field” means, that the DKIM part of > DMARC fails, then this ESC can be recommended by the DMARC specification > to signal to the sender, that the DKIM > implementations of sender and receiver disagree, as a light substitute to > the failure reports. > > Greetings > Дилян > > > On Fri, 2019-08-02 at 13:01 -0700, Murray S. Kucherawy wrote: > > On Fri, Aug 2, 2019 at 10:52 AM Дилян Палаузов < > dilyan.palau...@aegee.org> wrote: > > > I mean an enhanced status code, as at > > > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > . > > > > RFC7372 registered some for exactly this purpose (though not specific to > DMARC). Its Security Considerations section talks about the privacy risks. > > > > I don't know if they're actually in use. > > > > -MSK > > ___ > > 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] ESC for Failed DMARC Validation
Hello Murray, ESC X.7.20, X.7.21 and X.7.22 are glued to return code 550, while I propose an ESC, that works also with 250. Apart from this, X.7.20 and X.7.21 cannot be used instead of the proposed X.7.30: If a site sees a valid DKIM signature, and previous experience with the domain signing DKIM leads to increased trust in this domain, then the signature is acceptable, but it does not have to align with the From: address. With X.7.22: Description:This status code is returned when a message contains one or more passing DKIM signatures, but none are acceptable because none have an identifier(s) that matches the author address(es) found in the From header field. This is a special case of X.7.21. (This violates the advice of Section 6.1 of RFC 6376.) If “none have an identifier that matches the author address found in the From header field” means, that the DKIM part of DMARC fails, then this ESC can be recommended by the DMARC specification to signal to the sender, that the DKIM implementations of sender and receiver disagree, as a light substitute to the failure reports. Greetings Дилян On Fri, 2019-08-02 at 13:01 -0700, Murray S. Kucherawy wrote: > On Fri, Aug 2, 2019 at 10:52 AM Дилян Палаузов > wrote: > > I mean an enhanced status code, as at > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > > . > > RFC7372 registered some for exactly this purpose (though not specific to > DMARC). Its Security Considerations section talks about the privacy risks. > > I don't know if they're actually in use. > > -MSK > ___ > 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] ESC for Failed DMARC Validation
On Fri, Aug 2, 2019 at 10:52 AM Дилян Палаузов wrote: > I mean an enhanced status code, as at > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > . > RFC7372 registered some for exactly this purpose (though not specific to DMARC). Its Security Considerations section talks about the privacy risks. I don't know if they're actually in use. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL
On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote: > Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/, > does not contain the term "policy". > Wow. I'm amazed I got away with that. But it is clear from the things in the registry that that's how you do it. My recollection is that reporting the > client IP is immaterial, as for SPF. The term policy.iprev is certainly > misleading, since the value is not related to a locally-defined policy, > and is > not a reversed ip. To stick with A-R semantics, it should have been named > tcp.ip, remote.ip or some such. If a property warrants deprecation, it's > policy.iprev. > The choice of "policy" for "iprev" is rooted in history, because the earlier versions of the document (as you well know) demanded that the things being reported had something to do with the message itself. "iprev" was an exception the community chose to allow. It pre-dated RFC5782 which introduced DNSxLs formally. For guidance here, I would rely on anecdotes of implementation. Has anyone implemented something that attaches "iprev" results? Now for dnswl. Knowing which zone was queried is substantial in order to > interpret policy.ip, because there is no standard format. Yet, an > implementation could just throw a DNS query to a given local IP, instead > of a > FQDN to the default DNS server. In that case, one would have, for example: > >dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2 > > In that case one can hardly tell which is which. A meaningful ptype helps. > Why would the thing attaching "dnswl=pass" not also interpret "policy.ip"? I would expect it to have that knowledge, not downstream things. Again, I don't know what the value of "dnswl=pass" is if the thing attaching it doesn't even know how to interpret the result it got. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ESC for Failed DMARC Validation
Hello Alessandro, I mean an enhanced status code, as at https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml . Would you reply to messages failing DMARC with such a code, irrespective of whether the message was accepted or rejected? Are there privacy risks connected with such ESC? Regards Дилян On Fri, 2019-08-02 at 19:18 +0200, Alessandro Vesely wrote: > Hi Dilyan, > > > I'm not clear if you refer to the "DSN" extension (rfc3461). In fact, > positive > DSNs contain the A-R header field, and so can inform the sender when a message > is accepted although some of SPF/ DKIM/ DMARC failed. > > I don't send failure reports, as they look plenty of privacy risks. Perhaps > they could be sent to trusted sites only, but that way they'd lose generality. > > It's unfortunate that FR seem to be the only means to tell unwanted failures > from real spam/ phishing successfully blocked by the protocol. Perhaps that > distinction could be added to aggregate reports, even if it's not an exact > science. > > > Best > Ale > > > On Fri 02/Aug/2019 18:00:11 +0200 Дилян Палаузов wrote: > > why sites do not sent failure reports? > > > > Will a site, not sending failure report, be willing to use an Enhanced > > Status Code, to signal, that the DKIM/SPF > > implementations of the receiver and sender disagree? > > > > * * * New Enhanced Status Code for Failed DMARC Validation > > > > Code: X.7.30 > > Assocaited basic status code: Any > > Description: Used as partial substitution to failure reports, when DMARC > > validation fails. 250 2.7.30 means, that the > > message was delivered, ordinary or as junk, despite failed DMARC > > validation. 550 5.7.30 is used when the message is > > rejected, because the DMARC validation failed. This status code is only > > usefull, when the receiving site does not send > > failure reports. > > > > Regards > > Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL
On Fri, Aug 2, 2019 at 3:00 AM Alessandro Vesely wrote: > To stick with A-R semantics, it should have been named > tcp.ip, remote.ip or some such. > Note that RFC8617 section 10.2 ( https://tools.ietf.org/html/rfc8617#section-10.2) does add in an smtp.remote-ip method item. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ESC for Failed DMARC Validation
Hi Dilyan, I'm not clear if you refer to the "DSN" extension (rfc3461). In fact, positive DSNs contain the A-R header field, and so can inform the sender when a message is accepted although some of SPF/ DKIM/ DMARC failed. I don't send failure reports, as they look plenty of privacy risks. Perhaps they could be sent to trusted sites only, but that way they'd lose generality. It's unfortunate that FR seem to be the only means to tell unwanted failures from real spam/ phishing successfully blocked by the protocol. Perhaps that distinction could be added to aggregate reports, even if it's not an exact science. Best Ale On Fri 02/Aug/2019 18:00:11 +0200 Дилян Палаузов wrote: > > why sites do not sent failure reports? > > Will a site, not sending failure report, be willing to use an Enhanced Status > Code, to signal, that the DKIM/SPF > implementations of the receiver and sender disagree? > > * * * New Enhanced Status Code for Failed DMARC Validation > > Code: X.7.30 > Assocaited basic status code: Any > Description: Used as partial substitution to failure reports, when DMARC > validation fails. 250 2.7.30 means, that the > message was delivered, ordinary or as junk, despite failed DMARC validation. > 550 5.7.30 is used when the message is > rejected, because the DMARC validation failed. This status code is only > usefull, when the receiving site does not send > failure reports. > > Regards > Дилян -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC and Redirecting Messages
Hello, current text in https://tools.ietf.org/html/rfc7489#section-6 (DMARC Policy): Since email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY deviate from a Domain Owner's published policy during message processing [... and SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report (see Section 7.2).] I propose this amendment to the first part of the sentance, (writen in a more abstract way, where the receiving site decides on the policy. The wording is subject to further adjustments): * * * DMARC and Redirecting Messages For a site, that is supposed to redirect a message with failed DMARC validation, to another site, if the PCT with the policy is 100 the recommendation is not to redirect the message but reject it at SMTP level. The rationale is, that this message might be evaluated by the next hop site as Spam, while this hop does not consider the message as spam. In turn, the next hop can conclude, that this hop is sending spam. If the next hop decides to apply DMARC policy reject for the domain of the message, this hop will have to generate a bounce for the message, risking to be blacklisted by some backscatters IP reputation lists. For a site, that is supposed to redirect a message with failed DMARC validation, to another site, if the PCT with the policy is between 1 and 99, the recommendation is to reject the message at SMTP level and not forward it further. For redirected messages, the PCT sampling is applied at least twice, thus there is a probabily that the next hop rejects the message based on the PCT parameter, even if this hop has calculated not to reject the message. It is in unknown, whether the next hop will reject or quarantine messages failing DMARC validation and from the sender's perspective there is no difference, whether this hop or the next hop will reject the message. The recommendations above do not fully apply, when the current hop changes the From: address, as if the recipient on the next hop were a mailing list with one recipient, doing From: mungling. It is not recommended to tell the sender that the message was delivered in the Junk folder of the recipient, and to forward the message further, as the sender can get two rejections for the same message, from two different hops, which is confusing. This can happen, even if the From: address is mungled. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] ESC for Failed DMARC Validation
Hello, why sites do not sent failure reports? Will a site, not sending failure report, be willing to use an Enhanced Status Code, to signal, that the DKIM/SPF implementations of the receiver and sender disagree? * * * New Enhanced Status Code for Failed DMARC Validation Code: X.7.30 Assocaited basic status code: Any Description: Used as partial substitution to failure reports, when DMARC validation fails. 250 2.7.30 means, that the message was delivered, ordinary or as junk, despite failed DMARC validation. 550 5.7.30 is used when the message is rejected, because the DMARC validation failed. This status code is only usefull, when the receiving site does not send failure reports. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields
+1 No hats From my high tech gadget > On Aug 2, 2019, at 02:23, Stan Kalisch wrote: > >> On Thu, Aug 1, 2019, at 11:14 PM, John Levine wrote: >> Catching up on my mail after a laptop disaster, ... >> >> In article <4600949.rz9u5RyGOV@l5580> you write: >> >I think comments should be free-form. If we want data that can be machine >> >parsed, we should specify it. >> > >> >I think the above works in ABNF terms. It's: >> > >> >Authentication-Results:" authserv-id; method=result ptype.property=value >> >ptype.property=value >> >> I agree. We all put the DKIM stuff in comments but that's silly. If >> it's worth recording, it's worth doing in a way that we all agree >> about and can parse. > > Yes please. > > > Stan > > ___ > 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] New authentication method, DNSWL
On Fri 02/Aug/2019 08:18:20 +0200 Murray S. Kucherawy wrote: > On Thu, Aug 1, 2019 at 9:32 AM Alessandro Vesely wrote: > >> Let me narrate a use case. Courier-MTA can be configured to reject on >> SPF -all early in the SMTP dialogue, except if whitelisted. It writes SPF >> as well as dnswl results in the header, but does not interpret the >> policy.ip. Downstream filters can interpret the field based on the >> dns.zone. I use that feature to pass messages tagged "Heuristic" by the >> antivirus filter if policy.ip has a positive trustworthiness.>> > > I think this is a bit unusual, but RFC8601 doesn't preclude it. Seems to me > you're effectively throwing away the result, "pass" or "fail", if downstream > agents actually know more about the applied algorithm than the border MTA > adding it. In the case at hand, in fact, failed lookups are never reported. If no dnswl query is configured, it makes no sense to configure which trustworthiness value is needed to counterbalance which negative heuristics. The "pass" just confirms it's mere presence. In general, however, a filter may want to distinguish dnswl!=pass from no dnswl query at all. A negative query (NXDOMAIN or NO DATA) would be dnswl=none. No "fail" is provided for in the I-D. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Do is need a new ptype? Was Re: New authentication method, DNSWL
On Fri 02/Aug/2019 00:15:30 +0200 Scott Kitterman wrote: > Taking a step back, iprev uses the policy ptype. It's also based on local > interpretation of DNS data. Why doesn't policy work for dnswl just like for > iprev? Let me note that Section 3 of rfc8601, /The "iprev" Authentication Method/, does not contain the term "policy". My recollection is that reporting the client IP is immaterial, as for SPF. The term policy.iprev is certainly misleading, since the value is not related to a locally-defined policy, and is not a reversed ip. To stick with A-R semantics, it should have been named tcp.ip, remote.ip or some such. If a property warrants deprecation, it's policy.iprev. Now for dnswl. Knowing which zone was queried is substantial in order to interpret policy.ip, because there is no standard format. Yet, an implementation could just throw a DNS query to a given local IP, instead of a FQDN to the default DNS server. In that case, one would have, for example: dnswl=pass policy.ip=127.0.9.2 policy.zone=127.0.0.2 In that case one can hardly tell which is which. A meaningful ptype helps. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields
On Thu, Aug 1, 2019, at 11:14 PM, John Levine wrote: > Catching up on my mail after a laptop disaster, ... > > In article <4600949.rz9u5RyGOV@l5580> you write: > >I think comments should be free-form. If we want data that can be machine > >parsed, we should specify it. > > > >I think the above works in ABNF terms. It's: > > > >Authentication-Results:" authserv-id; method=result ptype.property=value > >ptype.property=value > > I agree. We all put the DKIM stuff in comments but that's silly. If > it's worth recording, it's worth doing in a way that we all agree > about and can parse. Yes please. Stan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New authentication method, DNSWL
On Thu, Aug 1, 2019 at 9:32 AM Alessandro Vesely wrote: > Let me narrate a use case. Courier-MTA can be configured to reject on SPF > -all > early in the SMTP dialogue, except if whitelisted. It writes SPF as well > as > dnswl results in the header, but does not interpret the policy.ip. > Downstream > filters can interpret the field based on the dns.zone. I use that feature > to > pass messages tagged "Heuristic" by the antivirus filter if policy.ip has a > positive trustworthiness. > I think this is a bit unusual, but RFC8601 doesn't preclude it. Seems to me you're effectively throwing away the result, "pass" or "fail", if downstream agents actually know more about the applied algorithm than the border MTA adding it. > Yes, the last paragraph is guidance about querying ANY. It could go to an > appendix or be stroked, if we want to go through another revision. > > The first paragraph is about how dnswl's may work. Rfc5782 just says > "DNSWLs > MAY have a TXT record that describes the reason for the entry." I agree > it is > slightly out of scope for registering the parameters. OTOH, I'd like to > know > more dnswl's in order to inform better on TXT record usage. > As long as the text is focused on the registration and not providing opinion about RFC5782, it's fine. I'm not so sure where the current text lands. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
