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
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,
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
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
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
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",
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
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
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
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
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
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
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
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
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.
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
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
+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
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
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
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
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.
>
22 matches
Mail list logo
