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

[John Levine via dmarc-discuss]

>p= none is not just because people don't care.

What he said.  p=none lets you collect reports and decide what to do.
In my case, the reports have told me that for all but one of the
domains I manage*, nobody is forging them enough to be worth further
DMARC pain.

I would suggest a note saying that Fortinet's implementation is known
to be fatally buggy.

R's,
John

* - the one is abuse.net, could probably do p=quarantine since nobody's
supposed to send mail from abuse.net addresses through lists.


___
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

[Roland Turner via dmarc-discuss]

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

To clarify, does enabling the setting cause the rejection of:
- all messages that fail DMARC-like tests whether or not they have a DMARC 
record; or
- just all of those that fail checks whose 5322.From address domain has any 
DMARC record, while not performing DMARC-like tests on domains who don't.
?

That a p=none record have the same impact as no record is an important 
property, as the ability to turn on p=none without impact is an important 
enabler for domain owner/registrants to explore implementation. If FortiMail is 
implementing feature that breaks this property then it would be worth 
addressing (sadly, I have no relevant contacts).

If it's simply applying the same overzealous rules to domains with no record as 
to those with a p=none record then this is a poor choice, but not as harmful in 
that it won't affect decision-making by implementing domain owner/registrants.

> In DMARC RFC there is:
> "To enable Domain Owners to receive DMARC feedback without impacting 
> existing mail processing, discovered policies of "p=none" SHOULD NOT 
> modify existing mail disposition processing."
> 
> So I guess it doesn't break RFC if there is "SHOULD NOT" and not "MUST 
> NOT"? But I still think this implementation of DMARC is wrong. What do 
> you guys think?

The implementation is poor, but it's complying. The p= value is a request by 
the domain-owner/registrant to the receiver to do a certain thing rather than 
an instruction; the receiver retains full discretion about whether or not they 
do as asked, which is why the specification says SHOULD NOT rather than MUST 
NOT. This doesn't mean that harmful implementations wouldn't benefit from being 
improved, just that receiver discretion is a high priority.

- Roland

___
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

[Petr Novák via dmarc-discuss]

Dne 14.11.2016 v 20:24 Steven M Jones via dmarc-discuss napsal(a):

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.



Yes this is the problem I wrote about. You cannot chose a different 
action based on the policy in FortiMail. There is just one action you 
take when DMARC fails. And it doesnt matter if p=none or p=reject that 
one action will take place.

___
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] Getting to reject, was :Re: FortiNet’s FortiMail DMARC implementation

[Phil Stracchino via dmarc-discuss]

On 11/14/16 14:53, Scott Kitterman via dmarc-discuss wrote:
> It's also essentially impossible if you make non-trivial use of
> mailing lists.  Even though I've has SPF -all records for over a
> decade and encourage people to reject mail purporting to be from my
> domains that fail SPF, I am no where near being able to do so for
> DMARC because of mailing lists.

Yup.  I'm in that boat too.  In fact a significant proportion of my
outgoing mail gets delivered by mit.edu, and mit.edu is throwing ALL
mail authentication on the floor - DMARC, DKIM, SPF...


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485
___
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] Getting to reject, was :Re: FortiNet’s FortiMail DMARC implementation

[Scott Kitterman via dmarc-discuss]

On November 14, 2016 2:42:42 PM EST, Terry Zink via dmarc-discuss 
 wrote:
>> Well, DMARC addresses one particular vector - we still need to find
>more effective ways 
>> to address cousin domains, display name abuse, etc.
>
>I didn't mean cousin domains, I mean domains that are not the same but
>have a relationship (e.g., one is a vendor of the other). They both
>have weak authentication records (no DMARC, or DMARC + p=none), and
>then one of them gets spoofed.
>
>So yes, the fix is to publish a stronger DMARC policy, but lots of
>domains who publish DMARC have a weak policy. It's hard to get to
>p=reject/quarantine if you are not a big company and are doing it
>yourself.

It's also essentially impossible if you make non-trivial use of mailing lists.  
Even though I've has SPF -all records for over a decade and encourage people to 
reject mail purporting to be from my domains that fail SPF, I am no where near 
being able to do so for DMARC because of mailing lists.

p= none is not just because people don't care.

Scott K
___
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

[Terry Zink via dmarc-discuss]

It's almost definitely an anti-phishing setting.

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.

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


-Original Message-
From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf Of Al 
Iverson via dmarc-discuss
Sent: Monday, November 14, 2016 7:53 AM
To: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] FortiNet’s FortiMail DMARC implementation

I agree with John Payne on this one. Their implementation shouldn't work this 
way based on the default settings.

Regards,
Al Iverson

--
Al Iverson

___
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)

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

[Payne, John via dmarc-discuss]

> On Nov 14, 2016, at 9:49 AM, Petr Novák via dmarc-discuss 
>  wrote:
> 
> Hello,
> 
> I saw that FortiNet's FortiMail is listed as a product that has a DMARC 
> support here: "https://dmarc.org/resources/products-and-services/; .
> 
> 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 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.
> 
> In DMARC RFC there is:
> "To enable Domain Owners to receive DMARC feedback without impacting existing 
> mail processing, discovered policies of "p=none" SHOULD NOT modify existing 
> mail disposition processing."
> 
> So I guess it doesn't break RFC if there is "SHOULD NOT" and not "MUST NOT"? 
> But I still think this implementation of DMARC is wrong. What do you guys 
> think?


Speaking only as an enterprise trying to use DMARC, FortiMail’s implementation 
as described above is wrong and serves only to discourage others from 
implementing a DMARC policy.  p=none is vital.

That said, I would have no objection to fortimail customers having the option 
to treat p=none as p=quarantine or p=reject -> that’s completely up to them.  
But by default no thank you!

___
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)