Re: Newest spammer trick - non-blank subject lines?
On Tuesday 09 February 2010, Ted Mittelstaedt wrote: >OK All, > > Please let me know if anyone has seen this one before. > > We have SA configured to insert "*SPAM* in the >beginning of the subject lines of spams before sending them on to >customers, then mail the message as an attachment to the user >along with the SA report as to why it's spam. > > Lately I've seen a new trick the spammers are using. > > They are putting characters in the subject line that >are not text characters - I don't know what they are, >I haven't looked into this closely yet. Our SA installation >is correctly tagging this as spam and sending it forward >to the user. > > The problem is the mail client program, specifically >Thunderbird. There must be a bug in T-bird that is tickled >by these non-text characters because although the Subject >line exists with ***SPAM*** in it if I look at the actual >message in the mailbox with an editor, T-bird displays >the subject line as a BLANK subject. Of course, since the >Subject is blank then you don't see that it is SPAM and >you have to go to the bother of opening it before you see >the SA report that it's spam. > > This has only happened to a few spams so far, and I want >to nip it in the bud. > > Now, why don't I just write a rule in T-bird that trashes mail >that has a blank subject line, I hear you ask? > > It's because we have a few moronic customers who seem to >think it's OK to send out e-mails with blank subject lines!! Put a valid subject line required into your TOS, mail it to everybody, & then do it a day later, bounce it at them if no subject line content. They will either jump ship in which case offer to hold the door, or come around and do it right in a day or so. > It would be most useful if when SA was creating the subject >lines of the e-mails with the spams attached, that instead of >just blindly copying over the Subject line from the spam and >inserting the *SPAM* in front of the subject, that >SA stripped out all the non-text characters in the Subject >line. > > Any suggestions appreciated! (even the smart-ass ones but >they have to be clever) > >Thanks! >Ted > -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Hurd and architecture in one sentence? Uh-oh... - Al Viro on linux-kernel
Re: Newest spammer trick - non-blank subject lines?
Gene Heskett wrote: On Tuesday 09 February 2010, Ted Mittelstaedt wrote: OK All, Please let me know if anyone has seen this one before. We have SA configured to insert "*SPAM* in the beginning of the subject lines of spams before sending them on to customers, then mail the message as an attachment to the user along with the SA report as to why it's spam. Lately I've seen a new trick the spammers are using. They are putting characters in the subject line that are not text characters - I don't know what they are, I haven't looked into this closely yet. Our SA installation is correctly tagging this as spam and sending it forward to the user. The problem is the mail client program, specifically Thunderbird. There must be a bug in T-bird that is tickled by these non-text characters because although the Subject line exists with ***SPAM*** in it if I look at the actual message in the mailbox with an editor, T-bird displays the subject line as a BLANK subject. Of course, since the Subject is blank then you don't see that it is SPAM and you have to go to the bother of opening it before you see the SA report that it's spam. This has only happened to a few spams so far, and I want to nip it in the bud. Now, why don't I just write a rule in T-bird that trashes mail that has a blank subject line, I hear you ask? It's because we have a few moronic customers who seem to think it's OK to send out e-mails with blank subject lines!! Put a valid subject line required into your TOS, mail it to everybody, & then do it a day later, bounce it at them if no subject line content. They will either jump ship in which case offer to hold the door, or come around and do it right in a day or so. I have doubts that the offenders can even read at all, let alone read a TOS or even know what it is. We have customers who call in for tech support and when I tell them to open their web browser they don't know what I'm talking about. I swear to God this is true, I'm not making a joke! I got a call the other day from a customer who is a dialup customer who was planning on buying one of those Atom-based half-a-laptop netbooks and wanted to know how to put a modem on it - and she was NOT planning on doing this because she was traveling - she was planning on keeping her dialup as her main Internet connection at home!! (don't even ask what she is currently using, just imagine) We've got calls in the past from customers who disconnected service from us (went to some other DSL provider than us) and wanted to know why their e-mail stopped working (and expected us to fix it!) Ted It would be most useful if when SA was creating the subject lines of the e-mails with the spams attached, that instead of just blindly copying over the Subject line from the spam and inserting the *SPAM* in front of the subject, that SA stripped out all the non-text characters in the Subject line. Any suggestions appreciated! (even the smart-ass ones but they have to be clever) Thanks! Ted
Re: Newest spammer trick - non-blank subject lines?
On 02/09, Ted Mittelstaedt wrote: > Thunderbird. There must be a bug in T-bird that is tickled Submit a bug report against thunderbird. -- "Dance, dance, wherever you may be" - Lord of the Dance http://www.ChaosReigns.com
Re: Newest spammer trick - non-blank subject lines?
dar...@chaosreigns.com wrote: On 02/09, Ted Mittelstaedt wrote: Thunderbird. There must be a bug in T-bird that is tickled Submit a bug report against thunderbird. I don't want to have to play wack-a-mole with every mail client out there. I can just imagine that bug report anyway: Dear t-bird maintainers: I am getting spams that have non-ASCII characters in the subject line and t-bird is displaying the entire subject line as a blank line. I really want to see what my spammer friends are putting in their subject lines, so could you please fix t-bird so that it displays the bogus characters that my spammer friends are putting in their spams to me? I'd stand a better chance of that bug being fixed if I DIDN'T report it!!! Ted
Re: Newest spammer trick - non-blank subject lines?
On Tue, 2010-02-09 at 12:58 -0800, Ted Mittelstaedt wrote: >The problem is the mail client program, specifically > Thunderbird. There must be a bug in T-bird that is tickled > by these non-text characters because although the Subject > line exists with ***SPAM*** in it if I look at the actual > message in the mailbox with an editor, T-bird displays > the subject line as a BLANK subject. As you said, this appears to be a thunderbird issue. Went there to report it? >Now, why don't I just write a rule in T-bird that trashes mail > that has a blank subject line, I hear you ask? Err, nope. :) Note that the Subject actually is NOT empty, as you said. And unless filtering in TB on (raw or decoded) headers is affected by the very same bug /displaying/ the Subject header in a specific widget is... Very unlikely. What's invisible to the eye in the UI seriously isn't invisible to code logic. This appears to be a client *rendering*, displaying bug. Not to be confused with an actual empty header (which isn't the same as a missing header either) to filter on. Even though this most likely is a TB bug, it would be interesting to have a look at these headers. If possible, the raw one, prior to your SA header munging, err, rewriting option. guenther -- char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
From: "Ted Mittelstaedt" Sent: Tuesday, 2010/February/09 13:24 Gene Heskett wrote: On Tuesday 09 February 2010, Ted Mittelstaedt wrote: OK All, Please let me know if anyone has seen this one before. We have SA configured to insert "*SPAM* in the beginning of the subject lines of spams before sending them on to customers, then mail the message as an attachment to the user along with the SA report as to why it's spam. Lately I've seen a new trick the spammers are using. They are putting characters in the subject line that are not text characters - I don't know what they are, I haven't looked into this closely yet. Our SA installation is correctly tagging this as spam and sending it forward to the user. The problem is the mail client program, specifically Thunderbird. There must be a bug in T-bird that is tickled by these non-text characters because although the Subject line exists with ***SPAM*** in it if I look at the actual message in the mailbox with an editor, T-bird displays the subject line as a BLANK subject. Of course, since the Subject is blank then you don't see that it is SPAM and you have to go to the bother of opening it before you see the SA report that it's spam. This has only happened to a few spams so far, and I want to nip it in the bud. Now, why don't I just write a rule in T-bird that trashes mail that has a blank subject line, I hear you ask? It's because we have a few moronic customers who seem to think it's OK to send out e-mails with blank subject lines!! Put a valid subject line required into your TOS, mail it to everybody, & then do it a day later, bounce it at them if no subject line content. They will either jump ship in which case offer to hold the door, or come around and do >> it right in a day or so. I have doubts that the offenders can even read at all, let alone read a TOS or even know what it is. We have customers who call in for tech support and when I tell them to open their web browser they don't know what I'm talking about. I swear to God this is true, I'm not making a joke! I have a thoroughly retired and partially disabled friend I try to help out, such as he'll let me. (I thought I was paranoid until I met him...) I am slowly breaking him of the thought pattern that opening Internet Explorer connected him to the Internet. He WAS at one time on dial-up where this might have be true. He's on DSL now. So he's always connected. He still talks about connecting when he means opening the browser. I got a call the other day from a customer who is a dialup customer who was planning on buying one of those Atom-based half-a-laptop netbooks and wanted to know how to put a modem on it - and she was NOT planning on doing this because she was traveling - she was planning on keeping her dialup as her main Internet connection at home!! (don't even ask what she is currently using, just imagine) Two tin cans and a string? {^_-} We've got calls in the past from customers who disconnected service from us (went to some other DSL provider than us) and wanted to know why their e-mail stopped working (and expected us to fix it!) Ah yes, and they won't take, "It is not a free service we offer to everybody, " for an answer, will they? Perhaps offer then a one month period for forwarding email to their new address once they can provide it - for say $10.00 or something like that. It would give them time to inform all their correspondents of their new email address. After the first month allow them to continue it for a full "email only" account rate. {^_-}
Re: Newest spammer trick - non-blank subject lines?
From: Sent: Tuesday, 2010/February/09 13:35 On 02/09, Ted Mittelstaedt wrote: Thunderbird. There must be a bug in T-bird that is tickled Submit a bug report against thunderbird. I seem to remember "way back when" that a cr/lf pair in the subject line could result in strange things being displayed in the Outlook Express subject line. If T'bird scrolls the subject in that case you'd get the effect he's talking about. {^_^}
Re: Newest spammer trick - non-blank subject lines?
From: "Ted Mittelstaedt" Sent: Tuesday, 2010/February/09 13:50 dar...@chaosreigns.com wrote: On 02/09, Ted Mittelstaedt wrote: Thunderbird. There must be a bug in T-bird that is tickled Submit a bug report against thunderbird. I don't want to have to play wack-a-mole with every mail client out there. I can just imagine that bug report anyway: Dear t-bird maintainers: I am getting spams that have non-ASCII characters in the subject line and t-bird is displaying the entire subject line as a blank line. I really want to see what my spammer friends are putting in their subject lines, so could you please fix t-bird so that it displays the bogus characters that my spammer friends are putting in their spams to me? I'd stand a better chance of that bug being fixed if I DIDN'T report it!!! Ted Ted, you cannot expect any more help from them than you give to expired accounts, you know. You MUST give them some data to work with. Figure out what those characters are. I am betting it would be a simple "cr/lf" pair or maybe even a simple "lf". But without good knowledge of what it is how can the T'bird people fix it? "Insufficient data" is as good a reason as "insufficient account." {^_-}
Re: Newest spammer trick - non-blank subject lines?
On Tue, 2010-02-09 at 14:27 -0800, jdow wrote: > I have a thoroughly retired and partially disabled friend I try to > help out, such as he'll let me. (I thought I was paranoid until I > met him...) I am slowly breaking him of the thought pattern that > opening Internet Explorer [...] Being paranoid. Using IE... *boggle* Nope, he is definitely not paranoid enough, if he never questioned the part about needing IE. Let alone never ever read / heard anything about security and main-stream mom-and-pap computer usage. Come on, IE exploits have been all over the general news in this country quite a few times. -- char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
On Tue, 2010-02-09 at 13:50 -0800, Ted Mittelstaedt wrote: > > > Thunderbird. There must be a bug in T-bird that is tickled > > > > Submit a bug report against thunderbird. > > I don't want to have to play wack-a-mole with every mail > client out there. TB doesn't display the Subject header. It is a TB bug, weather you like it or not. > I can just imagine that bug report anyway: > > Dear t-bird maintainers: > >I am getting spams that have non-ASCII characters in the > subject line and t-bird is displaying the entire subject line > as a blank line. I really want to see what my spammer friends > are putting in their subject lines, so could you please fix > t-bird so that it displays the bogus characters that my spammer > friends are putting in their spams to me? This bug report is insufficient and NEEDINFO. ;) Seriously, this needs an attachment at the very least with the headers. And again, as I mentioned in a previous post -- yes, seeing these headers would be nice. For this audience, too. Yes, that even enables some of us to check other MUAs. So, well, you wouldn't need to report it for those... >I'd stand a better chance of that bug being fixed if I > DIDN'T report it!!! Now there's OSS involvement speaking. Sorry, Ted. If you or someone else don't report it, it won't be fixed. Period. Unless it accidentally gets fixed by an unrelated code change nearby. guenther -- char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
Karsten Bräckelmann wrote: On Tue, 2010-02-09 at 12:58 -0800, Ted Mittelstaedt wrote: The problem is the mail client program, specifically Thunderbird. There must be a bug in T-bird that is tickled by these non-text characters because although the Subject line exists with ***SPAM*** in it if I look at the actual message in the mailbox with an editor, T-bird displays the subject line as a BLANK subject. As you said, this appears to be a thunderbird issue. Went there to report it? Now, why don't I just write a rule in T-bird that trashes mail that has a blank subject line, I hear you ask? Err, nope. :) Note that the Subject actually is NOT empty, as you said. And unless filtering in TB on (raw or decoded) headers is affected by the very same bug /displaying/ the Subject header in a specific widget is... Very unlikely. What's invisible to the eye in the UI seriously isn't invisible to code logic. This appears to be a client *rendering*, displaying bug. Not to be confused with an actual empty header (which isn't the same as a missing header either) to filter on. Even though this most likely is a TB bug, it would be interesting to have a look at these headers. If possible, the raw one, prior to your SA header munging, err, rewriting option. OK I did it - and this one is really, really cool!!! Thunderbird is barfing when it gets TWO "Subject:" lines in the e-mail message. SA processes it and here's the result: From mau...@ionizer.nl Tue Feb 9 14:22:38 2010 Return-Path: Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com [71.87.206.218]) by mail.ipinc.net (8.13.8/8.13.8) with SMTP id o19MMY9W075540 for ; Tue, 9 Feb 2010 14:22:35 -0800 (PST) (envelope-from mau...@ionizer.nl) From: Bugarewicz To: newu...@ipinc.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_4B71E02E.A0717A8B" Date: Tue, 09 Feb 2010 17:22:37 -0500 Subject: *SPAM* Subject: Message-ID: <1265753645.mind...@nosbih.ba> X-Greylist: Delayed for 00:15:02 by milter-greylist-3.0 (mail.ipinc.net [65.75.192.11]); Tue, 09 Feb 2010 14:22:35 -0800 (PST) X-Spam-Flag: YES X-Spam-Status: Yes, score=11.7 required=4.1 tests=DYN_RDNS_AND_INLINE_IMAGE, EMPTY_MESSAGE,MISSING_SUBJECT,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_PBL,RCVD_IN_XBL, RDNS_DYNAMIC,SPF_NEUTRAL,TVD_SPACE_RATIO autolearn=disabled version=3.2.3 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.ipinc.net Status: O X-Status: X-Keywords: X-UID: 25585826 Thunderbird only displays the SECOND subject line. Now, why the message that SA is creating is getting TWO Subject: lines is a different question. cat -v does not show any non-printable chars. Here's the original header from the SA attachment: =_4B71E02E.A0717A8B Content-Type: message/rfc822; x-spam-type=original Content-Description: original message before SpamAssassin Content-Disposition: attachment Content-Transfer-Encoding: 8bit X-Envelope-From: X-Envelope-To: Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com [71.87.206.218]) by mail.ipinc.net(8.13.8/8.13.8) with SMTP id o19MMY9W075540 Tue, 9 Feb 2010 14:22:34 -0800 (PST) (envelope-from From: Bugarewicz To: newu...@ipinc.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-0BCB4D94223158510682CA52847" Date: Tue, 09 Feb 2010 17:22:37 -0500 Subject: Message-ID: <1265753645.mind...@nosbih.ba> X-Greylist: Delayed for 00:15:02 by milter-greylist-3.0 (mail.ipinc.net [65.75.192.11]); Tue, 09 Feb 2010 14:22:35 -0800 (PST) This is a multi-part message in MIME format. ---0BCB4D94223158510682CA52847 Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit ---0BCB4D94223158510682CA52847 Content-Type: image/jpeg; name="mimosa.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDACgcHiMeGSgjISMtKygwPGRBPDc3PHtYXUlkkYCZ lo+AjIqgtObDoKrarYqMyP/L2u71m8H6/+b9//j/2wBDASstLTw1PHZBQXb4pYyl +Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj/wAAR CAEQAV8DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAECAwQFBgcICQoL/8QAtRAA . . . Ted
Re: Newest spammer trick - non-blank subject lines?
On Tue, 2010-02-09 at 14:31 -0800, jdow wrote: > From: "Ted Mittelstaedt" > Sent: Tuesday, 2010/February/09 13:50 > > > > dar...@chaosreigns.com wrote: > >> On 02/09, Ted Mittelstaedt wrote: > >>> Thunderbird. There must be a bug in T-bird that is tickled > >> > >> Submit a bug report against thunderbird. > >> > > > > I don't want to have to play wack-a-mole with every mail > > client out there. > > > > I can just imagine that bug report anyway: > > > > Dear t-bird maintainers: > > > > I am getting spams that have non-ASCII characters in the > > subject line and t-bird is displaying the entire subject line > > as a blank line. I really want to see what my spammer friends > > are putting in their subject lines, so could you please fix > > t-bird so that it displays the bogus characters that my spammer > > friends are putting in their spams to me? > > > > I'd stand a better chance of that bug being fixed if I > > DIDN'T report it!!! > > > > Ted > > Ted, you cannot expect any more help from them than you give to > expired accounts, you know. You MUST give them some data to work > with. Figure out what those characters are. I am betting it would > be a simple "cr/lf" pair or maybe even a simple "lf". But without > good knowledge of what it is how can the T'bird people fix it? > "Insufficient data" is as good a reason as "insufficient account." > Agreed. Have you looked at their bug tracker to see it its a known problem? If it is, adding a 'me too' comment should raise its urgency. If there's no matching bug report, howinhell can you expect them to know there's something that needs fixing? If their bug tracker accepts attachments, attach the whole message. Otherwise, stuff the Subkect: line through 'od' and send them the output. Re wack_a_mole: I think you'll find the major MUAs have already woken up: non-ASCII doesn't disturb Evolution, the only MUA I use. Besides, I have the distinct impression that FireFox occupies most of Mozilla's attention and TB is definitely sucking on the hind teat. Martin
Re: Newest spammer trick - non-blank subject lines?
On Tue, 2010-02-09 at 14:56 -0800, Ted Mittelstaedt wrote: > Karsten Bräckelmann wrote: > > Even though this most likely is a TB bug, it would be interesting to > > have a look at these headers. If possible, the raw one, prior to your SA > > header munging, err, rewriting option. > > OK I did it - and this one is really, really cool!!! > > Thunderbird is barfing when it gets TWO "Subject:" lines in the e-mail > message. > > SA processes it and here's the result: [...] > Date: Tue, 09 Feb 2010 17:22:37 -0500 > Subject: *SPAM* > Subject: The second one does not have a space (or tab) after the colon. An artifact of copy-n-paste, or the same with the raw message? > Thunderbird only displays the SECOND subject line. > > Now, why the message that SA is creating is getting TWO Subject: lines > is a different question. > > cat -v does not show any non-printable chars. > > Here's the original header from the SA attachment: [...] > Date: Tue, 09 Feb 2010 17:22:37 -0500 > Subject: Single Subject header. No white-space here either. Again, copy-n-paste? What about the RAW, incoming mail, as fed into SA? No white-space there either? Any monkey business in the original header? This might after all turn out to be a SA header re-write bug. :( -- char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
On 09/02/2010 22:56, Ted Mittelstaedt wrote: I sometimes send email without adding a Subject line. I guess that makes me "moronic" in your eyes. Oh well. > OK I did it - and this one is really, really cool!!! Not really. > SA processes it and here's the result: > > > From mau...@ionizer.nl Tue Feb 9 14:22:38 2010 > Return-Path: > Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com > [71.87.206.218]) > by mail.ipinc.net (8.13.8/8.13.8) with SMTP id o19MMY9W075540 > for ; Tue, 9 Feb 2010 14:22:35 -0800 (PST) > (envelope-from mau...@ionizer.nl) > From: Bugarewicz > To: newu...@ipinc.net > MIME-Version: 1.0 > Content-Type: multipart/mixed; boundary="--=_4B71E02E.A0717A8B" > Date: Tue, 09 Feb 2010 17:22:37 -0500 > Subject: *SPAM* > Subject: > Thunderbird only displays the SECOND subject line. So Thunderbird displays the last Subject line header it comes across. Is that incorrect behaviour for an MUA? Is it valid for an email to have more than one Subject line? Bring it up with Mozilla. > Now, why the message that SA is creating is getting TWO Subject: lines > is a different question. > > cat -v does not show any non-printable chars. Try saving it to disk and uploading it using the file upload method to spamalyser.com. It might show characters that you can't see. > Here's the original header from the SA attachment: > Subject: So that's just a blank subject line? Using SpamAssassin 3.3 here, if I run this command: echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin I end up with a single Subject line of: Subject: *SPAM* And no additional empty subject line. That's how it should work. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Karsten Bräckelmann wrote: On Tue, 2010-02-09 at 14:56 -0800, Ted Mittelstaedt wrote: Karsten Bräckelmann wrote: Even though this most likely is a TB bug, it would be interesting to have a look at these headers. If possible, the raw one, prior to your SA header munging, err, rewriting option. OK I did it - and this one is really, really cool!!! Thunderbird is barfing when it gets TWO "Subject:" lines in the e-mail message. SA processes it and here's the result: [...] Date: Tue, 09 Feb 2010 17:22:37 -0500 Subject: *SPAM* Subject: The second one does not have a space (or tab) after the colon. An artifact of copy-n-paste, or the same with the raw message? if I load it up in vi then vi claims there is a single blank space after the colon. Thunderbird only displays the SECOND subject line. Now, why the message that SA is creating is getting TWO Subject: lines is a different question. cat -v does not show any non-printable chars. Here's the original header from the SA attachment: [...] Date: Tue, 09 Feb 2010 17:22:37 -0500 Subject: Single Subject header. No white-space here either. Again, copy-n-paste? No. once more, vi claims there is a single blank space after the colon What about the RAW, incoming mail, as fed into SA? No white-space there either? Any monkey business in the original header? I don't have that. All mail that comes in to here goes through sa-milter. However, I telnetted into port 25 and just typed in a test message. When I used "Subject:" WITHOUT a trailing space after the colon, the resulting message in my inbox - with SA headers that of course don't say the message is spam - DOES HAVE a single trailing space after the colon. It DOES NOT have 2 "Subject: lines, however. This might after all turn out to be a SA header re-write bug. :( I suspect it is. I also tried this test on another mailserver we have here that's running a similar setup EXCEPT for SA - and it DOES NOT have the trailing space after the Subject: So clearly SA is adding that trailing space. I'm not sure, though, that the addition of the trailing space in the Subject: line has any relevance to the duplicated Subject line. Ted
Re: Newest spammer trick - non-blank subject lines?
Mike Cardwell wrote: On 09/02/2010 22:56, Ted Mittelstaedt wrote: I sometimes send email without adding a Subject line. I guess that makes me "moronic" in your eyes. Oh well. OK I did it - and this one is really, really cool!!! Not really. SA processes it and here's the result: From mau...@ionizer.nl Tue Feb 9 14:22:38 2010 Return-Path: Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com [71.87.206.218]) by mail.ipinc.net (8.13.8/8.13.8) with SMTP id o19MMY9W075540 for ; Tue, 9 Feb 2010 14:22:35 -0800 (PST) (envelope-from mau...@ionizer.nl) From: Bugarewicz To: newu...@ipinc.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_4B71E02E.A0717A8B" Date: Tue, 09 Feb 2010 17:22:37 -0500 Subject: *SPAM* Subject: Thunderbird only displays the SECOND subject line. So Thunderbird displays the last Subject line header it comes across. Is that incorrect behaviour for an MUA? I think it is. Setting aside the question of whether they are supposed to be there or not, the purpose of an MUA is to make it easier for the user to interact with a mail message. Multiple Subject: lines can contain multiple amounts of information, and only displaying the last Subject line is denying the user information that they are supposed to be able to see see. A deeper question is do all parts of t-bird treat this equally. If the filtering in t-bird reacts to both Subject line contents then this definitely is a bug. A user might have a filter saying "delete all mail with viagrera in its subject line except mail that has "fred" in it's subject line. The spammer sends a message with the first subject line having viagrera in it, the second subject line having fred in it, and the message is not deleted - but the display only shows viagrea. Is it valid for an email to have more than one Subject line? I do not think this defined anywhere. But I won't swear to it. I think it's not particularly valid, however because the results are undefined. > Bring it up with Mozilla. Since this is a SA bug I think I will file it with Mozilla just to have it in the database, but I would only argue for internal consistency in t-bird. Now, why the message that SA is creating is getting TWO Subject: lines is a different question. cat -v does not show any non-printable chars. Try saving it to disk and uploading it using the file upload method to spamalyser.com. It might show characters that you can't see. To determine this I tailed it from the mail file then cat -v'ed it. this is on the actual UNIX server the mailbox is on. The mailbox is in mbox format. If you understand how cat -v works you will understand that there are no chars I can't see. I can try uploading to spamalyser but this is after SA has processed the message, so the internal structure of the message has been altered already and whatever condition caused the bug is probably gone. I need the raw message. Here's the original header from the SA attachment: Subject: So that's just a blank subject line? Using SpamAssassin 3.3 here, if I run this command: echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin I end up with a single Subject line of: Subject: *SPAM* And no additional empty subject line. That's how it should work. And that is how it works here, too, when the normal blank-subject-line spam comes in. Something is different with these spams that is causing the SA parser to duplicate the Subject line. At this point I am up against a wall. For starters this is an old ver of sa, old sendmail, etc. This server is scheduled for re-gen soon and there's no point in filing a bug on the old code. I will continue to observe and once the server is re-gened then if it keeps happening then I'll look into it further. I'll probably have to run the server for a few hours with SA turned off to get the raw spam, not something that is going to be very popular. Ted
Re: Newest spammer trick - non-blank subject lines?
On Tue, 2010-02-09 at 15:44 -0800, Ted Mittelstaedt wrote: > if I load it up in vi then vi claims there is a single blank > space after the colon. > It would be better to use od or beav rather than vi - both use unambiguous notation for non-printable bytes. beav (if you have it) will show you exactly what's there in a scrolling screen. So will "od -c file" if you pipe it through less. Martin
Re: Newest spammer trick - non-blank subject lines?
On 10/02/2010 00:04, Ted Mittelstaedt wrote: >>> Thunderbird only displays the SECOND subject line. >> >> So Thunderbird displays the last Subject line header it comes across. Is >> that incorrect behaviour for an MUA? > > I think it is. Setting aside the question of whether they are supposed > to be there or not, the purpose of an MUA is to make it easier for > the user to interact with a mail message. Multiple Subject: lines > can contain multiple amounts of information, and only displaying the > last Subject line is denying the user information that they are > supposed to be able to see see. > > A deeper question is do all parts of t-bird treat this equally. If > the filtering in t-bird reacts to both Subject line contents then > this definitely is a bug. A user might have a filter saying > "delete all mail with viagrera in its subject line except mail > that has "fred" in it's subject line. The spammer sends a message > with the first subject line having viagrera in it, the second > subject line having fred in it, and the message is not deleted - but > the display only shows viagrea. You could probably have tested that yourself in the time it took you to write that paragraph. >> Is it valid for an email to have >> more than one Subject line? > > I do not think this defined anywhere. But I won't swear to it. I > think it's not particularly valid, however because the results are > undefined. Did you check? I would bet that it is defined... I just took a quick gander at rfc2822 and it states: "No multiple occurrences of fields (except resent and received).*" There might be other RFCs involved, but it looks to me from that as though it's only valid for an email to have one Subject header. It's understandable that an MUA might not display an invalidly formatted email correctly. >> Bring it up with Mozilla. >> > > Since this is a SA bug I think I will file it with Mozilla just > to have it in the database, but I would only argue for internal > consistency in t-bird. You've no reason to believe there is any internal inconsistency with regards to how Thunderbird treats Subject lines. And if it's true that it's not valid for an email to have more than one Subject line then this is not a Thunderbird bug, but still something that they may or may not wish to workaround. > At this point I am up against a wall. For starters this is an old ver > of sa, old sendmail, etc. This server is scheduled for re-gen soon and > there's no point in filing a bug on the old code. I will continue to > observe and once the server is re-gened then if it keeps happening then > I'll look into it further. I'll probably have to run the server for a > few hours with SA turned off to get the raw spam, not something that is > going to be very popular. Alternatively, configure your MTA to deliver an unmodified second copy of all incoming email to a separate maildir. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Quoting jdow : From: Sent: Tuesday, 2010/February/09 13:35 On 02/09, Ted Mittelstaedt wrote: Thunderbird. There must be a bug in T-bird that is tickled Submit a bug report against thunderbird. I seem to remember "way back when" that a cr/lf pair in the subject line could result in strange things being displayed in the Outlook Express subject line. If T'bird scrolls the subject in that case you'd get the effect he's talking about. I'm guessing that it's nothing more interesting than a bunch of backspaces. If so, it's a *really* old trick. Terry
Re: Newest spammer trick - non-blank subject lines?
Ted Mittelstaedt wrote on Tue, 09 Feb 2010 12:58:01 -0800: > Our SA installation > is correctly tagging this as spam and sending it forward > to the user. Well, the usual procedure (*) is to add headers that identify the message as spam and maybe even show the score, so users can have the mail client file it to junk. I would consider adding "Spam" in the subject as a courtesy. You do not have control over the subject at all, it could even come from another system and be already "tagged" as spam there. However, you have control over the headers you add yourself and there's where the music should play. (*) I personally think that it's a waste to deliver all these messages, anyway. We put all messages over a certain score in quarantine and there's almost never a need to release one. I was about to ask about the message, but I just see that you posted it now. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: Newest spammer trick - non-blank subject lines?
Ted Mittelstaedt wrote on Tue, 09 Feb 2010 14:56:49 -0800: > MISSING_SUBJECT, > Now, why the message that SA is creating is getting TWO Subject: lines > is a different question. because SA thinks it's got no subject, so it adds one as it is instructed to tag the subject. Obviously, it wants to see at least a whitespace after the colon to accept it as a header. I did some research on this matter some time ago and if I remember correctly the latest RFCs (5322, maybe 2822) indeed require a whitespace while older RFCs (822) were not 100% clear about this. And it's good practice for clients to be forgiving in the interpretation of received messages. Thus, Thunderbird finds two subjects and displays the second one. I'm sure it's not the only program that does that. What SA probably should do is use the existing subject header, repair it with a whitespace and then tag it. To be sure that there are really no characters (you said there are some unprintable characters, but it rather looks like there are no characters at all) you should examine that message with a hex editor. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: Newest spammer trick - non-blank subject lines?
2010/2/9 Karsten Bräckelmann : > On Tue, 2010-02-09 at 14:27 -0800, jdow wrote: >> I have a thoroughly retired and partially disabled friend I try to >> help out, such as he'll let me. (I thought I was paranoid until I >> met him...) I am slowly breaking him of the thought pattern that >> opening Internet Explorer [...] > > Being paranoid. Using IE... *boggle* > > Nope, he is definitely not paranoid enough, if he never questioned the > part about needing IE. Let alone never ever read / heard anything about > security and main-stream mom-and-pap computer usage. > > Come on, IE exploits have been all over the general news in this country > quite a few times. Uh, paranoia is not mitigated by ignorance. Remember the earlier description of her friend: retired and partially disabled. This probably means older and not nearly as educated as we are about computers, and set in his/her ways. This, augmented by scare stories in the mass media, probably contribute to the difficulty. If I had to guess, for this friend of hers, new == deeply suspicious Kurt
Re: Newest spammer trick - non-blank subject lines?
From: "Karsten Bräckelmann" Sent: Tuesday, 2010/February/09 14:40 On Tue, 2010-02-09 at 14:27 -0800, jdow wrote: I have a thoroughly retired and partially disabled friend I try to help out, such as he'll let me. (I thought I was paranoid until I met him...) I am slowly breaking him of the thought pattern that opening Internet Explorer [...] Being paranoid. Using IE... *boggle* Nope, he is definitely not paranoid enough, if he never questioned the part about needing IE. Let alone never ever read / heard anything about security and main-stream mom-and-pap computer usage. Come on, IE exploits have been all over the general news in this country quite a few times. Even with FireFox he calls THAT connecting to the Internet. And for the type of applications he wants his best bet is Windows, sadly enough. And, predictably, he's infected. He and I are paranoid different ways. I am rather careful about my browsing and my system's still clean. I got nailed ONCE so far - that's from being online since the 80s. That was during an install. I simply started over with a full format. Since then - negativum perspirium. And that is with using IE and (mostly) FireFox on my part. Safe browsing is the key. {^_-}
Re: Newest spammer trick - non-blank subject lines?
From: "Ted Mittelstaedt" Sent: Tuesday, 2010/February/09 14:56 Karsten Bräckelmann wrote: On Tue, 2010-02-09 at 12:58 -0800, Ted Mittelstaedt wrote: The problem is the mail client program, specifically Thunderbird. There must be a bug in T-bird that is tickled by these non-text characters because although the Subject line exists with ***SPAM*** in it if I look at the actual message in the mailbox with an editor, T-bird displays the subject line as a BLANK subject. As you said, this appears to be a thunderbird issue. Went there to report it? Now, why don't I just write a rule in T-bird that trashes mail that has a blank subject line, I hear you ask? Err, nope. :) Note that the Subject actually is NOT empty, as you said. And unless filtering in TB on (raw or decoded) headers is affected by the very same bug /displaying/ the Subject header in a specific widget is... Very unlikely. What's invisible to the eye in the UI seriously isn't invisible to code logic. This appears to be a client *rendering*, displaying bug. Not to be confused with an actual empty header (which isn't the same as a missing header either) to filter on. Even though this most likely is a TB bug, it would be interesting to have a look at these headers. If possible, the raw one, prior to your SA header munging, err, rewriting option. OK I did it - and this one is really, really cool!!! Thunderbird is barfing when it gets TWO "Subject:" lines in the e-mail message. SA processes it and here's the result: From mau...@ionizer.nl Tue Feb 9 14:22:38 2010 Return-Path: Received: from nqcek.charter.com (71-87-206-218.dhcp.kgpt.tn.charter.com [71.87.206.218]) by mail.ipinc.net (8.13.8/8.13.8) with SMTP id o19MMY9W075540 for ; Tue, 9 Feb 2010 14:22:35 -0800 (PST) (envelope-from mau...@ionizer.nl) From: Bugarewicz To: newu...@ipinc.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_4B71E02E.A0717A8B" Date: Tue, 09 Feb 2010 17:22:37 -0500 Subject: *SPAM* Subject: Message-ID: <1265753645.mind...@nosbih.ba> X-Greylist: Delayed for 00:15:02 by milter-greylist-3.0 (mail.ipinc.net [65.75.192.11]); Tue, 09 Feb 2010 14:22:35 -0800 (PST) X-Spam-Flag: YES X-Spam-Status: Yes, score=11.7 required=4.1 tests=DYN_RDNS_AND_INLINE_IMAGE, EMPTY_MESSAGE,MISSING_SUBJECT,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_PBL,RCVD_IN_XBL, RDNS_DYNAMIC,SPF_NEUTRAL,TVD_SPACE_RATIO autolearn=disabled version=3.2.3 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.ipinc.net Status: O X-Status: X-Keywords: X-UID: 25585826 Thunderbird only displays the SECOND subject line. Now, why the message that SA is creating is getting TWO Subject: lines is a different question. cat -v does not show any non-printable chars. Here's the original header from the SA attachment: I don't see a problem here with what got through the emails for that header here. I submit it's a bug in your setup, Ted. Empty subjects here end up looking quite normal here. ===8<--- To: undisclosed recipients:; Subject: *SPAM* 007.9 ** Date: Tue, 9 Feb 2010 02:11:22 -0800 (PST) Message-Id: <369.95984...@web82008.mail.mud.yahoo.com> ===8<--- I have SpamAssassin provide the markup. How do you generate your markup? {^_^}
Re: Newest spammer trick - non-blank subject lines?
From: "Ted Mittelstaedt" At this point I am up against a wall. For starters this is an old ver of sa, old sendmail, etc. This server is scheduled for re-gen soon and there's no point in filing a bug on the old code. I will continue to observe and once the server is re-gened then if it keeps happening then I'll look into it further. I'll probably have to run the server for a few hours with SA turned off to get the raw spam, not something that is going to be very popular. An old (really old) version of SA might show that problem. I seem to remember it being noted and fixed a long time ago. (2.3xish is when I started fiddling with this beastie.) You may be seriously stuck if you cannot upgrade. You might have to generate a special filter for your milter that looks for an empty second subject line and simply deletes it. {^_^}
Re: Newest spammer trick - non-blank subject lines?
On Tuesday 09 February 2010, Ted Mittelstaedt wrote: >Gene Heskett wrote: >> >> Put a valid subject line required into your TOS, mail it to everybody, & >> then do it a day later, bounce it at them if no subject line content. >> They will either jump ship in which case offer to hold the door, or come >> around and do it right in a day or so. > >I have doubts that the offenders can even read at all, let alone >read a TOS or even know what it is. We have customers >who call in for tech support and when I tell them to open their >web browser they don't know what I'm talking about. I swear to >God this is true, I'm not making a joke! Tell them you aren't really running a school, but there may be computer classes at the senior center, where they make fairly valiant efforts to teach old farts in my age category how to use that spanking new winders box they just bought at Wallies cuz their kids told them to. I think there is an enrollment fee involved for those classes though. >I got a call the other day from a customer who is a dialup >customer who was planning on buying one of those Atom-based >half-a-laptop netbooks and wanted to know how to put a modem on it - >and she was NOT planning on doing this because she was >traveling - she was planning on keeping her dialup as >her main Internet connection at home!! (don't even ask >what she is currently using, just imagine) And old 56k Zoom maybe? They were pretty good modems in their day. I keep one around just in case. >We've got calls in the past from customers who disconnected >service from us (went to some other DSL provider than us) >and wanted to know why their e-mail stopped working (and >expected us to fix it!) Most ISP's will fwd it to the new address, usually for 30 days while they sort that basket of rattlesnakes. Chuckle. Yup, I think I have one such in the neighborhood. Asked me a question about winderz a year or so back, with obviously no ability to grok the language, and about which I know just enough to reach for a linux dvd and fix it. I said, sorry, I don't even know how to turn a windows machine on. They probably think I must be some sort of a twit/arse, but hell, they thought that before they asked for free help. We had already tangled a couple of times because their cats would starve if we didn't feed ours 4x what she can eat a day, 3 or 4 times a day! Gets old, & then a scrap between our fixed pussy, and a froggy tom cost us $200 for stitches & antibiotics 6 weeks back. I have some traps, but apparently that one has seen the patterns, I've caught quite a few cats, but not the troublemaker. But then I am not much of a cat lover, having said on several occasions that it was a shame we had so many cats & so few good recipes... But in this house, I'm a definite minority. ;( -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: Why don't lawyers go to the beach? A: The cats keep trying to bury them.
Re: Newest spammer trick - non-blank subject lines?
On Tuesday 09 February 2010, Ted Mittelstaedt wrote: >dar...@chaosreigns.com wrote: >> On 02/09, Ted Mittelstaedt wrote: >>> Thunderbird. There must be a bug in T-bird that is tickled >> >> Submit a bug report against thunderbird. > >I don't want to have to play wack-a-mole with every mail >client out there. > >I can just imagine that bug report anyway: > >Dear t-bird maintainers: > > I am getting spams that have non-ASCII characters in the >subject line and t-bird is displaying the entire subject line >as a blank line. I really want to see what my spammer friends >are putting in their subject lines, so could you please fix >t-bird so that it displays the bogus characters that my spammer >friends are putting in their spams to me? > > I'd stand a better chance of that bug being fixed if I >DIDN'T report it!!! > >Ted > One thing I've noted Ted, is that if I have all the fonts for most of the worlds languages installed, some of that stuff then becomes visible. That of course doesn't mean I can read it, but all those pictograms from the oriental languages are sorta purtty. ;-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Don't go around saying the world owes you a living. The world owes you nothing. It was here first. -- Mark Twain
Re: Newest spammer trick - non-blank subject lines?
On Tuesday 09 February 2010, Mike Cardwell wrote: >On 09/02/2010 22:56, Ted Mittelstaedt wrote: > >I sometimes send email without adding a Subject line. I guess that makes >me "moronic" in your eyes. Oh well. Chuckle, so do I, entirely too often, Mike. But kmail checks before sending it, and if the Subject: line is blank, it calls it to my attention & offers me a chance to fix it. Saved my bum many a time. ;) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) All theoretical chemistry is really physics; and all theoretical chemists know it. -- Richard P. Feynman
Re: Newest spammer trick - non-blank subject lines?
Ted Mittelstaedt wrote: > Multiple Subject: lines can contain multiple amounts of information, > and only displaying the last Subject line is denying the user > information that they are supposed to be able to see see. Multiple Subject: lines are not allowed according to RFC5322 - only zero or one only. /Per Jessen, Zürich
Re: Newest spammer trick - non-blank subject lines?
On 10/02/2010 00:31, Kai Schaetzl wrote: Our SA installation is correctly tagging this as spam and sending it forward to the user. Well, the usual procedure (*) is to add headers that identify the message as spam and maybe even show the score, so users can have the mail client file it to junk. I would consider adding "Spam" in the subject as a courtesy. You do not have control over the subject at all, it could even come from another system and be already "tagged" as spam there. However, you have control over the headers you add yourself and there's where the music should play. (*) I personally think that it's a waste to deliver all these messages, anyway. We put all messages over a certain score in quarantine and there's almost never a need to release one. At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user, immediately marked as Seen and flagged as Junk. Email in "Junk E-Mail" folders is automatically deleted after a week. In the 5xx code, I also include a special URL which the sender will hopefully see if they read their NDR. They can then click that URL and fill in a captcha in order to release the email. Releasing the email removes it from the recipients Junk E-Mail folder, and places a copy in their INBOX. So... the sender gets notified if the message is filtered and if they're human they can "unclassify" it as such. While the recipient isn't bothered by Spam, however if they're expecting a message which doesn't arrive due to spam filtering, they know they can just peak in their "Junk E-Mail" folder and it will be there. Best of both Worlds. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
On 10/02/2010 00:31, Kai Schaetzl wrote: MISSING_SUBJECT, Now, why the message that SA is creating is getting TWO Subject: lines is a different question. because SA thinks it's got no subject, so it adds one as it is instructed to tag the subject. Obviously, it wants to see at least a whitespace after the colon to accept it as a header. I don't think so. At least, in my tests here, v3.3.0 doesn't. Both of these commands lead to SpamAssassin outputting a single "Subject: *SPAM*" header: echo -ne "Subject: \nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
On Tue, 2010-02-09 at 17:51 -0800, jdow wrote: > And for the type of applications he wants his best bet is Windows, > sadly enough. And, predictably, he's infected. He and I are paranoid > different ways. I am rather careful about my browsing and my system's > still clean. I got nailed ONCE so far - that's from being online since > the 80s. That was during an install. I simply started over with a full > format. Since then - negativum perspirium. And that is with using IE > and (mostly) FireFox on my part. Safe browsing is the key. > also a good anti-virus scanner with a current subscription and regular updates sitting behind a NAT firewall router with no port forwarding. I've been online since '90 and no infections until I stopped using 'doze in 2002. None since then either. Martin
Re: Newest spammer trick - non-blank subject lines?
On Wednesday February 10 2010 10:45:37 Mike Cardwell wrote: > On 10/02/2010 00:31, Kai Schaetzl wrote: > >> MISSING_SUBJECT, > >> > >> Now, why the message that SA is creating is getting TWO Subject: lines > >> is a different question. > > > > because SA thinks it's got no subject, so it adds one as it is instructed > > to tag the subject. Obviously, it wants to see at least a whitespace > > after the colon to accept it as a header. > > I don't think so. At least, in my tests here, v3.3.0 doesn't. Both of > these commands lead to SpamAssassin outputting a single "Subject: > *SPAM*" header: > > echo -ne "Subject: \nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin > echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin Indeed, the bug was fixed with v3.3.0 (Bug 6016). Kai Schaetzl wrote: > I did some research on this matter some > time ago and if I remember correctly the latest RFCs (5322, maybe 2822) > indeed require a whitespace while older RFCs (822) were not 100% clear > about this. This is incorrect. A space is not required after a colon. Both the RFC 5322 and RFC 2822 are perfectly clear on this. Ted Mittelstaedt wrote: >> So Thunderbird displays the last Subject line header it comes across. >> Is that incorrect behaviour for an MUA? > > I think it is. Setting aside the question of whether they are supposed > to be there or not, the purpose of an MUA is to make it easier for > the user to interact with a mail message. Multiple Subject: lines > can contain multiple amounts of information, and only displaying the > last Subject line is denying the user information that they are > supposed to be able to see see. The RFC 5322 (and RFC 2822) require that a Subject header field appears zero or one time. Multiple Subject header fields are not allowed. A MUA can do whatever it pleases with syntactically invalid mail messages: garbage-in, garbage-out. Mark
Re: Newest spammer trick - non-blank subject lines?
Martin Gregorie wrote: On Tue, 2010-02-09 at 15:44 -0800, Ted Mittelstaedt wrote: if I load it up in vi then vi claims there is a single blank space after the colon. It would be better to use od or beav rather than vi - both use unambiguous notation for non-printable bytes. beav (if you have it) will show you exactly what's there in a scrolling screen. So will "od -c file" if you pipe it through less. Apparently you missed my statement earlier that I already ran it through cat -v Ted
Re: Newest spammer trick - non-blank subject lines?
Mike Cardwell wrote: On 10/02/2010 00:04, Ted Mittelstaedt wrote: Thunderbird only displays the SECOND subject line. So Thunderbird displays the last Subject line header it comes across. Is that incorrect behaviour for an MUA? I think it is. Setting aside the question of whether they are supposed to be there or not, the purpose of an MUA is to make it easier for the user to interact with a mail message. Multiple Subject: lines can contain multiple amounts of information, and only displaying the last Subject line is denying the user information that they are supposed to be able to see see. A deeper question is do all parts of t-bird treat this equally. If the filtering in t-bird reacts to both Subject line contents then this definitely is a bug. A user might have a filter saying "delete all mail with viagrera in its subject line except mail that has "fred" in it's subject line. The spammer sends a message with the first subject line having viagrera in it, the second subject line having fred in it, and the message is not deleted - but the display only shows viagrea. You could probably have tested that yourself in the time it took you to write that paragraph. Yes but since this is a spamassassin mailing list, I doubt most users would be interested in a long discussion of problems with t-bird. If your a t-bird user who cares, you will investigate it. I don't, frankly. Once I saw that SA was producing the double "Subject: " line entries then it seems to me that further discussion on t-bird's behavior is not warranted, epically on this mailing list. Is it valid for an email to have more than one Subject line? I do not think this defined anywhere. But I won't swear to it. I think it's not particularly valid, however because the results are undefined. Did you check? I would bet that it is defined... I just took a quick gander at rfc2822 and it states: "No multiple occurrences of fields (except resent and received).*" There might be other RFCs involved, but it looks to me from that as though it's only valid for an email to have one Subject header. It's understandable that an MUA might not display an invalidly formatted email correctly. I'll repeat, it seems to me that further discussion on t-bird's behavior is not warranted, epically on this mailing list. Bring it up with Mozilla. Since this is a SA bug I think I will file it with Mozilla just to have it in the database, but I would only argue for internal consistency in t-bird. You've no reason to believe there is any internal inconsistency with regards to how Thunderbird treats Subject lines. And if it's true that it's not valid for an email to have more than one Subject line then this is not a Thunderbird bug, but still something that they may or may not wish to workaround. I'll repeat, it seems to me that further discussion on t-bird's behavior is not warranted, epically on this mailing list. Seriously! I know it's a fun diversion, but lets get back to the real issue. At this point I am up against a wall. For starters this is an old ver of sa, old sendmail, etc. This server is scheduled for re-gen soon and there's no point in filing a bug on the old code. I will continue to observe and once the server is re-gened then if it keeps happening then I'll look into it further. I'll probably have to run the server for a few hours with SA turned off to get the raw spam, not something that is going to be very popular. Alternatively, configure your MTA to deliver an unmodified second copy of all incoming email to a separate maildir. Yup. Ted
Re: Newest spammer trick - non-blank subject lines?
Kai Schaetzl wrote: Ted Mittelstaedt wrote on Tue, 09 Feb 2010 12:58:01 -0800: Our SA installation is correctly tagging this as spam and sending it forward to the user. Well, the usual procedure (*) is to add headers that identify the message as spam and maybe even show the score, so users can have the mail client file it to junk. I would consider adding "Spam" in the subject as a courtesy. You do not have control over the subject at all, it could even come from another system and be already "tagged" as spam there. However, you have control over the headers you add yourself and there's where the music should play. In an ideal world. (*) I personally think that it's a waste to deliver all these messages, anyway. We put all messages over a certain score in quarantine and there's almost never a need to release one. That would mean even more expensive support labor having to be spent on e-mail since now we would have to putz around with a quarantine. One of our ISP customers does this with mailscanner, (we built his server, BTW) but they have a lot fewer end user customers. With us, we have a great many very uneducated/inexperienced/untrained users and subject line munging is about the most they can handle. I'd estimate only about 2% of them actually use the filtering in their MUA's and 1% of them avail themselves of the procmail-based filtering on the server. Even less than that avail themselves of the PHP-based interface for SA that I put onto the server that allows them to TURN OFF the subject line munging. There's no question that subject-line munging is inelegant and a perversion of the Correct Way to do e-mail. But it's necessary when your dealing with mail users who you have to hit over the head with a 2 x 4 to get them to notice something. Ted I was about to ask about the message, but I just see that you posted it now. Kai
Re: Newest spammer trick - non-blank subject lines?
Kai Schaetzl wrote: Ted Mittelstaedt wrote on Tue, 09 Feb 2010 14:56:49 -0800: MISSING_SUBJECT, Now, why the message that SA is creating is getting TWO Subject: lines is a different question. because SA thinks it's got no subject, so it adds one as it is instructed to tag the subject. Obviously, it wants to see at least a whitespace after the colon to accept it as a header. Ah, I see, I see. The caveat of course is that the message must be spam, since a regular non-spam message isn't going to trigger the subject tagging. Such as the test message I typed into port 25. Ted I did some research on this matter some time ago and if I remember correctly the latest RFCs (5322, maybe 2822) indeed require a whitespace while older RFCs (822) were not 100% clear about this. And it's good practice for clients to be forgiving in the interpretation of received messages. Thus, Thunderbird finds two subjects and displays the second one. I'm sure it's not the only program that does that. What SA probably should do is use the existing subject header, repair it with a whitespace and then tag it. To be sure that there are really no characters (you said there are some unprintable characters, but it rather looks like there are no characters at all) you should examine that message with a hex editor. Kai
Re: Newest spammer trick - non-blank subject lines?
Mark Martinec wrote: On Wednesday February 10 2010 10:45:37 Mike Cardwell wrote: On 10/02/2010 00:31, Kai Schaetzl wrote: MISSING_SUBJECT, Now, why the message that SA is creating is getting TWO Subject: lines is a different question. because SA thinks it's got no subject, so it adds one as it is instructed to tag the subject. Obviously, it wants to see at least a whitespace after the colon to accept it as a header. I don't think so. At least, in my tests here, v3.3.0 doesn't. Both of these commands lead to SpamAssassin outputting a single "Subject: *SPAM*" header: echo -ne "Subject: \nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin echo -ne "Subject:\nX-Foo: bar\n\nviagra CIALIS\n"|spamassassin Indeed, the bug was fixed with v3.3.0 (Bug 6016). Kai Schaetzl wrote: I did some research on this matter some time ago and if I remember correctly the latest RFCs (5322, maybe 2822) indeed require a whitespace while older RFCs (822) were not 100% clear about this. This is incorrect. A space is not required after a colon. Both the RFC 5322 and RFC 2822 are perfectly clear on this. Ted Mittelstaedt wrote: So Thunderbird displays the last Subject line header it comes across. Is that incorrect behaviour for an MUA? I think it is. Setting aside the question of whether they are supposed to be there or not, the purpose of an MUA is to make it easier for the user to interact with a mail message. Multiple Subject: lines can contain multiple amounts of information, and only displaying the last Subject line is denying the user information that they are supposed to be able to see see. The RFC 5322 (and RFC 2822) require that a Subject header field appears zero or one time. Multiple Subject header fields are not allowed. A MUA can do whatever it pleases with syntactically invalid mail messages: garbage-in, garbage-out. Mark The intent of the people who wrote the MUA under question was to assist users to read mail, it was NOT to advance an agenda on the Internet. If you want to use MUA's which attempt to enforce agendas then there are plenty of those out there - you can start with Outlook. I would assume that by definition any MUA written to help users has a flaw in it if it does something that makes it harder for the user to read mail. That is why I consider this incorrect behavior. An MUA that's goal was to assist should at least make an effort to notify the user that there's a problem with the message. And as a matter of fact, Thunderbird DOES do this quite a lot with other types of errors on e-mail messages. Ted
Re: Newest spammer trick - non-blank subject lines?
On 10-Feb-2010, at 02:42, Mike Cardwell wrote: > > At SMTP time I return a 5xx code during the "DATA" phase for messages > classified as Spam. However, I also deliver the message into a read only > "Junk E-Mail" folder for the user, This is just wrong. Either accept the message, or reject the message. Rejecting the message while secretly accepting it is just completely wrong. Let's say your filter catches a legitimate message to u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying the message was spammy and didn't go through, so he goes to his gmail account and sends it again, hoping for better results. This time it goes through. Now your user has two emails, one tagged spam and one not. One is in quarantine, and one isn't. How have you helped your user? As for your modified 'prove-you-love-me' scheme of quarantines and releases and web urls, that would look very spammish to me, and I wouldn't follow that link, even if I did see it which I probably wouldn't because my SA would almost certainly classify that sort of NDN as spam... I've never clicked on a prove-you-love-me link, and I'm not about to start now. And when asked by my customers I recommend they don't click them either. As I point out, this falls under the class of 'unknown URL from unknown source' and that's always a risk. -- 'How do you know I'm mad?' said Alice 'You must be' said the Cat 'or you wouldn't have come here.'
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 08:27, LuKreme wrote: At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user, This is just wrong. Either accept the message, or reject the message. Rejecting the message while secretly accepting it is just completely wrong. "This is just wrong" is not a very good argument for your case. Hopefully you'll do better below. Let's say your filter catches a legitimate message to u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying the message was spammy and didn't go through, so he goes to his gmail account and sends it again, hoping for better results. This time it goes through. Bob could also have just clicked the link in the NDR. Now your user has two emails, one tagged spam and one not. One is in quarantine, and one isn't. How have you helped your user? You've described one scenario out of many. One where my system wouldn't provide any additional benefit, but at the same time it doesn't make either the sender or the recipient worse off. You didn't even describe a scenario which is particularly common. Here's another scenario. One which is definitely more common: A user goes to some website and signs up. They're sent an automated confirmation email. The mail server classifies the incoming email as spam and rejects it. In my system, the user is expecting a confirmation email and doesn't receive it so checks their Junk E-Mail folder and finds it there. In a "normal" system which just 5xx's, the user has to wait longer just to make sure that the email wasn't delayed and then has to jump through loops to find an alternative means of confirming the signup. A couple of days ago I bought a lottery ticket online for the EuroMillions lottery this Friday. The order email got a score of 5.5. Mainly because the "HK_LOTTO" rule fired which applied a score of 3.6. I noticed that I never received a confirmation email, so I looked in my Junk E-Mail folder and there it was. Highly useful. As for your modified 'prove-you-love-me' scheme of quarantines and releases and web urls, that would look very spammish to me, and I wouldn't follow that link, even if I did see it which I probably wouldn't because my SA would almost certainly classify that sort of NDN as spam... Your SpamAssassin installation would, "almost certainly," classify an NDR, which your *own system* generated, as spam? I rarely use "LOL", but in this case I think it's appropriate... LOL. I've never clicked on a prove-you-love-me link, and I'm not about to start now. And when asked by my customers I recommend they don't click them either. As I point out, this falls under the class of 'unknown URL from unknown source' and that's always a risk. Providing the URL *might* provide benefit for *some* people. Again, the existance of the URL doesn't make either the sender or the recipient worse off in any way. You've failed to convince me. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
On Don, 2010-02-11 at 10:38 +, Mike Cardwell wrote: > On 11/02/2010 08:27, LuKreme wrote: > >> At SMTP time I return a 5xx code during the "DATA" phase for messages > >> classified as Spam. However, I also deliver the message into a read only > >> "Junk E-Mail" folder for the user, > > > > This is just wrong. Either accept the message, or reject the > message. Rejecting the message while secretly accepting it is just > completely wrong. [...] > > Let's say your filter catches a legitimate message to > u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying > the message was spammy and didn't go through, so he goes to his gmail > account and sends it again, hoping for better results. This time it > goes through. > > Bob could also have just clicked the link in the NDR. Some people - e.g. /me - do not try to pass Turing tests. Obviously you are not interested in my mails anyway Apart from that why should I decode captchas from some random site? After all, they could come from a third site so that people solve them to the the other can log automatically into the third one ... Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 11:26, Bernd Petrovitsch wrote: At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user, This is just wrong. Either accept the message, or reject the message. Rejecting the message while secretly accepting it is just completely wrong. [...] Let's say your filter catches a legitimate message to u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying the message was spammy and didn't go through, so he goes to his gmail account and sends it again, hoping for better results. This time it goes through. Bob could also have just clicked the link in the NDR. Some people - e.g. /me - do not try to pass Turing tests. Obviously you are not interested in my mails anyway If you email somebody and the spam filtering rejects the message, you assume they don't want your mail and don't bother trying to contact them again? Not even if it's obviously beneficial for you to do so? Apart from that why should I decode captchas from some random site? After all, they could come from a third site so that people solve them to the the other can log automatically into the third one ... It's not some random email from a "random site". It's an NDR to an email that you yourself sent. Let me explain this in simple terms. Normal behaviour: Spam filtering causes a 5xx rejection. You get an NDR. You either contact the user some other way or not at all. Behaviour on my system: Spam filtering causes a 5xx rejection. You get an NDR. You either contact the user some other way or not at all. But ... the recipient can still access the email if it's something they were expecting, *and* if the sender still wants to contact the recipient they now have an *extra* option to make their life easier - they can click a URL and fill in a captcha. So ... my system provides 2 extra little features which makes some senders and some recipients lives more easy. Neither sender nor recipient would benefit from me removing those features from my system. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
On Thu, 11 Feb 2010 12:26:03 +0100 Bernd Petrovitsch wrote: > On Don, 2010-02-11 at 10:38 +, Mike Cardwell wrote: > > On 11/02/2010 08:27, LuKreme wrote: > > >> At SMTP time I return a 5xx code during the "DATA" phase for > > >> messages classified as Spam. However, I also deliver the message > > >> into a read only "Junk E-Mail" folder for the user, > > > > > > This is just wrong. Either accept the message, or reject the > > message. Rejecting the message while secretly accepting it is just > > completely wrong. > [...] > > > Let's say your filter catches a legitimate message to > > u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying > > the message was spammy and didn't go through, so he goes to his > > gmail account and sends it again, hoping for better results. This > > time it goes through. > > > > Bob could also have just clicked the link in the NDR. > Some people - e.g. /me - do not try to pass Turing tests. Obviously > you are not interested in my mails anyway But it's only applied to mail classified as spam, and unlike CR it generates no additional backscatter. > Apart from that why should I decode captchas from some random site? > After all, they could come from a third site so that people solve them > to the the other can log automatically into the third one ... Because the NDR is generated by *your* mail server in response to *your* email. I think it's rather a good idea.
Re: Newest spammer trick - non-blank subject lines?
RW wrote: >> > >> > Bob could also have just clicked the link in the NDR. >> Some people - e.g. /me - do not try to pass Turing tests. Obviously >> you are not interested in my mails anyway > > But it's only applied to mail classified as spam, and unlike CR it > generates no additional backscatter. > >> Apart from that why should I decode captchas from some random site? >> After all, they could come from a third site so that people solve >> them to the the other can log automatically into the third one ... > > Because the NDR is generated by *your* mail server in response to > *your* email. > > I think it's rather a good idea. I agree, it's not bad at all. The only minor issue I see is that a lot of people don't understand NDRs (or can't be bothered to try to). /Per Jessen, Zürich
Re: Newest spammer trick - non-blank subject lines?
On 2/11/2010 8:08 AM, Per Jessen wrote: > The only minor issue I see is that a lot > of people don't understand NDRs (or can't be bothered to try to). True. Also, a lot of mail relays mangle NDR's beyond usability.
Re: Newest spammer trick - non-blank subject lines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Cardwell wrote: > At SMTP time I return a 5xx code during the "DATA" phase for messages > classified as Spam. However, I also deliver the message into a read only What kind of mail load do you service? It takes a significant amount of time for spamassassin to process a message, and holding the connection open during that time can easily allow for a DoS by flooding your mail server with connections. This is why amavisd* variants always accept the mail and then process - it helps keep the incoming smtpd process from jamming. - -- David Morton Morton Software & Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLdCcMUy30ODPkzl0RAvn8AKDGCHegd5F+GxMT0+6yTWBV0qtDZQCeMMXg oLBV5aIBYMqx9wH5VACx57s= =/4HM -END PGP SIGNATURE-
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 15:49, David Morton wrote: At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only What kind of mail load do you service? On this system, not much. On the scale of about 6,000 messages a day. It takes a significant amount of time for spamassassin to process a message, and holding the connection open during that time can easily allow for a DoS by flooding your mail server with connections. This is why amavisd* variants always accept the mail and then process - it helps keep the incoming smtpd process from jamming. SpamAssassin seems to average about 5 seconds per message here. I have other light weight checks which take place before spamassassin as well. Even if SpamAssassin isn't used during SMTP, there's nothing stopping somebody who wants to DOS you from just setting their DOS tool to hold open connections and spend lots of time waiting between issuing SMTP commands... It could even go straight through to the DATA phase and send a 10MB email at a speed of 1 byte per second. I don't think moving SpamAssassin to after the SMTP transaction has finished would help prevent someone from performing a DOS. If you *can* do SMTP time spam scanning, then that's the best place for it. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
On Thu, Feb 11, 2010 at 09:49:32AM -0600, David Morton wrote: > > This is why amavisd* variants always accept the mail and then process You are wrong: amavisd-milter works fine here. Pre-queue filtering is generally well understood with it's pros and cons, no point taking it up here.
Re: Newest spammer trick - non-blank subject lines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Cardwell wrote: > On this system, not much. On the scale of about 6,000 messages a day. Very light duty then. :) > Even if SpamAssassin isn't used during SMTP, there's nothing stopping > somebody who wants to DOS you from just setting their DOS tool to hold > open connections and spend lots of time waiting between issuing SMTP > commands... It could even go straight through to the DATA phase and send > a 10MB email at a speed of 1 byte per second. True, though most MTA's have some defenses built for this, but waiting to scan for spam by nature takes time, and so these defenses must be lowered to allow it. > I don't think moving SpamAssassin to after the SMTP transaction has > finished would help prevent someone from performing a DOS. > > If you *can* do SMTP time spam scanning, then that's the best place for it. - From experience with larger ISP settings, and some large enterprise settings, it doesn't take a malicious attempt - normal traffic can be bursty and bring a system to its knees. From a practical standpoint, it's just a whole lot easier to have the front line smtpd servers swallow the email as fast as possible (some quick rbl or greylisting aside) and then you can process in batches behind the lines. It's scary when email starts piling up faster than all your scanners can chew... but most admins I've met would prefer that to other mail servers getting connection errors and possible bouncing or sending problem reports back to the sender. - -- David Morton Morton Software & Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLdC8CUy30ODPkzl0RAlSnAJ4tjvtTkZnfTSt3xyDMsMx/A0565wCfb1GT qgz12JDzpApjgoLmcN208e8= =XivG -END PGP SIGNATURE-
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 16:23, David Morton wrote: On this system, not much. On the scale of about 6,000 messages a day. Very light duty then. :) Even if SpamAssassin isn't used during SMTP, there's nothing stopping somebody who wants to DOS you from just setting their DOS tool to hold open connections and spend lots of time waiting between issuing SMTP commands... It could even go straight through to the DATA phase and send a 10MB email at a speed of 1 byte per second. True, though most MTA's have some defenses built for this, but waiting to scan for spam by nature takes time, and so these defenses must be lowered to allow it. I don't think moving SpamAssassin to after the SMTP transaction has finished would help prevent someone from performing a DOS. If you *can* do SMTP time spam scanning, then that's the best place for it. - From experience with larger ISP settings, and some large enterprise settings, it doesn't take a malicious attempt - normal traffic can be bursty and bring a system to its knees. From a practical standpoint, it's just a whole lot easier to have the front line smtpd servers swallow the email as fast as possible (some quick rbl or greylisting aside) and then you can process in batches behind the lines. It's scary when email starts piling up faster than all your scanners can chew... but most admins I've met would prefer that to other mail servers getting connection errors and possible bouncing or sending problem reports back to the sender. I must admit, I have seen this several times before. Looking at the logs on our servers at work we've rejected on average 151 emails per minute for the past week. We do SpamAssassin scanning during SMTP here as well and the vast majority of the time it's fine, but it does cause problems during spikes. To me this just says that we don't have enough servers to deal with the spikes, but it happens infrequently enough that it's not worth investing. I still think SMTP time scanning is both practical and desirable. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
On Don, 2010-02-11 at 11:52 +, Mike Cardwell wrote: [...] > Let me explain this in simple terms. > > Normal behaviour: > > Spam filtering causes a 5xx rejection. You get an NDR. You either > contact the user some other way or not at all. Spam filtering rejects valid non-spam because it mis-identified it as "spam". > Behaviour on my system: > > Spam filtering causes a 5xx rejection. You get an NDR. You either > contact the user some other way or not at all. But ... the recipient can Spam filtering rejects valid non-spam because it mis-identified it as "spam". Now *I* have to do something to work around *Your* buggy/screwed spamcheck. You just have to hope that I´m really, really that interested to my mail through. If it's an answer per PM to e.g. typical ML mails (like this here), you would loose. > still access the email if it's something they were expecting, *and* if > the sender still wants to contact the recipient they now have an *extra* > option to make their life easier - they can click a URL and fill in a > captcha. > > So ... my system provides 2 extra little features which makes some > senders and some recipients lives more easy. No, you are pushing effort from your side out to others. If you want to do something for the (valid) sender, fix the FP rate by changing whatever it needs so that my on-spam mail gets through. > Neither sender nor recipient would benefit from me removing those > features from my system. Of course anyone can do as they think it´s best. But that doesn´t imply that other think the same. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 17:08, Bernd Petrovitsch wrote: >> Let me explain this in simple terms. >> >> Normal behaviour: >> >> Spam filtering causes a 5xx rejection. You get an NDR. You either >> contact the user some other way or not at all. > Spam filtering rejects valid non-spam because it mis-identified it as > "spam". Yes. It's called a "false positive". >> Behaviour on my system: >> >> Spam filtering causes a 5xx rejection. You get an NDR. You either >> contact the user some other way or not at all. But ... the recipient can > Spam filtering rejects valid non-spam because it mis-identified it as > "spam". Now *I* have to do something to work around *Your* buggy/screwed > spamcheck. No different to a normal situation where the features I've described aren't in place. > You just have to hope that I´m really, really that interested to my mail > through. If it's an answer per PM to e.g. typical ML mails (like this > here), you would loose. No different to a normal situation where the features I've described aren't in place. >> still access the email if it's something they were expecting, *and* if >> the sender still wants to contact the recipient they now have an *extra* >> option to make their life easier - they can click a URL and fill in a >> captcha. >> >> So ... my system provides 2 extra little features which makes some >> senders and some recipients lives more easy. > No, you are pushing effort from your side out to others. If you want to > do something for the (valid) sender, fix the FP rate by changing > whatever it needs so that my on-spam mail gets through. Ridiculous claim. In a normal situation the effort relies on the sender to get their mail through after a false positive occurs, or it wont get through at all. With the 2 features I described, the sender is provided with an extra simple option to get the mail through, and the recipient has also been provided with an option to get the mail through. >> Neither sender nor recipient would benefit from me removing those >> features from my system. > Of course anyone can do as they think it´s best. But that doesn´t imply > that other think the same. I want you to describe a scenario where the sender or recipient are actually worse off because of the particular two features I've described. You've failed to even attempt that so far. I know this system works well because I've been using it for a long time. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Mike Cardwell wrote: On 11/02/2010 17:08, Bernd Petrovitsch wrote: Let me explain this in simple terms. Normal behaviour: Spam filtering causes a 5xx rejection. You get an NDR. You either contact the user some other way or not at all. Spam filtering rejects valid non-spam because it mis-identified it as "spam". Yes. It's called a "false positive". Behaviour on my system: Spam filtering causes a 5xx rejection. You get an NDR. You either contact the user some other way or not at all. But ... the recipient can Spam filtering rejects valid non-spam because it mis-identified it as "spam". Now *I* have to do something to work around *Your* buggy/screwed spamcheck. No different to a normal situation where the features I've described aren't in place. You just have to hope that I´m really, really that interested to my mail through. If it's an answer per PM to e.g. typical ML mails (like this here), you would loose. No different to a normal situation where the features I've described aren't in place. still access the email if it's something they were expecting, *and* if the sender still wants to contact the recipient they now have an *extra* option to make their life easier - they can click a URL and fill in a captcha. So ... my system provides 2 extra little features which makes some senders and some recipients lives more easy. No, you are pushing effort from your side out to others. If you want to do something for the (valid) sender, fix the FP rate by changing whatever it needs so that my on-spam mail gets through. Ridiculous claim. In a normal situation the effort relies on the sender to get their mail through after a false positive occurs, or it wont get through at all. With the 2 features I described, the sender is provided with an extra simple option to get the mail through, and the recipient has also been provided with an option to get the mail through. Neither sender nor recipient would benefit from me removing those features from my system. Of course anyone can do as they think it´s best. But that doesn´t imply that other think the same. I want you to describe a scenario where the sender or recipient are actually worse off because of the particular two features I've described. You've failed to even attempt that so far. I know this system works well because I've been using it for a long time. I'm going to make 2 points here since you all hijacked my thread for this discussion, I feel I have the right to. ;-) First of all with regards to accepting then processing mail, that's bogus. It's imperative to issue an error 5xx to the sending server before the server closes TCP connection, if your going to reject the mail. Otherwise if you accept the message, your telling the spammer that they have a valid e-mail address, even if such a recipient address does not exist on your system, and your then encouraging them to spam. The claim that amavisd* variants accept then process mail is nonsense, nobody who runs a large mailserver with amavisd could possibly have their server configured in this manner without it melting down, so please no more of this ridiculous talk. Secondly with regards to this reject-but-save system that Mike is expounding on - it is an instance of a system that only works because a few people (or one person) is doing it. It is totally worthless as anything that can be scaled to multiple sites for a very simple reason. Right now one of the constants in the e-mail universe is that an error 5xx means you failed to deliver your mail. If many people deploy "reject-but-save-a-copy" then this breaks that assumption and the spammers response is extremely predictable - they will simply assume that EVERY error 5xx carries with it a chance for a successful delivery - so they will then program their spambots to continually retry no matter what the error. Right now if their spambot gets an error 5xx it schedules the victim address for removal - because the spambot only has a limited amount of time it can do things on whatever host system it has hijacked, and it can't spend time sending to addresses that are rejected when there are so many more out there that will accept the spam. If you remove that assumption by having a lot of sites deploy this hack of Mike's, then the spambots will simply continually send to millions of nonexistent e-mail addresses on your server - because of the chance that your running the Mike Hack and those nonexistent addresses your telling the spambot that are nonexistent are really existing. The spammers don't care that their spam is delivered to a junk mail folder. If the user isn't automatically deleting their junkmail unread (in which case there's no point in the Mike Hack in the first place) then they ARE having to periodically read at least the subject lines of messages in the Junk Mail folder. In short, the Mike Hack only has value if the users are periodically opening up and reading the subject lines of messages in the
Re: Newest spammer trick - non-blank subject lines?
On Don, 2010-02-11 at 18:26 +, Mike Cardwell wrote: [...] > I want you to describe a scenario where the sender or recipient are > actually worse off because of the particular two features I've The point is: The sender is worse off because he needs to invest time for the workaround which is caused by the receiver. The receiver is worse off because some senders plain simply give up when they are expected to pass a Turing test. No, I don't have numbers. But I'm pretty sure I'm not the only one. > described. You've failed to even attempt that so far. You see only two alternatives: - keep these two features (and tell the senders that they should actually be happy that they can invest time and effort to work around FPs caused by the receiver spam). - or deactivate it. I proposed the 3rd solution: - repair your spam-detection (change weight/limits, use Bayes, greylistung, etc.) to not generate so many FPs that you actually need an additional workaround. That would actually remove the cause and not fiddle with the symptoms. > I know this system works well because I've been using it for a long time. To use your own words: Ridiculous. Just because someone uses something for a long time doesn't make it good (or is even an indication for it). Apart from that: You very probably don't know how many FPs didn't come through because of people disliking Turing tests. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 19:29, Ted Mittelstaedt wrote: > Secondly with regards to this reject-but-save system that Mike is > expounding on - it is an instance of a system that only works because > a few people (or one person) is doing it. It is totally worthless as > anything that can be scaled to multiple sites for a very simple reason. > > Right now one of the constants in the e-mail universe is that an error > 5xx means you failed to deliver your mail. > > If many people deploy "reject-but-save-a-copy" then this breaks that > assumption and the spammers response is extremely predictable - they > will simply assume that EVERY error 5xx carries with it a chance for > a successful delivery - so they will then program their spambots to > continually retry no matter what the error. > > Right now if their spambot gets an error 5xx it schedules the victim > address for removal - because the spambot only has a limited amount of > time it can do things on whatever host system it has hijacked, and it > can't spend time sending to addresses that are rejected when there are > so many more out there that will accept the spam. > > If you remove that assumption by having a lot of sites deploy this > hack of Mike's, then the spambots will simply continually send to > millions of nonexistent e-mail addresses on your server - because > of the chance that your running the Mike Hack and those nonexistent > addresses your telling the spambot that are nonexistent are really > existing. > > The spammers don't care that their spam is delivered to a junk mail > folder. If the user isn't automatically deleting their junkmail unread > (in which case there's no point in the Mike Hack in the first place) > then they ARE having to periodically read at least the subject lines > of messages in the Junk Mail folder. In short, the Mike Hack only has > value if the users are periodically opening up and reading the subject > lines of messages in the Junk Mail folder. > > And the spammers thought is that their spam is so attractive that > all the user has to do is read the subject line and they will open > it. They aren't thinking "my spam got delivered to someone's junk > mail folder, boo hoo" They are thinking "Zowie, my mail got delivered > to someone's folder - it's just going to be a few more weeks and I'll > be rich, yipee yipee!!" Spammers are the most optimistic people you > will ever meet. Only an optimist would think that the sewage they send > out is something that people want to read. > > Mike I'm not sure why you think this hack of yours is so clever. It's > just a cheap hack. I can think of a dozen more for filtering spam, > some I've read other people expounding on over the years as the > greatest thing since sliced bread, all of which work - and all of > which are totally unscalable. > > If you want to write a clever spam filter than write one that everyone > can use. Otherwise the more you defend this, the more you look like > an inexperienced mail admin who knows just enough to be dangerous. All I can see above is a long list of dubious predictions of what spammers would do if everybody used the same system as me. I can't be bothered with this thread anymore. Feel free to make dubious assumptions of why that may be. Out. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Bernd Petrovitsch wrote: On Don, 2010-02-11 at 18:26 +, Mike Cardwell wrote: [...] I want you to describe a scenario where the sender or recipient are actually worse off because of the particular two features I've The point is: The sender is worse off because he needs to invest time for the workaround which is caused by the receiver. The receiver is worse off because some senders plain simply give up when they are expected to pass a Turing test. No, I don't have numbers. But I'm pretty sure I'm not the only one. Hmm. I'd say the balance is slightly in favour of Mike's system - you CAN NOT *prevent* all false-positives, so providing some way to let senders know relatively quickly that their mail got caught seems to me to be a positive. Some FPs are due to the sender's attempt to avoid some other differently-broken mail system elsewhere - I got an interesting call back from someone I notified about a webform generating mail missing a Message-Id header. (I've found it to be a pretty good spamsign here to see a Message-Id generated by one of our MXes.) Apparently, they used to generate one... and somewhere along the line their colo/hosting host's outbound relays started rejecting these messages based on that Message-Id. I proposed the 3rd solution: - repair your spam-detection (change weight/limits, use Bayes, greylistung, etc.) to not generate so many FPs that you actually need an additional workaround. That would actually remove the cause and not fiddle with the symptoms. :/ Until you have a business customer whose one FP for the year was moderately time-sensitive, and which missing out on in time cost them a juicy contract and guess who they're upset at for spam-tagging that one message, never mind how much junk the filter has kept out of their inbox? -kgd
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 19:52, Bernd Petrovitsch wrote: >> I want you to describe a scenario where the sender or recipient are >> actually worse off because of the particular two features I've > The point is: The sender is worse off because he needs to invest time > for the workaround which is caused by the receiver. The receiver is > worse off because some senders plain simply give up when they are > expected to pass a Turing test. > No, I don't have numbers. But I'm pretty sure I'm not the only one. > >> described. You've failed to even attempt that so far. > You see only two alternatives: > - keep these two features (and tell the senders that they should > actually be happy that they can invest time and effort to work around > FPs caused by the receiver spam). > - or deactivate it. > I proposed the 3rd solution: > - repair your spam-detection (change weight/limits, use Bayes, > greylistung, etc.) to not generate so many FPs that you actually need > an additional workaround. > That would actually remove the cause and not fiddle with the symptoms. > >> I know this system works well because I've been using it for a long time. > To use your own words: Ridiculous. Just because someone uses something > for a long time doesn't make it good (or is even an indication for it). > Apart from that: You very probably don't know how many FPs didn't come > through because of people disliking Turing tests. Your assuming that my false positive rate is bad. I would be surprised if it was worse than the average on this list. It's very good. But if my additions knock 0.1% more off the rate, then I'm happy. Out. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ted Mittelstaedt wrote: > The claim that amavisd* variants accept then process mail > is nonsense, nobody who runs a large mailserver with amavisd could > possibly have their server configured in this manner without it melting > down, so please no more of this ridiculous talk. ?? Of course you 5xx reject unknown users and other low hanging fruit that identifes bad stuff - but then the rest is accepted to process later. This is exactly how most amavisd variants work. - -- David Morton Morton Software & Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLdJKYUy30ODPkzl0RArlNAJ9ccE6wA/XcAlmUkSr4X0AXgVaT1ACfbZpr GyD+ExM0KUAEq8jPhAfCEE4= =jbCy -END PGP SIGNATURE-
Re: Newest spammer trick - non-blank subject lines?
On Friday February 12 2010 00:28:24 David Morton wrote: > Of course you 5xx reject unknown users and other low hanging fruit > that identifes bad stuff - but then the rest is accepted to process > later. This is exactly how most amavisd variants work. Btw, with the most recent advances in SpamAssassin 3.3.0 (master_deadline time limiting), in Postfix (smtpd_proxy_options=speed_adjust), and in the coming amavisd-new release (warm restart, reworked time limiting), amavisd will behave much better in a pre-queue (proxy) setup when combined with Postfix and SA 3.3.0. This gives admin more choice to choose between a pre-queue and post-queue setups. Mark
Re: Newest spammer trick - non-blank subject lines?
David Morton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ted Mittelstaedt wrote: The claim that amavisd* variants accept then process mail is nonsense, nobody who runs a large mailserver with amavisd could possibly have their server configured in this manner without it melting down, so please no more of this ridiculous talk. ?? Of course you 5xx reject unknown users and other low hanging fruit that identifes bad stuff - but then the rest is accepted to process later. This is exactly how most amavisd variants work. Yes, and this is exactly how everything else works, too. So what? That is not what the poster stated when he claimed that amavisd* queued everything. As I said, please no more of this rediculous talk. Ted
Re: Newest spammer trick - non-blank subject lines?
Mike Cardwell wrote: On 11/02/2010 19:29, Ted Mittelstaedt wrote: All I can see above is a long list of dubious predictions of what spammers would do if everybody used the same system as me. I can't be bothered with this thread anymore. You can't be bothered - yet you continued responding to someone else on this thread.. Uh huh. Sounds like you know I'm right and you can't think of a logical defense (since there isn't one) so your going to turn and run off with your tail between your legs. If anyone had any doubts that you weren't an inexperienced mail admin who knows just enough to be dangerous you just dispelled them. If you can't defend your hack in an open forum, then it's exactly as I said, nothing new, nothing revolutionary, just a cheap hack that only works if -one- site is doing it. I'll slip it in my file of other cheap hacks that only work if one site is doing them. Who knows maybe I might even have to use it one day for some border case - but I sure as hell would never be foolish enough to try and defend it. These hacks simply scream "I got mine and I don't give a damn if you got yours", hardly the attitude for an Internet admin to have. What exactly do you think the SA ruleset is, Mike? It is nothing more than a "dubious predictions of what spammers would do" Good Lord, and on top of that, a hijacked thread, too! Ted
Re: Newest spammer trick - non-blank subject lines?
On Thu, 11 Feb 2010 16:40:04 -0800 Ted Mittelstaedt wrote: > case - but I sure as hell would never be foolish enough to try and > defend it. These hacks simply scream "I got mine and I don't give > a damn if you got yours", Isn't that really your position - that 5xx responses make the botnet move on to someone else. You also seem to arguing that his idea is bad because it make a botnet less efficient at delivering spam. Your argument that it doesn't scale can be applied equally well to rejecting spam per se. Even if spammers do lay-off addresses where spam filters reject at the smtp level, they can't afford to do that if it's ubiquitous.
Re: Newest spammer trick - non-blank subject lines?
On 11-Feb-2010, at 15:42, Kris Deugau wrote: > > Hmm. I'd say the balance is slightly in favour of Mike's system - you CAN > NOT *prevent* all false-positives, so providing some way to let senders know > relatively quickly that their mail got caught seems to me to be a positive. An NDN means that a message was NOT DELIVERED. The natural thing to do when you get an NDN is to double check the address you sent to and if that is right then decide if it's worth trying to get the message through. If it is, you either re-craft the message, or you send it from another source. Or your forget about it and consider the message undelivered. To then have a undelivered message turn out to have been successfully delivered simply tells me that that person's mailserver is unreliable. This means that Mike's method is likely to create duplicate messages, and is guaranteed to create confusion about whether a specific message was delivered. Imagine these messages being generated by a mailing list. Never having seen one of the NDNs from Mike's system, I can't say exactly what they look like, but since I deal with severely malformed and suspicious NDNs every single day, it is very unlikely that I would look at any URL inside a NDN, much less even consider clicking on it. -- NO ONE CARES WHAT MY DEFINITION OF "IS" IS Bart chalkboard Ep. AABF02
Re: Newest spammer trick - non-blank subject lines?
On Don, 2010-02-11 at 17:42 -0500, Kris Deugau wrote: > Bernd Petrovitsch wrote: [...] > > I proposed the 3rd solution: > > - repair your spam-detection (change weight/limits, use Bayes, > > greylistung, etc.) to not generate so many FPs that you actually need > > an additional workaround. > > That would actually remove the cause and not fiddle with the symptoms. > > :/ Until you have a business customer whose one FP for the year was > moderately time-sensitive, and which missing out on in time cost them a > juicy contract and guess who they're upset at for spam-tagging that > one message, never mind how much junk the filter has kept out of their > inbox? I was more in "private" area - and the commercial. AFAICT almost every company I know of plain simply *never* rejects email just because some tool may think it's got too many spam points. So for them this is a non-issue anyways. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
Kurt Buff さんは書きました: > > Uh, paranoia is not mitigated by ignorance. Remember the earlier > description of her friend: retired and partially disabled. This > probably means older and not nearly as educated as we are about > computers, and set in his/her ways. This, augmented by scare stories > in the mass media, probably contribute to the difficulty. > A lot of older people still believe that giving the PC the wrong command will cause it to explode in a shower of sparks, thanks to Hollywood. It seems that Hollywood is still doing that. I can't count how many times my boss's boss would yell at me when a PC quit working, afraid I'd given it some command that would cause it to explode. -- jd
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
Quoting jd : Kurt Buff さんは書きました: Uh, paranoia is not mitigated by ignorance. Remember the earlier description of her friend: retired and partially disabled. This probably means older and not nearly as educated as we are about computers, and set in his/her ways. This, augmented by scare stories in the mass media, probably contribute to the difficulty. A lot of older people still believe that giving the PC the wrong command will cause it to explode in a shower of sparks, thanks to Hollywood. It seems that Hollywood is still doing that. I can't count how many times my boss's boss would yell at me when a PC quit working, afraid I'd given it some command that would cause it to explode. While explosions aren't a big problem, smoke and damage was completely possible. Back in the "olden days" before flat panel displays and smart CRTs, it was entirely possible to select a refresh rate or resolution that would cause a monitor to smoke and die. AFAIK, this is not possible with current hardware. Terry
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
jd wrote: > A lot of older people still believe that giving the PC the wrong > command will cause it to explode in a shower of sparks, thanks to > Hollywood. It seems that Hollywood is still doing that. > Electronics generating sparks when overloaded? Yes. Generating smoke? Yes. Flames? Yes. A dynamic explosion? No. (Never did figure out why all the electronics consoles in movies seem to contain explosives...) -- Bowie
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
jd wrote: > Kurt Buff さんは書きました: >> >> Uh, paranoia is not mitigated by ignorance. Remember the earlier >> description of her friend: retired and partially disabled. This >> probably means older and not nearly as educated as we are about >> computers, and set in his/her ways. This, augmented by scare stories >> in the mass media, probably contribute to the difficulty. >> > > A lot of older people still believe that giving the PC the wrong > command will cause it to explode in a shower of sparks, thanks to > Hollywood. No ageism here please :-) - a lot people will believe all kinds of things about PCs. /Per Jessen, Zürich
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
jd wrote: Kurt Buff さんは書きました: Uh, paranoia is not mitigated by ignorance. Remember the earlier description of her friend: retired and partially disabled. This probably means older and not nearly as educated as we are about computers, and set in his/her ways. This, augmented by scare stories in the mass media, probably contribute to the difficulty. A lot of older people still believe that giving the PC the wrong command will cause it to explode in a shower of sparks, thanks to Hollywood. It seems that Hollywood is still doing that. I can't count how many times my boss's boss would yell at me when a PC quit working, afraid I'd given it some command that would cause it to explode. Back in 1995 one day at Central Point Software I was walking by the server room when I heard a funny noise, I ran in just in time to see the IBM monitor spew out a huge cloud of greasy stinky smoke. I held my breath, ran in and unplugged it and carried it out into the hall. The flyback transformer had melted down. I later found out from someone else that this was a common occurrence with those IBM monitors. The monitor was in a rack, right underneath our fiber distribution panel. That would have been rather messy if it had caught on fire. Ted
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
On Wednesday 10 February 2010, te...@cnysupport.com wrote: >Quoting jd : >> Kurt Buff さんは書きました: >>> Uh, paranoia is not mitigated by ignorance. Remember the earlier >>> description of her friend: retired and partially disabled. This >>> probably means older and not nearly as educated as we are about >>> computers, and set in his/her ways. This, augmented by scare > >stories > >>> in the mass media, probably contribute to the difficulty. >> >> A lot of older people still believe that giving the PC the wrong >> command will cause it to explode in a shower of sparks, thanks to >> Hollywood. It seems that Hollywood is still doing that. >> >> I can't count how many times my boss's boss would yell at me when a > >PC > >> quit working, afraid I'd given it some command that would cause it >> to explode. > >While explosions aren't a big problem, smoke and damage was completely >possible. > >Back in the "olden days" before flat panel displays and smart CRTs, it >was entirely possible to select a refresh rate or resolution that >would cause a monitor to smoke and die. > >AFAIK, this is not possible with current hardware. > >Terry > True, but X's paranoia lives on. I have preached before, but perhaps not to this choir. If you enjoy a good rant, by someone who has been there and done that, read on. The grand and glorious failures generally occurred 20-10 years ago for the most part. The usual cause was trying to run the monitors at a lower scan rate than they had transformer iron to handle. Generally speaking this is very very rarely a vertical sweep problem, for 2 reasons, but first & foremost, those transformers were iron cored, and because of that had a much softer saturation failure than the highly tuned ferrite cores used in the horizontal scan (and high voltage) circuits. There, the sweep currant amplitude determines the width, but that amplitude delivered to the coils of the deflection yoke is determined by the rate of rise or fall of the current in the transformer. The width is now regulated, usually by adjusting the supply voltage downward at the lower sweep frequencies. However, the slower sweep rates, because this is a 'velocity' to amplitude conversion, allows the current in the transformer to rise for a longer period of time before its turned off & reversed to retrace the beam to the left side of the CRT. If this current is allowed to rise for long enough, the ferrite core will become saturated, which is a fancy way of saying the core no longer has an influence on the circuit inductance, and the effective inductance is then no more than if the core had been physically removed. The rate of current rise is then largely un-impeded and can rise many tens of amps per microsecond, quite high by the time the transistor's drive is removed and it _tries_ to turn off. Junction temps in the transistor rise until it explodes, usually blowing bits of epoxy-B off the top. Correspondingly during this same time frame, the circulating currents cause the supplies capacitors to overheat, and occasionally those electrolytics will vent, or at least push the tops up into a definite dome shape. A similar effect can also be triggered by heat in that ferrite core. Most ferrite mixes have a quite low 'curie' point, often below 100C! The 'curie' point is that point in the process of heating an iron alloy, where the iron loses its magnetic properties. So at temp X, the ferrite disappears from the magnetic circuit, and like steel, if cooled quickly enough, will not regain those magnetic properties ever again. Its still steel, or in this case ferrite, but you cannot pick it up with a magnet. Exhaust valves in lots of engines have been made from it since WW-II times, its then called Austenitic (SP?) steel. All this because somebody replaced an ega rated monitor that could run at 22khz, with a vga rated one that was designed to run at a minimum of 31khz, and their card could only muster up 28khz. The results were predictable, a failure, the only question was how long it took. And it was a big enough problem for the monitor makers that they were quickly fitted with protective circuitry. So that is not now a problem in terms of being a fire hazard and has not been for much of a decade now. Conversely, going the other way, at the top end, the power supply runs out of headroom, the high voltage gets soft, the pix narrower and probably dimmer, but generally speaking a 70khz rated monitor will not be damaged by a 90khz drive. Similarly, a 15khz rated monitor is not damaged, even on a long term basis, by running it at 19 khz, I have been doing that for many years on what this group would definitely call a 'legacy computer', a TRS-80 Color Computer 3. It is, when its hooked up, the second, fully independent monitor I can use. So, IMNSHO, X is way overdue to lose that paranoia, the monitor folks fixed that problem nearly a decade ago. They (X) are trying to protect the user
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
On Wednesday 10 February 2010, Bowie Bailey wrote: >jd wrote: >> A lot of older people still believe that giving the PC the wrong >> command will cause it to explode in a shower of sparks, thanks to >> Hollywood. It seems that Hollywood is still doing that. > >Electronics generating sparks when overloaded? Yes. > >Generating smoke? Yes. > >Flames? Yes. > >A dynamic explosion? No. > >(Never did figure out why all the electronics consoles in movies seem to >contain explosives...) Explosion? Most certainly a resounding yes, Bowie. I once had a house in Nebraska, with a quarter sized dent in the plaster & lathe ceiling about 1/4" deep over the kitchen table. Poor folks at the time, I had bought an old 6 volt CB radio, and _thought_ I had it converted to 12 volts, and was testing it. After about 30 minutes powered up on a 12 volt supply, one of the power supply filters, a 350 volt rated item, decided it had had enough of the 600 volts it was getting, and exploded. The top of the alu can put that dent in the plastered ceiling, and I had a heck of a time cleaning up all the exploded antifreeze soaked kraft paper & see through tinfoil they are made of. The antifreeze of course being 1000's of times purer than what you put in your cars radiator, but its still ethylene glycol none the less. Lets just say that I am glad I had no body parts in the way... I realized that I had missed a connection that needed to be moved to the 12 volt position, fixed that, and replaced the filter, and it ran just fine in my hunting truck for as long as I owned it, another 6 or 7 years. The movie folks of course have their own definition of reality. ;-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Common sense is the collection of prejudices acquired by age eighteen. -- Albert Einstein
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
On Wednesday 10 February 2010, Per Jessen wrote: >jd wrote: >> Kurt Buff さんは書きました: >>> Uh, paranoia is not mitigated by ignorance. Remember the earlier >>> description of her friend: retired and partially disabled. This >>> probably means older and not nearly as educated as we are about >>> computers, and set in his/her ways. This, augmented by scare stories >>> in the mass media, probably contribute to the difficulty. >> >> A lot of older people still believe that giving the PC the wrong >> command will cause it to explode in a shower of sparks, thanks to >> Hollywood. > >No ageism here please :-) - a lot people will believe all kinds of >things about PCs. > > >/Per Jessen, Zürich > That is only because common sense is a limited availability trait, and with more people, there simply is not enough to go around. Like this dirtball, we haven't made any new dirt, not in big enough quantities to count since that crater near the yucatan 65 million years ago. Same for common sense. If you happen to run across some, grab it & hoard it. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Piece of cake! -- G.S. Koblas
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
On Wed, 10 Feb 2010, Bowie Bailey wrote: jd wrote: A lot of older people still believe that giving the PC the wrong command will cause it to explode in a shower of sparks, thanks to Hollywood. It seems that Hollywood is still doing that. Electronics generating sparks when overloaded? Yes. Generating smoke? Yes. Flames? Yes. http://en.wikipedia.org/wiki/Halt_and_Catch_Fire -- 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 --- Rights can only ever be individual, which means that you cannot gain a right by joining a mob, no matter how shiny the issued badges are, or how many of your neighbors are part of it. -- Marko --- 2 days until Abraham Lincoln's and Charles Darwin's 201st Birthdays
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
Gene Heskett wrote: >>> A lot of older people still believe that giving the PC the wrong >>> command will cause it to explode in a shower of sparks, thanks to >>> Hollywood. >> >>No ageism here please :-) - a lot people will believe all kinds of >>things about PCs. >> >> >>/Per Jessen, Zürich >> > That is only because common sense is a limited availability trait, and > with more people, there simply is not enough to go around. +1 /Per Jessen, Zürich
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
On Wed, 10 Feb 2010, Bowie Bailey wrote: Electronics generating sparks when overloaded? Yes. Generating smoke? Yes. Flames? Yes. A dynamic explosion? No. (Never did figure out why all the electronics consoles in movies seem to contain explosives...) Self-destruct mechanism, obviously! :) PS. Explosions are not 100% unreal. Ever had a capacitor pop? Even the small ones can make quite a loud bang :) - Charles
Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
On Wednesday 10 February 2010, Per Jessen wrote: >Gene Heskett wrote: A lot of older people still believe that giving the PC the wrong command will cause it to explode in a shower of sparks, thanks to Hollywood. >>> >>>No ageism here please :-) - a lot people will believe all kinds of >>>things about PCs. >>> >>> >>>/Per Jessen, Zürich >> >> That is only because common sense is a limited availability trait, and >> with more people, there simply is not enough to go around. > >+1 Thanks Per. That is an observation based on 75 years of observing. ;-) > >/Per Jessen, Zürich > -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) How should I know if it works? That's what beta testers are for. I only coded it. -- Attributed to Linus Torvalds, somewhere in a posting
Re: [SPAM:9.6] Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
On Wed, 10 Feb 2010 12:42:46 -0500 Bowie Bailey wrote: > jd wrote: > > A lot of older people still believe that giving the PC the wrong > > command will cause it to explode in a shower of sparks, thanks to > > Hollywood. It seems that Hollywood is still doing that. > > > > Electronics generating sparks when overloaded? Yes. > > Generating smoke? Yes. > > Flames? Yes. > > A dynamic explosion? No. > > (Never did figure out why all the electronics consoles in movies seem > to contain explosives...) > It's a simple mistake - but the repair technician substitutes the 4700uf smoothing caps with Le Maitre theatrical maroons (the very small ones I hasten to add, the really big ones you put into a car a disconnected car stereo, wired across the supply cables and leave the car unlocked :-) If the thief is local, you'll hear the bang)
Re: [SPAM:9.6] Re: OT::Making a PC explode (was Re: Newest spammer trick - non-blank subject lines?)
On Wed, 10 Feb 2010 12:32:06 -0800 (PST) John Hardin wrote: > On Wed, 10 Feb 2010, Bowie Bailey wrote: > > > jd wrote: > >> A lot of older people still believe that giving the PC the wrong > >> command will cause it to explode in a shower of sparks, thanks to > >> Hollywood. It seems that Hollywood is still doing that. > > > > Electronics generating sparks when overloaded? Yes. > > > > Generating smoke? Yes. > > > > Flames? Yes. > > http://en.wikipedia.org/wiki/Halt_and_Catch_Fire > Wow, forgot about that! Thanks for the memory!