Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[David B Funk]

On Tue, 29 Mar 2016, Bill Cole wrote:


On 29 Mar 2016, at 19:36, John Hardin wrote:

So, a message that's explicitly multipart MIME but which has only one part? 
Or does it actually have multiple parts, just none are marked as 
text/plain?


multipart/report; type=delivery-status. The standard MIME delivery status 
notification structure. 2 very similar RFCs on it. Has 3 (or 4?) parts. All 
except the first part (which IS text/plain; charset=us-ascii but in 
Sendmail's case has no Content-Type header saying so) have proper 
message/[thisandthat] CT headers.



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.


--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[John Hardin]

On Tue, 29 Mar 2016, Bill Cole wrote:


On 29 Mar 2016, at 19:36, John Hardin wrote:


 Can you send me some samples?



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.


That I can do. Thanks.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  You are in a maze of twisty little protocols,
  all written by Microsoft.
--
 3 days until April Fools' day

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[Bill Cole]

On 29 Mar 2016, at 19:36, John Hardin wrote:

So, a message that's explicitly multipart MIME but which has only one 
part? Or does it actually have multiple parts, just none are marked as 
text/plain?


multipart/report; type=delivery-status. The standard MIME delivery 
status notification structure. 2 very similar RFCs on it. Has 3 (or 4?) 
parts. All except the first part (which IS text/plain; charset=us-ascii 
but in Sendmail's case has no Content-Type header saying so) have proper 
message/[thisandthat] CT headers.



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.


sorry if that's incoherent babbling, I can't tell. not awake. typed and 
randomly abridged but not really proofread


--
Bill Cole
Not here right now.

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[John Hardin]

On Tue, 29 Mar 2016, Bill Cole wrote:

This is true for 8.14.7 in FreeBSD 8.4-RELEASE-p27 (a.k.a. "Update your damn 
boxes, Bill!") and I see nothing in later release notes indicating a relevant 
change in Sendmail, which is formally within spec by putting no MIME headers 
in the human-readable first part of a DSN (Seriously, all MIME headers are 
formally optional... text/plain charset=us-ascii is default).


So, a message that's explicitly multipart MIME but which has only one 
part? Or does it actually have multiple parts, just none are marked as 
text/plain?


Since MIME_NO_TEXT is pegged to its limit in the current ruleset (1.999) 
there's likely a lot of backscatter out of Sendmail feeding the score, making 
it harder for me to form an opinion on the right sort of global fix, if one 
exists.


Can you send me some samples? Suppressing it for something that looks like 
a DSN might be reasonable; we can at least see how that plays in 
masscheck.


(I'll probably write a bug on this when my brain has rested adequately to do 
so cogently, can't say when that might be.)


Not sure it's worthy of a bug. Discuss it here and if any changes seem 
justified I'll make them.



--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
 3 days until April Fools' day

HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[Bill Cole]

This is true for 8.14.7 in FreeBSD 8.4-RELEASE-p27 (a.k.a. "Update your 
damn boxes, Bill!") and I see nothing in later release notes indicating 
a relevant change in Sendmail, which is formally within spec by putting 
no MIME headers in the human-readable first part of a DSN (Seriously, 
all MIME headers are formally optional... text/plain charset=us-ascii is 
default). If, like me, you have a bunch of old machines that 
occasionally generate mail that is required/forced to use local sendmail 
submission, which is configured to send bounces for just about anything 
to some elsewhere that actually gets read, this matters.


Since MIME_NO_TEXT is pegged to its limit in the current ruleset (1.999) 
there's likely a lot of backscatter out of Sendmail feeding the score, 
making it harder for me to form an opinion on the right sort of global 
fix, if one exists.


(I'll probably write a bug on this when my brain has rested adequately 
to do so cogently, can't say when that might be.)

How to know if TxRep is white listing out going email.

[Philip]

I've enabled outgoing white listing using the TxRep plugin is there a 
way to find out if outbound emails are actually being white listed? A 
log somewhere... a file being updated?


--
Phil

Re: spamd running much slower than spamassassin?

[Daniel J. Luke]

On Mar 28, 2016, at 8:57 PM, Bill Cole 
 wrote:
> On 28 Mar 2016, at 14:42, Daniel J. Luke wrote:
>> On Mar 24, 2016, at 12:10 PM, Daniel J. Luke  wrote:
>>> /usr/bin/time spamassassin < spam.msg
>>>   7.92 real 1.85 user 0.13 sys
>>> 
>>> /usr/bin/time spamc -U /var/run/spamd.sock < spam.msg
>>>126.44 real 0.00 user 0.00 sys
>> 
>> well, it looks like it's DNS related, somehow.
> 
> The 2 minute pause had me thinking that, but nothing jumped out as a specific 
> explanation and nothing yet does...
> 
>> I'm still confused as to why 'spamassassin' doesn't have a problem but 
>> 'spamd' does. I'm running SA 3.4.1 with perl5.22.1. I've tried both 
>> downgrading Net::DNS to 0.83 and upgrading it to 1.05_2
>> 
>> Any thoughts would be appreciated.
> 
> You haven't mentioned your platform, that I've seen, but it may be relevant, 
> e.g. historically FreeBSD jails can't do real loopback (not sure on 10.2...) 
> EL6/7 derivatives have SELinux on by default, etc...
> 
> So: more clues please?

Sorry, this is a Mac OS X 10.11.4 system, perl5.22.1 is self-built (perlbrew). 
I'm not sure exactly when this started, I noticed it after I upgraded to 
10.11.4 from 10.11.3, but it may have been happening before. What else would be 
helpful to know? 

-- 
Daniel J. Luke