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