----- Original Message ----- > From: "Steven M Jones via dmarc-discuss" <[email protected]> > To: [email protected] > Sent: Monday, August 17, 2015 5:14:04 PM > Subject: Re: [dmarc-discuss] Still having problems with third-party > sending
> On 08/17/2015 04:56, eric johnansson via dmarc-discuss wrote: > > Domain is intelli-shop.com > > > From addresses are: [email protected] > > > According to report from unlock the inbox, I have passed identifier > > alignments, DKIM check, DKIM alignment. What I'm lacking is the > > organization domain's DMARC record. Putting in an DMARC record in > > the organization domain only helps part of the problem. I can't get > > any of the aggregate reports without getting all of the aggregate > > reports. > > If you advertise a DMARC policy to the 'Net, then the 'Net will see > it, and sites implementing DMARC aggregate reporting will send you > those reports. > Previously you had indicated that you couldn't publish a DMARC record > for the organizational domain... If you are now able to do that, why > can't you ignore the aggregate reports from the sites you aren't > interested in? In the worst case, create a simple filter using the > scripting language or MUA of your choice. the challenges if there are other third-party vendors delivering messages as well, how does one redistribute them appropriately. It would've been much simpler if they had allowed the DMARC record to be tied to the selector key. > It might be helpful to try to state your current problem as clearly > as possible. For example: fair enough. I'm trying to improve my understanding of the third-party sender problem when, for reasons technical and political, you want to maintain a distance between organizational domain and the working domain. - From addresses should look like: [email protected] . - Domain key has its own selector so I can use a separate key from all the other third-party senders . - I don't have consistent access to the organization domain (Some will let me, some won't) . - Many of the organization domains do not have DMARC implemented. ( I'm trying to fix that). - How does one handle it when the organizational domain needs multiple different DMARC policies i.e. one per sender. - I want to deliver all of the aggregate reports that result of my messages to mailboxes under my control. - Filtering email, except at a very gross level, is not available. If I follow the common model, I can stick my own key into the originating domain with its own selector. All of the aggregate reports for traffic I generate are mixed up with all the traffic that the originating domain generates. separating them out is well-nigh impossible without processing every single record and re-mailing it to vendor specific mailboxes. Today with so many clients using hosted services such as Google or Microsoft for email, filtering is not easy. If I isolate what I do into its own subdomain, then I have the problem of how to handle reply mail, in this case, back to the schedulers. The customer would not accept another set of email accounts because they already have email accounts that work and re-mailing responses from workers in the field seems like a silly solution. I tried using the reply-to model like a mailing list but the message headers didn't look right to most users and I got a lot of complaints asking me if this was a phishing attack. I wasn't surprised to hear this complaints because ordinary folks, using email as a tool are sensitive to appearance changes. The proof of this is when I ran tests with ordinary email versus mailing list style email headers, the response rates for the messages that looked like they were from a mailing list was one 10th of the messages that look like ordinary email. As it stands now, I'll try to convince customers to put in a DMARC record in the organization domain and pray that nothing goes wrong with the other suppliers. I'm probably going to have to ignore the aggregate reports because that are the result of activity from my service will be overwhelmed by the reports from other service providers. --- eric
_______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
