Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs
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
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
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
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
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.
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?
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