|
Re: Enough DMARC whinging
2014-05-02 07:51:36
Alessandro Vesely wrote:
On Thu 01/May/2014 17:18:38 +0200 Dave Crocker wrote:
On 5/1/2014 8:22 AM, Phillip Hallam-Baker wrote:
Spam filters should know about things as important as mailing list
subscriptions.
+1
We have about 20 years of spam filtering experience in the industry.
The quality of modern filters is astonishingly good; it's the only
reason email remains viable for users, in spite of open-Internet spam
traffic being far above 90%.
I believe that little or none of that filtering includes awareness of
mailing list subscriptions. So while the above is an interesting and
possibly useful line of pursuit, it's not clear how it can be elevated
to the status of 'should'.
It is certainly useful to simplify spam filtering. I think there
would be consensus on 'should'; not on 'must' because of privacy
considerations.
Note that historically, mailing list operators have been resistant to
the imposition of technical or operational changes.
Speaking for at least one mailing list operator, who knows a lot more:
I've ALWAYS implemented quite a bit of controls over our lists - both
authenticating users before allowing them to join lists, and
implementing extensive spam filtering at both the MTA and list level.
The list software we use (Sympa), likewise has multiple spam and virus
filtering mechanisms, as well as hooks for linking with external
mechanisms. I haven't worked with Mailman extensively, but it also has
spam filtering mechanisms.
Spam is as much, or more of a problem for list operators, as anyone
else. What I object to is when someone foists a new mechanism down our
throats - without any care for breaking things.
Actually, you may have unintentionally phrased this accurately: I (and
probably other list operators) are "resistant to the IMPOSITION of
technical or operational changes." Working WITH us, might yield better
effect. And there are at least two forms that could have taken:
1. Contribute support (labor/dollars) to write patches to the major
email list packages, BEFORE turning on restrictive DMARC policies. (We
are talking about large, well funded corporate entities who have
invested dollars in developing and implementing DMARC for business
reasons that presumably have signficant payback).
2. Designing and implementing mechanisms that mitigate the impact on
mailing lists - for example, whitelists.
3. Actually developing something that plays nice with whitelists - as
there is now some discussion about (XOAR, whitelists, ....).
I'm not clear what you mean. Is there a standard that defines mailing
lists?
There are some that approach it - like the SMTP extensions for
list-related headers. I personally think mailing list functionality is
well enough understood that we could improve on this, and incorporate
some standard authentication mechanisms in the process.
Personally, I think some kind of standard that allows for:
- separate identification and signing/authentication of author,
originating MTA, list/forwarder would go a long way (I think this would
require additional headers and/or standardizing the use of existing
headers a bit more tightly)
- maybe an extra list header or two regarding reply-to (separate author,
author-errors, list, list-errors)
- a mechanism that allows a list to modify messages that doesn't break
incoming signatures, say:
--- separate "original-subject" "subject-with-tags""listname" headers
--- a well-specified way to add a header and/or footer to a message
(e.g., headers to indicate header-line-count, and footer-line-count)
--- provisions for MIME
--- i.e., a recipient can verify the original message and author, verify
changes that have been made by a listprocessor, run some checks on the
diffs, then make a decision on what to do with the message
- maybe some best practices for mail client presentation of information
to end users
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
|
|