Re: Why is this failing SPF???
On 13-Apr-07, at 9:41 AM, Ken Morley wrote: According to my understanding of the way SPF works the following message should not be failing. Can anyone tell me why this failed? Here's the pertinent parts of the log: -- Apr 11 15:00:18 maildrop postgrey[2407]: request: client_address=66.179.38.26 client_name=hamhock-outbound.hoovers.com etrn_domain= helo_name=hamhock.hoovers.com instance=7dbd.461d3042.a4146.0 protocol_name=ESMTP protocol_state=RCPT queue_id= [EMAIL PROTECTED] recipient_count=0 request=smtpd_access_policy reverse_client_name=hamhock-outbound.hoovers.com [EMAIL PROTECTED] size=18654 action=PREPEND X-Greylist: delayed 1063 seconds by postgrey-1.27 at maildrop.domain.com; Wed, 11 Apr 2007 15:00:18 EDT Apr 11 15:00:18 maildrop amavisd[32198]: (32198-06) ESMTP MAIL FROM:[EMAIL PROTECTED] SIZE=18654\r\n Apr 11 15:00:18 maildrop amavisd[32198]: (32198-06) lookup (debug_sender) = undef, [EMAIL PROTECTED] does not match Apr 11 15:00:18 maildrop amavisd[32198]: (32198-06) ESMTP 250 2.1.0 Sender [EMAIL PROTECTED] OK Apr 11 15:00:18 maildrop amavisd[32198]: (32198-06) ESMTP::10024 /var/amavisd/tmp/amavis-20070411T141549-32198: [EMAIL PROTECTED] - [EMAIL PROTECTED] SIZE=18654 Received: from maildrop.domain.com ([127.0.0.1]) by localhost (maildrop.domain.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP for [EMAIL PROTECTED]; Wed, 11 Apr 2007 15:00:18 -0400 (EDT) Apr 11 15:00:19 maildrop amavisd[32198]: (32198-06) Checking: pOlR15g8xTwO [66.179.38.26] [EMAIL PROTECTED] - [EMAIL PROTECTED] Apr 11 15:00:33 maildrop amavisd[32198]: (32198-06) SPAM, [EMAIL PROTECTED] - [EMAIL PROTECTED], Yes, score=9.243 tag=3 tag2=6.31 kill=6.31 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1.091, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=0.75, SPF_HELO_FAIL=10], autolearn=no, quarantine pOlR15g8xTwO (spam-quarantine) Apr 11 15:00:33 maildrop amavisd[32198]: (32198-06) one_response_for_all [EMAIL PROTECTED]: REJECTs, '554 5.7.0 Reject, id=32198-06 - SPAM' Here's the SPF record for hoovers.com: -- hoovers.com text = v=spf1 ip4:66.179.38.0/23 ip4:66.45.81.128/27 ip4:66.45.81.160/27 ip4:66.179.85.192/27 ip4:216.234.248.64/26 ip4:216.234.248.78 ip4:216.234.248.82 ip4:66.162.217.59 mx ptr a:exchange.hoovers.com a:mail.eca.com include:dartmail.net ~all The sending server is hamhock-outbound.hoovers.com [66.179.38.26] and that IP address is within the range listed in the first SPF entry. Why did this fail? It didn't fail SPF, it failed SPF_HELO. The sending server said: helo_name=hamhock.hoovers.com' SPF policy for hamhock.hoovers.com is: hamhock.hoovers.com. IN TXT v=spf1 a -all Which resolves to: hamhock.hoovers.com. IN A 66.179.38.137 Which does not match 66.179.38.26 -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Re: SPF is hopelessly broken and must die!
On 14-Dec-06, at 10:30 AM, Marc Perkel wrote: I'm not the one who brought it up. Gino Cerullo wrote: Marc, I get the impression that you run a business that markets itself as an anti-spam solution and it's based on forwarding email and that business model is threatened by the growing adoption of SPF. Now, I maybe I'm completely wrong but your incessant rants over this leads me to think otherwise. Regardless, if you have concerns about SPF and it's perceived relations to anti-spam or it's problems with email forwarding why are you continuing to bring it up on this list. The venue for it is the SPF Discuss and the SRS Discuss mailing lists. To subscribe to those lists use the following addresses. [EMAIL PROTECTED] [EMAIL PROTECTED] For a complete list of SPF related discussion list please visit the following page. http://www.openspf.org/Forums I presume the answer you gave is an admission that you are, in fact, using email forwarding as the method behind your spam filtering system. To me that sounds like an abuse of the email forwarding feature to accomplish something that it was not designed or meant to be used for. So you see, many people, including yourself, are using the email system in ways that it was not meant or at least, envisioned to be used for. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 This email address protect by SPF! Want to protect your domain's email from forgery? Visit openspf.org
Re: SPF is hopelessly broken and must die!
On 14-Dec-06, at 4:35 PM, j o a r wrote: On 14 dec 2006, at 20.40, Gino Cerullo wrote: I presume the answer you gave is an admission that you are, in fact, using email forwarding as the method behind your spam filtering system. The link from perkel.com - junkemailfilter.com is pretty self explanatory. It all makes sense now... I already knew the answer, I just wanted him to admit it in front of everyone but he didn't. He opted to send the email directly to me, off list but I put it back in for everyone to see. Marc's, rants have nothing to do with the perceived short comings of SPF but everything to do with the threat to his flawed business model. There are work-arounds to Marc's problems if he thinks about it a little but he's so fixated on what he's read about SPF breaking forwarding he can't see the forest through the trees so to speak. Marc: Since you already require that your customers modify their MX records to have their email sent to your servers, why not update / add the appropriate SPF records at the same time? That would prevent any problems caused by SPF checks. No, that's not the solution and I'm not going to share it with him either. He'll have to work it out himself. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 This email address protect by SPF! Want to protect your domain's email from forgery? Visit openspf.org
Re: SPF is hopelessly broken and must die!
What many of you fail to realize is that although SPF was originally envisioned as an anti-spam tool, because it dealt with a major characteristic of spam, address forgery, it is in fact a domain verification tool. With that in mind, it becomes irrelevant whether spammers publish SPF policies or not; or if they do, that it covers the entire range of IP addresses on the planet. Why? Because, if every *legitimate* domain owner published an SPF policy for their domain and every mail server was SPF aware, it becomes trivial to identify the bad domains and they become that much easier to deal with. By publishing an SPF policy for your domain you prevent your domain from being abused. Of course this requires the co-operation of everyone and we're not there yet. Every legitimate domain does not have an SPF policy and every mail server is not SPF aware but we're getting there. Now some of you bring up the case of DDOS attacks caused by backscatter. Listen, there is no profit in DDOS attacks. Spammers don't make money by taking down mail servers and those interested in using DDOS attacks to disrupt networks already have enough tools at their disposal, one more isn't going to make much of a difference in the grand scheme of things. Spammers only make money if they sell something. For those of you who keep harping on the SPF breaks forwarding issue (Marc). When I say SPF aware mail servers, I mean mailer servers that support SRS so that becomes a non issue. But, let's look at the present situation we are faced with even today where most mail servers don't support SRS. Even when you send an email to someone who has forwarded their email and it is later bounced, you're made aware of the email address that the original is being forwarded to so you can just resend the message to the other address. Since this probably affects about 0.01% of all email, I've only ever experienced it once myself, it's only a minute annoyance. From a Spamassassin point of view, SPF is very effect at assisting in what Spamassassin is designed to do. Evaluate email based on the characteristics of the contents of its header as well as the contents of its body. It the case of the header, SPF is very effect at contributing to the score of as well as for whitelisting purposes. For the record, in the one year that my email server has been SPF aware I've only ever seen one (1) junk email with an SPF PASS. That is about 0.001% of the total email that has been sent to my server. On the other hand, about 10% of legitimate email sent to my server are verified with an SPF PASS (and it's growing all the time) and I've never had a false positive, no legitimate email has been blocked as a result of SPF. Marc, if you really have legitimate concerns about SPF, why don't you take them to the SPF Discuss mailing list where they belong. If they are in fact legitimate, then that's the place to discuss them. To subscribe to the list send an email to subscribe-spf- [EMAIL PROTECTED] -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 This email address protect by SPF! Want to protect your domain's email from forgery? Visit openspf.org
Re: SPF is hopelessly broken and must die!
On 13-Dec-06, at 12:53 PM, Marc Perkel wrote: Mark, SPF isn't an anti-spam technology. Anyone who says it is, is an imbecile. SPF is an anti-forgery technology. Those who continue to think of SPF purely as a spam control technology are doomed to be disappointed and/or endlessly make posts like SPF can be evaded by spammers, they just publish their own SPF. Duh. It's anti spam technology. The reason people use it is because spammers are forging email addresses. Just because YOU say it, doesn't make it so. Everybody who understands SPF knows what it is. That said, your comment about blocking no spam is pure horsehockey. I have plenty of spam matching SPF_FAIL and SPF_SOFTFAIL. I've also have had no FPs from SPF, except websites like hire.net that insist upon forging my domain as the envelope sender when generating emails to my HR staff. Actually, MAIL FROM, RCPT TO, From: and To: are all identical. Brilliant. Yep - they are using normal email technology. That's supposed to work. That's what SPF breaks. It also breaks email forwarding. I prefer to say email forwarding breaks SPF but that's just semantics. The truth of the matter is that email forwarding makes up less than 0.001% of all email so, when it happens its an minute annoyance at best since the sender is made aware of the forwarded address and the message can be re-sent. And SRS does not break the ability to do conditionals, because the true envelope from address is still a part of the rewritten envelope from. You just need to make your conditionals match the SRS version. You have to rewrite all your conditionals to support the broken technology. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 This email address protect by SPF! Want to protect your domain's email from forgery? Visit openspf.org
Re: SPF is hopelessly broken and must die!
On 13-Dec-06, at 1:15 PM, Marc Perkel wrote: [EMAIL PROTECTED] wrote: Sounds good, I found this an interesting read about why SPF is ineffective: http://en.hakin9.org/products/articleInfo/102 Excellent article. SPF catches no spam - but does create false positives. It's less than useless. It's dangerous. That article, at best, disseminates incomplete and outdated information and at worst, completely false statements. Why SPF is bad SPF is supposed to protect against sender address forgery. It protects only the envelope sender address, not the From: header address. Mail User Agents such as Outlook Express display only the unprotected address. Therefore the users are still fooled and unprotected against joe-jobs, forgery, phishing and various scams. SPF wasn't designed with MUA in mind. It was designed for use at the MTA level to block email before DATA. What's the use of accepting the email only to have the MUA query DNS to determine if it passes SPF checks. To that end there is nothing stopping the developers of MUAs from incorporating that functionality in the MUA and flagging messages based on SPF. The recipient does not need to see the 'envelope sender' address. SPF is supposed to protect against spam. A 2004 CipherTrust survey shows that more mail comes to SPF-protected servers from domains with SPF records, than from domains with no such records. Spammers have adopted SPF and are using it even more than legitimate sites to ensure spam delivery to mailbox. Citing a study that is over two years old, that was published when the first stable draft of the SPF spec was only months old is hardly evidence of a greater trend in regard to the deployment of the protocol. In my own actual experience, after running an SPF aware mailer server for a year less than 1 in 100 000 emails have scored an SPF PASS and been spam. SPF breaks many Internet standards. It does not take into consideration pre-delivery forwarding (and a scheme called SRS adopted to counteract this is far from perfect). It is based on a vulnerable protocol (DNS), which makes it easy to spoof SPF records. Email forwarding is not a standard, it is a feature; used by less than 0.01% of email users. As well the resulting bounce email informs the sender of the address that is being forwarded to so the sender merely has to resend the message. Yes the Internet is built on an fragile infrastructure that does not take into account the realities we face today. So we adapt! That is what SPF is all about, adapting to the realities of today. Also, the DNS protocol is not as vulnerable as the author makes it out to be, otherwise the Internet wouldn't be useable at all. Listen, I can go on and on about that article but you get the point. It goes on to propose inappropriate uses for SPF and then uses that to justify why the protocol is flawed. It proposes scenarios that have no bases in fact and uses those to try and prove the ineffectiveness of the protocol. Just because someone writes an article, one lacking any real evidence and citing an ancient study, doesn't make it true. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 This email address protect by SPF! Want to protect your domain's email from forgery? Visit openspf.org
Re: SPF is hopelessly broken and must die!
On 13-Dec-06, at 6:38 PM, Marc Perkel wrote: From openspf.org http://old.openspf.org/aspen.html What's your point? Did you bother reading the article. It talks about accreditation and reputation and only uses spam as an example. You saw a couple of graphics that say spam and ham and now you think you have proof of something. Did you fail to notice the overwhelming number of graphics that have good domain and bad domain in them. I know you didn't bother to actually read any of it otherwise you wouldn't have embarrassed yourself by linking to it. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 This email address protect by SPF! Want to protect your domain's email from forgery? Visit openspf.org
Re: failure notice / spaassassin.apache.org
On 29-Sep-06, at 1:06 PM, Tom Myers wrote: To whom it may concern. I need your help. I run a legitimate business ( 27 years ) of Search and Placement in the electronic industry. As you can see for the text below I am unable to contact people about the jobs that they want to interview for. How do I get unlisted from the Spamassassin black list? Every letter I send out is an individual letter not a spam or junk mail. I view resumes on Hot Jobs. I pay for this service. People post their resumes so that a recruiter like myself will contact them with the hope of finding work. By being blocked from contacting that person causes Spamassassin to harm both of us. In addition, several clients have not been able to receive emails from me. These clients are fortune 500 manufactures that have written agreements with our firm to arrange legitimate interviews for valid jobs. Can you help me get delisted ? SpamAssassin is not a blacklist, you do not get delisted from it since it is not listing you as a spammer. Comcast, is the ISP that is responsible for the mail servers of the person you are trying to reach. They have determined that the email you are sending is spam for whatever reason and have given you an address with possible explanations as to why. http://www.comcast.net/help/faq/index.jsp?faq=SecurityMail_Policy18628 That page also has a contact address where you can contact someone about the problems you are having. [EMAIL PROTECTED] They are the ones you should be taking this up with. We can't help you. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: Earthlink emails
On 26-Sep-06, at 12:43 PM, Benny Pedersen wrote: On Tue, September 26, 2006 18:24, bryan haase wrote: I am getting a lot of earthlink.net emails with 4-5 random words in the body. I am at a lost how to prevent these. Any suggestions?? http://openspf.org/wizard.html?mydomain=earthlink.net SpamAssassin 3.0.1 (2004-10-22) on relay2.corp.good-sam.com update to 3.1.5 if posible and enable spf check How does this help? Earthlink does not publish SPF records. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: Strange SPF problem/wrong result
On 1-Sep-06, at 7:18 AM, decoder wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, today I saw a strange SPF bug occuring. The original mail header was: Return-Path: [EMAIL PROTECTED] Received: from mail.cs.uni-sb.de (mail.cs.uni-sb.de [134.96.254.200]) by wjpserver.cs.uni-sb.de (8.12.11.20060308/8.12.11) with ESMTP id k7T8rU6P012050; Tue, 29 Aug 2006 10:53:30 +0200 Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by mail.cs.uni-sb.de (8.13.8/2006081400) with ESMTP id k7T8rT98004989; Tue, 29 Aug 2006 10:53:29 +0200 (CEST) Received: from x.europe.corp.microsoft.com ([65.53.193.xxx]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 09:53:29 +0100 (Some unrelated privacy details replaced with xxx). Now what SPF should do is (as far as I understood): - - Get the mail server that sent this (mail-eur1.microsoft.com) - - Check that its IP is in the allowed SPF record of microsoft.com This check passes as you can see here: http://www.dnsstuff.com/tools/spf.ch? server=microsoft.comip=213.199.128.139 Now SpamAssassin did something else, it took mail.cs.uni-sb.de as the mailserver that sent, and tried to match it against microsoft.com's SPF records which produced a SOFTFAIL: 1.4 SPF_SOFTFAIL Sending host does not match SPF-record (softfail) [SPF failed: Please see http://www.openspf.org/why.html?sender=xxx% 40microsoft.comip=134.96.254.200receiver=This%20account%20is% 20currently%20not%20available] 2.4 SPF_HELO_SOFTFAIL HELO-Name does not match SPF-record (softfail) [SPF failed: Please see http://www.openspf.org/why.html?sender=xxx% 40microsoft.comip=134.96.254.200receiver=This%20account%20is% 20currently%20not%20available] Can someone explain me this failure? Spamassassin gave the correct result. It compared the IP address of the last received server mail.cs.uni-sb.de (mail.cs.uni-sb.de [134.96.254.200]) against the SPF record for Microsoft and did not see a match. Result SOFTFAIL Why do you think it should compare to mail-eur1.microsoft.com (mail- eur1.microsoft.com [213.199.128.139]). SPF compares the IP address of the last server to handle the message before it was handed off to a server on your receiving end. If the message was sent to someone who is using forwarding and forwarded through mail.cs.uni-sb.de (mail.cs.uni-sb.de [134.96.254.200]) then this would explain the SOFTFAIL. Forwarding breaks SPF. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: Hacked E-Trade Phishing Site
On 1-Sep-06, at 9:12 AM, Bowie Bailey wrote:
Chris wrote:
On Thursday 31 August 2006 7:54 pm, David B Funk wrote:
On Wed, 30 Aug 2006, jdow wrote:
From: Evan Platt [EMAIL PROTECTED]
At 04:02 PM 8/30/2006, you wrote:
Check at the top of this E-trade Phishing site:
http://196.1.161.115/e/t/user/login/
I get it but I don't get it. I could understand if it was an
image, but that's TEXT.
Cluless phisher?
18:00:23 up 13 days, 43 min, 1 user, load average: 0.39,
0.34, 0.30
Must not be running a Windoze box eh?
You did not read the very top line.
{^_^} - did a wget and read the html. There is an interesting
h1 line. And it appears most people will miss it.
revisited it, the black-hat mostly fixed the grey-hat's damage. ;
Maybe they'll start a black-hat/grey-hat war :)
Looks like it's been hacked again. :)
And he's signed his work this time.
Hail 'The Fat Bastard Controller' :P Whooop!
--
Gino Cerullo
Pixel Point Studios
21 Chesham Drive
Toronto, ON M3M 1W6
416-247-7740
smime.p7s
Description: S/MIME cryptographic signature
Re: Spammed by Non-delivery-report? (someone is using my email to spam)
On 31-Aug-06, at 7:18 PM, Christian Purnomo wrote: Hi Gurus, I am having so much trouble at present that some people are using my email address to send their spam messages, in return I get hundreds and hundres of non-delivery email + other misc reply such as out of office. How would I be able to use spamassassin to help me with this? would sa-learn be the most efficient way? I can think of using procmail to filter them into a seperate mailbox, but the mail headers all very random. Your help would be much appreciated. Sorry, correction to URL. http://www.openspf.org -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: The grey hats are at it in force
On 31-Aug-06, at 8:08 PM, Chris wrote: This is even better than the last one: http://194-144-135-77.du.xdsl.is/~ingi/.change/index.php? MfcISAPICommand=ChangeFPP Who are these masked avengers? ;-) -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On 30-Aug-06, at 1:10 PM, Michael Grey wrote:Are there any SA methods that allow verification of the ‘sender’ of an email ? I am aware of SPF which can confirm that a host at ip address x.x.x.x is authorized to send mail as from domain “A”, but how about a means to confirm that ‘[EMAIL PROTECTED]’ actually is a real user before accepting mail from him ?I don't believe SA can do that as it's a content filter. Some MTAs can do this and this is were you want those kinds of verifications to happen, before DATA. The problem is that if you do it for every address you will get false positives, especially from sources like mailing lists, news info subscriptions, etc., and you'll find yourself whitelisting alot. I actually do this using Postfix but I use a table of 'frequently forged domains' whose addresses are verified before they are allowed to pass on to the content filters. --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: source SENDER authentication ? (as opposed to SPF HOST authentication)
On 30-Aug-06, at 1:44 PM, Justin Mason wrote: Gino Cerullo writes: part 1.2 text/plain1027 On 30-Aug-06, at 1:10 PM, Michael Grey wrote: Are there any SA methods that allow verification of the ‘sender’ of an email ? I am aware of SPF which can confirm that a host at ip address x.x.x.x is authorized to send mail as from domain “A”, but how about a means to confirm that [EMAIL PROTECTED] actually is a real user before accepting mail from him ? I don't believe SA can do that as it's a content filter. Some MTAs can do this and this is were you want those kinds of verifications to happen, before DATA. The problem is that if you do it for every address you will get false positives, especially from sources like mailing lists, news info subscriptions, etc., and you'll find yourself whitelisting alot. I actually do this using Postfix but I use a table of 'frequently forged domains' whose addresses are verified before they are allowed to pass on to the content filters. It's also worth noting that doing this is counterproductive in an overall strategy sense, since it drives the spammers to simply use known-valid third-party addresses -- such as random addrs from their target address list -- as the forged source of the spam. The end result for us end users, is a massive increase in spam blowback, which is what we've seen since those MTAs implemented it. :( Unfortunate but SPF would prevent that as well. If everyone just used SPF, none of this would be a problem. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: catching fake usernames?
On 30-Aug-06, at 11:41 PM, Rick Roe wrote: I get a lot of spam whose From addresses are users that don't exist on my system (random names like [EMAIL PROTECTED], [EMAIL PROTECTED], etc). I recently set up a scheme to manually blacklist all From addresses on my domains and un-blacklist the fifty or so real addresses mail can legitimately come from (the system aliases like postmaster, daemon, and so forth, and a small handful of real users each with a handful of aliases), using blacklist_from and unblacklist_from in the local config file. This is a rather fragile system, though -- anytime I go to add any new users or aliases, I'll have to edit my local.cf files to match. My user population is rather static, so it's not a big deal, but it seems like there should be a simpler, more automatic way to do this. Am I missing something? SPF will address this at the MTA. Depending on your MTA you may be able to address this by checking against the user database but I wouldn't do it in SpamAssasin. It's a content filter, it shouldn't be verifying user accounts for this purpose. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: Stupid phisher
On 29-Aug-06, at 7:49 AM, Magnus Holmgren wrote: On Monday 28 August 2006 01:00, Chris took the opportunity to say: This is a pretty good fake site except he left a little something from Mother Russia at the bottom. http://signin-ebay-co-uk-ebay.land.ru/ ws.eBayISAPI.dll.SignIn.pUserId.co.pa rtnerid.siteid.pageType.pa1.i1.html Speaking about phishers, has anyone thought about spamming them with phony personal data? It's probably not very effective with things that can automatically and instantly be verified, such as eBay credentials, but perhaps more effective with credit card numbers? If you noticed, that particular site piped the data directly to the ebay login site. If the credentials supplied were bogus then the real ebay site would indicate as such. The OP has a script that records the data as it is streamed across their connection. If they can also detect the un-successful log-in attempts, then the bogus credentials you supply are useless. They would disregard them resulting in a big waste of time on your part. A better use of your time is to fill-in the input fields with Russian swear words until you get board. ;-) -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Re: Ok, what's the point of this spam/phish?
On 28-Aug-06, at 8:30 AM, Loren Wilton wrote: I can't figure out who is trying to do what here, but it looks real suspicious. Anyone seen one of these before? Loren Status: U Return-Path: [EMAIL PROTECTED] Received: from mta5a.dm-4.com ([64.40.98.32]) by mx-clapper.atl.sa.earthlink.net (EarthLink SMTP Server) with SMTP id 1ghjmQ4WF3Nl34b2 for [EMAIL PROTECTED]; Sun, 27 Aug 2006 08:03:56 -0400 (EDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; q=dns; s=x; d=dm-4.com; h=Date:Subject:From:To:Mime-Version:Content-Type; b=bveD9400nJ18QotyLuey2SwDQoG8lK/ VCoFxRlPQEkOts6AoGD2kr02TPEBlYGtKAJBAEz0/vu5O hUkHSekGa +CPYZHDPIJO2FWTERIO6sUYqFifQJBu54RgUr5R0PN1s8qTb6Gbj68hN5npUh/ AvOrc BJoV0ftmoVaSvURJSFI=DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=x; d=dm-4.com; b=WVASzl9kHmkmjVLCihLcLHaHwky6WdpNboPQ+ExpbRnS6UpXJjJTtUaJ +TLvDTgjbzY55U8mcqtM 4oxLqh/sQD/4jpL4TcnqrTNsWBAYiKhzsXU+WqaOpE/ tLxbgMii9eGlE/LnRLLjp+4H6wY6jFx+9 MdtNTCsPGCB1NR4njd8=;Received: by mta5a.dm-4.com (PowerMTA(TM) v3.0r31) id hu652o09jc44 for[EMAIL PROTECTED]; Fri, 25 Aug 2006 15:48:22 -0700 (envelope-from[EMAIL PROTECTED])Date: Fri, 25 Aug 2006 22:48:22 GMTSubject: Notice of DRAM Class Action Partial SettlementsFrom: DRAM Class Administrator [EMAIL PROTECTED]To: [EMAIL PROTECTED]: [EMAIL PROTECTED]: XTUU1N H2P03IY VZQTROO QG0ICIMime-Version: 1.0Content-Type: multipart/alternative; boundary=dmboundaryMessage-Id: [EMAIL PROTECTED] clappe r.atl.sa.earthlink.netX-ELNK-AV: 0X-ELNK-Info: sbv=0; sbrc=.0; sbf=0b; sbw=000;X-NKVIR: ScannedX-WiltonBefore: user wiltonX- Wilton: user wilton--dmboundaryContent-Type: text/plain; charset=iso-8859-1* * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * *An Important Notice from the United States DistrictCourt for the Northern District of California AboutPartial Class Action Settlements Involving DynamicRandom Access Memory (DRAM)* * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * *IF YOU PURCHASED DRAM IN THE UNITED STATES, YOUCOULD GET BENEFITS FROM THE PARTIAL SETTLEMENTS.* * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * *Three separate proposed settlements totaling$160,750,000.00 have been reached in a class actionlawsuit concerning prices of DRAM with defendants:Infineon Technologies AG and Infineon Technologies North American Corp.; Samsung Semiconductor, Inc.;and Hynix Semiconductor Inc. and Hynix SemiconductorAmerica, Inc. These are the first settlements reachedin this litigation, which will continue against theremaining defendants. You may be a member of theSettlement Class whose rights may be affected bythis lawsuit. The sole purpose of this notice is toinform you of the lawsuit so that you may decide whatsteps to take in relation to it.You do not need to do anything to remain in the Class.Settlement Class members will be entitled to receivemoney from the settlement fund when it is ultimatelydistributed. If you want to exclude yourself from theClass, you must do so not later than October 3, 2006.Please read the Notice described in the next paragraphcarefully for directions on how to exclude yourself.If you do not timely exclude yourself from the Classbut want to object to any or all of the settlements,you must file a written objection not later thanOctober 3, 2006. Please read the Notice describedin the next paragraph carefully on how to object.A more detailed description of this litigation and theproposed settlements are contained in the Notice ofPendency of Class Action and Partial Class ActionSettlements (the Notice). The Notice may be accessed athttp:// www.DramAntitrustSettlement.com/or obtained free of charge by writing to: In re DRAMAntitrust Litigation, c/o Rust Consulting, Inc., P.O.Box 24657, West Palm Beach, FL 33416 or calling theClass Administrator at (866) 483-9938.To obtain more information describing your rights underthe partial settlements, contact the Class Administratorby writing to: In re DRAM Antitrust Litigation, c/o RustConsulting, Inc., P.O. Box 24657, West Palm Beach, FL33416 or calling toll-free 1-866-483-9938.To access the settlement web site, click on thefollowing link:http:// www.DramAntitrustSettlement.com/* * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * * * * * * * * * * * * * * * * * *--dmboundary This looks like legitimate mail that was sent to the wrong address. Unless, of course, your name and address was added to the list regarding this class-action. It happens sometimes. It's just that we've become overly suspicious of all the email we get, sometimes we forget that honest mistakes sometimes happen. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Re: Ok, what's the point of this spam/phish?
On 28-Aug-06, at 8:30 AM, Loren Wilton wrote: I can't figure out who is trying to do what here, but it looks real suspicious. Anyone seen one of these before? Loren Status: U Return-Path: [EMAIL PROTECTED] Received: from mta5a.dm-4.com ([64.40.98.32]) Just to follow-up, the domain dm-4.com publishes an SPF record and according to the online tools, the email did originate from an approved sender. # SPF record dm-4.com. IN TXT v=spf1 ptr:dm-4.com -all # Approved mail server mta5a.dm-4.com. IN A 64.40.98.32 # From the open.spf.org evaluator An email system which uses SPF saw a message coming from the IP address 64.40.98.32 which is mta5a.dm-4.com; the sender claimed to be [EMAIL PROTECTED] mta5a.dm-4.com is approved for dm-4.com, so that mail should have been accepted. Unfortunately, I don't know of any online tools to evaluate the Domain Key. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Discourage broken configs (was: Discourage broken content (was: Broken images in mails)
On 25-Aug-06, at 3:20 PM, Kenneth Porter wrote: --On Friday, August 25, 2006 12:05 AM -0700 Plenz [EMAIL PROTECTED] online.de wrote: I disagree. To check out what happens I converted a JPG picture into a GIF file and sent it to myself. One time I converted it with IrfanView and the second time with PaintShop Pro. Both GIF files had the result giftopnm: EOF or error reading data portion... So I produced a corrupt (?) image, but it was not spam. I think we should discourage all broken content in email and on the web. At one time we could assume that broken content was an honest mistake and make an attempt at fixing it. But with the rise of malicious content attempting to exploit bugs in content handlers (like overruns in image libraries), we should simply reject anything that fails to pass validation, on the assumption that's it out to get us. This includes not just broken images but also broken HTML, which is so commonly used to conceal spam. We need to stop giving a free pass to broken content creation software just because it's popular. When someone sends you broken content, you should react the same way you would if they sent you documents on dirt-smeared paper. Stop letting your emperor walk around naked. I would, and do, go even further and discourage broken Server/DNS configurations. I've downright had it with all this crap hitting my server. I'm now doing checks right at the MTA and if the sending server fails any hostname, HELO, domain name, SPF etc., checks they don't even get to my content filters. The biggest thing we have in our favour is that the spambots are mostly broken or running on machines that will fail most of these checks. For legitimate email, I send an message to the admins responsible for the broken configs with my log entries explaining why their email was blocked. It's up to them to fix it if they want to send email my way. I know this isn't practical in an environment where you're administering hundreds or thousands of accounts, and I feel your pain, but I think it's time we encouraged proper and correct server and DNS configurations so we can use all the tools at our disposal to our advantage. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Re: SPF Scoring... SPF_NEUTRAL
On 23-Aug-06, at 12:45 PM, Michael Grey wrote: Since this is not a production system, we have had to do some MX magic on a remote domain to push mail through this new system... that domain doesn't have SPF enabled (curse you Network Solutions !) So the big question is really this : Should NONE get an SPF score ? That is a matter of internal policy on your part. If you want to penalize domains for not having an SPF record you could give it a negative score. On the other hand, if you wish to reward them for not having an SPF record give them a positive score. I believe the general consensus is to leave it alone. Especially since SPF is still quite new and still technically in an experimental stage. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Re: SPF Scoring... SPF_NEUTRAL
On 23-Aug-06, at 1:09 PM, John D. Hardin wrote: On Wed, 23 Aug 2006, Gino Cerullo wrote: So the big question is really this : Should NONE get an SPF score ? That is a matter of internal policy on your part. If you want to penalize domains for not having an SPF record you could give it a negative score. On the other hand, if you wish to reward them for not having an SPF record give them a positive score. I think you got that backwards. U! Yeah, I think i did. Okay just do what I meant but do it the other way around. ;-) -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Re: SPF Scoring... SPF_NEUTRAL
On 23-Aug-06, at 1:01 PM, Michael Grey wrote: Sorry, I was too philosophical in my question... to rephrase; In the standard SA config, should I expect to see an SPF_* rule hit returned when the SPF return value is 'none' ? This is from the latest 50_scores.cf # SPF # Note that the benefit for a valid SPF record is deliberately minimal; it's # likely that more spammers would quickly move to setting valid SPF records # otherwise. The penalties for an *incorrect* record, however, are large. ;) ifplugin Mail::SpamAssassin::Plugin::SPF score SPF_PASS -0.001 score SPF_HELO_PASS -0.001 # gen:mutable score SPF_FAIL 0 1.333 0 1.142 score SPF_HELO_FAIL 0 score SPF_HELO_NEUTRAL 0 score SPF_HELO_SOFTFAIL 0 2.078 0 2.432 score SPF_NEUTRAL 0 1.379 0 1.069 score SPF_SOFTFAIL 0 1.470 0 1.384 # /gen:mutable endif # Mail::SpamAssassin::Plugin::SPF So the answer to your question is no you shouldn't. Their is no score to cover NONE. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740
Re: SA-LEARN Question
On 22-Aug-06, at 1:57 PM, Magnus Holmgren wrote: On Tuesday 22 August 2006 16:31, Jean-Paul Natola took the opportunity to say: Wouldn't forwarding strip away header info that is used to train spam? It depends on the MUA. Some MUAs, like MS Outlook (who would've guessed?) (at least Outlook 2000), mangle the mail even when forwarding as an attachment. Well-behaved MUAs preserve everything when forwarding as an attachment, but then you need to extract that attachment. I've been told to, and do use, Redirect instead of Forward when sending spam to a common mailbox for sa-learn. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 416-247-7740 smime.p7s Description: S/MIME cryptographic signature
Re: Is there a new spambot army on the march?
Yeah, I've been getting hammered by these too. I've configured Postfix to do HELO checks and the vast majority (95%) are failing at the MTA. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503 smime.p7s Description: S/MIME cryptographic signature
Re: SPF and SORBS problems
On 8/14/2006 6:45 PM, Xepher wrote: I've got a server configured with postfix and spamassassin. The mailserver is the only one for the domain, and thus receives mail from other servers, as well as letting users connect directly (with smtp auth) to send mail. Everything works fine, EXCEPT when users send email to each other. In those cases, the emails get tagged both by SPF_FAIL and RCVD_IN_SORBS_DUL as those tests see the email as coming from the user's personal IP address. I've tried whitelist_from_spf [EMAIL PROTECTED] in local.cf, but it doesn't work. Messages still get tagged with SPF_FAIL. I didn't see any similar option for the RBL stuff. Is there any way to do conditional tests, such that SMTP Auth messages get whitelisted? I don't know if there's a way in postfix to add a header only to auth connections? All I could find for postfix was address rewriting stuff, nothing about conditional situations like an authenticated user. Any help would be appreciated, as I'd really rather not disable SPF and RBL completely. Yeah I have that problem as well, who doesn't. ;-) In the short term I just whitelisted the domains that the server is responsible for in local.cf so that all my users would automatically get a -100 added to their score when they send mail. This will nullify any scores added due to SPF and DUL. Example: whitelist_from [EMAIL PROTECTED] The drawback to this is that someone can spam you by forging your own domain but if your domain is protected by something like SPF then there is no worry of that. If you are running Postfix v2.3 you might want to look at this page http://wiki.apache.org/spamassassin/DynablockIssues under the heading 'I'm an ISP, and mails from our customers, using authenticated connections from another ISP, are hitting RCVD_IN_DYNABLOCK.' -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: users Digest 14 Aug 2006 13:38:56 -0000 Issue 1597
On 14-Aug-06, at 9:38 AM, [EMAIL PROTECTED] wrote:Now that even spammers are using SPF, is there a way to penalize those with SPF records that are too broad?[EMAIL PROTECTED]:~$ host -t txt topsyvwkh.nettopsyvwkh.net descriptive text "v=spf1 ip4:51.0.0.0/2 ip4:66.0.0.0/2 ip4:145.0.0.0/2 ip4:245.0.0.0/2 -all"I doubt any legit sender would SPF-authorize the entire Internet. Is this hypothetical? topsyvwkh.net does not list a TXT record, it has no records at all that I can find.--Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: SPF Relay
Unless you post real domains it is very difficult to help with SPF questions. Since we cannot query your DNS, we can't determine whether there are errors in the SPF record. On 5-Aug-06, at 4:29 PM, Benu [EMAIL PROTECTED] wrote:I need help also, I am seeing the same messages. In /etc/mail/spamassassin/local.cf clear_internal_networks trusted_networks 127.0.0.1 my.ip.adr internal_networks 127.0.0.1 == I performed the following test: perl -MMail::SPF::Query -le 'print for Mail::SPF::Query-new(helo=shift, ipv4=shift, sender=shift)-result' ns.domain.net ip.add.res [EMAIL PROTECTED] It returns: none SPF: domain of sender [EMAIL PROTECTED] does not designate mailers host.domain.net: domain of [EMAIL PROTECTED] does not designate permitted sender hostsThis is stating there is no SPF record for the domain 'smtpd.domain.net.' Since you didn't post a real domain I cannot confirm if this is correct. == A SPF Check from the internet reports: SPF lookup of sender [EMAIL PROTECTED] from IP my.ip.adr: SPF string used: v=spf2 a ip4:my.ip.adr mx:smtpd.domain.net -all exp=getlost.domain.net. Processing SPF string: v=spf2 a ip4:my.ip.adr mx:smtpd.domain.net -all exp=getlost.domain.net. Testing 'a' on IP=my.ip.adr, target domain domain.net, CIDR 32, default=PASS. No match. Testing 'ip4:my.ip.adr' on IP=my.ip.adr, target domain my.ip.adr, CIDR 32, default=PASS. MATCH! Testing 'mx:smtpd.domain.net' on IP=my.ip.adr, target domain smtpd.domain.net, CIDR 32, default=PASS. Testing 'all' on IP=my.ip.adr, target domain domain.net, CIDR 32, default=FAIL. Testing 'exp=getlost.domain.net' on IP=my.ip.adr, target domain domain.net, CIDR 32, default=PASS. Looking up TXT record for getlost.domain.net. Got explanation: "Not authorized to send mail for the domain". Result: PASS = What do I need to change? Thanks Here you show a report for the domain 'domain.net.' This is not the same as the domain 'smtpd.domain.net' as far as SPF is concerned, smtpd.domain.net,' must have its own SPF record. Merely including 'mx:smtpd.domain.net' in the record for 'domain.net' does not mean 'smtpd.domain.net' has an SPF record or that it is cover by the record of 'domain.net' --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: SPF Relay
On 6-Aug-06, at 9:54 PM, Benu wrote: On Sunday 06 August 2006 14:07, you wrote: On 6-Aug-06, at 2:36 PM, Benu wrote: On Sunday 06 August 2006 09:39, you wrote: Unless you post real domains it is very difficult to help with SPF questions. Since we cannot query your DNS, we can't determine whether there are errors in the SPF record. http://www.dnsreport.com/tools/spf.ch?server=ted% 40teesa.netip=66.15.198.88 SPF Information for 66.15.198.88 SPF lookup of sender [EMAIL PROTECTED] from IP 66.15.198.88: SPF string used: v=spf2 a ip4:66.15.198.88 mx:smtpd.teesa.net -all exp=getlost.teesa.net. Processing SPF string: v=spf2 a ip4:66.15.198.88 mx:smtpd.teesa.net -all exp=getlost.teesa.net. Testing 'a' on IP=66.15.198.88, target domain teesa.net, CIDR 32, default=PASS. No match. Testing 'ip4:66.15.198.88' on IP=66.15.198.88, target domain 66.15.198.88, CIDR 32, default=PASS. MATCH! Testing 'mx:smtpd.teesa.net' on IP=66.15.198.88, target domain smtpd.teesa.net, CIDR 32, default=PASS. Testing 'all' on IP=66.15.198.88, target domain teesa.net, CIDR 32, default=FAIL. Testing 'exp=getlost.teesa.net' on IP=66.15.198.88, target domain teesa.net, CIDR 32, default=PASS. Looking up TXT record for getlost.teesa.net. Got explanation: Not authorized to send mail for the domain. Result: PASS On 5-Aug-06, at 4:29 PM, Benu [EMAIL PROTECTED] wrote: I need help also, I am seeing the same messages. In /etc/mail/spamassassin/local.cf clear_internal_networks trusted_networks127.0.0.1 my.ip.adr internal_networks 127.0.0.1 == I performed the following test: perl -MMail::SPF::Query -le 'print for Mail::SPF::Query-new (helo=shift, ipv4=shift, sender=shift)-result' ns.domain.net ip.add.res [EMAIL PROTECTED] It returns: none SPF: domain of sender [EMAIL PROTECTED] does not designate mailers host.domain.net: domain of [EMAIL PROTECTED] does not designate permitted sender hosts This is stating there is no SPF record for the domain 'smtpd.domain.net.' Since you didn't post a real domain I cannot confirm if this is correct. == A SPF Check from the internet reports: SPF lookup of sender [EMAIL PROTECTED] from IP my.ip.adr: SPF string used: v=spf2 a ip4:my.ip.adr mx:smtpd.domain.net -all exp=getlost.domain.net. Processing SPF string: v=spf2 a ip4:my.ip.adr mx:smtpd.domain.net -all exp=getlost.domain.net. Testing 'a' on IP=my.ip.adr, target domain domain.net, CIDR 32, default=PASS. No match. Testing 'ip4:my.ip.adr' on IP=my.ip.adr, target domain my.ip.adr, CIDR 32, default=PASS. MATCH! Testing 'mx:smtpd.domain.net' on IP=my.ip.adr, target domain smtpd.domain.net, CIDR 32, default=PASS. Testing 'all' on IP=my.ip.adr, target domain domain.net, CIDR 32, default=FAIL. Testing 'exp=getlost.domain.net' on IP=my.ip.adr, target domain domain.net, CIDR 32, default=PASS. Looking up TXT record for getlost.domain.net. Got explanation: Not authorized to send mail for the domain. Result: PASS = What do I need to change? Thanks Here you show a report for the domain 'domain.net.' This is not the same as the domain 'smtpd.domain.net' as far as SPF is concerned, smtpd.domain.net,' must have its own SPF record. Merely including 'mx:smtpd.domain.net' in the record for 'domain.net' does not mean 'smtpd.domain.net' has an SPF record or that it is cover by the record of 'domain.net' The test you show above shows a PASS. Which test gave you a problem? -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503 This fails: perl -MMail::SPF::Query -le 'print for Mail::SPF::Query-new (helo=shift, ipv4=shift, sender=shift)-result' smtpd.teesa.net 66.15.198.88 [EMAIL PROTECTED] none SPF: domain of sender [EMAIL PROTECTED] does not designate mailers victoria.teesa.net: domain of [EMAIL PROTECTED] does not designate permitted sender hosts and spamassassin --lint --debug complains: [22361] dbg: plugin: registering glue method for check_hashcash_value (Mail::SpamAssassin::Plugin::Hashcash=HASH(0xab22624)) [22361] dbg: eval: all '*To' addrs: [22361] dbg: plugin: registering glue method for check_for_spf_neutral (Mail::SpamAssassin::Plugin::SPF=HASH(0xaaeece4)) [22361] dbg: spf: no suitable relay for spf use found, skipping SPF check [22361] dbg: plugin: registering glue method for check_for_spf_softfail (Mail::SpamAssassin::Plugin::SPF=HASH(0xaaeece4)) [22361] dbg: rules: ran eval rule NO_RELAYS == got hit [22361] dbg: plugin: registering glue method for check_for_spf_pass (Mail::SpamAssassin::Plugin::SPF=HASH(0xaaeece4)) [22361] dbg: plugin: registering glue method for check_for_spf_helo_softfail (Mail::SpamAssassin::Plugin::SPF=HASH(0xaaeece4)) [22361] dbg: plugin: registering glue method for check_for_def_spf_whitelist_from (Mail::SpamAssassin::Plugin::SPF=HASH(0xaaeece4)) [22361] dbg: spf: cannot get Envelope-From, cannot use SPF
Re: spf fails for smtp auth clients
Hi Benny,I just tried to send you an email directly and got this back.Aug 2 17:39:33 server postfix/smtpd[13818]: BFB481BD016: client=unknown[216.138.200.230], sasl_method=CRAM-MD5, sasl_username=gcerulloAug 2 17:39:33 server postfix/cleanup[13821]: BFB481BD016: message-id=[EMAIL PROTECTED]Aug 2 17:39:33 server postfix/qmgr[69]: BFB481BD016: from=[EMAIL PROTECTED], size=9008, nrcpt=1 (queue active)Aug 2 17:39:45 server postfix/smtpd[13825]: connect from localhost[127.0.0.1]Aug 2 17:39:45 server postfix/smtpd[13825]: 5E07D1BD041: client=localhost[127.0.0.1]Aug 2 17:39:45 server postfix/cleanup[13821]: 5E07D1BD041: message-id=[EMAIL PROTECTED]Aug 2 17:39:45 server postfix/qmgr[69]: 5E07D1BD041: from=[EMAIL PROTECTED], size=9592, nrcpt=1 (queue active)Aug 2 17:39:45 server postfix/smtpd[13825]: disconnect from localhost[127.0.0.1]Aug 2 17:39:45 server postfix/smtp[13822]: BFB481BD016: to=[EMAIL PROTECTED], relay=127.0.0.1[127.0.0.1], delay=12, status=sent (250 2.6.0 Ok, id=13694-01, from MTA: 250 Ok: queued as 5E07D1BD041)Aug 2 17:39:45 server postfix/qmgr[69]: BFB481BD016: removedAug 2 17:39:50 server postfix/smtp[13826]: 5E07D1BD041: to=[EMAIL PROTECTED], relay=mx.junc.org[80.166.75.22], delay=5, status=deferred (host mx.junc.org[80.166.75.22] refused to talk to me: 550 Client host rejected: cannot find your hostname, [216.138.200.230])Aug 2 17:40:33 server postfix/smtpd[13818]: disconnect from unknown[216.138.200.230]Try sending me an email directly from your domain 'rima.ws' so I can see what happens. My server is configured to check SPF at both the MTA before DATA and when Spamassassin scans it.On 2-Aug-06, at 4:53 PM, [EMAIL PROTECTED] wrote:dig rima.ws txtspf fails when mails sent to my own mail server, but it should work for allothers that recieve mail from rima.ws ?is this a bug or just my config ?my smtp auth ip is both in internal networks and trusted networkswhat have i done wroung ?-- Benny --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: Allowing IMAP/POP to Send Email
For someone who was worried about breaking forwarding with SPF just a little while ago. What you propose below blows forwarding out of the water. On 2-Aug-06, at 4:53 PM, Marc Perkel [EMAIL PROTECTED] wrote:Allowing IMAP/POP to Send EmailThe email SMTP protocol was created in simpler times. One of the problems is that it is far too easy for any one person to impersonate any other person on the planet. One of the things that will reduce spam and fraud on the Internet is to make it more difficult for one person to impersonate someone what they aren’t. But to do this we need to change that way email is distributed and do it in a way that is a natural evolution of the current system.In the beginning the Internet was a Unix network where every computer had its own SMTP server. One person would create an email that was submitted to the local SMTP server, the local server contacted the destination SMTP server and that server would deliver the message into the local email box. That method still works today but few people get their email that way.Yes and there use to be a time when every SMTP server was an open relay and you could use any server to send email. Unfortunately criminals are abusing the present system to their advantage and our detriment.Sender --> SMTP --> Recipient Actually the system works like thisSender (SMTP) -- Sender’s Server (SMTP) -- Recipient’s Server (SMTP) -- Recipient (POP/IMAP)Sender -- SMTP -- Recipient (is usually intranet mail or mail sent between recipients of the same domain)which would take the form ofSender (SMTP) -- Sender’s/Recipient’s Server (SMTP) -- Recipient (POP/IMAP)but also allows for Sender -- SMTP -- SMTP -- SMTP -- Recipient (where there can be any number of intermediate SMTP servers)orSender -- Forwarding SMTP -- SMTP -- SMTP -- Recipient (where there can be any number of intermediate Forwarding and standalone SMTP servers)It's a real mess! Today we have more of a consumer model where consumers run email clients and leave the SMTP servers to their Internet Service Providers (ISPs) The user creates an email message that is sent to their local ISP who has an SMTP server. That server accepts the email and then transfers the email by SMTP to the server that stores the incoming email for that user. Then the recipient connects to their server by POP/IMAP protocols to download their email.Sender --> SMTP --> Sender’s ISP Server Sender’s ISP Server --> SMTP --> Recipient’s ISP Server Recipient’s ISP Server --> IMAP --> Recipient The problem is that anyone can impersonate any other person by setting their address to be anyone else on the planet. SMTP provides no checking to determine if the sender is the same person as they say they are. And the end user is using the same protocols to talk to servers that servers use to talk to each other so servers can’t tell if they are talking to legitimate servers or end users. I suggest a modification in the IMAP/POP protocols that allow for a two way transfer of email rather than requiring incoming email to be downloaded with IMAP/POP and outgoing to be SMTP.Sender --> IMAP --> Sender’s ISP Server Sender’s ISP Server --> SMTP --> Recipient’s ISP Server Recipient’s ISP Server --> IMAP --> Recipient If IMAP and POP were enhanced to allow outgoing email to be transferred back up the same connection as incoming email it would have several advantages.It would eliminate the need to configure outgoing SMTP. That makes it easier for the consumer. It would also eliminate the need for authenticated SMTP because IMAP/POP are already authenticated protocols.You're just trading IMAP/POP (which isn't designed for what you propose) for SMTP and gaining nothing. What's wrong with authenticated SMTP? Viruses would not be able to send email because the outgoing email connection, IMAP, will require a password to send email. The virus won’t have the password and won’t be able to send.You can configure your client now to ask for a password before sending email even with authenticated SMTP. It's just that people don't configure it that way because it's inconvenient.Most zombies responsible for sending spam are self contained with mini SMTP servers. So what if you use IMAP/POP, they'll just contain mini versions of that instead.The server would accept outgoing email and label the from field to be the same as the email account preventing the user from pretending to be an email address other than the one the user authenticated as. It would then deliver the message to the local SMTP server which would then send it to the destination server.So you propose configuring every outgoing email server to know every possible return address that an account is allowed to use for outgoing email. I host many domains on my server. How is the server suppose to know which outgoing domain I'm using if it doesn't read it from my email client. And if we leave it to the client to inform the server what email address to stamp the outgoing message with then what's to prevent me
Re: Am I wasting my time with SpamCop?
On 2-Aug-06, at 4:53 PM, [EMAIL PROTECTED] wrote:Anyone serious about stopping SPAM should not use SpamCop. They have no real checking method, it's like AOL's spam blocking method...they just let users submit what they think is spam and then block it. It's pointless. There's not even a way to contact anyone at SpamCop to fix a falsely listed server or what not. They are a joke. John Rudd wrote: On Aug 2, 2006, at 1:09 PM, Zinski, Steve wrote: I use SpamCop to report my spam. I use the SpamHaus RBL as a first line of defense then I use SpamAssassin to catch the rest of the spam coming to my server. Am I wasting my time? Should I just delete low-scoring spam and let the honeypots harvest and report to the various RBLs, or should I keep reporting spam via SpamCop (which wastes a lot of my time). In my experience, SpamCop is a colossal waste of _everything_ it uses. Time, space, energy, matter, etc. But that's just "in my experience". YMMV. Well I use Spamcop as one of my RBLs and it has been fantastic, absolutely no false positives.When I have time I also take the time to report spam that gets through the RBL and Spamassassin checks.No problems here. --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: Allowing IMAP/POP to Send Email
On 2-Aug-06, at 6:29 PM, Jason Haar [EMAIL PROTECTED] wrote:FYI: Courier-IMAP has had this feature for some time. You can configure it so that any mail message dropped into an IMAP subfolder named (e.g.) "Outbox" will be auto-sent - i.e. piped into /usr/sbin/sendmail. Completely removes the need for SMTP. Of course, it would really require all MUAs to be rewritten to "hide" this technical backend skulduggery from the end-user. They should just be able to hit "Send" as usual. -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 If it's piped into '/usr/sbin/sendmail' then it is still using SMTP. Sendmail is an SMTP server.--Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: Allowing IMAP/POP to Send Email
On 2-Aug-06, at 7:29 PM, [EMAIL PROTECTED] wrote:Sniffers exist. Passwords are NOT the solution. They may evolve into part of the problem. Traffic analysis and slow downs for sending too many emails too rapidly are part of the solution. Forcing authenticated SMTP submission finishes the solution. The authenticated SMTP exists now. It has password problems via simple sniffing. I wish Earthlink supported SSL connections which can't be sniffed. That at least raises the password ante a little. They probably don't want to use SSL because that encrypts the whole communication even the body of the message. That might be noticeable on older, slow computers their clients may still be using if they are sending a message with a large attachment. A better authentication method would just encrypt the account name and password but Outlook/Outlook Express, arguably the most used email clients, don't support anything but MS's own proprietary technology for doing that.The slow down technology exists. Earthlink claimed to be using it something like a decade ago. If the data extracted from the slow down technology is used to simply shut off accounts that are spewing, in real time, zombie spam would be materially reduced. Automated submission of spewing addresses to Block Lists from larger ISPs that can notice the patterns would also help everyone. But mere passwords on unsecure protocols are no really big deal other than it, theoretically, points to a specific machine that can be shut down. (Since zombies share data it'll be a short time before this also becomes mooted.) There is no "solution" there is only measure and counter-measure as both sides get better at what they want to do. Selling snake oil about POP3 or IMAP email submission is just plain amateurish stupidity if it is not driven by an ulterior motive. {^_^} --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
smime.p7s
Description: S/MIME cryptographic signature
Re: SPF breaks email forwarding
On 27-Jul-06, at 4:32 PM, Hamish wrote: On Wednesday 26 July 2006 17:25, Marc Perkel wrote: Benny Pedersen wrote: On Tue, July 25, 2006 18:51, Marc Perkel wrote: SPF breaks email forwarding. My users use forwarding. fair, but why not stop using forwarding ? Because my customers want to use forwarding. Perhaps it would be fairer to say that SPF is fine but the forwarding is broken. Forwarding should (IMO) be implemented in such a way as the FORWARDING mailbox should be used as the new return-path (Just like if you forwarded an email from your MUA rather than with the MDA). Then both SPF and forwarding would work fine. And furthermore be consistent. Hamish. That's the basic idea behind SRS. The forwarding server re-writes the header and takes responsibility for the forwarded email. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
On 26-Jul-06, at 4:00 AM, Rolf Kraeuchi wrote:Gino Cerullo schrieb:[...] Hey, I never claimed checking and rejecting before DATA to be ready for'large scale' deployments. ;-) But, I have to say that in the six monthsthat I've been doing it I've never had a false positive. knocks onwood Also, I've been publishing an SPF record for over two years andagain, I've never had a problem with mail being rejected, misdirected orlost.The truth is that there is no reason for any domain not to be able topublish SPF records that end in at least a SOFTFAIL (~all). [...] Well, maybe there is. Doesn't SA score SOFTFAIL with more than 1 point?regards,rolfNo, the default scores are as follows.SOFT_FAIL 0.5FAIL 0.9 --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503 smime.p7s Description: S/MIME cryptographic signature
Re: SPF breaks email forwarding
On 26-Jul-06, at 10:46 AM, Graham Murray wrote: Rolf Kraeuchi [EMAIL PROTECTED] writes: Hmm, SOFTFAIL scores higher than FAIL?? Maybe because some (many?) people reject SPF fail at SMTP time, so spam with SPF fail is not presented to SpamAssassin. Actually this makes sense in my situation. I normally reject at the MTA on FAIL and let everything else through where it gets examined by SA. I have users who use AUTH to connect to my server from outside to send mail. The MTA correctly ignores the fact that they are connected from a unauthorized, according to SPF, IP address but because SA scans the outgoing email regardless, it scores that message as a FAIL. If the score was too high for FAIL then these legitimate messages could be rejected even before they left the sending server. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
Whether it's SPF, DKIM, a combination of both or something completely new, the laissez-faire attitude of the past toward SMTP just doesn't cut it anymore. Criminals (and yes, I consider anyone who forges an identity to hide who they are a criminal no matter their intent) have taken advantage of the loose way in which SMTP was and still is implemented and they are causing considerable damage. If a few 'eggs' have to be broken on the way to securing our email systems than so-be- it. I agree with Michael Scheidell, SMTP is broken. has been, phishing, forgeries, email viruses prove it. To make a statement like SPF breaks email forwarding and not offer an alternative merely makes you come off as a troll with an agenda. Now, I know from your contributions here that you are neither a troll or have an ulterior motive with such a statement but at the same time I can't even trust that the original email came from Marc Perkel [EMAIL PROTECTED]. As it stands, I can't trust the integrity of your domain 'perkel.com' since it does not have an SPF record. Anyone can claim to be you, even a troll. Now, you might say that s/mime could be the answer to that and you'd be correct but s/mime is expensive. Expensive in computer resources because it means that my server still has to receive every email, process it through virus and spam filters and then pass it on to me where what remains still has to be evaluated by me or my MUA. The idea behind SPF and its contemporaries is that obvious forgeries are handled by the MTA before entering the system for further evaluation, taking a huge load off the infrastructure we've been forced to put in place to deal with a system that is clearly, at present, broken. Personally, I think SPF, DKIM and any other workable proposal goes beyond just protecting me from spam, phishing and email viruses. It protects the integrity of my domains and further, the IP addresses in my control since I insist that all the domains I host on my server all have SPF records. People can trust that an email message claiming to come from one of my domains or from one of my IP addresses does in fact originate there. Thanks -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
Hello, is this really Marc? ;-) Sorry about the rant Marc, if that's you. I understand why you can't or won't implement SPF and I don't blame you under the circumstances. It's just that your statement was at best obvious and at the same time incomplete. A more accurate statement would have been, SPF breaks email forwarding for my users and myself because my email forwarder does not support SRS for which we would have said something like, well don't use SPF or better yet, find a different email provider that has implemented SRS and you too can implement SPF. Other statements that would have been considered more acceptable to starting a conversation in general would have been, SPF breaks email forwarding in present SMTP implemenations or SPF breaks email forwarding due to that lack of the wide spread implementation of SRS but then we would have just said Duh! On 25-Jul-06, at 12:51 PM, Marc Perkel wrote: I don't have an SPF record because I refuse to support a broken technology. SPF breaks email forwarding. My users use forwarding. SMTP is broken - but I can't change that. I have to be compatible with the rest of the world. Again, it's not that SPF is a broken technology, it's that SMTP, at best, hasn't caught up to it yet or at worst, as has been stated already, is broken. Also, no one is forcing you to implement SPF, or are they? Tell me who they are, I'll send my boys. Gino Cerullo wrote: Whether it's SPF, DKIM, a combination of both or something completely new, the laissez-faire attitude of the past toward SMTP just doesn't cut it anymore. Criminals (and yes, I consider anyone who forges an identity to hide who they are a criminal no matter their intent) have taken advantage of the loose way in which SMTP was and still is implemented and they are causing considerable damage. If a few 'eggs' have to be broken on the way to securing our email systems than so-be-it. I agree with Michael Scheidell, SMTP is broken. has been, phishing, forgeries, email viruses prove it. To make a statement like SPF breaks email forwarding and not offer an alternative merely makes you come off as a troll with an agenda. Now, I know from your contributions here that you are neither a troll or have an ulterior motive with such a statement but at the same time I can't even trust that the original email came from Marc Perkel [EMAIL PROTECTED]. As it stands, I can't trust the integrity of your domain 'perkel.com' since it does not have an SPF record. Anyone can claim to be you, even a troll. Now, you might say that s/mime could be the answer to that and you'd be correct but s/mime is expensive. Expensive in computer resources because it means that my server still has to receive every email, process it through virus and spam filters and then pass it on to me where what remains still has to be evaluated by me or my MUA. The idea behind SPF and its contemporaries is that obvious forgeries are handled by the MTA before entering the system for further evaluation, taking a huge load off the infrastructure we've been forced to put in place to deal with a system that is clearly, at present, broken. Personally, I think SPF, DKIM and any other workable proposal goes beyond just protecting me from spam, phishing and email viruses. It protects the integrity of my domains and further, the IP addresses in my control since I insist that all the domains I host on my server all have SPF records. People can trust that an email message claiming to come from one of my domains or from one of my IP addresses does in fact originate there. The only legitimate excuse I hear for not implementing SPF has to do with forwarding. There are situations beyond the control of the people involved that prevent them from implementing it. Until the default behaviour of an MTA is to implement SRS or SRS can easily be implemented in existing MTAs this will continue to be a problem. We'll just have to live with that for now. All the other excuses I hear regarding the lack of implementation of SPF are due to a lack of understanding of the protocol, laziness or the unfounded loss of control, I refusal to implement a protocol that controls which email servers I can send my mail from, excuse. To them I say, SPF and its contemporaries are the future, you can either implement them or find your email in the bit bucket. The choice is yours. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
On 25-Jul-06, at 5:05 PM, Daryl C. W. O'Shea wrote:I'd settle for just well defined, and actually usable.Or we could just wait until it actually works right.That sounds reasonable. If the protocol is as sound as it appears to be, the MTA developers will make an effort to implement it. If not, then it just wasn't meant to be.You find me a large scale installation that is actually checking, and rejecting on, SPF records before DATA and isn't frequently rejecting mail their users want and I'll buy you lunch. Daryl Hey, I never claimed checking and rejecting before DATA to be ready for 'large scale' deployments. ;-) But, I have to say that in the six months that I've been doing it I've never had a false positive. knocks on wood Also, I've been publishing an SPF record for over two years and again, I've never had a problem with mail being rejected, misdirected or lost.The truth is that there is no reason for any domain not to be able to publish SPF records that end in at least a SOFTFAIL (~all). It would at least allow filters like Spamassassin to have additional data to use in its scoring and a SOFTFAIL will not prevent forwarded email from reaching it's destination. Nobody in there right mind rejects on a SOFTFAIL. --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: SPF breaks email forwarding
On 25-Jul-06, at 5:05 PM, Bill Landry wrote: I only recently got spamassassin up and running and am hardly an expert but can anyone explain to me exactly what spf is? See http://www.openspf.org/ for detailed information on SPF. Bill There is also http://new.openspf.org/ If you are really interested you can subscribe to their mailing lists here http://new.openspf.org/Forums If you like you can email me directly as well. I would imagine that people are getting tired of us going off-topic on this list by now. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
On 25-Jul-06, at 6:34 PM, Marc Perkel wrote: Many people, including me, think SRS is a bad idea. So I'm not getting on board with a system that is clearly a mistake. That's fine. You, along with everyone else, are entitle to your opinion. Furthermore, you along with those people are free to choose to implement a technology if it suits you. No one is forcing this on you or anyone else. At the same time, I am merely excising my freedom to voice an alternate view or opinion. The people reading this list will make up there own minds. Some may have even benefited from this thread. I am curious though. Why do you think SRS is a bad idea and what makes it clearly a mistake. You appear to feel strongly about this but without an explanation it's hard to fathom why. Please elaborate. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: SPF breaks email forwarding
On 25-Jul-06, at 6:34 PM, Michele Neylon wrote: After some of the clever implementations I've seen NOTHING would surprise me The word muppetry springs to mind :) Ahh, but that's why I qualified my statement by saying, Nobody in there right mind... I notice your SPF record ends in NEUTRAL (?all) do you have a tale to tell or are you just being overly cautious for now? -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: users Digest 18 Jul 2006 15:14:24 -0000 Issue 1541
On 18-Jul-06, at 11:14 AM, Logan Shaw [EMAIL PROTECTED] wrote:On Tue, 18 Jul 2006, Chr. v. Stuckrad wrote: I'm a postmaster working with spamassassin (now debian sarge) for the last years, we habe one filter-host for all mails, so at the moment we have only one global bayes-database.. We are a department for math and computer science and so we get zillions of spam for all addresses 'known on the net' and we get ham for lots of different 'themes' for different workgroups in diverse languages (mostly german of course, being Berlin Germany). Not beeing allowed to peek into other users mailboxes I have no 'representative ham corpus' but only my own, which seems to be very postmaster-specific, while I seem to get a typical average of spams (because my address already existed on a 'News' server :-). Can somebody tell me, whether the bayes-database's accuray does deteriorate by feeding it 'only my spam' (my false negatives) and not feeding it the (to me unknown) typical hams. Yes, feeding your Bayes database only spam is a bad idea. As an analogy, imagine that you are a policeman trying to learn to identify dangerous and violent people. You examine 100 violent criminals, and all of them are carrying knives. You don't examine anyone else, though, so based on your sample, anyone carrying a knife must be a violent criminal. The reasoning for this is simple: every time you have seen someone carrying a knife, they have been a violent criminal, so knife-carrying correlates perfectly with being a criminal. Now imagine that you see a chef. He is carrying a knife, but what does your experience tell you about him? You have never seen anyone *else* carrying a knife who wasn't a criminal, so this new guy must be a criminal too. But he's not: he's just a chef. This problem only arises with words (tokens) that could be expected to appear in both spam and ham. It isn't a problem for words that are names of "performance-enhancing" drugs. But it is a problem for neutral words. For example, a word like "link" or "today" might occur in both ham and spam, so it doesn't indicate much about which type of message it is. But if you train your Bayes database only with spam, it will see neutral words as strongly associated with spam. Basically, by doing that, you will give it a very negative view of the world, where everything looks like spam. (This is all assuming, of course, that your Bayes database is empty when you train it with spam only.) To me it lately seems to slowly skew to let more and more spam through, instead of 'catching' it. Is this typical? Do I have to recreate the database? Or do I need to get 'ham from a set of typical users' to balance the database? OR are there typical values for bayes_auto_learn_threshold_{non,}spam, different from the defatult, to use in my case? To answer that question, we'd first have to know whether Bayes is really at fault here. Perhaps there are other configuration changes that need to be made. Do you have the latest SpamAssassin, and have you enabled some network tests like dcc or razor and some RBLs? Those should be carrying some of the load; you shouldn't be relying on Bayes only, because these days Bayes alone isn't sufficient. If your Bayes database really is messed up, personally I would recommend that you just wipe it and start over. If you have the proper setup, then you can be confident it will be trained correctly. Yes, you would be throwing away existing data, but what you get in exchange is the knowledge that the data you *do* have is worthwhile. Just curious why so many spams get through to me ... (i.e. around 10 false negatives relative to 90 marked as spam, which ist 'relatively bad' compared to many opinions on the list) Well, there are probably several different explanations. The best place to start is by looking at the spams that get through and how they scored, especially comparing that to what scores others get on the same messages or similar ones. - Logan Great analogy Logan and reading it only reinforces by belief that Stucki's problem may not be due to a DB skewed by too much spam. Actually the opposite result would probably be true. If the DB was skewed with too much spam the result would normally be too many false positives. The DB would be skewed by too many tokens for 'neutral' words. Stucki, maybe Spamassassin is working better then you think and the answer to your false negatives is to lower the score at which a message is considered spam. Have you examined the scores assigned to your ham messages? Assuming your spam score level is set at 7 and all your ham is scoring below 4 maybe you should adjust the score to 5.Just something to consider. --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
smime.p7s
Description: S/MIME cryptographic signature
Spamassassin and SPF
I have a question regarding Spamassassin's behaviour with SPF. My configuration is running Postfix v2.1.5 and Spamassassin v3.0.1 is called by Amavis-new v2.2.0 as is installed as part of Mac OS X Server 10.4.x All domains handled by the email server have strict SPF records that require all account holders to send their email through the server. As such all account holders authenticate with the server through the submission port 587 when they want to send email from outside the network. I noticed that Spamassassin is scoring an SPF_FAIL with these users based on the fact that they are connecting with IPs that fall outside what is in their domain's SPF record. It seems to me that this is the incorrect behaviour. Spamassassin should not be evaluating the IP address from which the clients are connecting but should be ignoring that altogether. The Postfix policy daemon is handling this correctly , as it should, ignoring where the client is connecting from since it is the outbound server. It's not evaluating itself against the SPF record. Is there something that is configured incorrectly that is causing this to happen? Has this behaviour changed in a more recent version of Spamassassin? Any suggestions would be appritiated. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503 smime.p7s Description: S/MIME cryptographic signature
Re: Spamassassin and SPF
On 10-Jul-06, at 5:49 PM, Daryl C. W. O'Shea wrote: If the MSA in question is *ONLY* an MSA, you're easiest quickest fix is to just not trust it (or mark it as trusted but not internal). If I'm understanding you correctly, I'm fairly new to this, then no, the MSA (Mail Submission Agent) is also the MTA (Mail Transfer Agent.) All mail for the domains in question are received and delivered by this one server. trusted_networks lists my public and private IP addresses (WAN LAN) internal_networks lists only private IP addresses (LAN) I think that's how those are suppose to work. I haven't bothered to try and list the IPs where outside users may connect from since that can be anywhere. If SA is running on that host, or it's also doing another mail function, MX or intermediate relay, etc., then describe your mail topology and we'll help you out. Okay, this one server is running Postfix, Amavisd-new, Spamassassin, ClamAV, pretty standard stuff. This server does not relay to any other servers for mail delivery and is not a relay for any servers. Both incoming and outgoing mail is handled by Postfix which hands it off to Amavisd-new which calls Spamassassin and ClamAV to scan the message. Clean email is handed back to Postfix to complete delivery. Bad email is quarantined by Amavis-new. At least that's my understanding of how it works. Generally, because of SPF, all users submit directly to this server and all outgoing email for the domains handled by this server are delivered directly by this server, no relays involved. Fairly simple stuff and it all works as expected except for SA. Daryl This is what I'm seeing if it helps. 0.9 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.org/why.html? sender=dmaguire% 40maguiremarketing.comip=24.42.90.104receiver=server.pixelpointstudios .lan] maguiremarketing.com is hosted by the server in question. 24.42.90.104 is the IP address that he is connecting from. In this case it's the IP assigned dynamically to his router by his cable company (ISP). Like I said the Postfix policy daemon that checks SPF correctly ignores this IP address as it represents the MUA (Mail User Agent.) I guess I'm expecting SA to know that as well but I guess it doesn't. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503 smime.p7s Description: S/MIME cryptographic signature
Re: Spamassassin and SPF
On 10-Jul-06, at 7:39 PM, Daryl C. W. O'Shea wrote:
Gino Cerullo wrote:
On 10-Jul-06, at 5:49 PM, Daryl C. W. O'Shea wrote:
If the MSA in question is *ONLY* an MSA, you're easiest quickest
fix is to just not trust it (or mark it as trusted but not
internal).
If I'm understanding you correctly, I'm fairly new to this, then
no, the MSA (Mail Submission Agent) is also the MTA (Mail Transfer
Agent.) All mail for the domains in question are received and
delivered by this one server.
trusted_networks lists my public and private IP addresses (WAN LAN)
internal_networks lists only private IP addresses (LAN)
These are incorrect for your setup. Trusted and internal networks
should both list YOUR public and private IP addresses. IP
addresses of other people could go in trusted networks only, but
don't even bother with that.
The only 'one' of your addresses that wouldn't go in internal
networks would be your MSA if it was only an MSA, but yours isn't
as you've said it's also working as an MX.
I think that's how those are suppose to work. I haven't bothered
to try and list the IPs where outside users may connect from since
that can be anywhere.
So... fixing the above will resolve your SPF (and other) issues for
LAN users. Add all the IP space you control to trusted networks
(including your internal RFC 1938 ranges). Don't even bother with
setting internal networks. In your case they'll be the same as
your trusted networks, so SA will just copy them for you if you
leave internal networks unset.
Thanks for the clarification. I'll make the changes.
That still leaves a problem with your roaming users not being
trusted. Postfix makes this oh so fun.
If SA is running on that host, or it's also doing another mail
function, MX or intermediate relay, etc., then describe your mail
topology and we'll help you out.
Okay, this one server is running Postfix, Amavisd-new,
Spamassassin, ClamAV, pretty standard stuff. This server does not
relay to any other servers for mail delivery and is not a relay
for any servers. Both incoming and outgoing mail is handled by
Postfix which hands it off to Amavisd-new which calls Spamassassin
and ClamAV to scan the message. Clean email is handed back to
Postfix to complete delivery. Bad email is quarantined by Amavis-
new. At least that's my understanding of how it works.
Generally, because of SPF, all users submit directly to this
server and all outgoing email for the domains handled by this
server are delivered directly by this server, no relays involved.
Fairly simple stuff and it all works as expected except for SA.
This is what I'm seeing if it helps.
0.9 SPF_FAIL SPF: sender does not match SPF record
(fail)
[SPF failed: Please see http://www.openspf.org/why.html?
sender=dmaguire%
40maguiremarketing.comip=24.42.90.104receiver=server.pixelpointstud
ios.lan] maguiremarketing.com is hosted by the server in question.
24.42.90.104 is the IP address that he is connecting from. In this
case it's the IP assigned dynamically to his router by his cable
company (ISP).
Like I said the Postfix policy daemon that checks SPF correctly
ignores this IP address as it represents the MUA (Mail User
Agent.) I guess I'm expecting SA to know that as well but I guess
it doesn't.
You can't expect SA to do something based on information that
Postfix has and SA doesn't (because Postfix doesn't give it up, at
least not easily), that is, SA doesn't know the user is an
authenticated user while Postfix does.
This is what I thought. Thanks for confirming this as well.
You have two options:
1) Quoting mouss...
mouss wrote:
martin f krafft a écrit :
Well, sure, this makes sense, but how can I support this standard
use-case? Postfix adding a SASL-header that causes Spamassassin
then
to ignore the message isn't the solution as spammers would
simply do
that sooner or later. Short of whitelisting people, what should
I do?
how do you integrate SA with postfix?
If using content_filter, then you could skip SA for authenticated
users.
for instance:
content_filter=
#or this to still check for viruses:
#content_filter=scan:[clamsmtp.domain.example]:10020
smtpd_recipient_restrictions =
...
permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
check_client_access pcre:/etc/postfix/default_filter.pcre
...
== default_filter.pcre:
/./FILTER scan:[amavisd.domain.example]:10024
('scan' is the name of the transport as defined in master.cf).
I see but is the trade-off here that if SA skips authenticated users
and they are compromised then they can become spam sources that
wouldn't be caught locally or does it only skip SPF and still do all
other scans?
or
2) Upgrade to Postfix 2.3, if necessary, set
smtpd_sasl_authenticated_header yes in your Postfix config and
then offer to buy me lunch next time I'm in the city
Re: Spamassassin and SPF
On 10-Jul-06, at 9:16 PM, Daryl C. W. O'Shea wrote: Snip, snip and more snip. Thanks for all that good info. I see from the header in the message you sent that you have deployed DKIM. I'm hoping to do that as well but not for a while yet. Do similar problems arise with DKIM and SA as we've discussed here with SPF? DKIM doesn't rely on any defined set of relays. It uses the envelope sender (usually just the domain) and the signature found in the headers. Someday I'll have some time to play with this and get a better understanding of DKIM. Also note that SPF isn't the only thing suffering from your trust path issues, it's just a symptom you've noticed. You'll also currently be doing dynablock checks against users you'd rather not be, along with a whole slew of other tests that will FP when SA thinks it's testing mail from some random system/zombie and not an authenticated user. So what you're saying is that I'm better off not scanning authenticated users. I'll take your word on that. Let me know if you're running Postfix 2.3 and can enable the auth headers in your config. I'll probably get to making a patch tonight as long as the rain doesn't stop and I don't get distracted by the big stash of fireworks I've accumulated. :) Well I'm running Postfix v2.1.3 (standard in OS X Server 10.4.x.) I'm waiting until Apple previews OS X 10.5 in August to see whether 10.5 includes Postfix v2.3. If not than I may do the upgrade myself in 10.4. Since SA is being called by Amavisd-new shouldn't the changes to ignore authenticated user happen there? I think I read that somewhere, maybe the Amavis mailing list. That's the problem with being subscribed to all these lists. They all start to run into each other in your head. Off to the archives I go. BIG STASH OF FIREWORKS! Boy I'm glad you don't live in my neighbourhood. :-O Daryl -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503 smime.p7s Description: S/MIME cryptographic signature
Re: Looking for Turn-key SA solution
On 5-Jul-06, at 3:37 PM, [EMAIL PROTECTED] wrote:Does anybody know of a vendor that sells boxes with SpamAssassin pre-installed, with a pretty GUI with quarantine ability? (My company won't allow home-brewed solutions, as they want a vendor to call if I get hit by a spam bus).-- Burton Windle [EMAIL PROTECTED] Mac OS X Server 10.4.x comes with Postfix-Cyrus-Amavis-Spamassassin-ClamAV-SquirrelMail-Mailman pre-installed with a nice GUI to configure the basic settings. More advanced settings are still done through config files at the command line.Mac OS X Server web page: http://www.apple.com/server/macosx/Info about mail services (includes a look at the spam and virus configuration panel): http://www.apple.com/server/macosx/features/mailservices.html--Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503 smime.p7s Description: S/MIME cryptographic signature
Re: users Digest 29 Jun 2006 09:48:58 -0000 Issue 1518
On 29-Jun-06, at 5:48 AM, Leigh Sharpe wrote:1) Bayes is still in training. I've only recently given everybody the opportunity to feed it spam. I expect it to get better soon. My question was more related to why this stuff is getting through now, when it used to get blocked. I'm guessing your using 'junkmail/notjunkmail' accounts on the server where everybody is sending their SPAM (junkmail) and HAM (notjunkmail) to.Is it possible that some people may be making an error and sending SPAM to the 'notjunkmail' account? You might want to keep an eye on that. If you've employed another method of training disregard this post or better yet describe your training method so that we can see if the problem does lie there. I believe not training it with HAM can also be detrimental, especially during it's initial training. It needs to have at least 200 HAM messages for the bayes filter to be accurate.--Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: Bounced messages for email from forged email addresses for a hosted domain - need opinions
On 25-Jun-06, at 12:58 PM, "Jim Hermann - UUN Hostmaster" [EMAIL PROTECTED] wrote:Does it do any good to complain to the ISP that accepted the original emailwith a forged email address that uses a domain name that I administer?I administer a number of domain names that are being used in the forgedemail addresses for spam that is sent to recipients on other servers. Somepeople call this a JoeJob. Obviously, I can't prevent this, although I canuse SPF with HARDFAIL to help the recipient server identify that the emailaddress has been forged.The problem is that my server receives numerous bounced messages from therecipient servers because the recipients do not exist or do not accept thespam. Of course, I can reject or delete the bounced messages if the forgedemail address does not exist.However, I would like to be more proactive and complain to the ISP thataccepted the original email. The bounced message often includes the FullHeaders for the original email message. Most of these emails originate onmany different IP Addresses. I assume that these machines are zombies orpart of a network of machines that spammers control. Will the ISP takeaction if they receive a complaint? The ISPs are all of the world, notconcentrated in one region or country.Jim-Jim Hermann [EMAIL PROTECTED]UUism Networks http://www.UUism.netMinistering to the Needs of Online UUsWeb Hosting, Email Services, Mailing Lists Personally, nowadays I believe bouncing messages back to the alleged sender is a waste of resources and bandwidth with the amount of forgery going on. I wish that admins would configure their servers to stop that practice. Complaining to those admins I'm afraid will be an exercise in futility as trying to reach the right person will be nearly impossible and risks becoming a full time job in itself. My vote would be for setting SPF for HARDFAIL as soon as is feasible, after all dealing with forgery is what SPF was designed for. Sure, unless those ISPs are checking against SPF it may not help but that situation is getting better all the time as more and more SPF is being deployed. --Gino CerulloPixel Point Studios21 Chesham DriveToronto, ON M3M 1W6T: 416-247-7740F: 416-247-7503
Re: Bounced messages for email from forged email addresses for a hosted domain - need opinions
On 25-Jun-06, at 5:51 PM, John D. Hardin wrote: On Sun, 25 Jun 2006, Gino Cerullo wrote: Does it do any good to complain to the ISP that accepted the original email with a forged email address that uses a domain name that I administer? Personally, nowadays I believe bouncing messages back to the alleged sender That's not what he's asking. He wants to know whether asking ISPs to implement SPF checks (where they don't yet check SPF) will work. I'm not convinced that is what he meant but he wasn't clear about it so I wont argue with you on that point. I still think trying to contact those ISPs directly will be an exercise in futility but if he wants to try it certainly wont hurt. My vote would be for setting SPF for HARDFAIL as soon as is feasible, after all dealing with forgery is what SPF was designed for. Sure, unless those ISPs are checking against SPF it may not help but that situation is getting better all the time as more and more SPF is being deployed. So how do we increase the use of SPF checks? Ahhh! The million dollar question and one probably better suited to the SPF mailing lists...but since you asked. Evangelize. If you believe in a technology and it's benefits talk to people about it and hopefully your passion will rub off on them and they will turn around and do the same. Word-of-mouth is one of the best ways to spread...well...'The Word' but it works best when you are talking to people who value your opinion or at least are asking for it directly. That's why I feel an email from a stranger on the other side of the world whose tired of dealing with you bouncing messages back to him probably will have little influence. Although, it may make the person on the other side of that email aware of a tech they may not otherwise be aware of, that's why I also say it couldn't hurt. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
Re: Bounced messages for email from forged email addresses for a hosted domain - need opinions
On 25-Jun-06, at 7:22 PM, John D. Hardin wrote: On Sun, 25 Jun 2006, Jim Hermann - UUN Hostmaster wrote: There are at least two ISPs involved: Spammer A = SMTP Server B = Recipient Server C = (Bounce) = Forged Email Server D I don't think that's the case for most spam these days. For a spambotnet of compromised home systems, you'll see: Spambot A = Recipient Server C = (Bounce) = Forged Email Server D I think you've just proved my point. It's too hard to try and determine who to contact in these situations I already use SPF HARDFAIL, so I could ALSO complain to Recipient Server C about NOT using SPF to reject the email from SMTP Server B. Agreed. Again, this has merit but your approach will determine how successful you are. Also, it may be easier to determine who to approach about the subject. -- Gino Cerullo Pixel Point Studios 21 Chesham Drive Toronto, ON M3M 1W6 T: 416-247-7740 F: 416-247-7503
