Subject: [dmarc-ietf] Charter discussion being marked as spam

From: Barry Leiba <[email-masked]>
Date: Fri, 27 Jun 2014 18:55:47 -0400

>> [removed the SPAM tag from subject]
>
> Which the mailing list put right back on.  It seems that something in
> the charter text is causing that, and I've asked the Secretariat IT
> support to look into it.  The worst part of this is that none of the
> charter discussion is in the archive.
>
> I have put the proposed charter in the appsawg wiki:
> http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

The Secretariat gave their usual quick response (I just wasn't able to
respond here as quickly): it seems that there's a .co.uk domain name
used as an example in the charter text, that domain name is on a spam
block list, and that caused a high spam score.

That particular domain name has had its spamminess score reduced, so
the problem should stop (though I'm not trusting it here, obviously).
I've suggested that this represents a faulty spam rule: a blacklisted
domain name in an address field should cause a high spam score, but it
shouldn't do so when we're talking about the domain in the body of the
message.  I've also asked whether it's possible to get the missing
messages put back into the archive.

Meanwhile, discussions that include that part of the charter text
shouldn't cause a problem any more.  And just in case, it might not be
a bad idea just to redact the domain name in question when you include
the charter text.

More when I know more.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 27 Jun 2014 16:16:10 -0700

On 6/27/2014 3:55 PM, Barry Leiba wrote:
>    it seems that there's a .co.uk domain name

What is especially frustrating is that it's a formally-legal/appropriate
example name.

> message.

Lots of spam can be detected by virtue of specific URLs that occur in
the body.  So it's entirely reasonable that it was looking there.

That said, yes, the ruleset for IETF mailing lists probably needs
tweaking, given the unusual nature of our content, with respect to
spam/anti-spam work.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 Jun 2014 17:07:28 -0700

> tweaking, given the unusual nature of our content, with respect to

Dear Dave,

Adjusting the spam filter is fine, but not the characterization of work at hand.  Our company has had a fair amount of experience dealing with phishing, which DMARC helps to mitigate.  In essence, this is not an anti-spam effort.  Anti-spam is ineffective at dealing with the phishing problem which is why there is DMARC in the first place. 

It takes little effort for a malefactor to compose a phish not detected as spam.  Anti-spam generally looks for advertising or reaching out with a contact with related statistics identifying various campaigns.  There needs to be a mindset change about the problem, since it can't be measured or viewed as yet another spam issue.  Much greater weight must be given to source validation. Phishing differs from the way spam is detected, which is why DMARC offers feedback. Only the DMARC domain is ever authoritative.  They need to offer specific advice and NOT some spam reputation service.  As I said, anti-spam does not work.  We have tried and it completely failed. 

The payoff from a successful phish can be fairly high allowing much smaller numbers to be sent.  Often the malefactors increase their success rates by knowing more about their victim which is often not done with most spam.  If such weighing were done in this case, there should not have been a problem indicated with the proposed charter.  Perhaps one day we will be able to eat our own dog food while using a mailing-list.

Consider what can be done with the development of an informal federation where the From starts a chain of trust. The overhead is much smaller than most seem to imagine.  As I said, we were doing this for each message received by several very large ISPs using only modest resources.  Far less than that needed to sustain that of SPF, DKIM, or any reverse lookup.  Only those very few messages failing DMARC alignment checks will require additional federation related info.  In comparison. a piece of cake.

Regards
Douglas Otis

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 28 Jun 2014 13:55:27 -0400

> tweaking, given the unusual nature of our content, with respect to

There's no need to run SpamAssassin on the IETF lists: simply configure
Mailman to reject all traffic from non-members and let the list-owner
add other needed addresses on an ad-hoc basis.  (Mailman will by default
hold traffic sent from addresses it doesn't recognize.  The interface
then allows the list-owner to either discard, accept or reject those
messages.  Simultaneously, it allows the list-owner to decide what to
do about the originating address, and one common choice is to add the
address to the list which are permitted to send traffic.  This avoids
involving the list-owner again when more traffic is received from the
same non-subscribed address.  I've used this mechanism for many years
and it works efficiently and beautifully, particularly with people who
use multiple addresses to end traffic to mailing lists.)

---rsk