[dmarc-discuss] Slightly OT: New ARC logo to celebrate RFC8617

[Steven M Jones via dmarc-discuss]

You may have noticed the logo with the seal mascot that the ARC project
has been using for years.

To celebrate the ARC protocol being published as RFC8617, we updated the
logo - and have now published it on the arc-spec.org website. See both
logos here: http://arc-spec.org/?p=185

If you're at the M3AAWG meeting in San Francisco, I have some small
stickers to hand out.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] Know anyone working on ARC at Microsoft ?

[Steven M Jones via dmarc-discuss]

On 01/02/2020 09:53, Seth Blank via dmarc-discuss wrote:


Currently, AFAIK Microsoft's ARC implementation is internal only and 
is not yet expected to interoperate with external systems.



I'm happy to provide them with a New Year's reminder that people are 
watching. :-)


But yes, it's also worth noting that the item posted to the "Microsoft 
365 Roadmap" at the end of October only discussed the use of ARC when 
receiving messages for mailboxes hosted by Microsoft. It didn't address 
any use of ARC in messages received from Microsoft by other entities.


--S.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] Know anyone working on ARC at Microsoft ?

[Steven M Jones via dmarc-discuss]

On 01/01/2020 17:51, John Levine via dmarc-discuss wrote:

I that I am getting a fair number of messages from outlook.com servers
with ARC headers, which is good.

...

Any idea who we might talk to in order to figure out what's going on?


Yes, I can contact somebody at Microsoft who's in the right area - I'm 
not certain they'll be available before next week, though. I'll send up 
a flare and we'll see what happens... If I need samples or more details, 
I will most likely make contact off-list.


--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] Re-verifying external report destinations

[Steven M Jones via dmarc-discuss]

This has been a bit of a problem, as non-verification of “ruf” addresses 
combined with people copying sample DMARC records in their deployments led to 
what I have to assume are violations of GDPR and several other privacy regimes.

I would hope people would see reporting address verification as an important 
mitigation of concerns about “ruf” reporting. My fear is that instead it makes 
the lawyers say “no” a few microseconds faster...

—Steve. 

Sent from my iPhone (if I’m lucky)



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] DMARC RUF

[Steven M Jones via dmarc-discuss]

On 05/11/2019 08:34, John Levine via dmarc-discuss wrote:

In article  
you write:

Can someone tell me why the mail providers have stopped sending forensic
emails?

They haven't stopped because they never started.


I received failure/forensic reports ("ruf=") from NetEase and Hotmail 
for several years, for at least one small domain I operate, and I appear 
to have received such reports from NetEase as recently as 3Q2018. None 
from Hotmail since late 2017 though, and that was expected when 
Microsoft merged that service into other infrastructure.


Was that a special exception, and I'm the only one who ever got those? 
That was not my understanding of the situation at the time...




Forensic messages have big privacy problems because they send a
message, or at least part of it, to someone who may or may not have
any connection to the actual sender.


Yes, this is the reason usually given - and that was before GDPR went 
into effect.




No large mail system has ever sent them.


Just to quibble: NetEase was and is large, and Hotmail was pretty large 
before it was merged into other Microsoft infrastructure.



--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] dmarc Newbie

[Steven M Jones via dmarc-discuss]

On 5/9/19 10:55 AM, Wojtowicz, Andrew via dmarc-discuss wrote:
>
> I’m a newbie with dmarc.  I’ve been playing around with some
> generators and I thought I had it setup right but found out today one
> of my staff members sent out an notification email, that uses
> blackboard, and it didn’t go to all gmail and yahoo users. 
>

I'm guessing Blackboard is an application or service that may sometimes
send email on the user's behalf, and that they are using addresses in
your domain when sending from their servers. That's a known problem, you
might want to check the FAQ
(https://dmarc.org/wiki/FAQ#My_organization_uses_third-parties_senders.2C_how_can_I_get_them_DMARC_compliant.3F).

Did you have your DMARC policy set to "p=reject" at first? One should
generally start with "p=none" and check the reports to see who's sending
email that uses your domain in the From: address. It looks like you have
a "p=none" policy now - if we're talking about our Tenafly domain...

It looks like you may be working with Agari, based on that DMARC record.
But if you're still looking for a company to help you navigate the
implementation process, you could take a look at the services listed on
the DMARC.org website: https://dmarc.org/resources/products-and-services/

--S.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] DMARC is not working

[Steven M Jones via dmarc-discuss]

On 11/23/2018 00:01, Dpto Ciberseguridad via dmarc-discuss wrote:

Hello,

Last year we configured DMARC registry for another company with 
something like this


"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.


"ruc" is not a valid tag in a DMARC policy record. Did you mean "rua" ?


Looking for information in Internet, some DMARC testers did not pass 
ruc syntaxis so we only changed ruc to ruf; but the problem is still 
present.


"rua" and "ruf" only determine where reports are sent, provided the 
receiver sends the corresponding type of report. They do not normally 
have anything to do with enforcement, unless perhaps a receiver decides 
that the record is invalid and therefore ignores it completely. But you 
say receivers were rejecting invalid messages previously...


If you weren't receiving aggregate reports ("rua"), how certain are you 
that the invalid messages were rejected due to your DMARC policy?


--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] ARC WGLC - last comments on August 3rd (list test)

[Steven M Jones via dmarc-discuss]

A list member requested confirmation that this list was still working.

But I will take the opportunity to point out to any interested members 
who don't follow the IETF DMARC Working Group, that this group had the 
"Last Call" for comments about the ARC protocol specification, then at 
version -16, from July 17th through August 3rd.


In general, if WGLC achieves consensus that a document is ready to 
proceed, it proceeds to publication via the RFC Editor. (I believe 
there's another review step with the relevant Area Directors, but I've 
misplaced my IETF procedures decoder ring...)


There's a little follow-up discussion about section 5.1.2 that I believe 
has to be resolved before that step is taken. If that point proves too 
divisive, the WG might have to come to consensus on changes and go 
through WGLC again.


--S.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] Dmarctest

[Steven M Jones via dmarc-discuss]

On 06/26/2018 03:36, Keith Duthie via dmarc-discuss wrote:



Who runs the dmarctest.org  message reflector? 
It seems to have been broken for at least the last couple of days - my 
messages have been being rejected with a "451 4.1.8 Domain of sender 
address ke...@no.net.nz  does not resolve" 
error message.


Sorry about that - working now.
--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

On 05/04/2018 12:37 PM, Scott Kitterman via dmarc-discuss wrote:

I participate in a lot of mailing lists many of which that have a large number
of subscribers.  ...

Shouldn't it be possible to de-duplicate these based on message ID before
sending aggregate reports back?  Can/should this be added to DMARC the next
time the specification is updated?


There may be interesting anti-abuse cases that justify storing this kind 
of information in a readily accessible form for e.g. de-duplication, 
versus a static log file.


But even if receivers / mailbox providers are already doing that, 
where's their incentive for the reporting change you describe? What 
would be the resulting improvement in the quality of mailstreams sent 
using a given domain? The reduction in customer support, or increase in 
customer satisfaction, of the kind they purportedly see when it's easier 
to detect fraudulent messages?


I can understand how the reporting change you suggest *might* be useful 
to the individual sender, where the sender and the domain operator total 
1 or 2. Can you help us understand what's in it for the other parties 
involved? And how does it help in the more typical case where there are 
between dozens and thousands of users of the domain?


--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] Remote Participation for IETF DMARC WG meeting on Thursday, 7/20

[Steven M Jones via dmarc-discuss]

Here are the links for the DMARC Working Group session at the IETF 99
meeting in Prague. For reference, noon here is 06:00 (AM) in New York.

The DMARC session is at 09:30 CET, or 03:30 EDT, or 00:30 PDT, and is
scheduled to run up to one hour. It will be followed by the DKIM Crypto
Update WG, after a 10 minute break, for those interested and available.
The online IETF schedule still shows DCRUP starting at 11, but Barry
Leiba communicated the change to the IETF DMARC mailing list on 7/16.


DMARC WG: at 09:30 CET, or 03:30 EDT, or 00:30 PDT

Agenda:  
https://www.ietf.org/proceedings/99/agenda/agenda-99-dmarc-01.txt
Materials (PDF):   
https://datatracker.ietf.org/meeting/99/agenda/dmarc-drafts.pdf
Materials(tar):  
https://datatracker.ietf.org/meeting/99/agenda/dmarc-drafts.tgz
Jabber link:   xmpp:dm...@jabber.ietf.org?join
Meetecho video:   http://www.meetecho.com/ietf99/dmarc/
Audio stream:  http://ietf99streaming.dnsalias.net/ietf/ietf992.m3u


DCRUP WG:at 10:40 CET, or 04:40 EDT, or 01:40 PDT

Agenda:  
https://www.ietf.org/proceedings/99/agenda/agenda-99-dcrup-00.txt
Materials (PDF):   
https://datatracker.ietf.org/meeting/99/agenda/dcrup-drafts.pdf
Materials(tar):  
https://datatracker.ietf.org/meeting/99/agenda/dcrup-drafts.tgz
Jabber link:   xmpp:dc...@jabber.ietf.org?join
Meetecho video:   http://www.meetecho.com/ietf99/dcrup/
Audio stream:  http://ietf99streaming.dnsalias.net/ietf/ietf992.m3u


Share and Enjoy!
--Steve.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

Hi Jonathan,

> After further research, I think this is because failure reports aren't
> actually generated for p=none, i.e., they're only generated for p=reject.

There is no such linkage. I see failure reports for domains that publish
"p=none" all the time.

However (unfortunately) I don't get them from from all DMARC-enabled
receivers. Just as DMARC senders choose whether to deploy SPF, DKIM, or
both, receivers decide individually whether or not to send failure
reports. When you find somebody at a large mailbox provider who doesn't
send them, who's willing and/or able to talk about it, the driver is
usually liability concerns around whether or not you can send failure
reports without running afoul of data/personal privacy laws in some or
many jurisdictions where they operate.

Speaking only for the small domains I operate, Hotmail appears to be the
larges US-based mailbox provider sending failure reports - I received
one from them just last week. Internationally, I'd say it's NetEase of
China (notably 126.com and 163.com). However many small domain operators
using the OpenDMARC milter seem to enable failure reports.


> Unfortunately, the information we're getting from the aggregate
> reports that various domains are sending us is not always sufficient
> for us to figure out DMARC failures.

Are you seeing failures for messages sent by servers you operate or
authorize? Or is it more a question of identifying the various sources
you don't already know about and figuring out why messages using your
domain(s) are coming from them?

I'm sure you can deal with the aggregate reports from a parsing
perspective, but perhaps you could use some assistance with the
interpretation of the data? There are a number of  services listed on
the resources pages at DMARC.org (link below). Most often I hear about
folks starting with the free tier that dmarcian.com offers, but anybody
on that list could provide assistance.

>From comments in the reports, and from databases the report processors
maintain, you can often get a clearer picture of traffic that's going
through known forwarders or mailing list operators. (Such traffic might
be expected to have authentication failures for assorted reasons you're
probably already aware of.)

--Steve.

Products and Services: https://dmarc.org/resources/products-and-services/

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

On 01/27/2017 04:23 AM, Jim Popovitch via dmarc-discuss wrote:
>
> I can appreciate that folks do that, and that's awesome.   For me and
> my systems that just seems like unnecessary overkill.

Ultimately that's a decision each domain owner/operator has to make for
themselves.

But I would hope that, like you, they've first gone through deployment
of DKIM and SPF and checked the DMARC reporting to see what's going on.
And even if they don't see many fraudulent messages and/or aren't overly
concerned about it, I would recommend setting something up to monitor
the reports and summarize or set an alert driven by changes/increases in
authentication failures. This way if something goes wrong in a legit
sending setup (ESP, etc), or if a bad actor does start abusing their
domain, they'll find out about it in short order.

--Steve.



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] RUF reports

[Steven M Jones via dmarc-discuss]

On 01/05/2017 17:32, Jim Popovitch via dmarc-discuss wrote:
> I've been trying, albeit slowly, to determine why I haven't seen any
> RUF reports since Sept 2016.
>
> Shouldn't this RUA report also produce a corresponding RUF?

Are you DKIM signing these messages? Because I notice the reason given
for the local policy override includes "Ignore dkim/spf DNS query" and
there's no DKIM section in  - making me wonder if they had
a problem accessing your selector, and that the comment above really
means "our DNS query for a DKIM record received no response."

Plausible? I don't see enough information to rule it out...

--S.


-- 
Steven M Jones
CRASH Computing

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] DMARC forensic reporting options

[Steven M Jones via dmarc-discuss]

On 12/23/2016 08:10, John Comfort via dmarc-discuss wrote:
> Maybe it is time to rethink this, or open a more official dialogue.  I
> understand folks don't want to send reports.  I understand the privacy
> issue.  However, without these reports, or at least *some* information
> sent regarding the unaligned emails, we are at an impasse to migrating
> to a 'reject'.  For certain environments (e.g. financial), we cannot
> reject *any* legitimate emails and therefore require verification of
> all emails that are rejected.

It may be difficult, but it is not impossible.  I say this as somebody
who, at a financial, tried to get a DMARC "blocking" policy in place on
a sub-domain seeing x00,000's of fraudulent messages each day. But
because a few hundred legitimate messages would also have been blocked,
we couldn't proceed. Our business side partner couldn't accept the risk
of blocking those 00's of messages, but also didn't have the
authority/resources to investigate and address the root cause. Each case
is different, but often you need to check and make sure you've got
sufficient "clout" on the business side.

In 2016 Bank of America managed to get to "quarantine" after four years
of effort. Believe me, they didn't want to block legitimate messages,
but they understood the risk of allowing the fraudulent messages to
continue. And eventually, they sorted it out. Wells Fargo too. Discover
Card, too.

It may take time and effort but even stodgy, traditional financials can
get there.


> I would be perfectly fine with limiting the information if people are
> really that paranoid about header information.  For example:  date,
> receiving server information, originating smtp server sender, and
> subject line.  This would be a good start at least.

I believe Receivers already understand that they can subset the
information they share via failure reports, and do so.

If you look at the failure reports from NetEase, you only get certain
5322 headers - Message-ID, Received, To/From, dates and times,
authentication results, etc. Certainly there are times you want more,
but this is helpful and useful information.


--S.



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

On 12/12/2016 02:35, Petr Novák via dmarc-discuss wrote:
>
> I actually used "p=reject sp=none" on one domain for a while. The
> problem was I managed mail server for the main domain but I didnt have
> access to any of the subdomains. It took some time to find out which
> subdomains are used for sending emails and create their own p=none
> DMARC policies.

There are situations like this in real-world deployments, especially at
larger organizations. One always hopes it is a short-term need.


> in this specific case I was just testing our mail server with all
> possible DMARC settings and I always tried the same test case on gmail
> to see how they handle that.

Somebody on the team had run through the combinations during and after
the first big DMARC interop event some years back. It would be nice to
run through checks like that again, but I'm not really in a position to
do so right now.

--Steve.



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] DMARC reporting service for receivers (commercial)

[Steven M Jones via dmarc-discuss]

ReturnPath (a sponsor of DMARC.org) now has a service where they will
handle DMARC reporting functions for a mail receiver or mailbox
provider. They currently take a feed of authentication log data from a
Cloudmark instance, but other sources can be adapted.

The cloud-based system will not only compile and send DMARC reports to
the domain owners, it also provides a convenient dashboard so the mail
receiver can quickly see things like how many messages they've been able
to quarantine or block, the mix of policies sending domains publish, etc.

This is not an endorsement; it is offered as potentially useful
information for those wishing to add DMARC reporting to their
infrastructure. For more information please contact Greg Kimball at
ReturnPath (greg.kimb...@re...th.com).

--Steve.



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

On 11/14/2016 10:33, Terry Zink via dmarc-discuss wrote:
> In my experience, domains sit on p=none for a long time, and in the meantime 
> a lot of other senders send email as them - most legitimate but some 
> malicious. This setting is designed to catch the malicious.

Maybe I need to make that a more central focus in 2017...


> So, either (a) you rely upon DMARC proper but have to add additional layers 
> to catch the rest of the phish, or (b) you go hyper-aggressive and then add 
> layers (overrides) to allow the legitimate email.
>
> Both options are not great, although having to set up override after override 
> after override is management pain as it is prone to false positives.

If the option were there to make those overrides I'd be more supportive,
but it didn't sound like that was the case with this particular
product/service. If somebody with access could clarify, I'd appreciate it.


> I used to say that I would probably treat your own domain(s) as 
> p=quarantine/reject but respect the setting for domains you don't own. But in 
> the past month or two, I've seen plenty of "other-domain" spoofing, that is, 
> spammers/phishers spoofing domains with weak authentication policies and 
> getting in that way.

Well, DMARC addresses one particular vector - we still need to find more
effective ways to address cousin domains, display name abuse, etc. Some
products/services have moved in that direction, and there are some
efforts trying to determine if there's an approach amenable to being
standardized.

--S.



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

On 11/14/2016 06:49, Petr Novák via dmarc-discuss wrote:
>
> 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
> domains that have policy p=none. After contacting their support I was
> told that this implementation is by desing and they dont have any
> plans to change it.

I added them to the list when I heard they had implemented DMARC
support. Companies don't send me their products, and I don't perform
evaluations. So I'm grateful for this information about how they've
implemented the product.

I'll have to add a note to the listing.

I consider what you described to be a deeply flawed implementation.
Being able to selectively override the sending domain's policy is one
thing, treating them all as p=reject is another thing entirely.

Thanks,
--Steve.



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] Report sizes and transports, was Re: Beware of the size limit in DMARC URIs

[Steven M Jones via dmarc-discuss]

On 10/13/16 10:53, John Levine wrote:
> It's a poor idea to put stuff into a spec if nobody's planning to
> implement it, because that generally results in a spec that doesn't
> work when someone tries later.

I take your point, but I understood anecdotally that the large end of
the range of reports were getting big enough to cause concern to those
handling them daily. I guess I'll have to wait for somebody with direct
knowledge to speak up - it isn't something I'm seeing with my own
domains/reports.

So first up, backup the anecdotal suggestion that there's a need based
on the observed growth of report sizes. Second, an expression of
willingness to implement.


> The original http language was
> hopelessly broken, so I offered something different that I think
> would have worked, but nobody ever tested.
>
> So if DMARC reports are getting too big, I'd be happy to resuscitate
> the http language in a short draft to update RFC 7489, but only if
> there are a few people who plan to implement each side of it so we can
> be sure that it works.

Sure, I didn't mean to suggest we'd reinsert something without
discussion - let alone something that hadn't been tested/vetted
properly. That's real, substantive work for the WG.

--S.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

On 10/12/16 03:17, Steven M Jones via dmarc-discuss wrote:
> On 10/12/16 02:00, Roland Turner via dmarc-discuss wrote:
>>
>> Consider https://www.ietf.org/mailman/listinfo/dmarc
>> <https://www.ietf.org/mailman/listinfo/dmarc>
>>
>
> +1.

Let me clarify a bit -- the dmarc-discuss list is very much an
appropriate forum for the kind of operational topic Juri raised.
Implementation issues, operational questions/issues, etc -- all good for
this list.

But for things that appear to be more than that, the IETF WG is a better
place to take them. And I think that if you consider current handling of
size limits, planning for growing report sizes in the near future, and
an additional report transport - all those together - it seems an
appropriate bundle to take to the WG.

--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] ARC Interoperability testing this Friday, 9/23

[Steven M Jones via dmarc-discuss]

Have an implementation of the ARC protocol? We will be holding an
interoperability testing event this Friday, 9/23, between 9 and 11:30AM
Pacific (Noon and 2:30PM Eastern). Several different implementations
will be available for testing with each other, and remote participation
is the norm (versus traveling).

This is an event for those implementing ARC functionality in a product
or service, free or commercial. If you have an implementation, or are
actively working on one, and are not already on our interoperability
mailing list, please contact me directly via email.

Thanks,
--Steve.

-- 
Steven M Jones
DMARC.org

e: s...@dmarc.org, s...@crash.com



___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] ARC adoption

[Steven M Jones via dmarc-discuss]

+ dm...@ietf.org because Roland's responses should be 
considered/captured there too.

Additional comment bottom-posted.


 On 6/29/16 12:09 AM, Roland Turner via dmarc-discuss wrote:

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. ARC seeks to construct a situation in which forwarders and receivers will 
each gain incremental benefit if they choose to implement; it neither requires 
nor assumes implementation by any particular participant.


But the list operators fail over the last years to do so. Why should I expect 
they will do now?

List operators typically cite two compelling reasons for not making changes to 
support pre-ARC schemes:

1) the assumption that they're being asked to expend resources to solve someone 
else's problems; and
2) even if resource constraints are ignored, each of the proposed changes 
imposes harmful dilemmas (each option, including do nothing, is harmful).

ARC directly addresses (2). Unlike the measures for interoperating with earlier 
schemes, adding an ARC-* header set does not in any way impede or alter the 
traditional operation of mailing lists. Consequently: if list operators 
perceive benefit in implementing ARC, then they're free to do so without having 
to incur additional operational problems, in particular without changing user 
experience.

(1) is not a big problem; for a list operator who doesn't have a problem that 
ARC addresses there is no reason for them to implement ARC, and it doesn't 
matter to anyone else if they don't.

- Roland


Well put, Roland. I was so concerned with addressing the frequently 
asked question of "why will people upgrade" that I overlooked other 
considerations in my earlier response.


--S.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] ARC adoption

[Steven M Jones via dmarc-discuss]

+ dm...@ietf.org list to capture for ARC discussion/archive

On 06/28/2016 09:12, A. Schulze via dmarc-discuss wrote:
> 
> Kurt just mention adoption in his last message.
> Adoption is a good point, I've two questions:
> 
> 1)
> are there implementation available as open source?

There is an OpenARC milter under development - it currently runs and
signs messages. A few bugs turned up at the last interop have been
fixed, but I have to see if the signatures/seals now verify.

There are two modified versions of the dkimpy library that perform ARC
operations. If one - as planned - will be the basis for an
implementation in a mailing list manager, it will become publicly
available. The author of the other implementation is on these lists, but
it's up to them whether or not to discuss it further publicly.

I was told of another effort that might result in a Perl module/library
for performing ARC operations, but it had stalled and I haven't had an
update on that for a while.

> I'm aware Google has some code.

There is one other large mailbox provider who has a functioning
implementation, and these two implementations are working when tested
against each other, and with one of the dkimpy libraries.


> 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?
> But the list operators fail over the last years to do so. Why should I
> expect they will do now?
> p=reject on google/gmail/googlemail may generate the required pressure
> but that doesn't sound like the best way to achieve adoption.

Section 2 of the Usage doc describes how ARC works. The phrase "If the
mailing list..." just indicates what would happen differently after ARC
functionality was added - it isn't addressing the question of when, how,
or why an MLM operator would update their software.

Some kind of change will be required for virtually any application -
MLM, forwarding service, etc - to implement ARC. The only scenario I can
see where the application operator themselves didn't make a change, is
if a different group deployed an ARC signing capability to a downstream
MTA still within the ADMD that the application operates in. But somebody
is still making a change...

Your question about motivation is a good one. I don't think there's any
way to coerce everybody to implement ARC - or anything else, for that
matter. If there were, the Internet would be a very different place.

However I think we will see a standard "long tail" curve of adoption.
Once the protocol is fully tested and implementations released, there
will be a surge of early adopters - people who do it because they always
look for better ways to operate, ways to make sure their mail - or their
customers' mail - gets delivered cleanly everywhere, etc.

Another increment will raise the level slowly as packages like Mailman
and Sympa are updated (assuming they will be) and a natural upgrade
cycle occurs. This is a slow process, and not everybody will do so.

Will there be spikes as more senders or mailbox providers publish DMARC
p=reject policies? Maybe - if the provider is large enough, then
"definitely." But there are only so many of those that would make a
measurable impact, and even then it won't be universal.

I think smaller application operators - MLMs, forwarding services, etc -
may feel pressure to adopt ARC simply because they are below the volume
thresholds where medium to large mailbox providers make exceptions for
them, or even identify them as such. In some percentage of cases where
their messages are misidentified, or have some tricky content, they'll
have issues and in some cases turn to ARC. FOSS options, and MLM
support, will be critical for these cases.

Will they all do so? Of course not. Just as I'm sure somebody out there
is still running sendmail 5.65 on SunOS 4.x, somebody out there will
continue to run some version of Majordomo and never change it.

Anybody have data on the adoption rate of the RFC2369 List-*: headers? I
doubt those jumped from 0 to 100 overnight, but they're very wide-spread
now. And I suspect there would be an interesting comparison to the
uptake of ARC over time.

--Steve.

Steve Jones
DMARC.org

e: s...@dmarc.org, s...@crash.com


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] Overview Slides on ARC Available Online

[Steven M Jones via dmarc-discuss]

An overview of the ARC protocol has been presented to a couple
audiences, and after a few updates is now available online. It's
released under the Creative Commons Attribution-ShareAlike license, so
you're free to use it, or parts of it, for most purposes. I hope it
makes ARC and it's mechanisms a little clearer, so feel free to read it
and share it with others.

There are a couple ways to get it:

Announcement on DMARC.org:
https://dmarc.org/2016/05/new-presentation-describing-arc-protocol-available/

Direct download:
https://dmarc.org/presentations/ARC-Overview-2016Q2-v03.pdf

SlideShare:
http://www.slideshare.net/SteveJones250/overview-of-the-arc-protocol-for-email


Share and Enjoy,
--Steve.

Steven M Jones
DMARC.org

e: s...@dmarc.org, s...@crash.com

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] Deferring virtual ARC interop by a week: now April 8th

[Steven M Jones via dmarc-discuss]

Given the changes in signing mechanics being discussed on the
arc-discuss list recently, I'm moving the next round of ARC
interoperability tests to Friday, April 8th.

I think the discussion is valuable, and agree it would be best to give a
little more time so any necessary changes to working code can be made
before testing against other implementations.

Thanks, and again if you're working on an implementation please let me
know off-list.

-- 
Steven M Jones
DMARC.org

e: s...@dmarc.org, s...@crash.com

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] Semi-OT: Next ARC Interop Testing: April 1st

[Steven M Jones via dmarc-discuss]

We'll be holding another interoperability & testing session for ARC on
Friday, April 1st. This will be a "virtual" session coordinated via
online conference, from 10AM Pacific / 1PM Eastern through 1PM Pacific /
4PM Eastern.

This is intended for ARC implementers who have code to test, doesn't
have to be a complete or finished product. And if you're actively
working on a product/service/library that isn't yet ready, you can
observe if that's of interest.

If you'd like to participate please contact me off-list and I'll add you
to the interop mailing list.

There will be another virtual interop session held on Friday, May 13th.
So if you're just starting your implementation, that may serve as a
useful deadline or integration/testing opportunity.

Let me know,
--Steve.

-- 
Steven M Jones
DMARC.org

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] Two ARC implementations tested at interoperability event

[Steven M Jones via dmarc-discuss]

On February 19th AOL and Google successfully tested their implementations 
of ARC at the interoperability event held on February 19th. More details 
here:


https://dmarc.org/2016/03/two-arc-implementations-tested-at-interoperability-event/

Many thanks to LinkedIn for hosting the event.


I'm looking forward to more implementations and more testing by mid-year.

--Steve.

Steve Jones
DMARC.org
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] Email storage

[Steven M Jones via dmarc-discuss]

On 02/16/2016 08:31, jim c via dmarc-discuss wrote:
>
>
> The issue that we've noticed is that the forensic data is the entirety
> of the email.  It isn't just header info, but contains the entire
> message text, along with attachments.

Not every Receiver generates failure reports (what "ruf=" triggers), and
Receivers that do generate failure reports may each include different
items from the original message. You will observe a range of content,
from the bare minimum of message headers to, as you observed, the entire
intact message. It all depends on the Receivers internal policies.

No doubt you have to address the latter case, and I'll let others speak
to that. But I did want to point out that Senders won't automatically
get entire messages in every failure report, from every Receiver.

--Steve.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] ARC interoperability testing day: Friday, Feb 19th

[Steven M Jones via dmarc-discuss]

I'd like to share a reminder with this list about an upcoming. related
event. Follow-ups may be more appropriate on the arc-discuss list. See
http://lists.dmarc.org/mailman/listinfo/arc-discuss for details of that
list; see http://arc-spec.org for more information on ARC.


The interoperability testing event mentioned when the Authenticated
Received Chain (ARC) was announced back in October has been scheduled
for Friday, February 19th, 2016 in San Francisco - which is the same
week as the M3AAWG meeting there. We've got a line on some lovely nearby
office space we can borrow for Friday and potentially Saturday, if we
needed a second day for any reason.

This is a request for anybody implementing ARC to express interest in
participating in the interoperability testing event. You can think of
this as a "bake off" where you send/receive messages with other
participants to see that various ARC implementations are working
correctly, and working with each other. We may develop a series of cases
to test before or during the event. We expect to be able to accommodate
virtual participation as well as in-person.

You can reply to me privately if you don't wish to advertise your
participation publicly. Feel free to share this message with people not
on this list whom you think might be interested in participating (if
they are involved in implementing ARC).

What do I mean by implementing ARC?

- Writing code (library, milter, MTA) that implements ARC functionality
  (signing, verifying, etc)
- Building a free/commercial product that includes ARC functionality,
  whether you wrote the ARC code or not
- Deploying ARC functionality in an intermediary (e.g. MLM) or receiver
  (e.g. mailbox provider)

Feel free to ask any questions you may have about this event here or on
the arc-discuss list, or again feel free to contact me directly if you'd
prefer.

Thanks for your interest,
 --Steve.
___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

On 01/23/2016 05:08, Ben Greenfield via dmarc-discuss wrote:
> My name is Ben Greenfield and I have been running a couple of smalltime mail 
> servers (fewer then 200 messages a day) not accounting for an occasional 
> blast from a 1,500 person listserv.

Welcome Ben, and hopefully you got a response off-list (or that I missed
it).


> Should one use one DKIM key for each domain or a single domain tie it to the 
> ip addresses and the DNS text records sort out whether the domain is 
> associated with the sending ip’s DKIM key.

I may just not be following you, but DKIM doesn't mandate or require any
association with IP addresses. And in fact that's a good thing, because
it allows DKIM-signed messages to be forwarded and still be verifiable
(provided the message isn't altered).

DKIM signatures include information about which domain produced/attached
the signature, and how to retrieve the public key via DNS in order to
verify that signature. If you look at the DKIM-Signature: header in a
message, this information is in the selector ("s=...") and signing
domain (in full, the Signing Domain IDentifier, or SDID - the "d=...")
fields.

You might choose to only deploy a given signing key on a given host,
thereby effectively creating that association. But DKIM allows you to
use the same signing key on multiple hosts, and many people do this. You
can deploy multiple keys under different selectors for one domain to one
or more hosts. Or you might deploy keys for several different
(sub-)domains to one or several hosts. There's a lot of flexibility if
you need it.

Check the DKIM RFC: https://tools.ietf.org/html/rfc6376
The DKIM Service Overview: https://tools.ietf.org/html/rfc5585

Or look for other resources on the DKIM.org site: http://dkim.org/


> My question regarding mailman is that I see discussion of problems with 
> listserv’s but so far I haven’t seen any that seem to apply to my situation.

The problems associated with mailing lists, or more generally "indirect
mailflows," come when a message submitted to the list is forwarded out
to the list recipients such that SPF no longer passes, and if present a
DKIM signature no longer verifies because the message was altered in
some way.

So if the original sending domain has published a restrictive DMARC
policy (not "p=none"), the message would fail the DMARC check and would
likely be quarantined or rejected - if the receiver didn't know the
message had come through a list, and chose to allow an exception for
that list/host.


> We have an internal staff mailing list and a public mailing list. 
> Should I look in the Maillman docs for the right configuration? 
> Is their a consensus on what to do with listservs?

You might want to check the MailMan site, docs, or discussion forums.

But MailMan includes an option that effectively works around the
problems with strict DMARC policies and indirect flows by altering the
RFC5322.From: header of the outgoing message to use the mailing list's
address. Note that not everybody likes this approach, but it does work.

If you check the "General Options" screen for the list admin interface,
you'll see an option described as:

"Replace the From: header address with the list's posting address to
mitigate issues stemming from the original From: domain's DMARC or
similar policies."

I've used the "Munge From" setting in cases where list participants'
strict DMARC policies (or those of their mailbox provider) were or would
cause issues.


One approach that would avoid this kind of workaround was announced in
October. The Authenticated Received Chain, or ARC, would allow mailing
lists and other intermediaries to include the email authentication
results they observed when a message arrived, and some signatures of
same, that the ultimate recipient might then choose to use if/when
regular DKIM/SPF/DMARC checks fail. For more info on that head over to
http://arc-spec.org.

Hope that helps,
--Steve.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

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

[Steven M Jones via dmarc-discuss]

On 02/01/2016 18:53, Steven M Jones via dmarc-discuss wrote:
>
>> My question regarding mailman is that I see discussion of problems with 
>> listserv’s but so far I haven’t seen any that seem to apply to my situation.
> The problems associated with mailing lists, or more generally "indirect
> mailflows," ...

Oops - I meant to include a reference to the IETF DMARC Working Group's
draft that documents issues with (certain DMARC policies and) indirect
mailflows:

https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/

--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

[dmarc-discuss] arc-discuss list, was Re: A bit quiet?

[Steven M Jones via dmarc-discuss]

On 10/23/2015 03:52 AM, Andrew Beverley via dmarc-discuss wrote:
As Rolf has already asked: is there anywhere else where ARC is being 
discussed? I am surprised that this is the first I have seen it 
mentioned on this email list. Andy


There is an arc-discuss list with (at the moment) 37 subscribers. The 
description is:


   This list is for discussion of the Authenticated Received Chain
   protocol, or ARC. Topics may include:

   - implementation
   - operations
   - presentation (end-user)
   - interoperability

   It is at this stage intended for programmers, service providers,
   network operators, and so on.

   It is not a place for consumers or end-users to turn for help -
   please contact your mailbox provider's help desk in such cases. They
   are in the best position to be able to help you.


Link: http://lists.dmarc.org/mailman/listinfo/arc-discuss


There have been several discussions around the most effective way to get 
some code published for intermediaries. It's a fine topic for the 
arc-discuss list though... ;)


--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] am not getting any rua reports for a domain

[Steven M Jones via dmarc-discuss]

On 07/15/2015 12:18, Eric S Johansson via dmarc-discuss wrote:
I'm acting as a third party mailer for one of my customers.  ... but 
from my customer's domain, I get nothing even though the setup looks 
identical.


So your issue is that you aren't receiving any aggregate reports for the 
domain mumble.com at the mailbox sbmumblecom_...@my.mailservice.com 
right?



all mail messages are signed from sb.mumble.com and sent from 
my.mailservice.com and google says all is well for dkim/spf. messages 
are from u...@mumble.com.


Do you mean that the RFC5322.From domain for the message traffic in 
question is mumble.com, but all your DMARC and DKIM records are using 
sb.mumble.com -- as quoted below:



here are the records via dig with domain redacted (and hopefully not 
fat fingered)


_dmarc.sb.mumble.com. 2947 INTXTv=DMARC1\; 
p=none\;rua=mailto:sbmumblecom_...@my.mailservice.com\; fo=0\; 
adkim=r\; aspf=r\;sp=none


the authorizing record is:

mumble.com._report._dmarc.my.mailservice.com.185 IN TXT v=DMARC1


any suggestions on what I'm missing?


Message traffic using an RFC5322.From of sb.mumble.com would use a 
DMARC record published for the Organizational Domain mumble.com, but 
the reverse doesn't work.


I think you want to either change the RFC5322.From domain in the 
messages being sent to sb.mumble.com, or publish a DMARC record for 
mumble.com.


Hopefully I haven't missed something obvious...

--Steve.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] Mail delivery failed: returning message to sender

[Steven M Jones via dmarc-discuss]

On 07/09/2015 08:20, Sebastian Schweizer via dmarc-discuss wrote:

Am I the only one who gets bounces for reports to dmarc.org's reporting
address repo...@dmarc.org?


Bouncing was caused by some routine changes to mail aliases. Appears to 
have been corrected now.


Thanks for the heads-up.

--Steve.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] dmarc record added but no reports received

[Steven M Jones via dmarc-discuss]

On 01/16/2015 01:17 AM, Constantino Antunes via dmarc-discuss wrote:
 Hi,

 I would like to thank everyone for the help. A report arrived today.
 It is small - only one source ip address - but I suppose more should
 arrive in the next days.

If you want to receive a report quickly, send a message to
autore...@dmarctest.org from an address in your DMARC-enabled domain.
You'll receive a reply within a few minutes, and the site sends DMARC
reports (to the rua address(es)) every five minutes, so you should get
one without having to wait very long.

You can also ask for help in the #dmarc channel on the Freenode IRC network.

--S.


___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] Not receiving DMARC reports

[Steven M Jones via dmarc-discuss]

Welcome, Andrea.

On 09/29/2014 09:58 AM, Andrea Castelli via dmarc-discuss wrote:
 tdraegen you might try chopping off the trailing !10m from your RUA
 and RUF
 tdraegen fields.  Some receivers don't do a very good job parsing those.

 The rest of the record seems fine and I just removed the dimension
 cap. Hope things will improve.

If memory serves, we've seen reports from several others that the size
limit notation causes at least a couple of the biggest Receivers to not
emit reports. If you check the list archives, I believe I recall such a
case within the past few months.


 so I expected to see briefly my mailbox being flooded by reports

You probably don't want to point the ruf= tag at anything remotely
like a personal mailbox for the type of domains you described. And I
generally recommend a separate service mailbox for each.

While the number of aggregate (rua) reports will generally max out at
a few per receiving domain per day, the forensic reports (or whatever
we're calling them now) vary based on who may be spoofing your domain
(modulo anybody forwarding your messages/breaking your signatures). That
can get very big, very suddenly. In extreme cases, like a very popular
brand, it could be enough volume to seriously impact your main mailstore
with little warning.

--Steve.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] On Inbound DMARC Support

[Steven M Jones via dmarc-discuss]

On 06/19/2014 08:22 AM, John Levine via dmarc-discuss wrote:

 But if it can help put any dent whatsoever in the endless stream of
 corporate data breaches, for example, I think it's a net benefit for
 consumers.

Before I continue: No, DMARC is not designed to prevent data breaches,
and will not eliminate all data breaches - any more than it will
eliminate all phishing. And the above does not claim it will do so.

However DMARC can help remediate a vector commonly used to initiate an
intrusion against corporate networks, and recent data breaches have
shown phishing was a key step leading to the theft of consumer data.


 How can DMARC prevent breaches?  At most we've seen it defend
 imperfectly against the consequences a very specific and unusual kind
 of breach in which they stole address books of individual mail users.
 For the typical breach of financial information, it's irrelevant.

Phishing is targeted at corporate mailboxes, with one goal being to open
a way into the corporate infrastructure. Access to the infrastructure is
the first step in gaining whatever data you're after. Same-domain
phishing is highly effective, so anything that addresses it is a prudent
control to deploy. Thus, inbound DMARC filtering is desirable for
corporate infrastructure.

The corporate information security sector is well aware of the inbound
phishing threat:

  * net-security.org: Most cyber-attacks begin with spear-phishing emails
  * Verizon 2014 data breach report: Users will be phished, and they
will eventually click
  o ... even a [phishing] campaign consisting of a small number of
messages has a high probability of success - 9-18% depending on
methods
  o Once the phishing email has done its work ... the name of the
game is [getting the data by leveraging network access].
  * June 12, 2013: The FBI has seen an increase in criminals who use
spear-phishing attacks to target multiple industry sectors. These
attacks allow criminals to access private computer networks.
  * Trusteer: Spear-phishing is one of the main tools used by attackers
to compromise endpoints and gain a foothold in the enterprise network.
  * Computerworld 2011: Phishing emerges as major corporate security threat


A few examples of successful phishing of corporations leading to
consumer data breach:

  * The 2013 Target data breach was initiated by a phishing attack -
70+MM consumers affected?
  * In 2012 the South Carolina Dept of Revenue suffered a data breach
due to credential theft via phishing - 5.7MM people, 700k
businesses, and 3.3MM bank accounts
  * In 2010 Epsilon (the ESP) was the victim of a phishing attack that
ultimately exposed customer data of at least 50 of their corporate
customers - affecting as many as 5MM consumers


It's taken a while, but B2B mandatory TLS is now a common control at the
corporate level. I expect a similar evolution with DMARC as vendors make
it available.

--S.


Links:

  * net-security.org - http://www.net-security.org/secworld.php?id=16585
  * Verizon DBIR - http://www.verizonenterprise.com/DBIR/2014/
  * FBI -

http://www.fbi.gov/sandiego/press-releases/2013/fbi-warns-public-that-cyber-criminals-continue-to-use-spear-phishing-attacks-to-compromise-computer-networks
  * Trusteer -
http://www.trusteer.com/solutions/spear-phishing-and-credentials-theft
  * Computerworld -

http://www.computerworld.com/s/article/9215995/Phishing_emerges_as_major_corporate_security_threat
  * Target breach -

http://krebsonsecurity.com/2014/02/email-attack-on-vendor-set-up-breach-at-target/
  * S Carolina -

http://www.scmagazine.com/sc-tax-breach-began-when-employee-fell-for-spear-phish/article/269448/?DCMP=EMC-SCUS_Newswire
  * Epsilon -

http://www.darkreading.com/attacks-and-breaches/epsilon-fell-to-spear-phishing-attack/d/d-id/1097119?




___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] On Inbound DMARC Support

[Steven M Jones via dmarc-discuss]

On 06/19/2014 05:23 PM, Steve Atkins via dmarc-discuss wrote:
 On Jun 19, 2014, at 4:56 PM, Steven M Jones via dmarc-discuss 
 dmarc-discuss@dmarc.org wrote:
 However DMARC can help remediate a vector commonly used to initiate an 
 intrusion against corporate networks,
 I suspect you mean mitigate (although remediate does actually fit rather 
 well).

In fact i had switched between the two words - I don't mind switching back.


 You can't make that bald statement without expecting someone to ask for some 
 evidence of it being useful for that purpose, though.

I don't mind being asked. And I thought I had provided appropriate
references in the rest of my previous message...


  (It's fairly clear to me, for instance, that it's not true - so it's be 
 useful to provide a plausible line of reasoning for it being so; one that'll 
 stand up to discussion).

Again, I thought I'd provided the reasoning.

- Phishing is used to gain unauthorized access to corporate networks
- Unauthorized access to corporate networks is used to effect data breach
- To reduce incidence of data breach, mitigate unauthorized access
- To reduce incidence of unauthorized access, take measures to reduce
successful phishing
- DMARC is effective against one of the most effective forms of phishing

So to me, it follows that adopting DMARC is a reasonable corporate
measure to help combat inbound phishing, which can result in
unauthorized access, which can result in data breach.

I believe I provided examples to show that successful phishing of
corporate entities has been a key step leading to data breach.

--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] On Inbound DMARC Support

[Steven M Jones via dmarc-discuss]

On 06/19/2014 06:58 PM, John Levine via dmarc-discuss wrote:
 Same-domain phishing is highly effective, so anything that addresses it is a 
 prudent
 control to deploy.
 Yes, I believe it.

 Thus, inbound DMARC filtering is desirable for corporate infrastructure.
 No, for this threat it's irrelevant.

 Surely we don't have to explain why you don't need DMARC to implement
 a policy about mail from your own domains on your own servers.  You
 just do it.  Someone at Cisco told me they were doing inbound phish
 filtering almost a decade ago with IIM, one of the predecessors to
 DKIM.

There appears to be some confusion - the phrase same-domain phishing
has been used to identify what DMARC addresses, as opposed to cousin
domain phishing or display name munging. My apologies if the term is
not in sufficiently wide usage.

No, I don't need DMARC to counter inbound phishing using my own domains
- we did that at BofA using SPF almost a decade ago. Configuring a few
dozen domains we controlled and already saw and approved all updates for
to require SPF inbound was manageable and highly effective.

But managing similar many-to-many configurations and updates across
organizations is posing a real problem for B2B TLS at scale. It's been a
frequent topic among FS-ISAC members, if not at MAAWG or IETF.
Fortunately when it comes to anti-phishing and the role DMARC can play
there, the picture's a little different.

--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] On Inbound DMARC Support

[Steven M Jones via dmarc-discuss]

On 06/18/2014 05:32 AM, Solomon, Dianne B via dmarc-discuss wrote:

 I learned this week that two of the major players in enterprise email
 security  -- Proofpoint and IronMail -- do not support DMARC.  Said
 one vendor to me, I understand your inbound use case for DMARC, we
 just don't hear it very often.


BofA has been their customer since 2005, and has been asking for inbound
DMARC support from Proofpoint literally for years now. Of course it took
them so long to get DKIM support working properly, I suppose I shouldn't
be surprised...

Anyway - yes, making sure your vendors hear these requests is useful.


 So adoption is growing -- meaning more and more companies are putting
 the authentication tools in place to protect consumers through ISPs,
 but in the B2B email space, it is virtually ignored.


I do think DMARC has a useful role to play in the B2B space, but there's
usually a more urgent case for deploying it in business-to-consumer
scenarios. If you're looking for the low hanging fruit, getting your B2C
mailstreams into shape for a p=quarantine or p=reject probably wins.
If you have the resources and management support to pursue both in
parallel, great. If you have to prioritize, I'd recommend B2C first.

That said, on the B2B side I always come back to an example from some
years back where a large networking vendor was attacked by phishers
impersonating their HR  benefits provider. It mirrors the B2C case, the
consumers just happen to be employees, and it's a compelling reason to
be looking for receiver-side DMARC from your vendors.


 Businesses rely on spam filters, and technologies like Proofpoint's
 TAP, both of limited use against spearphishing and other targeted
 attack vectors.


I believe there are some announcements expected shortly, and both
Symantec and Halon are already offering it as a cloud filtering service.
(I think I'm forgetting another service...)

--Steve.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] On Inbound DMARC Support

[Steven M Jones via dmarc-discuss]

On 06/18/2014 08:02 AM, John Levine via dmarc-discuss wrote:
 As a community promoting DMARC, we have an obligation to champion deployment 
 at both ends - inbound as well as
 outbound.  A first step is to let our vendors know DMARC support is 
 requirement.
 Um, perhaps they've heard about AOL and Yahoo and have reasonable
 concerns about losing real mail.

Ignoring the swipe at current AOL and Yahoo policies, which are not the
sole determinants of DMARC usefulness, corporate use of email comes
under a lot of constraints that don't apply when considering free
mailbox users.

There are a lot of B2B mailstreams that represent very attractive
targets for attack - selectively or at scale. Similar to the case for
B2B use of enforced TLS, they are places where the use of DMARC could be
beneficial.

 Nothing personal, but like 99.9% of the people in the world, I care
 nothing about your brand.

Which has no bearing on whether or not inbound DMARC filtering should be
considered for corporate infrastructure. Like 99.9% of the people in the
world, you and I would never see the use of DMARC in these B2B cases.
But if it can help put any dent whatsoever in the endless stream of
corporate data breaches, for example, I think it's a net benefit for
consumers.

--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)

Re: [dmarc-discuss] suggestion to optimize the website

[Steven M Jones via dmarc-discuss]

On 06/12/2014 04:19 AM, Andreas Schulze via dmarc-discuss wrote:

 http://dmarc.org/faq.html is currently one single file.
 Would it make send to split it in separate files so the analysed
 access log of
 the webserver could show which questions people have?

 Frank suggested to place a Like! links next to the answers.

Well it's the web, many things are possible. Including analyzing the
current logs to see how much traffic the FAQ is getting today...

They're both good suggestions. It just occurs to me, I have no idea how
many visitors the current page is getting. Worth looking into.

--S.

___
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)