Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).
John Hardin wrote: What's odd here is it sounds like you're describing messages that have been received from a third-party MTA rather than an external MUA, so they _should_ have a Received: header added by that MTA. On 01.12.09 08:50, Per Jessen wrote: Yes, most would be coming from a third-party MTA - except for most of the spam :-) so, is it the spam which you want prevent from checking by SA? :) Seeing the headers from one of these would be helpful, can you post a sample? Body not needed. What I'm looking for is the presence of any Received: header not added by _your_ MTA. I would wager that the problematic messages when examined in your queue will only have one Received: header. Here is one example: http://jessen.ch/files/email77 I see headers here byt they all seem to be added by inbound.spamchek.net which is I guess your machine. It is message generated by mail2.emirates.net.ae and the generating host did not create any Received: header (apparently since it did not receive the message - it only created it and sent it to you). The really weird thing is that when I run that through SA manually with spamassassin -t -x , there is no problem. It's because at time you scan the message, the headers were already added by your MTA. That's why I'd like to have something like score NO_RELAYS die to make spamd quit processing it. well, you can shortcircuit on NO_RELAYS but I think you should either fake Received: headeror use a program that does it (like milter) -- 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. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).
Matus UHLAR - fantomas wrote: Seeing the headers from one of these would be helpful, can you post a sample? Body not needed. What I'm looking for is the presence of any Received: header not added by _your_ MTA. I would wager that the problematic messages when examined in your queue will only have one Received: header. Here is one example: http://jessen.ch/files/email77 I see headers here byt they all seem to be added by inbound.spamchek.net which is I guess your machine. Yup. It is message generated by mail2.emirates.net.ae and the generating host did not create any Received: header (apparently since it did not receive the message - it only created it and sent it to you). Yep, it's just a DSN. The really weird thing is that when I run that through SA manually with spamassassin -t -x , there is no problem. It's because at time you scan the message, the headers were already added by your MTA. But that goes for _both_ situations - in spamd and in the manual run. The message is first seen by my smtpd#1, the Received: header is added, and then I call the smtp proxy to run spamd. /Per Jessen, Zürich
Re: FP on blacklist hostkarma
On tir 01 dec 2009 02:16:04 CET, wrote I believe Raymond's response was addressing the fact a server connection could possibly be interrupted before it had a chance to issue the SMTP QUIT command. I would think being listed for that alone would be ridiculous. On 01.12.09 02:20, Benny Pedersen wrote: if its this i would agree, cant exim see diff in not sending quit or drop connection ? postfix have lost connection, spam sign ? It may depend on the number of lost connections. Marc said he's investigating the problem, let's see the result -- 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. Spam is for losers who can't get business any other way.
Re: FP on blacklist hostkarma
Benny Pedersen wrote: I believe Raymond's response was addressing the fact a server connection could possibly be interrupted before it had a chance to issue the SMTP QUIT command. I would think being listed for that alone would be ridiculous. if its this i would agree, cant exim see diff in not sending quit or drop connection ? It can. This is exactly what makes the noquit list possible. Exim has two relevant ACLs. One that is run when the connection is closed after a QUIT, and one that is run when the connection is closed without a QUIT. So one of those two is run at the end of every connection, depending on how it ended. As I understand it, Marc has added some configuration to his system so that when the Closed without QUIT ACL is run, he adds the IP address to a queryable list. It is described here: http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists#Tracking_use_of_QUIT It is described as Experimental His list gives three responses: * 127.0.1.1 - QUIT is used * 127.0.1.2 - No QUIT is used * 127.0.1.3 - Mixed - Quit is used sometimes If you don't want the Closed without QUIT part of the list, there's nothing stopping you from using every other feature of his lists without using this particulary part. You wouldn't use a DNSBL without knowing how it works first would you? When I say, you, I'm refering to the people using the JMF lists, not specifically you Benny. -- Mike Cardwell - IT Consultant and LAMP developer Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/ Technical Blog: https://secure.grepular.com/blog/
Re: Scoring for DATE_IN_FUTURE_96_XX
Thomas Harold wrote: On 11/30/2009 9:27 PM, Thomas Harold wrote: While looking at the scores in 50_scores.cf, I noticed the following: score DATE_IN_FUTURE_03_06 2.303 0.416 1.461 0.274 score DATE_IN_FUTURE_06_12 3.099 3.099 2.136 1.897 score DATE_IN_FUTURE_12_24 3.300 3.299 3.000 2.189 score DATE_IN_FUTURE_24_48 3.599 2.800 3.599 3.196 score DATE_IN_FUTURE_48_96 3.199 3.182 3.199 3.199 score DATE_IN_FUTURE_96_XX 3.899 3.899 2.598 1.439 Why does the 96+ hour rule score so much lower then the 48-96 hour test for the last two entries? (I'm also wondering if there should be an even higher score rule for stuff over 168 hours in the future or past.) I did dig up the following thread from back in Oct '06... http://mail-archives.apache.org/mod_mbox/spamassassin-users/200611.mbox/browser I'm guessing that what it boils down to is contained in the wiki page? The spam is better off caught by another rule once network tests are allowed? Yep, since SA is scored as a set, score stealing between rules is pretty common when there's a lot of overlap between two rules and one performs slightly better than the other. It's also possible for there to be more complicated cascades where one rule affects another, which in turn affects a third, which affects a fourth... Also looking at the above scores, there's likely no spam network tests that cover the same mail as 48_96, because its score is pretty much the same. On average the scores of all non-network spam rules should go down a little bit when the network tests are enabled there are more rules in the set competing for score. However since the distribution of hits across rules is distinctly not random, you'll see a lot of non-average cases, which means some rules will be: staying the same because they cover mail the network tests don't going down radically due to heavy overlap going up because they correct false negatives in some of the non-spam network tests. http://wiki.apache.org/spamassassin/HowScoresAreAssigned
Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).
On Tue, 1 Dec 2009, Per Jessen wrote: John Hardin wrote: On Mon, 30 Nov 2009, Per Jessen wrote: John Hardin wrote: That proxy shouldn't pass a message to spamd unless it has a Received: header, and I would suggest that it should not pass a message to spamd unless it has a Received header that was added by the local MTA; A message will always have one of those. That is what is so mind-boggling. No, there are circumstances when it won't. The MUA generally does not add a Received: header when it composes the message headers for a new message, it's up to the MTAs to do that. So the message sent from the MUA to the first MTA will likely not have a Received: header (modulo forgery, of course, and things like webmail MUAs). The MUA will start a conversation with my first smtpd - that will cause a Received: header to be added. The message is then queued, to be picked up by the smtp proxy which invokes spamd. In this situation, there will always be at least one Received: header. Okay, I misunderstood your mail architecture then. What's odd here is it sounds like you're describing messages that have been received from a third-party MTA rather than an external MUA, so they _should_ have a Received: header added by that MTA. Yes, most would be coming from a third-party MTA - except for most of the spam :-) :) Well, the spam _pretends_ it comes from an MTA so for the purposes of Received: headers we can ignore bots. In the messages that fail in this manner is there only a single Received: header, for the local MTA hop? Yep. That's the one I'm absolutely certain must be present. Yes, but that one is only present _after_ your local MTA has added it. Correct. If you are intercepting inbound mail prior to your MTA (as it sounds like you're doing with your proxy) then it's very possible you will see messages without any Received: header. No, the message is queued first, then passed to spamd. In that case I can't understand why there would not be a local Received: header. Seeing the headers from one of these would be helpful, can you post a sample? Body not needed. What I'm looking for is the presence of any Received: header not added by _your_ MTA. I would wager that the problematic messages when examined in your queue will only have one Received: header. Here is one example: http://jessen.ch/files/email77 MISSING_DATE,MISSING_HEADERS,MISSING_MID,MISSING_SUBJECT,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS Wow. I would suggest you look closely at your proxy. Are you _positive_ it's in the mail stream at the point you think it is? Are you _positive_ that it will always see a complete message (i.e. headers and body)? You might want to try adding logging and message capture to your proxy while you're troubleshooting this. It looks like somehow it's getting only the body of the message for some messages. The really weird thing is that when I run that through SA manually with spamassassin -t -x , there is no problem. Is that taking the message from the queue of the first real MTA, or the second? That's why I'd like to have something like score NO_RELAYS die to make spamd quit processing it. That's probably not going to happen. The scan/no-scan decision has to be made upstream. -- 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 --- Individual liberties are always loopholes to absolute authority. --- 14 days until Bill of Rights day
Re: FP on blacklist hostkarma
On Dienstag, 1. Dezember 2009 Raymond Dijkxhoorn wrote: So if you have a crappy connection towards your mailserver Marc you can get listed, thats rather funny, and annoying. Connections do break also when not running a botnet... pfff It's not that you get listed, but all of your customers who want to send you mail :-( BTW, another FP: http://ipadmin.junkemailfilter.com/remove.php?ip=62.179.121.43 mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: curl -s http://zmi.at/zmi.asc | gpg --import // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 signature.asc Description: This is a digitally signed message part.
Re: Filter question
thanks everyone! chucker8 wrote: Hello, I'm looking at spamassassin for our compnay's spam solution. We receive emails from u...@theirdomain.com, where the domain in correct but the user would be for instance, Viagra, which does not exist. We needthe spam software to realize that this user does not exist and register the email as spam. Is there any way to do this with SpamAssassin? thanks! -- View this message in context: http://old.nabble.com/Filter-question-tp26581365p26593098.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Filter question
On 11/30/2009 7:36 PM, Benny Pedersen wrote: and what happend is spammers just send to random email addresses and discover user not found ?, nothing mta can do about this Well, in that case (a dictionary attack spam run where they just try all the common names), it would light up red flags in the anti-spam system and possibly get them blacklisted. At least, that's how it worked prior to massive botnets that act in a coordinated fashion so that each bot'd machine only hits a mail server a few times instead of dozens/hundreds. But at least it raised the difficulty level so that they have to do a distributed and coordinated botnet now... (I still see regular dictionary style attack runs on our mail system.) postfix reject_unverified_sender does a vrfy ?, if remote have vrfy disabled it try even harder to use rcpt to i am unsure if postfix really does it or not Yes, I made the bad assumption that Postfix tries the VRFY command. Wolfgang has it right. http://www.postfix.org/ADDRESS_VERIFICATION_README.html I've never used the feature as the first paragraph states: The sender/recipient address verification feature described in this document is suitable only for low-traffic sites. It performs poorly under high load; excessive sender address verification activity may even cause your site to be blacklisted by some providers. And reading through the rest of it seems more like here's a very sharp tool that will probably hurt you if you don't take these half-dozen steps before using it.
Re: Is there a way of forcing spamd not to process malformed messages? (NO_RELAYS, NO_RECEIVED etc).
John Hardin wrote: No, the message is queued first, then passed to spamd. In that case I can't understand why there would not be a local Received: header. Yeah ... MISSING_DATE,MISSING_HEADERS,MISSING_MID,MISSING_SUBJECT,NO_HEADERS_MESSAGE,NO_RECEIVED,NO_RELAYS Wow. I would suggest you look closely at your proxy. Are you _positive_ it's in the mail stream at the point you think it is? Are you _positive_ that it will always see a complete message (i.e. headers and body)? Well, I'm beginning to have some doubts now, but it has been working fine for the last two-three years. I'll have to double check my code - maybe there's a weird corner case that's becoming more and more exposed (for whatever reason). That's why I'd like to have something like score NO_RELAYS die to make spamd quit processing it. That's probably not going to happen. The scan/no-scan decision has to be made upstream. It was just a thought - although it doesn't really sound like a scan/noscan decision. I mean, the message has already been scanned, but it has a condition that - according to my rules - makes it an invalid scan/message. I'm looking through the code to see if I can the right place. /Per Jessen, Zürich
Re: Filter question
If it is from obviously bogus senders, perhaps some rules like these might be helpful (note that lines are wrapped): headerTBI_FROM_MISCFrom =~ /((GiftCardDivision|WarrantyExtension|viagra|HairClubOffers|goldcash|BabyOffersDept |CashLoanProvider|Rebate_Processor_Position|RebateProcessorPosition|CastingCall |Grant_Info|Government_Grants|Secret\.Shopping|Rebate_Processor|ColonCure|DebtRelief |eHarmonyBetterDating|GetYourGrantNow|cardinalexponents_offer|OnlineAuctionPro |OnlineGiftRewards|ExtendWarranty|TopBrandSamples|ProcessatHome|TargetGiftCard |HomeImprovementDepartment|MillionDollarReward|GovernmentsGrants|HealthyOffer |Gevalia|Vegas4Free|wsenews|123Inkjets|SUPERAUCTIONPRO|Granteducation|CashBackRewardsVISA |CardsAndCalendars|OxiClean|DoubleYourMileage|AccreditedDegreePrograms|ForexOptimizer |EraseYourWrinkles|Loseweightnow|DunhillVacationNews|KitchenGiveaways|MedicalBillingir| ElectronicsSupremeSavings|SamsungWasherDryer|GevaliaKaffe|Platinum_Cards|Government_Grants |yourwalmartgiftcard|ProcessRebates|RedemptionCenter|Insurance_agent|SwissGoldInvestments |BizCardsOnLine|athometypers|DebtConsolidation|GoGreenOffers|CarFinancingSite |TaxSolutionsToday|EmerCashStore|Cash4Thanksgiving|HolidayCash|HolidayFundingToday)\@)/i scoreTBI_FROM_MISC3.5 headerTBI_FROM_MISC1From =~ /((EasyPayDayLoanOnline|MyEZLoanOnline|CarFinancingSight|YourFastCash|FamilyProtection |AcaiBerryCleanse|YourDebtSource|LuminousBrites|save_my_home|AcaiBerryCleance|HolidayCashQuick |SuperInstantCash|YourCashInAdvance|UniqueOrnamentsutyri|ChristmasGiftIdeaslwsy|AccessVisaCard |DebtChristianSolution784|PaydayToday|PayCenter|CashAdvanceNews|GevaliaCoffee|HolidayCashDirect |HolidayCash4You|ExecutiveFashionBargains|Viagra|HolidayPayCenter|AmazingDietTea|EasyLender |BiggestShoppingDayCash|CashStore|SantaClausCash|MyEZLoanOnline|creditreportamerica |PersonalizedChristmasGifts|GovtGrants|MyEZLoanOnline|InternationalWines|VistaPrintExclusive |NationwidePrinter|GroceryCoupons)\@)/i scoreTBI_FROM_MISC13.5 Your Mileage May Vary, Jared Hall General Telecom, LLC. chucker8 wrote: Hello, I'm looking at spamassassin for our compnay's spam solution. We receive emails from u...@theirdomain.com, where the domain in correct but the user would be for instance, Viagra, which does not exist. We needthe spam software to realize that this user does not exist and register the email as spam. Is there any way to do this with SpamAssassin? thanks!
Re: [sa] Re: Filter question
On Tue, 1 Dec 2009, Wolfgang Zeikat wrote: Benny Pedersen wrote: postfix reject_unverified_sender does a vrfy Nope. It opens an SMTP connection and waits what the receiving MTA answers to RCPT TO Then it closes the connection. As a side note, among the other many evils of 'callback verification' I've discovered that if you attempt callback on all the spam with forged yahoo addresses, you will earn a 'reputation' with yahoo's servers that your mail should be greylisted because it attempts to 'send mail' to too many non-existent addresses. One more reason to NOT verify addresses this way. - Charles
Re: [sa] Re: Filter question
Charles Gregory wrote: On Tue, 1 Dec 2009, Wolfgang Zeikat wrote: Benny Pedersen wrote: postfix reject_unverified_sender does a vrfy Nope. It opens an SMTP connection and waits what the receiving MTA answers to RCPT TO Then it closes the connection. As a side note, among the other many evils of 'callback verification' I've discovered that if you attempt callback on all the spam with forged yahoo addresses, you will earn a 'reputation' with yahoo's servers that your mail should be greylisted because it attempts to 'send mail' to too many non-existent addresses. One more reason to NOT verify addresses this way. I second that. ips.backscatter.org's blacklists have been discussed here before, and you WILL get on their blacklist for doing this. they explain why this is bad, and that you would be part of a DDOS against an innocent third party. (and, gee.. I have seen it). we had a hosted client who got a HUGE bill from their DNS provider for 'excessive queries' from a backscatter attack. they usually got 50,000 spams a month, well, this month, they got 7MM spams (6.5MM of them were backscatter, bounces of emails they never sent, sender callouts and CR emails). -- Michael Scheidell, CTO Phone: 561-999-5000, x 1259 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best Anti-Spam Product 2008, Network Products Guide * King of Spam Filters, SC Magazine 2008 _ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.spammertrap.com _
Re: Filter question
Wolfgang Zeikat wrote: Benny Pedersen wrote: postfix reject_unverified_sender does a vrfy Nope. It opens an SMTP connection and waits what the receiving MTA answers to RCPT TO Then it closes the connection. That is not vrfy. Hope this helps, wolfgang The VRFY mechanism predates any other verification method. It is disabled -specifically due to widespread abuse- essentially everywhere. Circumventing this configuration choice is clearly against the wishes of the host owners/implementors. How much more unambiguously can a behavior BE abusive? Bob --
Re: FP on blacklist hostkarma
Matus UHLAR - fantomas wrote: On tir 01 dec 2009 02:16:04 CET, wrote I believe Raymond's response was addressing the fact a server connection could possibly be interrupted before it had a chance to issue the SMTP QUIT command. I would think being listed for that alone would be ridiculous. On 01.12.09 02:20, Benny Pedersen wrote: if its this i would agree, cant exim see diff in not sending quit or drop connection ? postfix have lost connection, spam sign ? It may depend on the number of lost connections. Marc said he's investigating the problem, let's see the result Every list is imperfect. In this case there were about 10 hits on the hi MX record and they didn't use QUIT to close the connection. Generally this indicates a virus. If they had used QUIT they wouldn't have been listed. Although I try to keep the list perfect, if an email server impersonates a spam bot then they are more likely to get on the wrong lists.
Re: HABEAS_ACCREDITED SPAMMER
On Nov 30, 2009, at 12:38 PM, rich...@buzzhost.co.uk wrote: So please, spare me the sob story about what a wonderful idea HABEAS is. Talk is cheap, action speaks louder than words. Who's sobbing? I'm merely explaining how it works today. If you disagree with a particular entry on either the (formerly Habeas) Safe list or the Certified list, we've made it extremely easy for you to tell the people who operate those lists. Hint: insulting me on this mailing list has no effect. -- J.D. Falk jdf...@returnpath.net Return Path Inc
Re: FP on blacklist hostkarma
On tir 01 dec 2009 12:27:58 CET, Mike Cardwell wrote When I say, you, I'm refering to the people using the JMF lists, not specifically you Benny. if it was just for me you would post it on maillists ? :) thanks for clearify it, atleast for me -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
RE: FP on blacklist hostkarma
if it was just for me you would post it on maillists ? :) thanks for clearify it, atleast for me Benny, sure we would! as ummm ...well, you know, you are just so lovable... :-) seriously, and the reason you are so lovable is that even if i read some (not all) of your posts over and over, i cant figure out what you are saying... something lost in the translation maybe??? ;-) - rh
RE: HABEAS_ACCREDITED SPAMMER
If you disagree with a particular entry on either the (formerly Habeas) Safe list or the Certified list, we've made it extremely easy for you to tell the people who operate those lists. Hint: insulting me on this mailing list has no effect. -- J.D. Falk jdf...@returnpath.net Return Path Inc JD i asked for some clarification from Neal on the spam-l list in this last week and havent seen it yet... if he has been tied up, is understandablew.. yet if he is ignoring, would be nice to know so that appropriate actions can be taken thanks... - rh
Re: [sa] Re: Filter question
On tir 01 dec 2009 16:59:12 CET, Charles Gregory wrote servers that your mail should be greylisted because it attempts to 'send mail' to too many non-existent addresses. One more reason to NOT verify addresses this way. well KISS to yahoo for not setting spf for there domains so we dont need to call back for verifing senders dkim is no option since mta needs full body header to test it if yahoo dont get it, its simplier to just block yahoo senders http://rfc-ignorant.org/tools/lookup.php?domain=yahoo.com or just check if domain is on yahoo nameservers, but this will also hit on yahoogroups with is okay, but all freemailers there soooks :)) -- xpoint http://www.unicom.com/pw/reply-to-harmful.html
