Re: [dmarc-discuss] DMARC Successful Mail Delivery Reports

You have p=none and ruf= turned on, AOL's doing exactly what you've requested. - Roland On 05/12/2014 10:25 AM, Scott Kitterman via dmarc-discuss wrote: Over the last few days I've gotten a number of bounces like this, all from AOL: Return-Path: Received: from imb-d04.mx.aol.com

Re: [dmarc-discuss] Still having problems with third-party sending

Eric Johnansson wrote: Maybe the misunderstanding speaks to a common conceptual model for outsiders? what are the implications of generalizing selectors to identifying different streams? The relevant DKIM construct would appear to be the signature domain parameters (d={something}). This

Re: [dmarc-discuss] A bit quiet?

Shal wrote: > Roland wrote: > >> - Forwarders who are large enough to be monitoring deliverability can >> trivially determine whether their ARC-signing is being successfully >> validated and/or when receivers trust them enough to accept messages >> despite failing DMARC. > > I see how that is

Re: [dmarc-discuss] A bit quiet?

Shal wrote: > By allowing greater automation and accuracy in identifying > intermediaries ARC may benefit the little guys the most - you > won't as likely be lost in the noise because the receivers will > be more likely to track the reputation of each and every ARC > participant they receive

Re: [dmarc-discuss] A bit quiet?

Scott Kitterman wrote: > Okay. If I implement ARC as a receiver, then I ignore p=reject > from Senders I trust not to lie to me if it passes ARC? p=reject is asserted by Domain Owners, whether or not they're senders. This is orthogonal to ARC's interest in forwarders. The situation in which to

Re: [dmarc-discuss] A bit quiet?

Scott Kitterman wrote: > On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss > <dmarc-discuss@dmarc.org> wrote: >>The question is not who you trust - ARC doesn't directly change that - >>but how you reliably automate determining whether the message was &g

Re: [dmarc-discuss] A bit quiet?

Shal wrote: > Although I think ARC is a step forward, I think it still leaves list > managers with a bit of a conundrum, at least in the near and moderate > term: at what point does it make sense for the list service to invest > the effort in implementing ARC processing? There are multiple

Re: [dmarc-discuss] A bit quiet?

Al Iverson wrote: > From my own perspective, I'm unclear on how well this will work. I > assume the chain process is based on addressing anything thrown at at > it; mailing list posts going through mail forwarding; ARC on both > would in theory keep authentication intact and prevent p=reject

Re: [dmarc-discuss] A bit quiet?

Scott Kitterman wrote: >> On October 26, 2015 9:12:17 AM EDT, Roland Turner via dmarc-discuss >> <dmarc-discuss@dmarc.org> wrote: >>Scott Kitterman wrote: > ... > snipped down to one bit as we seem to mostly be going around in circles > ... >>> As

Re: [dmarc-discuss] A bit quiet?

Scott Kitterman wrote: > On Monday, October 26, 2015 06:47:33 AM Roland Turner via dmarc-discuss wrote: >> Scott Kitterman wrote: >> > I don't see why the signing domain of the DKIM signature that could be >> > added by the most recent sender doesn't already

Re: [dmarc-discuss] rddmarc & comcast reports

Yes, the slash is mandatory. From RFC 2045 5.1: content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive. - Roland Roland Turner | Labs Director Singapore | M:

Re: [dmarc-discuss] Neebie Questions about Spoofing Prevention and DMARC implementation

Hi Marc, Largely echoing others: * This is not a one-week project, you'll be lucky if it's a one-quarter project. To get to a steady state you have to (a) work with every 3rd-party sender used by every business unit in every country in which the companies do business, a non-zero

Re: [dmarc-discuss] Two DKIM sections in the DMARC report from Google

Here's a scenario, although it's a little contrived: - two people in your organisation are subscribed to an external mailing list - one posts to the list, the post is DKIM signed but the list's addition of a footer breaks the signature - that message goes to the second subscriber within your

Re: [dmarc-discuss] wanted: rfc number

Andreas wrote: > because > - the MTA already did the rDNS job > - I send the failure reports to myself. I still "see" the Source-IP > field which has not so much information... As you're not aiming for machine consumption, there's no need for a new field. Just use a comment: Source-IP:

Re: [dmarc-discuss] ARC adoption

Andreas Schulze wrote: > 2) > a general point I'm still unsure about: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-usage say in 2.) > >> "If the mailing list implemented ARC, ..." > > ARC *require* the list operator (Intermediary) to install new or update > existing - right? No.

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

Scott Kitterman wrote: > So I hear what you're saying, but it doesn't change my mind. I guess if the > large providers think this is useful, then meh, OK, That would be the guys who receive more than half of the world's email? I would rank that slightly above "meh", but sure, for small guys

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

John Levine wrote: >>I'd prefer: >> >>From: Foo list [Jane Smith] >>CC: Jane Smith > > Given that most MUAs these days don't show the e-mail address > at all, it's hard to see why that would be better. Granted, it's a fine point. >> 1: Reply-To: appears

Re: [dmarc-discuss] Sub-domain validation

Brotman, Alexander wrote: > I have a question about how to interpret a message for DMARC validation, > relating to section 3.1.1, specifically: > >To illustrate, in relaxed mode, if a validated DKIM signature >successfully verifies with a "d=" domain of "example.com", and the >

Re: [dmarc-discuss] Experience 16 days with DMARC

I'd suggest a few things: - You're looking a little too closely at daily changes, particularly around implementation time. Allow the thing some time to settle, perhaps a month, before considering next steps. Bear in mind that there are multiple, independent good and evil actors here, each

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

Scott, You're [still!] confusing multiple conceptions of trust, including at least: 1) trust in the intention and ability of multiple upstream forwarders to ARC-sign correctly, 2) trust in the lack of intention to abuse by the organisation at the other end of the SMTP connection, and 3) trust

Re: [dmarc-discuss] Increase in Forwarders Since Implementation of DMARC Reject Policy

This would appear to be a Dmarcian question rather than a DMARC one as the Threat/Unknown is a Dmarcian classification rather than a DMARC one. More broadly, a/some receiver(s) and/or Dmarcian would appear to have decided at about the time that you made your change to reclassify a bunch of mail

Re: [dmarc-discuss] what MUAs show, was introduction to the list-virtual

John Levine wrote: > DMARC does an OK job when crooks use the exact domain name, which they > stilll do a lot, but we still don't have a clue about what to do when > they don't, other than trying to filter it because it looks evil, not > because it sorta kinda looks like a domain name in someone

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

Scott Kitterman wrote: > To > the extent ARC is useful to mitigate the DMARC mailing list issue, it's only > useful with additional data inputs that are not public and are not feasible > for small providers to generate on their own. I meant to ask earlier: would you level the same criticism at

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

Franck Martin wrote: > As I said earlier spamhaus and surbl has the data. The question is not > which domains to trust, but which domains not to trust. They may or may not. (Analysing Received: headers to learn about forwarding behaviour is not an obviously important input for those

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

(merging two sub-threads) Scott Kitterman wrote: > Along with the good things you (quite reasonably) describe, there will also be > an increased tendency towards concentration of power in a few hands. > Personally, I think that's a bad thing. Your previous message in this thread > captured my

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

Ben Greenfield wrote: > I believe the IP and hostname match exactly the ip address and hostname of > the working DKIM, SPF. I was assuming that these were the emails that went to > list-serves, but on further consideration if they were list-servs that would > show the ip and hostname of the

Re: [dmarc-discuss] introduction to the list-virtual server & mailman questions

John Levine wrote: > How is this different from everyone's favorite alleged mailing list > solution? > > From: Foo list on behalf of Jane Smith ... > PS: well, other than it's a little more explicit about where the > responsibility lies That is the difference. I'd prefer:

Re: [dmarc-discuss] is that *really* valid

Franck Martin wrote: > Even in this case Lastname is not a valid mailbox as it does not have a valid > email address, That is my interpretation also. The ability of many MTAs to work with implicit domains internally is outside 5322's scope. - Roland On Wed, Apr 6, 2016 at 9:41 AM, A.

Re: [dmarc-discuss] please clarify

A. Schulze wrote: > I have a question about DMARC alignments. > > the usual case: > - RFC5322.From: sub.example.com > - DKIM or SPF authentication identifier: example.com > > -> this is aligned in relax mode. > > But: > - RFC5322.From: example.com > - DKIM or SPF authentication identifier:

Re: [dmarc-discuss] please clarify

Andreas Schulze wrote: > Roland Turner via dmarc-discuss: > >> Yes. In all of the cases above, the Organizational Domain for both >> RFC5322.From and the DKIM/SPF authentication is example.com, >> consequently they match in relaxed mode. The same would be true f

Re: [dmarc-discuss] please clarify

Andreas Schulze wrote: > Roland Turner via dmarc-discuss: > >> Yes. In all of the cases above, the Organizational Domain for both >> RFC5322.From and the DKIM/SPF authentication is example.com, >> consequently they match in relaxed mode. The same would be true f

Re: [dmarc-discuss] DMARC and null path

A. Schulze wrote: > Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss: >> In Office 365 it would. Others' implementations may vary. > > "may or may not" - is that really the intention of DMARC? That is how DMARC is specified, yes. Intention is a bit harder: - the ideal is that all

Re: [dmarc-discuss] DMARC and null path

Scott Kitterman wrote: >> Am 13.05.2016 um 22:35 schrieb Terry Zink via dmarc-discuss: >>> In Office 365 it would. Others' implementations may vary. >> >> "may or may not" - is that really the intention of DMARC? > > I think RFC 7489, paragraph 3.1.2 is very explicit about this. It is >

Re: [dmarc-discuss] exegesis: pass and fail together

Hi Thomas, It's not immediately clear from your edits whether the results that you are showing are from the same of the DMARC report; my guess is that they're not. Assuming that my guess is correct: it's worth bearing in mind that a DMARC aggregate report is just that: a report aggregating

Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

Jim Popovitch wrote: > The difficulty I have is exactly as you described. I received a > DMARC report that says there is a DKIM failure, but what is not clear > is whether or not the email was "quite possibly not tested or > recorded". That DMARC report is pointless without knowing more. You

[dmarc-discuss] Can dmarc-discuss-owner please step forward?

I've been having a subscription management problem for a couple of weeks, can't solve it myself, and the dmarc-discuss-owner alias doesn't appear to be working/responding. - Roland [https://www.trustsphere.com/images/signatures/trustsphere.gif] Roland Turner Chief Privacy Officer

Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

Jim Popovitch wrote: >> You should definitely disregard reports that aren't useful to you. > > I'd actually prefer to work with the sender in order to fully > understand the differences between what they see and what larger > receivers see. Given that feedback is provided on an as-is basis, and

Re: [dmarc-discuss] opendkim-atpszone reproducibility and examples

I'd suggest that reliance upon ADSP is unwise as - having being reclassified as historic - it could stop working at any time without warning. A better option might be to sign your reports with the DKIM signature of the reporting domain (i.e. sign with example.eu instead of example.com in your

Re: [dmarc-discuss] A bit quiet?

John Payne wrote: > Spoke too soon. I'm getting reports of IETF list mail from @akamai.com ending > up in Gmail spam folders :( > >> On Jan 31, 2017, at 9:07 AM, Payne, John via dmarc-discuss >> wrote: >> >> And it did the trick. Down to a manageable number of

Re: [dmarc-discuss] Can dmarc-discuss-owner please step forward?

ovitch via dmarc-discuss <dmarc-discuss@dmarc.org> Sent: Saturday, 4 February 2017 18:49 To: DMARC Discussion List Subject: Re: [dmarc-discuss] Can dmarc-discuss-owner please step forward? On Fri, Feb 3, 2017 at 7:45 PM, Roland Turner via dmarc-discuss <dmarc-discuss@dmarc.org> wrote: &g

Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

Jim Popovitch wrote: You should definitely disregard reports that aren't useful to you. >>> >>> I'd actually prefer to work with the sender in order to fully >>> understand the differences between what they see and what larger >>> receivers see. >> >> Given that feedback is provided on an

Re: [dmarc-discuss] Can dmarc-discuss-owner please step forward?

I'd add the the unsubscribe process has the same problem with clicking the confirmation link, and that using the reply-to-message approach works here too. - Roland On 02/08/2017 04:18 PM, Roland Turner via dmarc-discuss

Re: [dmarc-discuss] Why do I receive RUAs for emails that align?

Jim, Bear in mind that all reporting is at the good graces of receivers; the options to fine-tune what is sent may, or may not, actually be implemented by any given receiver. (This isn't an interoperability or conformance comment so much as a real-world systems one. Postel's Law definitely

Re: [dmarc-discuss] A bit quiet?

John Payne wrote: > That's awesome. Do we have enough implementers on this list to gain any > confidence on whether or not > p=quarantine and pct=0 would enforce quarantine or not? It is a reasonably safe bet that pct=0 will prevent quarantining. (Any receiver observed doing otherwise will no

Re: [dmarc-discuss] dmarc.org breaks dkim & dmarc

Benny, I would remind you that the Note Well terms linked at the bottom of each message include "you agree to participate in a ... cordial manner". I would suggest that your conduct has slipped a little below that standard[1], and that it might be helpful and productive to take a different

Re: [dmarc-discuss] dmarc fail for linkedin

This looks like a receiver-side bug. An SPF pass for bounces.linkedin.com implies a DMARC pass for linkedin.com so long as the linked.com policy specifies or defaults to relaxed alignment (it does). - Roland [https://www.trustsphere.com/images/signatures/trustsphere.gif] Roland Turner Labs

Re: [dmarc-discuss] A bit quiet?

Payne, John wrote: > Yeah, but why are they showing up in _my_ DMARC reports? ... > Domain MAIL FROM DKIM domain SPF AuthDKIM Auth Total > akamai.com >

Re: [dmarc-discuss] FortiNet’s FortiMail DMARC implementation

Petr Novák wrote: > I wonder what do you guys think about it's DMARC implementation. If you > enable DMARC check in FortiMail it rejects(or performs other configured > action) any mail that fails DMARC check no matter what policy source > domain has configured. So it also rejects mails from

Re: [dmarc-discuss] FBL via DMARC?

g.png]<http://mail.ru/> Mail.Ru: ?, ? ? ?, ???, <http://mail.ru/> mail.ru ? Mail.Ru - ?? ?? ?, ??? ? ??? ?, ?? ... Gil On Tue, Nov 29, 2016 at 6:55 AM, Roland Turner via dmarc-discuss <dmarc-discuss@dmarc.org<m

Re: [dmarc-discuss] FBL via DMARC?

I'd hazard a guess that confidentiality constraints get in the way here, for the same reason that most receivers won't provide DMARC failure reports, only aggregate reports. Note that the feedback mechanism for receivers who wish to volunteer reports already exists - and is the origin of

Re: [dmarc-discuss] Getting to reject, was :Re: FortiNet’s FortiMail DMARC implementation

Petr, Do you also kick small dogs? I'd suggest that a 2-week turnaround on a bug that's non-critical for Fortinet's customers is pretty impressive. On the meaning of "by design", there are of course multiple designs (intentions) present. Surely you're familiar with the tree-swing project

Re: [dmarc-discuss] A bit quiet?

at present? (If not, stop work on this now!) - Roland From: Payne, John <jpa...@akamai.com> Sent: Friday, 28 October 2016 04:45 To: Roland Turner Cc: DMARC Discussion List Subject: Re: [dmarc-discuss] A bit quiet? > On Oct 26, 2016, at 8:56 PM, Roland T

Re: [dmarc-discuss] Beware of the size limit in DMARC URIs

Consider https://www.ietf.org/mailman/listinfo/dmarc - Roland From: dmarc-discuss on behalf of Juri Haberland via dmarc-discuss Sent: Wednesday, 12 October 2016 16:32 To: Juri Haberland Cc: DMARC

Re: [dmarc-discuss] gmail's DMARC check doesn't respect subdomain policy

Rolf E. Sonneveld wrote: > On 12-12-16 07:47, Roland Turner via dmarc-discuss wrote: >> it's not at all clear why "p=reject sp=none" would ever be a good idea. > > actually I have two customers using mail for both their office automation > and for business processes. B

Re: [dmarc-discuss] gmail's DMARC check doesn't respect subdomain policy

Povl Hessellund wrote: > We are not alone here. We have all sorts of systems like newsletters (they do > DKIM etc), > HR system, time registration system, other misc systems. Maybe it is 10 > subdomains only, > and maybe we should just create DMARC record for all of them with p=none - > and

Re: [dmarc-discuss] gmail's DMARC check doesn't respect subdomain policy

Steven M Jones wrote: > Some of your subdomains may send infrequently, and you may not know what > all of them are until end of month/quarter. Depending on what's > happening with the parent domain, this odd-looking policy might be your > better option for the interim. Certainly, but that's also

Re: [dmarc-discuss] RUF reports

A local_policy override is a discretionary choice by the receiver; it's not clear what choice is being made or why. Failure reports are sent at the discretion of the receiver, and then only when they determine a failure, which in this case has not occurred for receiver-local reasons. -

Re: [dmarc-discuss] DMARC report from Google shows unexpected result

Jim Garrison wrote (after John Levine wrote): >> When you looked at your outgoing mail logs for mail you sent yesterday >> to MTAs in the IP range 209.17.112.0/21, which is one of web.com's >> hosting farms, what did you find? > > My mail logs show no outgoing connections to any IP address in >

Re: [dmarc-discuss] Fwd: Hotmail forwarding

I meant to add: it would be sensible to create a hotmail.com account yourself and test the simple case of a freshly-created account. This won't tell you everything, but it will tell you whether your setup is broken even for simple Microsoft cases. - Roland

Re: [dmarc-discuss] Get failure reports without actually rejecting messages?

Hi Jonathan, Your thesis is incorrect: there is no connection between your specified policy and whether you'll receive failure reports. Very few receivers are willing to send failure reports so, in general, you won't receive them. There are some situations in which they are made available

Re: [dmarc-discuss] Anything to be done about DMARC failures caused by internal Microsoft forwards?

On 16/07/17 09:07, Jonathan Kamens via dmarc-discuss wrote: my impression that DMARC is unreliable because of problematic elements scattered throughout its design and implementation. DMARC is only "unreliable" if you start with unrealistic expectations. The idea that domain registrants get

Re: [dmarc-discuss] OOF failed DMARC verification by linkedin

Despite the error message showing up in a DMARC context, this sounds more like a failure in how your OOO responses are created. For example, if LinkedIn sends you: MAIL FROM:<44a037374908b416988bae2914f01ccc32dadbf94fb7b0cceb2b8aa7aa8b5...@bounce.linkedin.com> RCPT

Re: [dmarc-discuss] DMARC authentication issues with Google

Is the information in this graph consistent with what's in Google's aggregate feedback? (This is to determine whether Google's DMARC implementation is broken, or just the postmaster tool.) - Roland On 05/10/17 18:51, The Venus Project Postmaster via dmarc-discuss wrote: Hi everyone, For

Re: [dmarc-discuss] Google not sending aggregate reports for my .US TLD

On 28/10/17 06:55, Dave Crocker via dmarc-discuss wrote: There's a meta-lesson here, given how relatively mature and heavily-used DMARC is, which ought to make it surprising that this sort of thing pops up this late. But I can't figure out what sort of productive statement to make to

Re: [dmarc-discuss] DSN from microsoftonline.com

What HELO/EHLO hostname is being presented? - Roland On 20/12/17 21:14, A. Schulze via dmarc-discuss wrote: Hello, we use to send a portion of messages requesting delivery status notification on success. In general

Re: [dmarc-discuss] DSN from microsoftonline.com

On 21/12/17 05:43, A. Schulze via dmarc-discuss wrote Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss: What HELO/EHLO hostname is being presented? I'm out of office for the next days and have no access to that data. From what I remember it's the hostname of the sending system

Re: [dmarc-discuss] DMARC Reporting De-duplication

Would this really help? You haven't explained what you mean by "a little hard to consume". On the face of it, it's just an integer; a 1 is no easier to perform arithmetic on than a 2,436. If what you mean is that it's difficult to make meaningful comparison between the number that you send

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On 25/05/18 19:00, Alessandro Vesely via dmarc-discuss wrote: Wasn't this tried for SPF already? A whitelist of "I trust these guys to make exactly the same abuse-filtering decisions that I'd make" and a whitelist of "I trust these guys not to lie in ARC signing/sealing" are two very

Re: [dmarc-discuss] DMARC newbie, seems to work, so why this report?

Gerben, Note that the HELO string is only ever processed for DMARC if MAIL FROM is <> and, even then, not all implementations process it at all (it's dependent upon the behaviour of the underlying SPF implementation). The tag is telling you that the return path is

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On 31/05/18 02:31, Alessandro Vesely via dmarc-discuss wrote: On Wed 30/May/2018 16:13:12 +0200 Roland Turner via dmarc-discuss wrote: On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote: [...] which includes pretty much all mail sites. The latter is *not* a slow-moving data set

[dmarc-discuss] RUF and GDPR (Re: RUA vs RUF reports)

On 30/05/18 22:56, Richard via dmarc-discuss wrote: I realize that enforcement of GDPR is still a work in progress, but: > Failure reports send copies of your users' > mail to total strangers. would seem to run directly against its intent. I hadn't thought to perform this analysis:

[dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)

On 31/05/18 04:51, Jonathan Kamens via dmarc-discuss wrote: On 5/30/18 4:22 PM, John Levine wrote: 2) The people receiving the failure reports aren't "total strangers." They are either (a) the same people who run the email infrastructure (if failure reports are handled internally), who are

[dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)

On 31/05/18 02:01, Jonathan Kamens via dmarc-discuss wrote: Two comments: 1) Most of the failure reports I've seen haven't included the message body, they've only included the headers. So the exposure is limited. I assume limiting the exposure is the whole reason why the reports don't

Re: [dmarc-discuss] Blind RUF and GDPR (Re: RUA vs RUF reports)

On 31/05/18 10:28, Richard via dmarc-discuss wrote: Date: Thursday, May 31, 2018 09:26:38 +0800 From: Roland Turner via dmarc-discuss Sending failure reports to strangers appears unjustifiable under GDPR. A currently common case where reports are going where they shouldn't is with mailing

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On 28/05/18 19:26, Alessandro Vesely via dmarc-discuss wrote: Your points define ARC's scope very well. But what's big guys' role? Let me call /semantic mailbox providers/ those company or personal mail sites whose users have some kind of trust relationship with, e.g. because they work for

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On 31/05/18 23:13, Alessandro Vesely via dmarc-discuss wrote: 1: Granted, the list becomes a priority list for compromise attempts no spam indicator implies that the upstream ARC chain is faked.>>> You've lost me: difficulty of substantiating statements like "I trust these guys not to lie in

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On 01/06/18 17:04, Alessandro Vesely via dmarc-discuss wrote: I see. As a small receiver, I didn't even think about comparing different forwarders of the same senders. In my case, such coincidences only cover a handful of trusted mailing lists. Your argument further confirms how ARC better

Re: [dmarc-discuss] RUA vs RUF reports

Al, Note that the terminology changed a while back from forensic reports to failure reports, presumably to remove the confusion that the use of the term forensic invites[1]. You've not stated what action you intend to take in response to the receipt of a failure report, so it's a little

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On 29/05/18 23:05, Alessandro Vesely via dmarc-discuss wrote:  * A single public whitelist is not necessary for ARC to work, multiple    lists are certainly possible, but the mapping of well-behaved    whitelist operators is: o much easier than mapping abusers, as the latter are

Re: [dmarc-discuss] General DMARC weakness - personal forwarding

On 30/05/18 06:09, Brandon Long via dmarc-discuss wrote: On Tue, May 29, 2018 at 8:10 AM Alessandro Vesely via dmarc-discuss mailto:dmarc-discuss@dmarc.org>> wrote: I know ARC proponents don't want author's domains to sign ARC-0, but never understood why.  Anyway, ordinary

Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC

terman via dmarc-discuss <dmarc-discuss@dmarc.org <mailto:dmarc-discuss@dmarc.org>> wrote: On Sunday, April 22, 2018 02:12:33 PM Roland Turner via dmarc-discuss wrote: > On 21/04/18 05:36, Scott Kitterman via dmarc-discuss wrote: > > As most of you alread

Re: [dmarc-discuss] Mimecast and Office 365

omplete managed email solution from a single web based platform. For more information please visit http://www.mimecast.com *From: *dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of Roland Turner via dmarc-discuss <dmarc-discuss@dmarc.org> *Reply-To: *Roland Turner <

Re: [dmarc-discuss] How to treat multiple DMARC reports for the same message

Hi Ivan, There is in general no way to identify multiple DMARC reports for the same message[1]. The spec is simply pointing out that DMARC report consumers cannot assume things like aggregate message counts across reports from multiple receivers indicate that same number of original

Re: [dmarc-discuss] DSN from microsoftonline.com

On 21/12/17 05:43, A. Schulze via dmarc-discuss wrote: Am 20.12.2017 um 18:44 schrieb Roland Turner via dmarc-discuss: What HELO/EHLO hostname is being presented? I'm out of office for the next days and have no access to that data. From what I remember it's the hostname of the sending system

Re: [dmarc-discuss] Email encryption services and DMARC

Ivan, Can you show sample/likely envelopes/headers that would cause the problem? It's not clear from your description why there's a problem. Are you saying that Cisco is running a service that impersonates author (5322.From) domains of *_non_*-customers? - Roland

Re: [dmarc-discuss] Mimecast and Office 365

On 11/04/18 22:07, Ivan Kovachev via dmarc-discuss wrote: Hello guys, I have three questions for you that I am unsure about and hoping that someone at Microsoft will be able to help: First two questions are related to Mimecast acting as inbound security gateway to O365: 1. When Mimecast

Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC

On 21/04/18 05:36, Scott Kitterman via dmarc-discuss wrote: As most of you already know, the DCRUP working group is adding a new signature algorithm to DKIM. I have been sending dual rsa-sha256/ed25519-sha256 signed mail for some time and I have notice an oddity in DMARC reporting. Typically,

Re: [dmarc-discuss] [EXTERNAL] Re: Mimecast and Office 365

Ah, in that case we've been talking at crossed purposes. I've just realised that Ivan's question ("Would O365 do DMARC checks for internal emails ie. O365 tenant employee to another O365 tenant employee?") is ambiguous: * I've assumed that he means: Would O365 do DMARC checks for internal

Re: [dmarc-discuss] Mimecast and Office 365

approximate a RUF report. But there’s no official DMARC reporting at this time. --Terry *From:*dmarc-discuss <dmarc-discuss-boun...@dmarc.org> *On Behalf Of *Roland Turner via dmarc-discuss *Sent:* Thursday, April 12, 2018 12:57 AM *To:* dmarc-discuss@dmarc.org *Subject:* [EXTE

Re: [dmarc-discuss] Mimecast and Office 365

On 24/04/18 00:51, Terry Zink via dmarc-discuss wrote: > Failure reporting seems odd (because it's always legitimate) > until you recall that part of the purpose of failure reporting > is to discover errors by the domain registrant, particularly > including errors in the DNS zone file, which

Re: [dmarc-discuss] dmarc-discuss Digest, Vol 72, Issue 2

As they're purely internal to a single organisation (the receiving domain, which happens to have outsourced to Mimecast and Microsoft), there's no reason to record the failures but, yes, Authentication-Results: headers might reasonably be expected to contain this information. ARC headers also

Re: [dmarc-discuss] dmarc-discuss Digest, Vol 72, Issue 2

On 19/04/18 00:48, Ivan Kovachev via dmarc-discuss wrote: I found this on Microsoft's website: "If you have configured your domain's MX records where EOP is not the first entry, DMARC failures will not be enforced for your domain. If you're an Office 365 customer, and your domain's primary MX

Re: [dmarc-discuss] LinkedIn DKIM validation failure resulting in DMARC fail

Ivan, I've dug into this in the past and confirmed that there is something wrong that no-one seemed to want to do anything about. (I forget the details but (a) LinkedIn does something slightly unusual in sending its invitation (different envelope sender and author domains?), and (b) Office

Re: [dmarc-discuss] "p=none" vs. "p=quarantine; pct=0"

On 10/10/18 03:28, Payne, John via dmarc-discuss wrote: p=none -> “we’re trying to figure out if we’re going to be able to go to p=quarantine” While that's undoubtedly true in many cases, it's certainly not true in all, and the spec does not make this assumption. If you treat quarantine

Re: [dmarc-discuss] "p=none" vs. "p=quarantine; pct=0"

On 10/10/18 01:02, Payne, John via dmarc-discuss wrote: I believe that p= should trigger “special handling” if there is any to be triggered. p=none is semantically different from the record not existing, but it’s being treated the same. It is an important characteristic of the current

Re: [dmarc-discuss] Help - updataed

What is a DMARC syntax error? (Which tool gave this? What operation was it performing at the time?) Yes, example.com TXT "v=spf1 -all" _dmarc.example.com "v=DMARC1; p=reject;" is a reasonable way to announce that a domain can never be used for sending email. - Roland On 26/09/18

Re: [dmarc-discuss] Hotmail violating DMARC specification

Calendaring corner cases are numerous. If the calendaring system is to co-operate with DMARC (but note that it's not a foregone conclusion that the operator will want to do so) the options in this case would appear to be: * Take ownership of the forwarded message by setting From: to the

Re: [dmarc-discuss] help!

Implement DKIM with as many of your third parties as possible. Most have now realised that they can do their own key-rotation if they simply specify two CNAME records for you to put into your zone file (rather than issue you a key, or have you issue them one). Third-party SPF will generally

Re: [dmarc-discuss] DMARC is not working

On 23/11/18 4:01 pm, Dpto Ciberseguridad via dmarc-discuss wrote: "v=DMARC1;p=reject;ruc=mailto:dmarc@x; It worked fine till last month when testing emails, we saw it was not rejecting unauthorized emails. Note that setting p=reject does not mean that receivers will reject messages

Re: [dmarc-discuss] DMARC oddity

Right. This is the envelope sender (5321.MAIL FROM). It doesn't align with linktechs.net, so won't contribute to a DMARC pass. Why does the message have an author/5322.From: address in the linktechs.net domain, but not a valid DKIM signature? This looks like a typical list-breaks-DKIM

  1   2   >