Subject: [DNSOP] warning

From: ac <[email-masked]>
Date: Sun, 18 Dec 2016 07:13:43 +0200

If any of you are thinking about speaking your mind, there are consequences.

[email-masked]
host smtp.rhyolite.com [192.188.61.3]
SMTP error from remote mail server after end of data:
550 5.7.1 mail uBI4vMnA039102 from 188.40.114.80 rejected by DCC

https://en.wikipedia.org/wiki/Distributed_Checksum_Clearinghouse

188.40.114.80 responsible ISP = Hetzner.de

Number of spam complaints the pas 24 months = 0

Number of spam emails sent by 188.40.114.80  = 0

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 18 Dec 2016 07:59:30 GMT

> From: ac <[email-masked]>
> To: [email-masked]

> If any of you are thinking about speaking your mind, there are consequences.

What consequences are those, besides subjecting me to two instead of
only one copy of a message that doesn't seem to contain improved words
for the RPZ draft?

> 550 5.7.1 mail uBI4vMnA039102 from 188.40.114.80 rejected by DCC

My logs show that the copy of the message sent directly from hostacc.com
at 188.40.114.80 to my mail system was rejected because it lacked a
Message-ID header.  I've long recommended that heuristic because it
has few false positives and a high rate of true positives.  It's
particularly good against bottom rung spam such as pillz and 419;
senders of higher quality spam tend to use higher quality spamware.

Among the 399 messages sent toward [email-masked] in the last 24
hours (usual weekend decrease), 43 or more than 10% lacked Message-ID
headers.  For fun, I looked at all 43 and found only the single false
positive, for a false positive rate of 0.023%, which is both not bad
and 10X or 100X higher (worse) than usual.

By my lights, unsolicited bulk email filtering "MUST" happen during
the SMTP transaction at the end of the DATA command so that the envelope
and some of the body can be logged and there is no blackholing.  On
the other hand, I've found that individuals from whom I don't want to
see more tend to have delicate and loud feelings, and so I use procmail
to blackhole their missives.

Vernon Schryver    [email-masked]

---

From: ac <[email-masked]>
Date: Sun, 18 Dec 2016 13:34:59 +0200

On Sun, 18 Dec 2016 07:59:30 GMT
Vernon Schryver <[email-masked]> wrote:
> My logs show that the copy of the message sent directly from
> hostacc.com at 188.40.114.80 to my mail system was rejected because
> it lacked a Message-ID header.  I've long recommended that heuristic
> because it has few false positives and a high rate of true
> positives.  It's particularly good against bottom rung spam such as
> pillz and 419; senders of higher quality spam tend to use higher
> quality spamware.
> 
okay, I accept your explanation and I apologize. you are bouncing me
emails because your email system is broken and not because you are
vindictive.

Please excuse my initial assumption, as it is I am questioning your
ethics, and to take one leap further, is not such a large leap.

For the record: It is a courtesy, when replying to a poster on a
mailing list to reply to all, this allows the poster to receive the
reply ahead of the posters relay position on that mailing list.

Regarding "Message-ID header"  - factually, over 80% of all spam 
(I have not bothered to do the actual number check, it is probably closer
to 99.99% but I am erring on the side of caution - as this is science
and not opinion, it is what it is)
 
- All contain a Message-ID header. 

Hard bounce on such a trivial rule, is also clearly what it is.

Andre

> the SMTP transaction at the end of the DATA command so that the
> envelope and some of the body can be logged and there is no
> blackholing.  On the other hand, I've found that individuals from
> whom I don't want to see more tend to have delicate and loud
> feelings, and so I use procmail to blackhole their missives.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: [email-masked]
Date: Sun, 18 Dec 2016 13:28:03 +0100 (CET)

> - All contain a Message-ID header. 

You're saying that most spam messages contain a Message-ID header. This

> and 10X or 100X higher (worse) than usual.

so he's saying that most messages without a Message-ID header is spam.

>From my own statistics, I'd have to agree - lack of a Message-ID header
is indeed a strong predictor of spam.

Steinar Haug, AS2116

---

From: Jim Reid <[email-masked]>
Date: Sun, 18 Dec 2016 12:37:37 +0000

> On 18 Dec 2016, at 12:28, [email-masked] wrote:
> 
> You're saying that most spam messages contain a Message-ID header.

Please take this discussion somewhere else. It is not appropriate for dnsop.

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 18 Dec 2016 08:27:17 -0500

Jim is correct, this is not relevant

tim

---

From: william manning <[email-masked]>
Date: Sun, 18 Dec 2016 10:45:57 -0800

SMTP configuration is not relevant... That said, the morphing of open SMTP
services to the tightly controlled heirarchy and draconian locally
administered rules which prevent delivery are EXACTLY what this draft
proposes for the DNS.

---

From: ac <[email-masked]>
Date: Mon, 19 Dec 2016 05:36:32 +0200

On Sun, 18 Dec 2016 10:45:57 -0800
william manning <[email-masked]> wrote:

this became very relevant to DNSOP list again...

> SMTP configuration is not relevant... That said, the morphing of open
> SMTP services to the tightly controlled heirarchy and draconian
> locally administered rules which prevent delivery are EXACTLY what
> this draft proposes for the DNS.
> 
no, respectfully, you are completely wrong.

This draft is dishonest, (I am refraining from calling it criminal, but
criminal is probably not a wrong word)

When Mail server admins control which mail they receive, they are
exercising control over resources in their legal control.

When it is okay for DNS administrators to lie it simply is not okay.

We as a community is making it acceptable to tell lies by not calling a
spade a spade, but dancing around and using fancy footwork and using
long explanations to explain why this is perfectly acceptable. 

I also am fully aware that DNS admins are able to do what they want
without this draft.

BUT

That the IETF publishes this as an RFC is a clear indication that it
lacks ethics, promotes criminal behavior on the Internet (by making it
"okay" to tell lies)

And, are we really so far down the garden path that we cannot even see
that dishonesty breeds evil. It is the broken window principle. I can
of course also start quoting Edmund Burke (and again, that would not be
a wrong thing to do)

Andre