On 30 Mar 2016, at 11:20, John Hardin wrote:
On Tue, 29 Mar 2016, David B Funk wrote:
On Tue, 29 Mar 2016, Bill Cole wrote:
On 29 Mar 2016, at 19:36, John Hardin wrote:
> Can you send me some samples?
Probably. Tomorrow. Afternoon. When I can spin up a bullshit VM
(what
still uses sendmail with a default workingish config?) or sanitize
examples made via real stuff.
OR: if you can submit mail through a Sendmail instance, send mail
to any
bad address anywhere on any machine running any MTA, all it has to
do is
say '5yz blah blah we hate you' to some part of your attempt to
send mail.
On any machine with a working classical Sendmail-managed mail
subsystem
you can just do 'echo "foo" |mailx -s 'any subject'
nonexist...@non-local.but.existing.domain' and get one of your very
own
for a bogus address of your choice delivered to
/var/spool/mail/yournamehere or somewhere like that. Unless your
Sendmail
is configured to not send MIME DSNs. In that case, fire your
sysadmin.
I tried your experiment (sent mail to "no-such-user...@hotmail.com"
), got the DSN, fed it to SA and didn't see any hits on MIME_NO_TEXT.
Saw a hit on T_TVD_MIME_NO_HEADERS but that has no score.
Now my original message was a CT: text/plain. Maybe if the original
message had no textural components at all it might fire as you
describe but I think it would be an unusual message to have no text,
html, etc at all.
Same here. I think that's the situation: the message that bounced has
to not have any text/plain parts.
I'll edit the bounce I generated and see if that will cause it to hit.
Ewww.
Yes. My bounced messages whose bounces hit MIME_NO_TEXT are all entirely
devoid of MIME headers: they are in fact plain text, but they have no
MIME-Version or Content-Type headers. A bit of experimentation shows
that the MIME_NO_TEXT matches if the original message being bounced
lacks a Content-Type header, even if it HAS a MIME-Version header, in
which case *formally* it is text/plain by default, just as Sendmail's
initial descriptive part is *formally* text/plain by default because it
has no CT header saying otherwise. OTOH: If it's got no MIME-Version
header and therefore is not a MIME object, a Content-Type: text/* header
makes MIME_NO_TEXT happy for (technically) no sound reason...
ALSO: MIME_NO_TEXT is not at all picky. If I add just a CT:t/p header up
top where Sendmail doesn't bother doing so, no match on MIME_NO_TEXT
*OR* T_TVD_MIME_NO_HEADERS:
bcole@sirius:$ diff -uw nonmimemsg smct+nonmimemsg
--- nonmimemsg 2016-03-30 20:52:25.137123397 +0000
+++ smct+nonmimemsg 2016-03-30 21:14:26.854310233 +0000
@@ -19,6 +19,7 @@
This is a MIME-encapsulated message
--u2TNd89e080242.1459294748/ungoliant.RED.ACT.DOM.AIN.net
+Content-Type: text/plain
The original message was received at Tue, 29 Mar 2016 23:39:01 GMT
from ungoliant.RED.ACT.DOM.AIN.net [1.2.3.4]
bcole@sirius:$ spamassassin < nonmimemsg |grep -m1 -A2 X-Spam-Status
X-Spam-Status: No, score=1.6 required=4.5
tests=AWL,CIPH_DEBUG,MIME_NO_TEXT,
T_TVD_MIME_NO_HEADERS shortcircuit=no autolearn=no autolearn_force=no
version=3.4.1
bcole@sirius:$ spamassassin < smct+nonmimemsg |grep -m1 -A2
X-Spam-Status
X-Spam-Status: No, score=0.6 required=4.5 tests=AWL,CIPH_DEBUG
shortcircuit=no
autolearn=no autolearn_force=no version=3.4.1
Received: from ungoliant.RED.ACT.DOM.AIN.net ([1.2.3.4] verified)
AND ALSO ALSO: T_TVD_MIME_NO_HEADERS is only complaining about the
untyped initial description part. If I add a "MIME-Version: 1.0" header
to the original message AND a "Content-Type: text/plain" to the initial
description part, T_TVD_MIME_NO_HEADERS doesn't notice that there's a
self-declared MIME object down there without any explicit MIME headers.
AND FINALLY: MIME_NO_TEXT isn't entirely unpicky about finding a CT:t/*
header. It won't find one in the epilog (after the last MIME boundary)
or in the original message body.
So, overall, I've got 8 carefully and not excessively redacted slight
variants of one bounce now with CT and MV headers inserted in various
ways and if anyone wants the entire collector's set, they're free for
the asking as a 30k tarball, I'll even compress it if you like.
I am still not sure what the right fix is, because as I was writing this
I realized that the cleanest fix would involve recognizing bounces, and
that must be useful enough to exist somewhere in SA already AND IT DOES:
but WOW, isn't THAT design broken! So I did the magic only revealed in
the comments of
/var/db/spamassassin/3.004001/updates_spamassassin_org/20_vbounce.cf
(yay, where I look for key functional facts all the time!) and set
whitelist_bounce_relays correctly and lo: the unredacted pristine
original bounce IS NOT recognized as a bounce but the set of 8 variants
with hostnames and IP's carefully redacted, they all match
BOUNCE_MESSAGE and ANY_BOUNCE_MESSAGE. If I add the redacted form of the
host that is passing back the bounce to me to whitelist_bounce_relays,
the redacted messages no longer match BOUNCE_MESSAGE and
ANY_BOUNCE_MESSAGE, which is positively perverse. Maybe I need to set
whitelist_bounce_relays to afklhfhfasfj so it won't match anything but
will magically activate bounce detection?
In my case the workaround is (in redacted form) this added to local.cf:
whitelist_from_rcvd mailer-daemon@*.RED.ACT.DOM.AIN.net [1.2]
But that sucks almost as bad as the design of
Mail::SpamAssassin::Plugin::VBounce & 20_vbounce.cf.
