Re: Spam filtering similar to SPF, less breakage
On 08.02.10 22:08, dar...@chaosreigns.com wrote: You get an email delivered from 64.71.152.40 (last untrusted relay). You look up the DNS A record for that IP, and get You won't look up A records for an IP, IP address do NOT have A records. You can look up PTR (or any other record) for 40.152.71.64.in-addr.arpa. mail.chaosreigns.com. Then you look up the DNS PTR record of 40.152.71.64.designatedsender.mail.chaosreigns.com, and if it's 127.0.0.1, it's a legit email sender and gets some negative SA score. Then I will look A record of mail.chaosreigns.com and see if it's 64.71.152.40. If you compare these two, you see that I need to control the same domains no matter which wsay I go. Just now I can do what you propose (and many spammers can too) but that doesn't mean my mail is legitimate. Otherwise it's not, and gets some positive SA score (low at first until adoption spreads). So it's not tied to the SMTP MAIL FROM or anything. Forwarding doesn't break. What do you mean by this? Do you want to implement new way of defining which hosts are permitted to send e-mail? There already are attempts to do this, with false positives and negatives. Yours is a bit complicated and new which means everyone would need to implement this (otherwise he'd get false positives on his outgoing mail). Therefore I think it won't work this way. If you want to implement new way of defining which hosts are permitted to send e-mail from which domain, the same applies. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They say when you play that M$ CD backward you can hear satanic messages. That's nothing. If you play it forward it will install Windows.
Re: Spam filtering similar to SPF, less breakage
On Mon, 8 Feb 2010 22:08:10 -0500 dar...@chaosreigns.com wrote: You get an email delivered from 64.71.152.40 (last untrusted relay). You look up the DNS A record for that IP, and get mail.chaosreigns.com. Then you look up the DNS PTR record of 40.152.71.64.designatedsender.mail.chaosreigns.com, and if it's 127.0.0.1, it's a legit email sender and gets some negative SA score. Otherwise it's not, and gets some positive SA score (low at first until adoption spreads). You've mixed-up A record and PTR record. Checking for full-circle DNS already does most of this. What your scheme would do is check for otherwise legitimate servers that have been compromised and are delivering direct-to-mx.
Re: Spam filtering similar to SPF, less breakage
On Mon, 2010-02-08 at 22:08 -0500, dar...@chaosreigns.com wrote: You get an email delivered from 64.71.152.40 (last untrusted relay). You look up the DNS A record for that IP, and get mail.chaosreigns.com. That's a PTR lookup, but let's press on Then you look up the DNS PTR record of 40.152.71.64.designatedsender.mail.chaosreigns.com, and if it's 127.0.0.1, it's a legit email sender and gets some negative SA score. What you describe here is functionally similar to an SPF lookup with a 'pass' result. The server provides positive verification that the listed IP is a legitimate sender for that domain. Otherwise it's not, and gets some positive SA score (low at first until adoption spreads). As long as 'otherwise' is a definitive 'fail' response from an SPF (or equivalent) server, and not merely an absence of SPF server So it's not tied to the SMTP MAIL FROM or anything. Your method would allow 'spoofing' so that a spammer who hacks a legitimate server can use a valid return address on a different domain, but still the mail would receive a 'passing' grade. At least, with SPF, the spammer must forge an address on the hacked domain, which increases the likelihood of detection Forwarding doesn't break. Ah, so you want to allow 'legitimate' forwarding, but not allow spammers to 'forward' their mail? Good luck with that. The only way to make it work for the legitimate sender, but not for spammers is to have a mechanism built-in to the forwarding server that encapsulates or rewrites the envelope 'From' address. Eventually you reject all email from IPs without such records. In a perfect world. Obviously you'd need a blacklist of spammer domains that list spamming IPs as legit senders. And you would be playing the same 'musical chairs' game with new domains created by spammers on a daily basis. All the same flaws of SPF, and no greater benefit. Is there any way this wouldn't be very useful? Is there any place where SPF does not do the same job, other than mail forwarding? - Charles
Re: SA 3.30 FreeBSD port ready for testing
The updated onever seems to be there few days after the original submission: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143654 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143654 LuKreme wrote: On 5-Feb-2010, at 08:38, Michael Scheidell wrote: I have uploaded the patch files for the SA 3.30 FreeBsd port. It has been tested on 7.1 amd64 and i386. What's the status? Looks to me like the port was pulled at your request? http://www.freebsd.org/cgi/query-pr.cgi?pr=143582 -- View this message in context: http://old.nabble.com/SA-3.30-FreeBSD-port-ready-for-testing-tp27469547p27518020.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Spam filtering similar to SPF, less breakage
I apparently need to clarify that I think this is a good idea because I am concerned about the number of people (who control DNS records) who are very strongly against creating SPF records specifically because of forwarding breakage. The email I got in response to my request for my employer to create an SPF record included the word abomination. From a friend. I don't entirely agree, but it is a problem for adoption. This is entirely an attempt to replicate the functionality of SPF without breaking forwarding, and without causing other problems that might discourage adoption. I set this up for my mail server (using mtx instead of designatedsender): $ host -t PTR 64.71.152.40 40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com. $ host -t A 40.152.71.64.mtx.panic.chaosreigns.com 40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1 All it took was creating a single record in bind: 40.152.71.64.mtx.panic.chaosreigns.com. IN A 127.0.0.1 I'll define it slightly differently: 127.0.0.1 is a pass (negative SA score). not found is a fail (positive SA score). 127.0.0.0 is a fail (positive SA score). Anything else is undefined (0 SA score) for future options. I'd still appreciate feedback on the format of the A record. On 02/09, RW wrote: You've mixed-up A record and PTR record. Yes. Embarrassing. Checking for full-circle DNS already does most of this. My home dynamic cablemodem address passes full-circle DNS. But not this. So this is far more useful for checking if an IP is a legitimate sending mail server. What your scheme would do is check for otherwise legitimate servers that have been compromised and are delivering direct-to-mx. An otherwise legitimate but compromised mail server would not be detected by this. I'm curious why you interpreted it differently. On 02/09, Charles Gregory wrote: On Mon, 2010-02-08 at 22:08 -0500, dar...@chaosreigns.com wrote: What you describe here is functionally similar to an SPF lookup with a 'pass' result. The server provides positive verification that the listed IP is a legitimate sender for that domain. Yes. As long as 'otherwise' is a definitive 'fail' response from an SPF (or equivalent) server, and not merely an absence of SPF server Yes. Definitive fail. Your method would allow 'spoofing' so that a spammer who hacks a legitimate server can use a valid return address on a different domain, but still the mail would receive a 'passing' grade. At least, with SPF, the spammer must forge an address on the hacked domain, which increases the likelihood of detection Yes. I would blacklist domains that pass hacked servers. Just as IPs of hacked servers are blacklisted. They're sending spam, and need to be fixed. Forwarding doesn't break. Ah, so you want to allow 'legitimate' forwarding, but not allow spammers to 'forward' their mail? Good luck with that. The only way to make it work for the legitimate sender, but not for spammers is to have a mechanism built-in to the forwarding server that encapsulates or rewrites the envelope 'From' address. Encapsulating or rewriting the envelope 'From' address seems significantly less likely to be adopted from what I've read. Obviously you'd need a blacklist of spammer domains that list spamming IPs as legit senders. And you would be playing the same 'musical chairs' game with new domains created by spammers on a daily basis. All the same flaws of SPF, and no greater benefit. Same domain blacklisting issues as SPF, yes. I am not very concerned about the throw-away domains because I'll reject all mail from domains not at least 10 days old. 10+ day old domains are already listed as 127.0.2.3 records from example.com.hostkarma.junkemailfilter.com. I believe the benefit of not breaking forwarding is sufficient to make it much more useful than SPF for spam filtering. I've come across enough people, personally, recently, in trying to block (some = positive SA score) emails without an SPF pass, who are not willing to ever implement SPF due to breaking forwarding that I believe this would be useful. Is there any way this wouldn't be very useful? Is there any place where SPF does not do the same job, other than mail forwarding? No. But as I said, I am concerned about the potential for wide spread adoption of SPF due to forwarding breakage enough that I think this would be much more useful. On 02/09, Matus UHLAR - fantomas wrote: On 08.02.10 22:08, dar...@chaosreigns.com wrote: So it's not tied to the SMTP MAIL FROM or anything. Forwarding doesn't break. What do you mean by this? Do you want to implement new way of defining which hosts are permitted to send e-mail? Yes. There already are attempts to do this, with false positives and negatives. How is this not better than the other attempts? Yours is a bit complicated How is it complicated? You need to create 1 record per sending mail
Re: Spam filtering similar to SPF, less breakage
Another point of clarification on why I think this will work: I'm running SA as a pre-queue content_filter from postfix, so when SA decides an email is spam, non-forged senders get an error, without sending backscatter to forged addresses. When I implement this, senders will get an error asking them to ask their administrator to create the necessary record. And I see no reason for that administrator not to create that record. The directions I followed to set up SA this way are half way down this page: http://wiki.apache.org/spamassassin/IntegratePostfixViaSpampd (Be sure to do the --sef and X-Envelope-From bits.) -- I'd rather be happy than right any day. - Slartiblartfast, The Hitchhiker's Guide to the Galaxy http://www.ChaosReigns.com
Re: How should this tricky spam be filtered?
On Mon, 8 Feb 2010, Adam Katz wrote: I wrote: My tests have been mildly successful on this note, with FROM_WWW already getting promoted out of testing: http://ruleqa.spamassassin.org/?rule=/FROM_Wsrcpath=khop This indicates that we don't actually need to parse any further because there is no sizable mass of legitimate mail that does this (and hopefully by getting this rule out the door, people considering it might decide against it). John Hardin wrote: Concur. http://ruleqa.spamassassin.org/20100201-r905213-n/T_FROM_URI/detail?srcpath=jhardin To get them both on the same view: http://ruleqa.spamassassin.org/?rule=%2F^FROM_...%24 Let's clear up the differences between FROM_URI and FROM_WWW ... Good idea. Maybe it's just because I'm testing on the command line, but FROM_URI appears to only fire if there's a character in front of the www. portion. It does. I'm explicitly targeting a quoted comment part. My rule is somewhat tighter than yours in an attempt to mimimize FPs, admittedly at the cost of missing some spams. It also appears to fire on other.www.u...@example.com other.www.u...@example.com Hrm. I modified it to avoid @www, but not ww...@.* - mod for that is checked in. Perhaps we should let another day's masscheck run against it... Presumably, my rule's lack of a TLD check is the main reason it hits more messages (ham and spam). Likely true. I'd argue that the list of TLDs spammers use is fairly limited and having an explicit match is a good idea. We should decide upon one (with or without revisions) and push it out the door. We've seen a few threads here on the list and I've seen several inquiries on the IRC channel about this, so I suspect the masscheck corpora just aren't getting blasted by it as much as others. Agreed. -- 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 --- Efficiency can magnify good, but it magnifies evil just as well. So, we should not be surprised to find that modern electronic communication magnifies stupidity as *efficiently* as it magnifies intelligence. -- Robert A. Matern --- 3 days until Abraham Lincoln's and Charles Darwin's 201st Birthdays
Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: I apparently need to clarify that I think this is a good idea because I am concerned about the number of people (who control DNS records) who are very strongly against creating SPF records specifically because of forwarding breakage. The email I got in response to my request for my employer to create an SPF record included the word abomination. From a friend. I don't entirely agree, but it is a problem for adoption. This is entirely an attempt to replicate the functionality of SPF without breaking forwarding, and without causing other problems that might discourage adoption. I set this up for my mail server (using mtx instead of designatedsender): $ host -t PTR 64.71.152.40 40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com. $ host -t A 40.152.71.64.mtx.panic.chaosreigns.com 40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1 All it took was creating a single record in bind: 40.152.71.64.mtx.panic.chaosreigns.com. IN A 127.0.0.1 I'll define it slightly differently: 127.0.0.1 is a pass (negative SA score). not found is a fail (positive SA score). 127.0.0.0 is a fail (positive SA score). Anything else is undefined (0 SA score) for future options. I'd still appreciate feedback on the format of the A record. Can you be a little more detailed on exactly which pieces of information you're looking at, and where you're getting them from? So far as I've been able to make out from your descriptions so far, this is a smallish subset of the functionality SPF provides, without the disadvantage of overloading TXT records. Consider: Spammer has control of a PC on a small(ish)-business LAN whose NAT gateway also handles their mail. (Exchange server, for instance - far too common a configuration IMO.) Spammer mail originates from 10.0.0.2 (static IP assigned by ISP). PTR record is 2.0.0.10.in-addr.arpa - exchange.smallbusiness.com 2.0.0.10.mtx.exchange.smallbusiness.com - 127.0.0.1 because this is the recognized designated outbound relay for Small Business's legitimate mail, and they've followed your proposal. How is the spam to be *not* considered a legitimate sender in this case? Even if the Exchange server isn't actually processing the email, its public IP will still be the originating IP of the message. SPF at least ties some aspect of the message itself to the relay IP in some way. (Whether that's good or bad I'll ignore for the moment.) -kgd
Re: Spam filtering similar to SPF, less breakage
On 02/09, Kris Deugau wrote: Spammer mail originates from 10.0.0.2 (static IP assigned by ISP). PTR record is 2.0.0.10.in-addr.arpa - exchange.smallbusiness.com 2.0.0.10.mtx.exchange.smallbusiness.com - 127.0.0.1 because this is the recognized designated outbound relay for Small Business's legitimate mail, and they've followed your proposal. How is the spam to be *not* considered a legitimate sender in this case? Even if the Exchange server isn't actually processing the email, its public IP will still be the originating IP of the message. Blacklist the validating domain smallbusiness.com. Reject all email that has a *.mtx.*.smallbusiness.com record. Just as you would blacklist the sending IP for spamming. As with SPF, I expect this to be quite a lot easier than maintaining a blacklist of spamming IPs. If I'm wrong on that one point, this is useless. Would you still like more detail on what pieces of information I'm looking at, and where I'm getting them from? -- Anarchy is based on the observation that since few are fit to rule themselves, even fewer are fit to rule others. -Edward Abbey http://www.ChaosReigns.com
Re: How should this tricky spam be filtered?
On Tue, 9 Feb 2010, John Hardin wrote:
On Mon, 8 Feb 2010, Adam Katz wrote:
Maybe it's just because I'm testing on the command line, but FROM_URI
appears to only fire if there's a character in front of the www.
portion.
It does. I'm explicitly targeting a quoted comment part. My rule is somewhat
tighter than yours in an attempt to mimimize FPs, admittedly at the cost of
missing some spams.
Tweaked that a bit, it will now hit on www.{etc} at the beginning of an
unquoted comment in the From: header.
--
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
---
Politicians never accuse you of greed for wanting other people's
money, only for wanting to keep your own money.-- Joseph Sobran
---
3 days until Abraham Lincoln's and Charles Darwin's 201st Birthdays
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010, dar...@chaosreigns.com wrote: My home dynamic cablemodem address passes full-circle DNS. But not this. So this is far more useful for checking if an IP is a legitimate sending mail server. So rather than mimicing SPF, you want to mimic the effect of various IP-based blacklists to which an ISP can report all of its 'unauthorized' IP's (typicalyl dynamic IP blocks)? The obvious drawback is the same for your system as the already existing dynamic-ip blackilsts, which is that it only works when domains take the time and trouble to register either their 'authorized' (in your case) or 'unauthorized' (for the blacklist) ranges of IP's. Large companies which frequently reorganize their IP blocks will shy away from such a system, and smaller companies will lack the time/resources to implement anything that isn't 'out of the box'. Encapsulating or rewriting the envelope 'From' address seems significantly less likely to be adopted from what I've read. Unlikely in many cases, but I would quibble over 'less'. Overall, most corporate minds seem to think that they prefer false negatives to false positives, so they are extremely reluctant to adopt any strategy that increases the chance of a false positive, even under such strange conditions as a hack Indeed, given that there are no issues of false positives from rewriting the envelope sender, one could argue that it is the change *most* likely to be adopted, and therefore it has significance that it is not being adopted by everyone I am not very concerned about the throw-away domains because I'll reject all mail from domains not at least 10 days old. Another feature already covered by a blacklist, and, already being bypassed by numerous spammers who are smart enough to buy a domain name months before they use it. (shrug) I believe the benefit of not breaking forwarding is sufficient to make it much more useful than SPF for spam filtering. I've come across enough people, personally, recently, in trying to block (some = positive SA score) emails without an SPF pass, who are not willing to ever implement SPF due to breaking forwarding that I believe this would be useful. But *why* do they refuse to 'fix' their forwarding? I strongly suspect that the same reasoning would apply to their decision to not implement SPF or your IP-based filter idea. - C
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010, dar...@chaosreigns.com wrote: When I implement this, senders will get an error asking them to ask their administrator to create the necessary record. Those administrators will say that they do not have control over DNS, because that's done at a higher organizational level, or that they don't want to do something that is not 'standard' and will tell their users to find another way to communicate with you. Same BS that is used to dodge SPF. It's not that your idea is 'bad', it's just not that much different from SPF in terms of the roadbblocks to its effective adoption. Don't blame you for trying. Actually wish it worked. :) - Charles
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010 11:42:07 -0500 dar...@chaosreigns.com wrote: On 02/09, RW wrote: What your scheme would do is check for otherwise legitimate servers that have been compromised and are delivering direct-to-mx. An otherwise legitimate but compromised mail server would not be detected by this. I'm curious why you interpreted it differently. A compromised webserver with full-circle DNS would be caught by this. My point is that is the only class of spam that this could help with Every thing else is either handled by full-circle and no DNS tests, or can be easily worked around by spammers setting their own dns.
Re: Spam filtering similar to SPF, less breakage
On 02/09, dar...@chaosreigns.com wrote: Anything else is undefined (0 SA score) for future options. This won't work. Everything lacking a 127.0.0.1 record needs to be a fail, otherwise spammers can create undefined records to circumvent this. On 02/09, Charles Gregory wrote: So rather than mimicing SPF, you want to mimic the effect of various IP-based blacklists to which an ISP can report all of its 'unauthorized' IP's (typicalyl dynamic IP blocks)? Basically, except of course that the default, when not participating, is effectively blacklisting (in the sense in which SA uses blacklists to increase the spammines score of an email). The obvious drawback is the same for your system as the already existing dynamic-ip blackilsts, which is that it only works when domains take the time and trouble to register either their 'authorized' (in your case) or 'unauthorized' (for the blacklist) ranges of IP's. Large companies which frequently reorganize their IP blocks will shy away from such a system, and smaller companies will lack the time/resources to implement anything that isn't 'out of the box'. I disagree. I can implement it now (in fact I expect to, which is why I'd really like feedback on the A record format). So I block some more spam, and I get some extra false positives, and the senders get notified. And the senders can try to get the relevant MTX records created if they want. And maybe along the way these MTX records become a little more common, and I can increase the spam score of emails without MTX records and block some more spam without further increasing false positives. And maybe eventually, as a result of this iterative process, enough people create MTX records that I can reject all email without one. Having looked over the scores of my non-spams, I'm comfortable with the additional false positives up to an additional score of 4.5, as long as the sender is notified and has some possibility of eliminating that additional score. Others might be more comfortable with an additional score of 1. Still, you catch more spams, cause a few false positives, and the senders have the possibility of fixing the false positives. Unlikely in many cases, but I would quibble over 'less'. Overall, most corporate minds seem to think that they prefer false negatives to false positives, so they are extremely reluctant to adopt any strategy that increases the chance of a false positive, even under such strange I think you missed something important. Creating the records I suggest can create no false positives. That point is critical to this idea. Either they participate, and get their sending IPs whitelisted, or they don't participate, and they don't get their IPs whitelisted and mail from those IPs is more likely to be flagged as spam. Unless they send spam, in which case they'll get blacklisted. Which would be worse than not participating. So they should be really sure not to whitelist any IPs that send spam. And of course just as in existing IP blacklists, it is worth taking someone off a blacklist if they have corrected their spam problem. Not flawless, but still way easier than maintaining an IP blacklist. Another feature already covered by a blacklist, and, already being bypassed by numerous spammers who are smart enough to buy a domain name months before they use it. (shrug) Good to know. It still doesn't concern me. This would still eliminate spams from the vast majority of IPs for which spammers aren't delegated to host PTR records. And if all spam has a verified paper trail (delivering IP - domain - registrar who can be subpoened), I think the sending of spam itself will be a lot easier to stop. But *why* do they refuse to 'fix' their forwarding? I strongly suspect I don't know. that the same reasoning would apply to their decision to not implement SPF or your IP-based filter idea. Except that it causes me no problems if they don't implement my whitelisting. On 02/09, Charles Gregory wrote: Those administrators will say that they do not have control over DNS, because that's done at a higher organizational level, or that they don't want to do something that is not 'standard' and will tell their users to find another way to communicate with you. Same BS that is used to dodge I'm comfortable with that possibility. As I said, I expect benefit even without people participating. -- The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents. http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
On 02/09, RW wrote: A compromised webserver with full-circle DNS would be caught by this. My point is that is the only class of spam that this could help with Ah, sorry, I thought you meant mail server. Still, I don't understand why you're saying this. It would also block, for example, spam from a dynamic cablemodem IP. And everything that it didn't block could be blocked by blacklisting domains which have MTX records for spamming IPs. Every thing else is either handled by full-circle and no DNS tests, Full circle DNS tests don't block spam from quite a lot of IPs. or can be easily worked around by spammers setting their own dns. Spammers can't create DNS records for hostnames for IPs they don't own (don't have PTR authority delegated to them for). -- Life is but a walking shadow, a poor player that struts and frets his hour upon the stage--and then is heard no more. It is a tale told by an idiot, full of sound and fury, signifying nothing. - William Shakespeare http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010, dar...@chaosreigns.com wrote: So rather than mimicing SPF, you want to mimic the effect of various IP-based blacklists to which an ISP can report all of its 'unauthorized' IP's (typicalyl dynamic IP blocks)? Basically, except of course that the default, when not participating, is effectively blacklisting (in the sense in which SA uses blacklists to increase the spammines score of an email). LOL Good luck with that. The first time that an important e-mail correspondent (money!) is blocked by such a 'default' setting, the sysadmins will be rushing to cripple this default action. You will never succeed in introducing ANY spam filtering system that blocks mail based upon an 'undecided' or 'neutral' status. . Large companies which frequently reorganize their IP blocks will shy away from such a system, and smaller companies will lack the time/resources to implement anything that isn't 'out of the box'. I disagree. I can implement it now (in fact I expect to... For your own use, sure. But that's just like SPF. A bunch of people will use it, and a bunch, including ones that you still *really* want to communicate with, will NOT. Have you figured out how you are going to sell 'hotmail' and 'gmail' on your idea? Or are you just going to block all mail from them? Your choice. But if you have multiple users, well, you had better choose conservatively. (grin) So I block some more spam, and I get some extra false positives, and the senders get notified. And every hotmail user will be writing to the you complaining they have no way to talk hotmail into adopting your system, and begging you to *remove* the 'block'. And if you stick to your guns, those are people who, by no choice of their own, you will not hear from again. And if you have users who stop hearing from good friends and relatives, they won't be yuour users much longer. As I said before, 'in a perfect world' your idea would work. But sadly, not in THIS one I think you missed something important. Creating the records I suggest can create no false positives. That point is critical to this idea. The FP's would occur on the systems *looking* for those records, and scoring positively in SA for simply not finding them. Your argument, and all of mine here, are not about the simplistic task of creating a DNS record, but about the battle to have the scoring/testing protocol implemented to make those records 'useful'. Either they participate, and get their sending IPs whitelisted, or they don't participate, and they don't get their IPs whitelisted and mail from those IPs is more likely to be flagged as spam. Expressed as a 'whitelist only' mechanism that at least opens the door to a possibility of avoiding the fears of implementation, but again, you face the same lethargy and fear that keeps SPF from benig widely adopted Good to know. It still doesn't concern me. This would still eliminate spams from the vast majority of IPs for which spammers aren't delegated to host PTR records. And if all spam has a verified paper trail (delivering IP - domain - registrar who can be subpoened), I think the sending of spam itself will be a lot easier to stop. If ISP's just blocked port 25 access for their DSL customers a great deal of spam would be stopped. And that is SO easy to do. Think about that. If you can't even talk ISP's into such a simple approach, truly free of any false positive, then how can you expect 'reason' regarding a system that you admit has to have a bigger chance of false postitives? Except that it causes me no problems if they don't implement my whitelisting. Then it will cuase you no problem at all if they just don't implement anything at all? Those administrators will say that they do not have control over DNS, because that's done at a higher organizational level, or that they don't want to do something that is not 'standard' and will tell their users to find another way to communicate with you. I'm comfortable with that possibility. As I said, I expect benefit even without people participating. Is this 'all about you'? If so, then just whitelist your own correspondents and save us all the trouble of debating a DNS PTR system that benefits no one but you. If you intend to introduce a new idea for broad adoption, then it needs to benefit everyone. And 'everyone' is not giong to be 'comfortable with that possibility' that you are :) - C
Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: On 02/09, Kris Deugau wrote: Spammer mail originates from 10.0.0.2 (static IP assigned by ISP). PTR record is 2.0.0.10.in-addr.arpa - exchange.smallbusiness.com 2.0.0.10.mtx.exchange.smallbusiness.com - 127.0.0.1 because this is the recognized designated outbound relay for Small Business's legitimate mail, and they've followed your proposal. How is the spam to be *not* considered a legitimate sender in this case? Even if the Exchange server isn't actually processing the email, its public IP will still be the originating IP of the message. Blacklist the validating domain smallbusiness.com. Reject all email that has a *.mtx.*.smallbusiness.com record. Just as you would blacklist the sending IP for spamming. As with SPF, I expect this to be quite a lot easier than maintaining a blacklist of spamming IPs. If I'm wrong on that one point, this is useless. I'm still not seeing the whole picture; maybe you can explain the difference between these two cases: 1) Legitimate sender, uses the NAT machine as the legitimate, designated relayhost. So far as a remote system is concerned, the mail originates from an IP (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). Remote system takes the IP, gets the PTR, and looks up 2.0.0.10.mtx.exchange.smallbusiness.com, and gets 127.0.0.1. Yay! Good mail, let's let it through! 2) Spam, from an infected machine on the same LAN, either via relay through the NAT box, or using its own SMTP engine to do direct-to-MX So far as a remote system is concerned, the mail originates from an IP (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). Remote system takes the IP, gets the PTR, and looks up 2.0.0.10.mtx.exchange.smallbusiness.com, and gets 127.0.0.1. Yay! Good mail, let's let it through! Would you still like more detail on what pieces of information I'm looking at, and where I'm getting them from? Obviously I've missed *something* about what you've been trying to describe, but I haven't seen any indication that you're working with **ANYTHING** other than the PTR record for the (apparent) originating IP (which, for a small business on a single static-IP connection, may or may not even have anything to do with the business's own domain(s) at all), and some arbitrary (sub^n)domain A record based on the PTR. About all your scheme seems to do is identify IPs which may emit legitimate email, generally; it's certainly nothing I'd score at anything more than an advisory -0.001 in SA. Consider the case of a legitimate ISP's outbound relay - most of the mail is perfectly legitimate, but sooner or later *someone* on an IP controlled by that ISP (and therefore allowed to relay through that outbound relay host) will have their machine infected or someone with an account with that ISP will have their password stolen, and then that infected machine will spew out junk via the relay, or a machine somewhere else will use that stolen password to send SMTP AUTH mail through that relay We regularly see both of those cases here (medium-sided ISP). The more I think about it and the more I read of what you're describing, the more most of it seems like a reasonable component of any blacklist operation, not a whole FUSSP[1] in its own right. [1] http://www.claws-and-paws.com/fussp.html, among other references -kgd
Newest spammer trick - non-blank subject lines?
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!! 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 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: Spam filtering similar to SPF, less breakage
Charles: Thanks, I clearly need to lay out implementation sequence. 1) People who are sufficiently entertained by the subject create MTX records for our servers, and collect blacklists of domains which create MTX records for spamming IPs. 2) New SA capability is implemented: A) Blacklisting by the domain of the PTR record of the sending IP (MTX_BL). B) Verifying IPs against MTX records (MTX_PASS / MTX_FAIL). 3) Conservative people use these new tests to reduce false positives: score MTX_BL 1 score MTX_PASS -1# Only hit if MTX_BL wasn't. score MTX_FAIL 0.001 People with less need to be conservative, perhaps with SA configured to report false positives to non-forged senders, use more aggressive scores: score MTX_BL 2 score MTX_PASS -2 score MTX_FAIL 1 4) In order to reduce false positives, more people create MTX records. 5) Due to 4, MTX_FAIL scores can safely be increased slightly without increasing false positives. 6) Go to 4. One day, due to steps 4-6, enough people have created MTX records that all email without one can reasonably be rejected by the MTA. Are you willing to, right now, create a IP (reversed).mtx.hostname DNS record for all your transmitting mail servers? If not, why not? Any thoughts on the format of that record yet? On 02/09, Charles Gregory wrote: LOL Good luck with that. The first time that an important e-mail correspondent (money!) is blocked by such a 'default' setting, the sysadmins will be rushing to cripple this default action. You will never succeed in introducing ANY spam filtering system that blocks mail based upon an 'undecided' or 'neutral' status. This is a good point. This is also why I suggested starting out with a low score, for most people. Of course I'll use something around 4 to 4.5. I disagree. I can implement it now (in fact I expect to... For your own use, sure. But that's just like SPF. A bunch of people will use it, and a bunch, including ones that you still *really* want to communicate with, will NOT. Have you figured out how you are going to sell 'hotmail' and 'gmail' on your idea? Or are you just going to block all mail from them? Your choice. But if you have multiple users, well, you had better choose conservatively. (grin) Did my implementation sequence above sufficiently cover this? Even with a MTX_FAIL score of 4.5, it still won't block the vast majority of email I get from gmail. And I certainly wouldn't switch to blocking all email without an MTX record without gmail adopting them. And I do think there is a decent possibility of gmail eventually adopting MTX records due to the sequence I described. And every hotmail user will be writing to the you complaining they have no way to talk hotmail into adopting your system, and begging you The vast majority of legit mail will still get through even with my high MTX_FAIL score. And if the complaints get annoying, I'll lower it. And really, everybody that's currently getting a score of 0.5+ score from SA, I'm happy to never hear from again. And even if nobody gives MTX_FAIL a positive score, I still expect MTX records to be adopted to reduce false positives, making it reasonable to gradually use slightly higher MTX_FAIL scores. I think you missed something important. Creating the records I suggest can create no false positives. That point is critical to this idea. The FP's would occur on the systems *looking* for those records, and scoring positively in SA for simply not finding them. Your argument, and all of mine here, are not about the simplistic task of creating a DNS record, but about the battle to have the scoring/testing protocol implemented to make those records 'useful'. No, actually, I was arguing for the simplicity of creating the DNS records. I realize it'll be a while before major email providers start giving MTX_FAIL significant positive values. The records are immediately useful for whitelisting to reduce false positives. -- We will be dead soon. Is this how we want to live? http://www.ChaosReigns.com
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: Spam filtering similar to SPF, less breakage
On 02/09, Kris Deugau wrote: I'm still not seeing the whole picture; maybe you can explain the difference between these two cases: 1) Legitimate sender, uses the NAT machine as the legitimate, designated (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). 2) Spam, from an infected machine on the same LAN, either via relay (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). The IP is sending spam, so it gets blacklisted (by a blacklist of domains which have MTX records for spamming IPs). Obviously I've missed *something* about what you've been trying to describe, but I haven't seen any indication that you're working with **ANYTHING** other than the PTR record Yes. for the (apparent) originating IP Nothing apparent about it. The delivering IP (last untrusted relay) is the only thing in an email that can't be forged. (which, for a small business on a single static-IP connection, may or may not even have anything to do with the business's own domain(s) at all), Indeed, so they would need to get whoever is delegated the authority to provide PTR records for that IP to create the necessary records. Two options where smallbusiness.com doesn't have the ability to define its own PTR records. For example, the PTR record is defined by isp.com. 1) isp.com sets the PTR record to exchange.smallbusiness.isp.com, and creates the MTX record for it (2.0.0.10.mtx.smallbusiness.isp.com with a value of 127.0.0.1). If 10.0.0.2 sends spam, isp.com gets blacklisted. 2) isp.com sets the PTR record to exchange.smallbusiness.com, and smallbusiness.com creates their own MTX record (2.0.0.10.mtx.smallbusiness.com = 127.0.0.1). If 10.0.0.2 sends spam, smallbusiness.com gets blacklisted. and some arbitrary (sub^n)domain A record based on the PTR. Yes. That's all. What format should this arbitrary A record be? About all your scheme seems to do is identify IPs which may emit legitimate email, generally; it's certainly nothing I'd score at anything more than an advisory -0.001 in SA. Of course, unless you use a blacklist of domains which have MTX records for spamming domains. Consider the case of a legitimate ISP's outbound relay - most of the mail is perfectly legitimate, but sooner or later *someone* on an IP controlled by that ISP (and therefore allowed to relay through that outbound relay host) will have their machine infected or someone with an account with that ISP will have their password stolen, and then that infected machine will spew out junk via the relay, or a machine somewhere else will use that stolen password to send SMTP AUTH mail through that relay We regularly see both of those cases here (medium-sided ISP). It's an issue of blacklisting. What is involved in keeping your ISP off of IP blacklists? The more I think about it and the more I read of what you're describing, the more most of it seems like a reasonable component of any blacklist operation, not a whole FUSSP[1] in its own right. [1] http://www.claws-and-paws.com/fussp.html, among other references I have been directed to that url frequently in the last few days :) -- For every complex problem, there is a solution that is simple, neat, and wrong. - H. L. Mencken http://www.ChaosReigns.com
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: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: For every complex problem, there is a solution that is simple, neat, and wrong. - H. L. Mencken I think your auto-quote program is trying to tell you something... :) -- Bowie
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Newest spammer trick - non-blank subject lines?
From: Ted Mittelstaedt t...@ipinc.net
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: dar...@chaosreigns.com
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: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010 14:15:37 -0500 dar...@chaosreigns.com wrote: On 02/09, RW wrote: A compromised webserver with full-circle DNS would be caught by this. My point is that is the only class of spam that this could help with Ah, sorry, I thought you meant mail server. Still, I don't understand why you're saying this. It would also block, for example, spam from a dynamic cablemodem IP. Aside from a few corner cases, I don't see any advantage over checking for full circle DNS And everything that it didn't block could be blocked by blacklisting domains which have MTX records for spamming IPs. The same thing applies to full circle DNS Every thing else is either handled by full-circle and no DNS tests, Full circle DNS tests don't block spam from quite a lot of IPs. But how many of those are neither mail-servers, nor spammer controlled ip ranges. My guess is that the kind of spam your scheme would identify is mostly caught by other means. The chief problem is that there is no way to use this scheme until it has *very* high adoption, below 95% it wouldn't even be worth scoring at 0.5 in Spamassassin. With SPF you at least know the difference between a fail and a non-adopter. Whilst you could identify compliant servers there's no way that that would warrant anthing more than a nominal negative score. SPF_PASS scores -0.001 or can be easily worked around by spammers setting their own dns. Spammers can't create DNS records for hostnames for IPs they don't own (don't have PTR authority delegated to them for). I was referring to IP ranges that they do control
Re: Newest spammer trick - non-blank subject lines?
From: Ted Mittelstaedt t...@ipinc.net
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=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: mau...@ionizer.nl 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 newu...@ipinc.net; Tue, 9 Feb 2010 14:22:35 -0800 (PST) (envelope-from mau...@ionizer.nl) From: Bugarewicz mau...@ionizer.nl 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: mau...@ionizer.nl X-Envelope-To: newu...@ipinc.net 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 mau...@ionizer.nl From: Bugarewicz mau...@ionizer.nl 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 t...@ipinc.net 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: [sa] Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010, dar...@chaosreigns.com wrote: Charles: Thanks, I clearly need to lay out implementation sequence. Sorry to be wasting your time, but I am smart enough to have grasped it from your previous e-mails. You just WANT your solution to be magically adopted by everyone and you seem to be completely dismissing/ignoring the real and practical improbability of any widespread implementation Are you willing to, right now, create a IP (reversed).mtx.hostname DNS record for all your transmitting mail servers? If not, why not? Because it does not benefit me or my users. You have failed to convince me that any significant widespread implementation will occur, and have not demonstrated any signficant new benefits that make your idea any more appealing than existing SPF and white/blacklists. For me, it is simpler to forward mail in an SPF-compatible fashion, and require SMTP Auth through one server designated with SPF-PASS. Haven't done that yet, for similar reasons. :) Any thoughts on the format of that record yet? Take a look at the format used by SPF. You are eliminating the cross-reference to sender address, but otherwise, all the subtle nuances are the same. Which still leads me back to 'why should I bother to participate in reinventing the wheel' Anyways, this is my fin du conversation - C
3.3.0 spamd using tcpwrappers?
Only observed so far on Debian lenny though, can't reproduce it on CentOS 4 or 5, nor Debian etch. Anyone else met up with this? I *really* don't want to have to maintain IP access lists for spamd in two places (spamd init script and hosts.allow). -kgd
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: On 02/09, Kris Deugau wrote: I'm still not seeing the whole picture; maybe you can explain the difference between these two cases: 1) Legitimate sender, uses the NAT machine as the legitimate, designated (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). 2) Spam, from an infected machine on the same LAN, either via relay (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). The IP is sending spam, so it gets blacklisted (by a blacklist of domains which have MTX records for spamming IPs). ... So what incentive do I as: (pick any one or more hats below) ISP mail/DNS admin Colo/self-hosted domain admin Inbound mail admin have to either set up this extra A record, or check for it, that existing blacklists don't provide? Chicken-egg. Where do you draw the lines for adding someone to a/the blacklist? 0.0001% spam? 0.01%? 1%? How would you publish the blacklist? Globally? Rely on individual local DNS operators running their own blacklist? (Good luck getting *off* ten million local blacklists...) Two options where smallbusiness.com doesn't have the ability to define its own PTR records. For example, the PTR record is defined by isp.com. 1) isp.com sets the PTR record to exchange.smallbusiness.isp.com, and creates the MTX record for it (2.0.0.10.mtx.smallbusiness.isp.com with a value of 127.0.0.1). If 10.0.0.2 sends spam, isp.com gets blacklisted. Immediately? Would you *really* blacklist eg AOL, Hotmail, or Gmail if you received *one* spam from any of their networks? If you have paying customers using your mail systems, you'd be out of business in a matter of months. 2) isp.com sets the PTR record to exchange.smallbusiness.com, and smallbusiness.com creates their own MTX record (2.0.0.10.mtx.smallbusiness.com = 127.0.0.1). If 10.0.0.2 sends spam, smallbusiness.com gets blacklisted. and some arbitrary (sub^n)domain A record based on the PTR. Yes. That's all. What format should this arbitrary A record be? Aside from considerations above, what you've posted is fine, structurally. From a pure how to publish data perspective, a new DNS RR type would be slightly better, but reversed IPs concatenated to a subdomain is a well-established way to publish this type of data. About all your scheme seems to do is identify IPs which may emit legitimate email, generally; it's certainly nothing I'd score at anything more than an advisory -0.001 in SA. Of course, unless you use a blacklist of domains which have MTX records for spamming domains. Well, aside from getting tougher on customers with infected systems, how do you propose to actually stop the spam from being generated? If you can't stop that, you-as-ISP *CAN NOT* fully prevent spam from being relayed through your servers unless you unplug the network and power cables... Consider the case of a legitimate ISP's outbound relay - most of the mail is perfectly legitimate, but sooner or later *someone* on an IP controlled by that ISP (and therefore allowed to relay through that outbound relay host) will have their machine infected or someone with an account with that ISP will have their password stolen, and then that infected machine will spew out junk via the relay, or a machine somewhere else will use that stolen password to send SMTP AUTH mail through that relay We regularly see both of those cases here (medium-sided ISP). It's an issue of blacklisting. What is involved in keeping your ISP off of IP blacklists? Blocking outbound connections to port 25 from residential IP blocks, responding to reports (cutting of residential customers found to be infected, warning and eventually cutting off static-IP business customers; notifying users whose passwords seem to have been cracked or stolen - among other standard measures). It helps, and we've signed up for the feedback loop widgets with a number of places (AOL, Comcast), but there is NO WAY we can absolutely stop all spam from emitting from IP space under our control, short of turning off our core routers. This is not exactly unusual. The more I think about it and the more I read of what you're describing, the more most of it seems like a reasonable component of any blacklist operation, not a whole FUSSP[1] in its own right. [1] http://www.claws-and-paws.com/fussp.html, among other references I have been directed to that url frequently in the last few days :) g The form may be a bit tongue-in-cheek, but taking it at face value is helpful in seeing if you're really trying something new, or if you're just putting a new coat of paint on something that's already in practice as a small subset of a larger operation. (Or trying to resurrect a dead horse that was already beaten to a thin paste ten years ago. I don't think you've gotten *that* far yet.) TBH, what you seem to be trying to do seems far better suited to a local system
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: mau...@ionizer.nl 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 newu...@ipinc.net; Tue, 9 Feb 2010 14:22:35 -0800 (PST) (envelope-from mau...@ionizer.nl) From: Bugarewicz mau...@ionizer.nl 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: snip rest of message 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: snip to subject 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: mau...@ionizer.nl 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 newu...@ipinc.net; Tue, 9 Feb 2010 14:22:35 -0800 (PST) (envelope-from mau...@ionizer.nl) From: Bugarewicz mau...@ionizer.nl 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: snip rest of message 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: snip to subject 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 j...@earthlink.net: From: dar...@chaosreigns.com Sent: Tuesday, 2010/February/09 13:35 On 02/09, Ted Mittelstaedt wrote: Thunderbird.nbsp; 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 guent...@rudersport.de: 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: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010 18:02:09 -0500 dar...@chaosreigns.com wrote: On 02/09, RW wrote: And everything that it didn't block could be blocked by blacklisting domains which have MTX records for spamming IPs. The same thing applies to full circle DNS So you want to blacklist all domains that have *any* PTR records for IPs that send spam? Perhaps you should google full-circle dns if you don't understand what it means. Essentially there's little difference, unless you are happy to ignore spammers that get blacklisted and then remove the MTX record. If you are, then there's little point to listing them in the first place. Every thing else is either handled by full-circle and no DNS tests, Full circle DNS tests don't block spam from quite a lot of IPs. But how many of those are neither mail-servers, nor spammer controlled ip ranges. A lot? Spam bot nets. Spambots don't have full-circle DNS. The chief problem is that there is no way to use this scheme until it has *very* high adoption, below 95% it wouldn't even be worth scoring As I recently posted, it can be used for whitelisting (after blacklisting) immediately. And that use could increase creation of the relevant records gradually until they're wide spread. How could your scheme be used for whitelisting when a huge amount of spam comes through mail-servers that send a mixture of spam and ham? Would you really want to whitelist hotmail? This kind of argument was made about SPF - a pass still scores -0.001. SPF has a limited amount of enlightened self-interest about it. If you publish SPF records you get less backscatter - your scheme doesn't do that. There's nothing in your scheme to encourage anyone to use it. at 0.5 in Spamassassin. With SPF you at least know the difference between a fail and a non-adopter. Whilst you could identify compliant servers there's no way that that would warrant anthing more than a nominal negative score. SPF_PASS scores -0.001 Only with a domain blacklist. So why would anyone use it and risk being blacklisted, what's the point of it existing if you don't punish domains that don't join - any that get on the blacklist could just drop-out of the scheme.
Re: Newest spammer trick - non-blank subject lines?
From: Karsten Bräckelmann guent...@rudersport.de
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 t...@ipinc.net
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: mau...@ionizer.nl
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 newu...@ipinc.net; Tue, 9 Feb 2010 14:22:35 -0800 (PST)
(envelope-from mau...@ionizer.nl)
From: Bugarewicz mau...@ionizer.nl
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 t...@ipinc.net
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.
{^_^}
best way to catch spams and fine tune the bayes
Hi its been 30days now i have setup a new qmail server with spamassassin 3.2.5 works well, but iam using here simscan i use to get in my old server lot of virus and spam emails so we made strict rules now, like if simscan detect spam we are rejecting the total mail either it can be from incoming or outgoing. may be i see now the trafic now is less compare to 30days back now i would like to give a relaxation to simscan to allow even if the spam captured. so i can use sitewide configuration to configure spamassassin to catch more spams here is my question iam running deamon user spamd its located in /home/spamd so how can i configure side wide bayes to capture more bayes iam running sa-update cron. its upto date. Ram
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: best way to catch spams and fine tune the bayes
On Wed, Feb 10, 2010 at 9:13 AM, ram talk2...@gmail.com wrote: Hi its been 30days now i have setup a new qmail server with spamassassin 3.2.5 works well, but iam using here simscan i use to get in my old server lot of virus and spam emails so we made strict rules now, like if simscan detect spam we are rejecting the total mail either it can be from incoming or outgoing. may be i see now the trafic now is less compare to 30days back now i would like to give a relaxation to simscan to allow even if the spam captured. so i can use sitewide configuration to configure spamassassin to catch more spams here is my question iam running deamon user spamd its located in /home/spamd so how can i configure side wide bayes to capture more bayes iam running sa-update cron. its upto date. I have enabled in local.cf learn bayes to 1 still i see 0 records sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 0 0 non-token data: nspam 0.000 0 0 0 non-token data: nham 0.000 0 0 0 non-token data: ntokens 0.000 0 0 0 non-token data: oldest atime 0.000 0 0 0 non-token data: newest atime 0.000 0 0 0 non-token data: last journal sync atime 0.000 0 0 0 non-token data: last expiry atime 0.000 0 0 0 non-token data: last expire atime delta 0.000 0 0 0 non-token data: last expire reduction count ram
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
spamassassin /etc/shadow access
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. Regards, Dw. -- dr Tóth Attila, Radiológus, 06-20-825-8057, 06-30-5962-962 Attila Toth MD, Radiologist, +36-20-825-8057, +36-30-5962-962
Re: Spam filtering similar to SPF, less breakage
On Tue, 2010-02-09 at 11:42 -0500, dar...@chaosreigns.com wrote: I apparently need to clarify that I think this is a good idea because I am concerned about the number of people (who control DNS records) who are very strongly against creating SPF records specifically because of forwarding breakage. The email I got in response to my request for my employer to create an SPF record included the word abomination. From a friend. I don't entirely agree, but it is a problem for adoption. This is entirely an attempt to replicate the functionality of SPF without breaking forwarding, and without causing other problems that might discourage adoption. How does this idea authenticate mail from domain ? SPF is aimed at doing that. IMHO the SPF-breaks-forwarding argument is misplaced What about SRS. If SRS implementation is not going to be easy because mailservers have been there too long for adopting anything new then can your be sure MailServer IP validation will be adopted ? Anyway I block spams from almost all non-mailservers by using RBL's I dont see any value add in implementing this Thanks Ram I set this up for my mail server (using mtx instead of designatedsender): $ host -t PTR 64.71.152.40 40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com. $ host -t A 40.152.71.64.mtx.panic.chaosreigns.com 40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1 All it took was creating a single record in bind: 40.152.71.64.mtx.panic.chaosreigns.com. IN A 127.0.0.1 I'll define it slightly differently: 127.0.0.1 is a pass (negative SA score). not found is a fail (positive SA score). 127.0.0.0 is a fail (positive SA score). Anything else is undefined (0 SA score) for future options. I'd still appreciate feedback on the format of the A record. On 02/09, RW wrote: You've mixed-up A record and PTR record. Yes. Embarrassing. Checking for full-circle DNS already does most of this. My home dynamic cablemodem address passes full-circle DNS. But not this. So this is far more useful for checking if an IP is a legitimate sending mail server. What your scheme would do is check for otherwise legitimate servers that have been compromised and are delivering direct-to-mx. An otherwise legitimate but compromised mail server would not be detected by this. I'm curious why you interpreted it differently. On 02/09, Charles Gregory wrote: On Mon, 2010-02-08 at 22:08 -0500, dar...@chaosreigns.com wrote: What you describe here is functionally similar to an SPF lookup with a 'pass' result. The server provides positive verification that the listed IP is a legitimate sender for that domain. Yes. As long as 'otherwise' is a definitive 'fail' response from an SPF (or equivalent) server, and not merely an absence of SPF server Yes. Definitive fail. Your method would allow 'spoofing' so that a spammer who hacks a legitimate server can use a valid return address on a different domain, but still the mail would receive a 'passing' grade. At least, with SPF, the spammer must forge an address on the hacked domain, which increases the likelihood of detection Yes. I would blacklist domains that pass hacked servers. Just as IPs of hacked servers are blacklisted. They're sending spam, and need to be fixed. Forwarding doesn't break. Ah, so you want to allow 'legitimate' forwarding, but not allow spammers to 'forward' their mail? Good luck with that. The only way to make it work for the legitimate sender, but not for spammers is to have a mechanism built-in to the forwarding server that encapsulates or rewrites the envelope 'From' address. Encapsulating or rewriting the envelope 'From' address seems significantly less likely to be adopted from what I've read. Obviously you'd need a blacklist of spammer domains that list spamming IPs as legit senders. And you would be playing the same 'musical chairs' game with new domains created by spammers on a daily basis. All the same flaws of SPF, and no greater benefit. Same domain blacklisting issues as SPF, yes. I am not very concerned about the throw-away domains because I'll reject all mail from domains not at least 10 days old. 10+ day old domains are already listed as 127.0.2.3 records from example.com.hostkarma.junkemailfilter.com. I believe the benefit of not breaking forwarding is sufficient to make it much more useful than SPF for spam filtering. I've come across enough people, personally, recently, in trying to block (some = positive SA score) emails without an SPF pass, who are not willing to ever implement SPF due to breaking forwarding that I believe this would be useful. Is there any way this wouldn't be very useful? Is there any place where SPF does not do the same job, other than mail forwarding? No. But as I said, I am concerned about the
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
