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!
MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
http://www.chaosreigns.com/mtx/ -- "Democracy is the theory that the common people know what they want, and deserve to get it good and hard." - H. L. Mencken http://www.ChaosReigns.com
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: unsubscribe
you need to send an email to this address to unsubscribe users-unsubscr...@spamassassin.apache.org It was in the header of the email On Wed, Feb 10, 2010 at 4:30 PM, Tim Alberts wrote: > > -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
unsubscribe
<>
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: 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: 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: 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?)
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 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, 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: [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: 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: 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?
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: 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: > 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?)
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: 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
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: 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?
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: Spam filtering similar to SPF, less breakage
On 2010-02-09 22:31, dar...@chaosreigns.com wrote: [Ideas for a new scheme similar to a subset of SPF.] I don't think the SpamAssassin users list is the right place to discuss a new generasl scheme like this, but here goes anyway. Please not that the comments below is just a first reaction. I haven't really thought this through. A general thought is: What does your current scheme give that HELO SPF + FCDNS doesn't? (SPF can be used with HELO as well as MAIL FROM). What format should this arbitrary A record be? I suggest you use a leading underscore for you magic subdomain (2.0.0.10._mtx.smallbusiness.com). I do this because I think your scheme need one more thing to be of any use at all. It needs a way for the domain owner to sopecify that they are using it. This could be done by creating a record for "_mtx.smallbusiness.com". Without a way to indicate wether the scheme is used or not, it'll be unusable for blocking until *all* major email providers as well as almost everyone else is using it. Using an underscore makes it less likely to collide with existing host names. It also makes it more apparent that it's not a regular hostname. A new record type might be even better. Regards /Jonas -- Jonas Eckerman Fruktträdet & Förbundet Sveriges Dövblinda http://www.fsdb.org/ http://www.frukt.org/ http://whatever.frukt.org/
Re: spamassassin /etc/shadow access
On Wednesday February 10 2010 07:11:57 Tóth Attila wrote: > Sorry for bringing up this topic again. It was previously discussed in > 2006: http://markmail.org/message/76w27on2gf44262g > > I still don't see an established reason why spamassassin should tamper > with shadow. From 2006: "Doesn't do anything other to see if their is a > matching entry in both /etc/passwd and /etc/shadow and it checks to see if > the user is still able to log in." > For a matching entry /etc/passwd is enough. And what if the user cannot > login? > Even sa-learn tries to read shadow. If I'm running it, I'm running it. > Aren't I? > > Would it be possible to disable shadow checks using an option? I don't > like programs running UID 0 being able to read /etc/shadow. Only if it's > reasonable. > > I just want to shorten my RBAC denial logs - by getting rid of unnecessary > system activities. It would be worth tracing the source of this behaviour. It doesn't do so on my system, and certainly SpamAssassin does not do it explicitly itself. Must be one of the underlying modules or perl itself on certain systems. Please open a bug report, it would be worth having this documented, although it is likely we won't be able to do much about it. Mark
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 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 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/
