Your question confirms my core argument: We do not have consensus around
email filter requirements because IETF has focused on sender behavior
rather than recipient behavior.
To the specifics:
By "secure email relay", I am referring to Zixmail-type functioinality.
It is complex code, generally involving a cloud server (although I would
prefer keeping it on an appliance under my control). It is the least bad
option for demonstrating regulatory compliance when transmitting sensitive
information to an ad-hoc recipient. Most organizations need it. Further
discussion on this point probably belongs in the MEDUP discussion.
Use Cases
I receive hositle mail from "server7.badexample.com". I want to block
the IP address because I know it is a bad source. But I also want to
blacklist the other servers at this organization, so I want hostname
filtering to block *.badexample.com. I actually want to block anything
from this organization, so I really want to block this entity anytime it
appears in a HELO/EHLO name, a reply-to name, a list header name, a URL
field, or a message-id field. But for simplicity in a low-end product
that meets my budget, I will settle for IP and ReverseDNS filtering.
DMARC has three components: detecting and enforcing sender
DMARC
policy, collecting feedback information and transmitting it to the sender,
and interpreting feedback received for the sender domain. In a low-end
product, I am only expecting policy enforcement, not the other two
components. From a coding standpoint, it seems only slightly more complex
than SPF enforcement or DKIM signature checking. From a regulatory
standpoint, it is mandatory. If PayPal and Gmail have gone to the trouble
to request DMARC enforcement, and I am devastated by malware because I did
not check DMARC information,, then I am guilty of reckless negligence. So
yes, DMARC enforcement is essential.
Multi-factor whitelisting is needed because whitelisting (give
this
message high trust because the sender is trustworthy) is only safe if the
sender is authenticated (the message really came from the trusted sender).
Sender authenticator requires multiple attributes.
Example: CompanyA.com uses HostingSevice.com. I want to ensure that
messages from CompanyA.com are not blocked based on spam scoring
heuristics. Siingle-factor whitelisting says that I can whitelist the
sender (and expose myself to atacks from anyone spoofing their domain) or I
can whitelist the source server (and expose myself to attacks from any
other client domain at HostingService.com). When ReverseDNS is not an
option, i have no feasible way to whitelist HostingService.com, because I
have no way to know all of their servers and keep the list maintained over
time. A related problem is that I should be able to do granular
whitelisting, for example to ignore only spam scoring while retaining other
tests. Many of the examined products provide all-or-nothing whitelist
mechanisms.
SPF corrections are a related issue, and multi-factor
whitelisting
would be a tolerable but inferior tool for handling the problem. What is
really needed is a local override mechanism that can be expressed in SPF
terms. SPF omissions can include (a) primary domain omitted a server from
its list, (b) included domain omitted a server from its list, or (c) an
entire domain is omitted from the list. Email filters should provide
constructs to handle all three; None of the corrections require
whitelisting. I do not necessarily want to guarantee delivery, I just
want the SPF sender authentication function to be peerformed on accurate
source data.
On EXIM in particular:
My secondary spam filter is based on EXIM, with a vendor-supplied wrapper
and user interface. Because it is secondary, I am protected from some of
the products weaknesses.
Other system administrators routinely complain that when the message
From-Address is there own domain, the message is not blocked. The product
does not fitler on message From -Address, and my research into Exim
capabilities indicated that the Exim filtering process could not even
extract the message From-Address to reference in filtering.
The product based on Exim cannot do ReverseDNS filtering. It
looked
like I might be able to simulate the capability with Exim filter syntax,
but I gave up because I could not decipher how the vendor implemented its
wrapper.
The logging is a summary of all of the chatter between sending
and
receiving systems. The logs entries need to be assembled to present a
single data record about what happened to this message. The vendor's GUI
provides a crude approximation of this process,, but the GUI information
cannot be exported. I finally wrote a bunch of complex code to turn the
log detail into a message data record.
The product based on Exim has only two SPF options: Off or
Block.
When it is off, it does not check or log SPF results. When it is on, it
blocks the message so there is no data on which to evaluate false
positives. If a false positive is detected despite the difficulties, the
product only supports single-factor whitelisting, although it does provide
granularity by feature.
Since email filtering is a heuristic process,, the message
review
features are as important as the message filtering features. It should be
possible to enable any filtering rule in two modes: without
enforcement
(learn mode) so that effectiveness and false positives can be evaluated and
corrected prospectively, before the policy is enforced. with
enforcement
(policy mode) with sufficient data collected so that false positives can be
detected and corrected retrospectively, after the policy is enforced.
Consequently, I stand by the assertion that my feature list is the bare
minimum for anything that claims to be a spam filter. It is not a complete
list. For example RBL checking is also mandatory, but I have not seen that
as an omitted feature, so it was omitted. Nothing in this list requires
proprietary databases that only the richest vendors can offer.
Doug Foster
----------------------------------------
From: "Jeremy Harris" <[email protected]>
Sent: Monday, April 8, 2019 7:21 AM
To: [email protected]
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
On 08/04/2019 12:02, Douglas E. Foster wrote:
> I had only these rudimentary requirements:
> [...] A secure-email method for outbound messages with sensitive
> content
Rudimentary? How secure; what's your threat model?
Those two things often don't go together.
(I should declare an interest: Exim developer.)
--
Jeremy
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
