Re: Unusual spam recently - hummm
Op za 05-06-2004, om 10:26 schreef Kjetil Kjernsmo: On fredag 4. juni 2004, 03:24, s. keeling wrote: I'm sick of whitelisting. It doesn't work if you care about communicating with people you've never met. Me too. And I think that most absolutes, whether it is a single rule to accept an e-mail or a single rule to reject is a Bad Thing[tm] But I'd like to plug a bug report of mine, FOAF-based whitelists: http://bugzilla.spamassassin.org/show_bug.cgi?id=3408 FOAF, Friend-of-a-Friend is meant to be used to mark up relationships, and so, SpamAssassin could set a lower negative score to those you know someone who knows, etc... If FOAF becomes as widespread as personal homepages, it could be really useful. So, let me also plug another bug report of mine, let KAddressbook export FOAF: http://bugs.kde.org/show_bug.cgi?id=72653 What about the privecy? Good question! Well, I must admit I haven't thought so carefully about it, but I'm sure the hackers working on this have. For one thing, each and every one publish their own information, and in principle, a single hashed version of the trusted e-mail address should be sufficient for this to work, and that's not too bad... Best, Kjetil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Op za 05-06-2004, om 10:26 schreef Kjetil Kjernsmo: On fredag 4. juni 2004, 03:24, s. keeling wrote: I'm sick of whitelisting. It doesn't work if you care about communicating with people you've never met. Me too. And I think that most absolutes, whether it is a single rule to accept an e-mail or a single rule to reject is a Bad Thing[tm] But I'd like to plug a bug report of mine, FOAF-based whitelists: http://bugzilla.spamassassin.org/show_bug.cgi?id=3408 FOAF, Friend-of-a-Friend is meant to be used to mark up relationships, and so, SpamAssassin could set a lower negative score to those you know someone who knows, etc... If FOAF becomes as widespread as personal homepages, it could be really useful. So, let me also plug another bug report of mine, let KAddressbook export FOAF: http://bugs.kde.org/show_bug.cgi?id=72653 What about the privecy? Good question! Well, I must admit I haven't thought so carefully about it, but I'm sure the hackers working on this have. For one thing, each and every one publish their own information, and in principle, a single hashed version of the trusted e-mail address should be sufficient for this to work, and that's not too bad... Best, Kjetil
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): You're talking about SPF. That's a concept, not an implementation. Implementation details have already been posted. Effective use of SPF requires widespread adoption. Until/unless widespread adoption happens the promises of SPF are vaporware. Reasons why early adoption yields large benefits have already been posted. (Further attempt to redefine the word vaporware duly ignored as of secondary concern.) I expect we're done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): You're talking about SPF. That's a concept, not an implementation. Implementation details have already been posted. Effective use of SPF requires widespread adoption. Until/unless widespread adoption happens the promises of SPF are vaporware. Reasons why early adoption yields large benefits have already been posted. (Further attempt to redefine the word vaporware duly ignored as of secondary concern.) I expect we're done.
Re: Unusual spam recently - hummm - postprocess
On Sat, 5 Jun 2004 08:52, Michael Stone [EMAIL PROTECTED] wrote: So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Which leads to more spam that uses addresses from small domains in the From: field, and thus more need for administrators of small servers to implement SPF records to counter it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Sat, 5 Jun 2004 08:52, Michael Stone [EMAIL PROTECTED] wrote: So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Which leads to more spam that uses addresses from small domains in the From: field, and thus more need for administrators of small servers to implement SPF records to counter it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Unusual spam recently - hummm
On fredag 4. juni 2004, 03:24, s. keeling wrote: I'm sick of whitelisting. It doesn't work if you care about communicating with people you've never met. Me too. And I think that most absolutes, whether it is a single rule to accept an e-mail or a single rule to reject is a Bad Thing[tm] But I'd like to plug a bug report of mine, FOAF-based whitelists: http://bugzilla.spamassassin.org/show_bug.cgi?id=3408 FOAF, Friend-of-a-Friend is meant to be used to mark up relationships, and so, SpamAssassin could set a lower negative score to those you know someone who knows, etc... If FOAF becomes as widespread as personal homepages, it could be really useful. So, let me also plug another bug report of mine, let KAddressbook export FOAF: http://bugs.kde.org/show_bug.cgi?id=72653 If I only had time to write the code... :-) Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
vapaorware Re: Unusual spam recently - hummm - postprocess
hi ya On Fri, 4 Jun 2004, Michael Stone wrote: On Fri, Jun 04, 2004 at 05:26:07PM -0700, Rick Moen wrote: You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. vaporware is good and bad ... good, because if its features gets implemented right and if it is needed, it will get widely adopted vaporware is bad, when its something that is sold, that is not yet fully functional to end users and in the old days, to generate revenue for the company and commissions to the sales droids think back to the stone ages .. even the linux kernel was vaporware in the beginning and there were other equivalent options to choose from c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
On fredag 4. juni 2004, 03:24, s. keeling wrote: I'm sick of whitelisting. It doesn't work if you care about communicating with people you've never met. Me too. And I think that most absolutes, whether it is a single rule to accept an e-mail or a single rule to reject is a Bad Thing[tm] But I'd like to plug a bug report of mine, FOAF-based whitelists: http://bugzilla.spamassassin.org/show_bug.cgi?id=3408 FOAF, Friend-of-a-Friend is meant to be used to mark up relationships, and so, SpamAssassin could set a lower negative score to those you know someone who knows, etc... If FOAF becomes as widespread as personal homepages, it could be really useful. So, let me also plug another bug report of mine, let KAddressbook export FOAF: http://bugs.kde.org/show_bug.cgi?id=72653 If I only had time to write the code... :-) Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
vapaorware Re: Unusual spam recently - hummm - postprocess
hi ya On Fri, 4 Jun 2004, Michael Stone wrote: On Fri, Jun 04, 2004 at 05:26:07PM -0700, Rick Moen wrote: You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. vaporware is good and bad ... good, because if its features gets implemented right and if it is needed, it will get widely adopted vaporware is bad, when its something that is sold, that is not yet fully functional to end users and in the old days, to generate revenue for the company and commissions to the sales droids think back to the stone ages .. even the linux kernel was vaporware in the beginning and there were other equivalent options to choose from c ya alvin
Re: Unusual spam recently - hummm - postprocess
Quoting Phillip Hofmeister ([EMAIL PROTECTED]): While I am sure finding out whose is bigger is exciting to you. I feel comfortable in speaking for the rest of the list when I say this thread has become WAY OT. I'm surprised that an allegation that SPF -- highly relevant to SMTP security -- is vapourware, not to mention refutations of that assertion, are off-topic. Nonetheless, I apologise for reacting with irritation to Michael's claim to that effect: It's just that I expected better from a Security Team member. Much better. Why is SPF important? Because it eliminates joe-jobs. That is, it allows mail admins to absolutely validate the envelope return path -- significant because spammers have recently gotten around to forging sender envelope information, allowing forged mail that appears to be credibly from your domain or mine, etc. -- and as such began defeating even quite good security regimes. Why is it not vapourware? Because prepackaged kits exist to trivially add support to -=all=- of common MTAs: Postfix, Exim, sendmail, qmail, Courier-MTA, and MS-Exchange Server. I posted the link twice earlier in the conversation, well before Michael dismissed it as vapourware. Here it is again: http://spf.pobox.com/downloads.html If using Exim4 on Debian, the required daemon (perl module Mail::SPF::Query) is available as Debian package libmail-spf-query-perl . The Exim4 ACL that invokes it can be found on the above-cited page, and a SysVInit script can be pulled down from http://www.jcdigita.com/eximconfig/ . If all that's vapourware, then it's amazing how much functional and well-debugged vapourware can be located in three minutes of googling. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 11:50:09AM -0700, Rick Moen wrote: I'm surprised that an allegation that SPF -- highly relevant to SMTP security -- is vapourware, not to mention refutations of that assertion, are off-topic. Nonetheless, I apologise for reacting with irritation to Michael's claim to that effect: It's just that I expected better from a Security Team member. Much better. Well, it is vaporware. Until it's used by a noticable percentage of hosts, it's irrelevant. I've had spf records on my own domain for some time, but that doesn't mean I believe that there is enough critical mass behind the idea to actually make it useful. I'm not yet pushing for spf records at my day job, for example, because there's not yet a benefit which would justify the effort on that scale. Why is it not vapourware? Because prepackaged kits exist to trivially add support to -=all=- of common MTAs: Postfix, Exim, sendmail, qmail, Courier-MTA, and MS-Exchange Server. That doesn't matter, unless a large enough fraction of people at both ends of smtp conversations actually use the stuff. An implementation that is not deployed is no more useful than a standard which isn't implemented. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
snip from='Michael Stone' date='2004-06-04 18:25:47 -0400' That doesn't matter, unless a large enough fraction of people at both ends of smtp conversations actually use the stuff. An implementation that is not deployed is no more useful than a standard which isn't implemented. /snip Fair enough, but it's up to people like us to push it, surely? J. -- +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ www:http://www.azazel.net/ public key: http://www.azazel.net/home/az-gpg.txt geek code: http://www.azazel.net/home/geekcode.txt +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate. Well, fisrt of all, I accept mail for outgoing relay only from verified sources, this includes SMTP AUTH or based on ip address. This is of course not 100% secure. And second, you should try to not generate bounces. This includes spam rejects, unknown mailboxes and virus alerts. All those must be rejcted on the smtp level. This is all one can do in his own local responsibility. For backup MX or centralized mail gateways it is therefore a matter of good service to do all those rejections at the smtp level, which might involve replicated addressbooks or even pipelining. A lot of organisations forget to include their backup mx into their mail concept and are the main reaons for bounce-floods caused by malware or faked-sender spam. (of course with open relays it does not help if you do not bounce, but those are note the biggest source of spam). Direct delivery from dialups or open proxies are much more common, at least for the large mail providers. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: Why is SPF important? Because it eliminates joe-jobs. That is, it allows mail admins to absolutely validate the envelope return path -- significant because spammers have recently gotten around to forging sender envelope information, allowing forged mail that appears to be credibly from your domain or mine, etc. -- and as such began defeating even quite good security regimes. Solutions like yahoos DomainKeys header signature is much better suited for that, I think. http://antispam.yahoo.com/domainkeys Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): Well, it is vaporware. Until it's used by a noticable percentage of hosts, it's irrelevant. (1) Where I come from, the term vapourware means software touted far in advance of its availability. As noted, such is most emphatically not the case, here. However, moving on: (2) A relevant index for usefulness wouldn't be the percentage of _hosts_, but rather the percentage of _mail_ for which it's useful. This distinction is important: The utility of SPF lies in its ability to eliminate joe-jobbing, providing a means to validate MXes -- and, as I'm reasonably sure you'll have observed, forged mail's envelopes strongly tend to forge the domains of major (very large) mail-handling sites. Those sites happen to have been among the earliest adopters of SPF RRs in their DNS, largely because they are particularly motivated to protect their trademarks and their names. So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. And that's a whole lot of spam, right there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 11:38:02PM +0100, Azazel wrote: Fair enough, but it's up to people like us to push it, surely? There's a line between advocacy and zealotry. At this point I'm not convinced that it's worth the effort. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 03:47:55PM -0700, Rick Moen wrote: The utility of SPF lies in its ability to eliminate joe-jobbing, providing a means to validate MXes -- and, as I'm reasonably sure you'll have observed, forged mail's envelopes strongly tend to forge the domains of major (very large) mail-handling sites. Those sites happen to have been among the earliest adopters of SPF RRs in their DNS, largely because they are particularly motivated to protect their trademarks and their names. yeah, aol's pleased as punch about it. they also don't have much interest in customers sending email with @aol from off their own system unless they use an obnoxious webmail client. same goes for hotmail. anyone with users who isn't aol and whose users don't particularly want a webmail client needs to give things more thought. So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): yeah, aol's pleased as punch about it. they also don't have much interest in customers sending email with @aol from off their own system unless they use an obnoxious webmail client. same goes for hotmail. anyone with users who isn't aol and whose users don't particularly want a webmail client needs to give things more thought. Not that I'm objecting, but I can't help noticing that you're ignoring the point I just made, and changing the subject. Well, I guess the spammers will have to use different addresses. That shouldn't take long. That's where reputations schemes (RHSBLs, greylisting, etc.) come in. See: Throwaway Domains on http://spf.pobox.com/objections.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): There's a line between advocacy and zealotry. Still stuck in name-calling mode? Pity. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. Are there any remaining MUAs that can't support SASL? Can't think of any, offhand, but perhaps there are some. In any event, nobody says you as an MTA admin ought to /dev/null mail whose sending MX cannot be verified. Your local policy might be to merely subject those to more-careful checks, for example. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
snip from='Michael Stone' date='2004-06-04 18:49:05 -0400' On Fri, Jun 04, 2004 at 11:38:02PM +0100, Azazel wrote: Fair enough, but it's up to people like us to push it, surely? There's a line between advocacy and zealotry. At this point I'm not convinced that it's worth the effort. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. /snip Oh, you're right. I have SPF records for my domains, but I haven't enabled it on my MTA, 'cause I'm not sure whether it's worth it yet. I do feel a degree of guilt about that though: SPF does have vulnerabili- ties, but it's as good a solution as I've come across, and, if I just trust to my Bayesian filter to keep my inbox clean, I'm not really helping. I was reading pobox.com's faq the other day, and the impression that I got was that somebody somewhere is going to have to make an effort at some point. That point, however, is likely to turn out to be something we can identify with hindsight and explain with statistics. J. -- +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ www:http://www.azazel.net/ public key: http://www.azazel.net/home/az-gpg.txt geek code: http://www.azazel.net/home/geekcode.txt +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 04:00:32PM -0700, Rick Moen wrote: Not that I'm objecting, but I can't help noticing that you're ignoring the point I just made, and changing the subject. No, I'm not. I'm pointing out that the world is more complicated than you seem to think. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 04:09:32PM -0700, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): There's a line between advocacy and zealotry. Still stuck in name-calling mode? Pity. What name calling? There's a difference. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. Are there any remaining MUAs that can't support SASL? Can't think of any, offhand, but perhaps there are some. You're assuming unrestricted outbound connections. Might even be true in your environment. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328 Not applicable. That requires not only a change on the part of the organization implementing SPF, but also a change at any location where a user wants to send mail. I know, I know, the zealous answer would be that everyone should just implement everything right now--but some of us live in the real world. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Sat, Jun 05, 2004 at 12:23:14AM +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate. Well, fisrt of all, I accept mail for outgoing relay only from verified sources, this includes SMTP AUTH or based on ip address. This is of course not 100% secure. And second, you should try to not generate bounces. This includes spam rejects, unknown mailboxes and virus alerts. All those must be rejcted on the smtp level. This is all one can do in his own local responsibility. For backup MX or centralized mail gateways it is therefore a matter of good service to do all those rejections at the smtp level, which might involve replicated addressbooks or even pipelining. A lot of organisations forget to include their backup mx into their mail concept and are the main reaons for bounce-floods caused by malware or faked-sender spam. (of course with open relays it does not help if you do not bounce, but those are note the biggest source of spam). Direct delivery from dialups or open proxies are much more common, at least for the large mail providers. None of this (and the rest of the thread too, not picking on anyone in particulary) has much to do with Debian-security. Pehaps there is a more general place this thread can be taken. pgpOcbYht1Sk4.pgp Description: PGP signature
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): What name calling? There's a difference. snort Cute. Ah, well. You're assuming unrestricted outbound connections. Might even be true in your environment. It's true that there will be interim problems with corporate firewalls (etc.) closing off outbound access to 587/tcp (but allowing access to 25/tcp). Should diminish over time. I suppose that's why alternatives like POP-before-SMTP persist. [SRS references:] Not applicable. That requires not only a change on the part of the organization implementing SPF, but also a change at any location where a user wants to send mail. Not really, only relays. On relay sites, implementation requires installing /usr/bin/srs (the Perl Mail::SRS module) or equivalent, then using it as a wrapper for .forward and /etc/alias entries. Over the longer term, it may end up being supported inline in MTAs. Ditto for SPF itself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): No, I'm not. You _weren't_ ignoring the point I just made and changing the subject? Then, some villain apparently snuck into your MTA and substituted different text that did, for the original message you tried to send. You should sue! ;- I'm pointing out that the world is more complicated than you seem to think. You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 05:26:07PM -0700, Rick Moen wrote: You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. You're talking about SPF. That's a concept, not an implementation. Effective use of SPF requires widespread adoption. Until/unless widespread adoption happens the promises of SPF are vaporware. Pointing to a bunch of implementations of SPF doesn't speak to whether it's been widely adopted. There have been many failed implementations of many forgotten concepts over the years and only time will tell whether SPF extensions to various MTA's will fall into that category. I think this thread's been beaten to death; have fun with your evangelizing, hopefully on a more applicable forum. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Bernd Eckenfels ([EMAIL PROTECTED]): If you relay mail from your customers, you have to deliver them their bounces if they spam. Well, that's the trick, isn't it? If they're sending spam (either deliberately or -- much more likely of late -- because customer hosts have been zombified by malware), then the sender addresses and (of late) the envelope return path will almost certainly be forged. It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate.
Re: Unusual spam recently - hummm - postprocess
Quoting Phillip Hofmeister ([EMAIL PROTECTED]): While I am sure finding out whose is bigger is exciting to you. I feel comfortable in speaking for the rest of the list when I say this thread has become WAY OT. I'm surprised that an allegation that SPF -- highly relevant to SMTP security -- is vapourware, not to mention refutations of that assertion, are off-topic. Nonetheless, I apologise for reacting with irritation to Michael's claim to that effect: It's just that I expected better from a Security Team member. Much better. Why is SPF important? Because it eliminates joe-jobs. That is, it allows mail admins to absolutely validate the envelope return path -- significant because spammers have recently gotten around to forging sender envelope information, allowing forged mail that appears to be credibly from your domain or mine, etc. -- and as such began defeating even quite good security regimes. Why is it not vapourware? Because prepackaged kits exist to trivially add support to -=all=- of common MTAs: Postfix, Exim, sendmail, qmail, Courier-MTA, and MS-Exchange Server. I posted the link twice earlier in the conversation, well before Michael dismissed it as vapourware. Here it is again: http://spf.pobox.com/downloads.html If using Exim4 on Debian, the required daemon (perl module Mail::SPF::Query) is available as Debian package libmail-spf-query-perl . The Exim4 ACL that invokes it can be found on the above-cited page, and a SysVInit script can be pulled down from http://www.jcdigita.com/eximconfig/ . If all that's vapourware, then it's amazing how much functional and well-debugged vapourware can be located in three minutes of googling.
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 11:50:09AM -0700, Rick Moen wrote: I'm surprised that an allegation that SPF -- highly relevant to SMTP security -- is vapourware, not to mention refutations of that assertion, are off-topic. Nonetheless, I apologise for reacting with irritation to Michael's claim to that effect: It's just that I expected better from a Security Team member. Much better. Well, it is vaporware. Until it's used by a noticable percentage of hosts, it's irrelevant. I've had spf records on my own domain for some time, but that doesn't mean I believe that there is enough critical mass behind the idea to actually make it useful. I'm not yet pushing for spf records at my day job, for example, because there's not yet a benefit which would justify the effort on that scale. Why is it not vapourware? Because prepackaged kits exist to trivially add support to -=all=- of common MTAs: Postfix, Exim, sendmail, qmail, Courier-MTA, and MS-Exchange Server. That doesn't matter, unless a large enough fraction of people at both ends of smtp conversations actually use the stuff. An implementation that is not deployed is no more useful than a standard which isn't implemented. Mike Stone
Re: Unusual spam recently - hummm - postprocess
snip from='Michael Stone' date='2004-06-04 18:25:47 -0400' That doesn't matter, unless a large enough fraction of people at both ends of smtp conversations actually use the stuff. An implementation that is not deployed is no more useful than a standard which isn't implemented. /snip Fair enough, but it's up to people like us to push it, surely? J. -- +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ www:http://www.azazel.net/ public key: http://www.azazel.net/home/az-gpg.txt geek code: http://www.azazel.net/home/geekcode.txt +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate. Well, fisrt of all, I accept mail for outgoing relay only from verified sources, this includes SMTP AUTH or based on ip address. This is of course not 100% secure. And second, you should try to not generate bounces. This includes spam rejects, unknown mailboxes and virus alerts. All those must be rejcted on the smtp level. This is all one can do in his own local responsibility. For backup MX or centralized mail gateways it is therefore a matter of good service to do all those rejections at the smtp level, which might involve replicated addressbooks or even pipelining. A lot of organisations forget to include their backup mx into their mail concept and are the main reaons for bounce-floods caused by malware or faked-sender spam. (of course with open relays it does not help if you do not bounce, but those are note the biggest source of spam). Direct delivery from dialups or open proxies are much more common, at least for the large mail providers. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: Why is SPF important? Because it eliminates joe-jobs. That is, it allows mail admins to absolutely validate the envelope return path -- significant because spammers have recently gotten around to forging sender envelope information, allowing forged mail that appears to be credibly from your domain or mine, etc. -- and as such began defeating even quite good security regimes. Solutions like yahoos DomainKeys header signature is much better suited for that, I think. http://antispam.yahoo.com/domainkeys Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): Well, it is vaporware. Until it's used by a noticable percentage of hosts, it's irrelevant. (1) Where I come from, the term vapourware means software touted far in advance of its availability. As noted, such is most emphatically not the case, here. However, moving on: (2) A relevant index for usefulness wouldn't be the percentage of _hosts_, but rather the percentage of _mail_ for which it's useful. This distinction is important: The utility of SPF lies in its ability to eliminate joe-jobbing, providing a means to validate MXes -- and, as I'm reasonably sure you'll have observed, forged mail's envelopes strongly tend to forge the domains of major (very large) mail-handling sites. Those sites happen to have been among the earliest adopters of SPF RRs in their DNS, largely because they are particularly motivated to protect their trademarks and their names. So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. And that's a whole lot of spam, right there.
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 11:38:02PM +0100, Azazel wrote: Fair enough, but it's up to people like us to push it, surely? There's a line between advocacy and zealotry. At this point I'm not convinced that it's worth the effort. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. Mike Stone
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 03:47:55PM -0700, Rick Moen wrote: The utility of SPF lies in its ability to eliminate joe-jobbing, providing a means to validate MXes -- and, as I'm reasonably sure you'll have observed, forged mail's envelopes strongly tend to forge the domains of major (very large) mail-handling sites. Those sites happen to have been among the earliest adopters of SPF RRs in their DNS, largely because they are particularly motivated to protect their trademarks and their names. yeah, aol's pleased as punch about it. they also don't have much interest in customers sending email with @aol from off their own system unless they use an obnoxious webmail client. same goes for hotmail. anyone with users who isn't aol and whose users don't particularly want a webmail client needs to give things more thought. So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Mike Stone
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): yeah, aol's pleased as punch about it. they also don't have much interest in customers sending email with @aol from off their own system unless they use an obnoxious webmail client. same goes for hotmail. anyone with users who isn't aol and whose users don't particularly want a webmail client needs to give things more thought. Not that I'm objecting, but I can't help noticing that you're ignoring the point I just made, and changing the subject. Well, I guess the spammers will have to use different addresses. That shouldn't take long. That's where reputations schemes (RHSBLs, greylisting, etc.) come in. See: Throwaway Domains on http://spf.pobox.com/objections.html
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): There's a line between advocacy and zealotry. Still stuck in name-calling mode? Pity. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. Are there any remaining MUAs that can't support SASL? Can't think of any, offhand, but perhaps there are some. In any event, nobody says you as an MTA admin ought to /dev/null mail whose sending MX cannot be verified. Your local policy might be to merely subject those to more-careful checks, for example. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328
Re: Unusual spam recently - hummm - postprocess
snip from='Michael Stone' date='2004-06-04 18:49:05 -0400' On Fri, Jun 04, 2004 at 11:38:02PM +0100, Azazel wrote: Fair enough, but it's up to people like us to push it, surely? There's a line between advocacy and zealotry. At this point I'm not convinced that it's worth the effort. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. /snip Oh, you're right. I have SPF records for my domains, but I haven't enabled it on my MTA, 'cause I'm not sure whether it's worth it yet. I do feel a degree of guilt about that though: SPF does have vulnerabili- ties, but it's as good a solution as I've come across, and, if I just trust to my Bayesian filter to keep my inbox clean, I'm not really helping. I was reading pobox.com's faq the other day, and the impression that I got was that somebody somewhere is going to have to make an effort at some point. That point, however, is likely to turn out to be something we can identify with hindsight and explain with statistics. J. -- +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ www:http://www.azazel.net/ public key: http://www.azazel.net/home/az-gpg.txt geek code: http://www.azazel.net/home/geekcode.txt +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 04:00:32PM -0700, Rick Moen wrote: Not that I'm objecting, but I can't help noticing that you're ignoring the point I just made, and changing the subject. No, I'm not. I'm pointing out that the world is more complicated than you seem to think. Mike Stone
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 04:09:32PM -0700, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): There's a line between advocacy and zealotry. Still stuck in name-calling mode? Pity. What name calling? There's a difference. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. Are there any remaining MUAs that can't support SASL? Can't think of any, offhand, but perhaps there are some. You're assuming unrestricted outbound connections. Might even be true in your environment. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328 Not applicable. That requires not only a change on the part of the organization implementing SPF, but also a change at any location where a user wants to send mail. I know, I know, the zealous answer would be that everyone should just implement everything right now--but some of us live in the real world. Mike Stone
Re: Unusual spam recently - hummm - postprocess
On Sat, Jun 05, 2004 at 12:23:14AM +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate. Well, fisrt of all, I accept mail for outgoing relay only from verified sources, this includes SMTP AUTH or based on ip address. This is of course not 100% secure. And second, you should try to not generate bounces. This includes spam rejects, unknown mailboxes and virus alerts. All those must be rejcted on the smtp level. This is all one can do in his own local responsibility. For backup MX or centralized mail gateways it is therefore a matter of good service to do all those rejections at the smtp level, which might involve replicated addressbooks or even pipelining. A lot of organisations forget to include their backup mx into their mail concept and are the main reaons for bounce-floods caused by malware or faked-sender spam. (of course with open relays it does not help if you do not bounce, but those are note the biggest source of spam). Direct delivery from dialups or open proxies are much more common, at least for the large mail providers. None of this (and the rest of the thread too, not picking on anyone in particulary) has much to do with Debian-security. Pehaps there is a more general place this thread can be taken. pgpXDZTqUymGy.pgp Description: PGP signature
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): What name calling? There's a difference. snort Cute. Ah, well. You're assuming unrestricted outbound connections. Might even be true in your environment. It's true that there will be interim problems with corporate firewalls (etc.) closing off outbound access to 587/tcp (but allowing access to 25/tcp). Should diminish over time. I suppose that's why alternatives like POP-before-SMTP persist. [SRS references:] Not applicable. That requires not only a change on the part of the organization implementing SPF, but also a change at any location where a user wants to send mail. Not really, only relays. On relay sites, implementation requires installing /usr/bin/srs (the Perl Mail::SRS module) or equivalent, then using it as a wrapper for .forward and /etc/alias entries. Over the longer term, it may end up being supported inline in MTAs. Ditto for SPF itself.
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): No, I'm not. You _weren't_ ignoring the point I just made and changing the subject? Then, some villain apparently snuck into your MTA and substituted different text that did, for the original message you tried to send. You should sue! ;- I'm pointing out that the world is more complicated than you seem to think. You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK.
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 05:26:07PM -0700, Rick Moen wrote: You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. You're talking about SPF. That's a concept, not an implementation. Effective use of SPF requires widespread adoption. Until/unless widespread adoption happens the promises of SPF are vaporware. Pointing to a bunch of implementations of SPF doesn't speak to whether it's been widely adopted. There have been many failed implementations of many forgotten concepts over the years and only time will tell whether SPF extensions to various MTA's will fall into that category. I think this thread's been beaten to death; have fun with your evangelizing, hopefully on a more applicable forum. Mike Stone
Re: Unusual spam recently - hummm
hiya david On Thu, 3 Jun 2004, David Stanaway wrote: X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from host-69-145-228-124.client.bresnan.net (unknown [69.145.228.124]) by david.dialmex.net (Postfix) with SMTP id CF733146132E for [EMAIL PROTECTED]; Thu, 3 Jun 2004 09:31:35 -0500 (CDT) X-Message-Info: 8+ggs369/bIdvoHulUPnaKEY41Q[1 Message-Id: [EMAIL PROTECTED] Date: Thu, 3 Jun 2004 09:31:35 -0500 (CDT) From: [EMAIL PROTECTED] To: undisclosed-recipients:; why is your spam filter allowing 3 basic spam signs thru ?? - email to undisclosed-recipients should be bounced - email from non-existent hosts should be bounced host-69-145-228-124.client.bresnan.net - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Incoming from Alvin Oga: On Thu, 3 Jun 2004, David Stanaway wrote: X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from host-69-145-228-124.client.bresnan.net (unknown [69.145.228.124]) by david.dialmex.net (Postfix) with SMTP id CF733146132E for [EMAIL PROTECTED]; Thu, 3 Jun 2004 09:31:35 -0500 (CDT) X-Message-Info: 8+ggs369/bIdvoHulUPnaKEY41Q[1 Message-Id: [EMAIL PROTECTED] Date: Thu, 3 Jun 2004 09:31:35 -0500 (CDT) From: [EMAIL PROTECTED] To: undisclosed-recipients:; why is your spam filter allowing 3 basic spam signs thru ?? - email to undisclosed-recipients should be bounced - email from non-existent hosts should be bounced host-69-145-228-124.client.bresnan.net - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net Assuming my incoming mail is POPped off my ISP's mailhost and my outgoing mail goes to my ISP's mailhost, how do I implement this? If I can't, what does my ISP have to do to implement this? Is it feasible for busy sites to implement this or is this going to cost them too much, in comparison to simply accepting it and dropping it? In other words, what's my ISP's busy admin likely to say when I suggest this? That's at least one good reason why this crap gets through. I'd love to implement this, or have my ISP implement this, but I doubt it's going to happen soon. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
On Thu, 03 Jun 2004 at 12:57:46PM -0400, Alvin Oga wrote: - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net This is a bad suggestion. My ISP requires us (by blocking port 25 outbound) to use their SMTP server. Therefore I cannot connect to the normal SMTP Server for the zionlth.org domain. Implementing your suggestion wide spread would cause my emails (and all emails from people in my situation) to be rejected just because their ISP has their head on backwards and thinks blocking port 25 outbound will reduce spam abuse. -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Incoming from Alvin Oga: On Thu, 3 Jun 2004, s. keeling wrote: why is your spam filter allowing 3 basic spam signs thru ?? - email to undisclosed-recipients should be bounced - email from non-existent hosts should be bounced host-69-145-228-124.client.bresnan.net - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net If I can't, what does my ISP have to do to implement this? ISP will probably NOT provide spam filtering, becuase of legal issues My ISP does provide spam filtering; spamassassin marks crap on the mailhost and procmail moves it to my spamfile. I can review it there via webmail and blow it away without downloading it. However, I _would_ like to STOP it from being delivered at all, as defined by simple rules like those above. As far as I can tell, this must be done in the SMTP negotiation phase. What's it going to cost my ISP to implement this? Is it feasible for an ISP to implement this? -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Quoting s. keeling ([EMAIL PROTECTED]): However, I _would_ like to STOP it from being delivered at all, as defined by simple rules like those above. As far as I can tell, this must be done in the SMTP negotiation phase. Mostly. What's it going to cost my ISP to implement this? Is it feasible for an ISP to implement this? Is it feasible for them _not_ to? ;- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Quoting Phillip Hofmeister ([EMAIL PROTECTED]): On Thu, 03 Jun 2004 at 12:57:46PM -0400, Alvin Oga wrote: - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net This is a bad suggestion. My ISP requires us (by blocking port 25 outbound) to use their SMTP server. Therefore I cannot connect to the normal SMTP Server for the zionlth.org domain. Implementing your suggestion wide spread would cause my emails (and all emails from people in my situation) to be rejected just because their ISP has their head on backwards and thinks blocking port 25 outbound will reduce spam abuse. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328 (Tell your ISP: Adapt or die. ;- ) -- Cheers, find / -user your -name base -print | xargs chown us:us Rick Moen [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Incoming from Phillip Hofmeister: On Thu, 03 Jun 2004 at 12:57:46PM -0400, Alvin Oga wrote: - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net This is a bad suggestion. My ISP requires us (by blocking port 25 outbound) to use their SMTP server. Therefore I cannot connect to the Considering 60% - 80% of the traffic these days is crap, this is beginning to look like a fairly reasonable restriction. If you can figure out how to have SMTP negotiate that your ISP legitimately handles mail for your domain, that's the only way around it I can see. There are a lot of spam friendlies out there for whom no amount of reporting spam will have any effect on their actions. Refusing forgeries is the only solution for those. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
On Thu, 3 Jun 2004, s. keeling wrote: why is your spam filter allowing 3 basic spam signs thru ?? - email to undisclosed-recipients should be bounced - email from non-existent hosts should be bounced host-69-145-228-124.client.bresnan.net - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net Assuming my incoming mail is POPped off my ISP's mailhost and my outgoing mail goes to my ISP's mailhost, how do I implement this? if you do NOT have control of your own MTA for your domain, than you're on your own and yes .. everybody has different anti-spam rules one implements depending on your tolerance level, or network configs If I can't, what does my ISP have to do to implement this? ISP will probably NOT provide spam filtering, becuase of legal issues that they can easily be in deep kaa-kaa if they start editing what users can send/receive ( long running legal issues vs just letting thing flow un-touched c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
On torsdag 3. juni 2004, 20:24, s. keeling wrote: This is a bad suggestion. My ISP requires us (by blocking port 25 outbound) to use their SMTP server. Therefore I cannot connect to the Considering 60% - 80% of the traffic these days is crap, this is beginning to look like a fairly reasonable restriction. If you can figure out how to have SMTP negotiate that your ISP legitimately handles mail for your domain, that's the only way around it I can see. There are a lot of spam friendlies out there for whom no amount of reporting spam will have any effect on their actions. Refusing forgeries is the only solution for those. Then I think it is much more reasonable to let SpamAssassin or some other good spam scanner have a look at it, then reject in the SMTP dialogue based on not only a single characteristic. SA will also give hammy scores, so even if there is one spammy thing about the message, a few hammy things can let it pass through nevertheless. It is straightforward to set this up using the Exim4 backports and SA. Vennlig Tiddeli-bom, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Re: Unusual spam recently - hummm
hi ya s. On Thu, 3 Jun 2004, s. keeling wrote: If I can't, what does my ISP have to do to implement this? ISP will probably NOT provide spam filtering, becuase of legal issues My ISP does provide spam filtering; spamassassin marks crap on the mailhost and procmail moves it to my spamfile. I can review it there via webmail and blow it away without downloading it. However, I _would_ like to STOP it from being delivered at all, run your own mta .. as defined by simple rules like those above. As far as I can tell, this must be done in the SMTP negotiation phase. yup What's it going to cost my ISP to implement this? Is it feasible for an ISP to implement this? about 5 minutes of time to configure sendmail/exim/postfix etc - and worry about censoring issues from the legal side of the world when the lawayers for the spammers comes knocking implementing antispam rules would depend on the rules you want to use to call it spam before you even see it my antispam rules http://www.linux-sec.net/Mail/AntiSpam/ i call it 5 minute antispam rules, to implement my list of about dozen antispam rules ... ( and i use sendmail :-) - no incoming html is one of my rules :-) ( but, its obviously not for work related mta servers ) if you do not have control of the mta .. you're costs is lot more ( 100x - 1000x ) since you have to post process your emails after you already received it. further, each user has to also implement those same antispam rules in their mua if the mta is just for you and your policies, antispam costs is trivial if the mta is like mta.hotmail.com, or your corp server, would become in a non-trivial anti-spam set of rules .. because what is considered by spam to one user is i want that same identical email by another user - catalogs and price lists is a common issue - some things are still spam, even for 10 or 1000 users - if one uses someone elses MTA and pop from it, i suppose one has to be willing to find a harder solution to not get the spam ( harder solution - more than 5 or 10 minutes to implement ) c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
On torsdag 3. juni 2004, 20:53, Alvin Oga wrote: you have to post process your emails after you already received it. ...and then it is a bit late to bounce, isn't it...? Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Re: Unusual spam recently - hummm
Incoming from Phillip Hofmeister: On Thu, 03 Jun 2004 at 01:32:55PM -0400, s. keeling wrote: Assuming my incoming mail is POPped off my ISP's mailhost and my outgoing mail goes to my ISP's mailhost, how do I implement this? If I can't, what does my ISP have to do to implement this? User-Agent: Mutt/1.3.28i You use Mutt, a wonderful MUA if I must say so myself... I agree. It's only failing that I can see is it encourages insufferable smugness on the part of its users (Nyaa, nyaa. My mailer is marter, more conformant, faster, more configurable, and better documented and supported than your mailer! Nyaa, nyaa! Pthbthbthbthb! :-) I don't know how you currently handle your email. Whether you use IMAP My ISP has SA installed and running globally. I have a procmail recipe in my shell account on the ISP pluck out the crap and segregate it in a spamfile on my ISP. I can view it with webmail and blow it all away without DLing it. I have procmail here on my own machine splitting mail into folders locally and some more spam matching recipes to handle whatever manages to make it past SA. It has been slowly building up to the point that this system is verging on the unmanageable. So much crap (unsubscribes, viruses, worms, ...) are coming in from mailing lists, I now have two passes filtering out crap, before and after mailing list processing. Add to that false positives, whitelisting known senders, ... and it's becoming annoying. Most people would be very happy with the result but I've come to the conclusion it's no longer good enough for me. So, time for a re-org. I don't use spamassisin, just bogofilter. Here is my relevant procmailrc snippet... Downloading it now, thanks. Hopefully this gets me back to a maintainable system without all the exception handling, whitelisting, false positives etc. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Incoming from Rick Moen: Quoting s. keeling ([EMAIL PROTECTED]): However, I _would_ like to STOP it from being delivered at all, as [snip] What's it going to cost my ISP to implement this? Is it feasible for an ISP to implement this? Is it feasible for them _not_ to? ;- Yes. The problem with Alvin's solution is it only looks at the crap that spammers send. A lot of legitimate mail does all the silly things that spammers do, and users do want to receive that mail. Add to that all the broken-ness of many mail systems and you're left with little to count on. You and I may see no legitimate point to html mail, but ordinary users do. I ordinarily couldn't care less about html mail, but if it contains a job offer you bet I want to see it. The same is true for undisclosed-recipients: and From 's that don't match mailhosts. For a big organization with thousands of users, what's Spam is not really all that easy to quantify. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
On Thu, 03 Jun 2004 at 04:10:30PM -0400, s. keeling wrote: I don't use spamassisin, just bogofilter. Here is my relevant procmailrc snippet... Downloading it now, thanks. Hopefully this gets me back to a maintainable system without all the exception handling, whitelisting, false positives etc. Let me warn you. Bogofilter requires training a database. You may not get accurate results for the first few weeks or a month+ (depending on your spam volume and your ham volume). It would be great if you have a handful of a few hundred spam messages and a few hundred ham messages to shoot at it right away. use cat to pipe the messages/MBOX files through bogofilter -n and bogofilter -s. I would adjust the ~/.bogofilter.cf defaults as well. Here is mine: robx= 0.415000 robs= 0.01 min_dev = 0.10 ham_cutoff = 0.50 spam_cutoff = 0.70 block_on_subnets = yes replace_nonascii_characters = no timestamp=Y spam_header_name = X-Bogosity header_format = %h: %c, tests=bogofilter, spamicity=%p, version=%v terse_format = %1.1c %f log_header_format = %h: %c, spamicity=%p, version=%v log_update_format = register-%r, %w words, %m messages spamicity_tags= Yes, No, Unsure spamicity_formats = %0.6f, %0.6f If you are interested I can try bzip2ing my wordlist.db and sending it to you via http. Email me off-list if you would like this. This database is of coursed tuned to MY spam preferences. I have found it very reliable (for me). -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Quoting s. keeling ([EMAIL PROTECTED]): Yes. The problem with Alvin's solution is it only looks at the crap that spammers send. A lot of legitimate mail does all the silly things that spammers do, and users do want to receive that mail. 1. Content-based filtering doesn't work very well (if that's what you mean, which you probably don't). 2. Most silly things legitimate mail does can be accomodated by an efficient antispam regime; a few cannot. Remember the screams of outrage when people started being told You shouldn't run open relays any more? We're entering another round of that. Some of the you-can't-do-that-any-more items will be RFC violations (lack of postmaster@ and abuse@ addresses, failure to accept DSN mail, lack of deliverability to the alleged sender), others are not (lack of DNS RRs sufficient to serve as SPF data, support for revised forwarding standards such as SRS). Exactly as with open relays, the Net will be full of admins saying I don't have to do that; screw you. Increasingly, they'll find their mail refused at SMTP time, or stuffed into spamboxes and neglected. Some admins learn only when struck forcefully by Papa Darwin. So, that's how reality works. Deal, or be dealt. Add to that all the broken-ness of many mail systems and you're left with little to count on. I have no problem with my MTA issuing 55x Reject to broken systems. If you feel otherwise, cool. Go for it. You and I may see no legitimate point to html mail, but ordinary users do. Delightful red colour on that herring of yours. (If you think this discussion concerns HTML mail, you have badly misunderstood. See also point #1, supra.) The same is true for undisclosed-recipients: and From 's that don't match mailhosts. Whoever said block mail for undisclosed-recipients has rocks in his head and needs to reconsider. (I have no time to debate with such people.) And, hey, de-facto standards for forwarded mail handling (and thus envelope sender headers) have recently changed. Adapt or die. Die in this case means expect to see your mail rejected at an accelerating rate. Nobody's going to insist that you not die. If death becomes you, enjoy! For a big organization with thousands of users, what's Spam is not really all that easy to quantify. And another fine, ruddy herring! Delicious, thanks. -- Cheers, Rick Moen Age, baro, fac ut gaudeam. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, 3 Jun 2004, Kjetil Kjernsmo wrote: On torsdag 3. juni 2004, 20:53, Alvin Oga wrote: you have to post process your emails after you already received it. ...and then it is a bit late to bounce, isn't it...? i typically dont need to post process... i never got the spam post processing is for the birds in my limited world of 10,000+ mails per day ... most of which are spam - the original posts spam assassin didnt reject the incoming spam to undisclosed recepient - once they validate the email addy is good, you're promptly added to a new more expensive spam list - receiving spam is a bad thing c ya alvin
Re: Unusual spam recently - hummm - postprocess
On Jun 3, 2004, at 3:07 PM, Alvin Oga wrote: post processing is for the birds in my limited world of 10,000+ mails per day ... most of which are spam - the original posts spam assassin didnt reject the incoming spam to undisclosed recepient - once they validate the email addy is good, you're promptly added to a new more expensive spam list - receiving spam is a bad thing My mail system has a number of users, and I prefer to let the recipient decide what is spam. The question was really about the empty spams that are showing up in the last month or so, and what they are intended for. Weather it was a prelude to an MTA exploiting worm strike, or just spammers assessing the value of their spam lists before using them to deliver their spamloads. My content filtering mostly works. It catches over 99% of spam and I have only had 1 false positive, and I think I will stick with it. Some list servers such as yahoogroups (May it rot in pieces) have the annoying behavior of deactivating your subscription on hard bounces from MTAs so whenever a list I am subscribed to with lax attachment policies gets a worm, and I hard bounce it with mime-header-checks, I get deactivated. So this is just one example of hard bouncing spam not being a great system wide policy right now (Unless you don't like your users :P). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting David Stanaway ([EMAIL PROTECTED]): My mail system has a number of users, and I prefer to let the recipient decide what is spam. There's a minor problem with this, about which more below. Some list servers such as yahoogroups (May it rot in pieces) have the annoying behavior of deactivating your subscription on hard bounces from MTAs so whenever a list I am subscribed to with lax attachment policies gets a worm, and I hard bounce it with mime-header-checks, I get deactivated. So this is just one example of hard bouncing spam not being a great system wide policy right now (Unless you don't like your users :P). Bouncing spam at all, in any way, is irresponsible admin behaviour. Consider: Essentially all spam forges as much header information as possible, and the newer generation even forges the envelope return-path data. Therefore, if you bounce spam, it is almost 100% guaranteed to be sent out to a forged address -- a party (extant or not) that did not send the original spam in the first place. In effect, you are generating _additional_ spam with each and every such bounce. However, if your system is able to determine _during the SMTP session_ that the mail is unwanted (as spam or for some other reason), it can issue a 55X Reject error and refuse delivery, instead of accepting the mail and then having to make the poor choice between /dev/nulling the received mail and issuing an almost certainly inappropriate bounce message. Smarter and better remedies are possible during SMTP time, than they are after delivery. A number of other steps are possible, beyond what I've mentioned. And, of course, by the time your users have a chance to apply their judgement on the matter, the MTA has already accepted the mail and handed it off to an LDA or MDA -- so the opportunity is lost. -- Cheers, Rick MoenBu^so^stopu min per kulero. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Incoming from Rick Moen: Quoting s. keeling ([EMAIL PROTECTED]): Yes. The problem with Alvin's solution is it only looks at the crap that spammers send. A lot of legitimate mail does all the silly things that spammers do, and users do want to receive that mail. 1. Content-based filtering doesn't work very well (if that's what you mean, which you probably don't). I actually meant the typical worst practices for which spammers are so well known. Spammers use these things to avoid detection. Average users do them without even realizing it. For instance, Alvin automatically deep-sixes html mail. Ordinary users don't even know when they're sending html mails. 2. Most silly things legitimate mail does can be accomodated by an efficient antispam regime; a few cannot. Remember the screams of outrage when people started being told You shouldn't run open relays any more? We're entering another round of that. Immaterial, I know, but Last time I looked Gilmore was still fighting that one. :-) You and I may see no legitimate point to html mail, but ordinary users (If you think this discussion concerns HTML mail, you have badly misunderstood. See also point #1, supra.) No, it was just an example since Alvin mentioned it. I don't see much point in html mail but the headhunters who send me job offers appear to like it, so I have to find a way to accept it in an inoffensive (to me) manner. For a big organization with thousands of users, what's Spam is not really all that easy to quantify. And another fine, ruddy herring! Delicious, thanks. Uhh, what? My original starting point in all this was to find out if Alvin's suggestions had merit. Following on that, what would it take to implement them? My favourite admin is loathe to do _anything_ that could cause his users to complain of lost mail. How he cuts out the %60-%80 of crap without causing a riot is all I wanted to know. BTW, regarding 2. above. Remember the days when there was such reticence on the part of Sendmail's maintainers to actually change Sendmail to comply with RFCs? It was pretty well a given then that doing so would turn half the planet dark overnight because so many admins were still running Sendmail versions that had been obsoleted years before. Ah, those were the days. :-P -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Quoting s. keeling ([EMAIL PROTECTED]): I actually meant the typical worst practices for which spammers are so well known. Spammers use these things to avoid detection. Average users do them without even realizing it. Thanks for clarifying. Yes, this is an excellent point: Spammers lean towards the dodgy side of mail standards in order to better avoid being tracked down and for other reasons. Reasserting control of the SMTP stream is going to require enforcing RFC requirements that have traditionally been laxly applied, and also enforcing a couple of other standards that are currently de-facto. This will entail temporary problems for sites and users that have become dependent on badly set up MUAs and MTAs -- in exactly the same way they used to be with open relays. One can pretend that the matter's open for debate, but that would be a waste of time: It's happening. For instance, Alvin automatically deep-sixes html mail. Noted. The practice strikes me as a bit silly. Moreover (if I understand your recounting of that policy), unlike with SMTP-time rejection, the sending MTA receives no indication of refused delivery -- a bad thing. Oh well. Not my problem. 2. Most silly things legitimate mail does can be accomodated by an efficient antispam regime; a few cannot. Remember the screams of outrage when people started being told You shouldn't run open relays any more? We're entering another round of that. Immaterial, I know, but Last time I looked Gilmore was still fighting that one. :-) My point, of course, was to compare that transition with the current one. (And, yeah, sorry, John, but you lose. ;- ) [HTML mail:] No, it was just an example since Alvin mentioned it. I don't see much point in html mail but the headhunters who send me job offers appear to like it, so I have to find a way to accept it in an inoffensive (to me) manner. Using a suitable mailcap does the trick for me. If you're having to do post-MDA filtering based on content (such as discarding HTML mail), that means that your primary mail-handling is failing to do the job, ealrier in the process. People who put significant stock in content-based filtering are pursuing a losing antispam strategy. They'll probably figure that out by themselves, eventually. In either case, not my problem. And another fine, ruddy herring! Delicious, thanks. Uhh, what? My original starting point in all this was to find out if Alvin's suggestions had merit. Oh, sorry: I actually didn't see Alvin's post, having been a bit busy today. Accordingly, I was responding to yours. A What's spam discussion struck me as irrelevant to the point I was discussing with you -- so thank you for explaining where it came from. (You're welcome to have that other conversation with Alvin, of course.) Following on that, what would it take to implement them? My favourite admin is loathe to do _anything_ that could cause his users to complain of lost mail. How he cuts out the %60-%80 of crap without causing a riot is all I wanted to know. A good point. It's unfortunate that so many mail admins, especially corporate ones, are obliged to resort to that sort of doublespeak. Anyhow, although I don't have Alvin's list of suggestions, I do have my own: o Do all possible detection and rejection at SMTP time. o Use MTA ACLs (preferably using Exim 4.x's extremely cool callout interface) to test for RFC-compliance and to check SPF records. o Season with punitive teergrubing, to taste. ;- o Help advance the state of the art by introducing SRS rewriting for any required forwarding, using SMTP AUTH, etc. BTW, regarding 2. above. Remember the days when there was such reticence on the part of Sendmail's maintainers to actually change Sendmail to comply with RFCs? It was pretty well a given then that doing so would turn half the planet dark overnight because so many admins were still running Sendmail versions that had been obsoleted years before. Ah, those were the days. :-P Yes, indeed! http://linuxmafia.com/pub/humour/500-mile-e-mail -- Cheers,Remember: The day after tomorrow is the third day Rick Moen of the rest of your life. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 03:23:51PM -0700, Rick Moen wrote: However, if your system is able to determine _during the SMTP session_ that the mail is unwanted (as spam or for some other reason), it can issue a 55X Reject error and refuse delivery, instead of accepting the mail and then having to make the poor choice between /dev/nulling the received mail and issuing an almost certainly inappropriate bounce message. Yeah, big difference. If the spam is going through a relay, the relay will send the same bounce and the same person will get the bounce message. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Incoming from Phillip Hofmeister: On Thu, 03 Jun 2004 at 04:10:30PM -0400, s. keeling wrote: I don't use spamassisin, just bogofilter. Here is my relevant procmailrc snippet... Downloading it now, thanks. Hopefully this gets me back to a maintainable system without all the exception handling, whitelisting, Let me warn you. Bogofilter requires training a database. You may not Much appreciated. That prompted me to read the man page before I let it bite me. :-) handful of a few hundred spam messages and a few hundred ham messages to shoot at it right away. use cat to pipe the messages/MBOX files through bogofilter -n and bogofilter -s. That would be bogofilter -Mn ~/Mail/spam for mbox style, no? If you are interested I can try bzip2ing my wordlist.db and sending it to you via http. Email me off-list if you would like this. This Again, much appreciated. I'll just start banging my head on it and see what I can come up with. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): Yeah, big difference. If the spam is going through a relay, the relay will send the same bounce and the same person will get the bounce message. Oh, oh! jumps up and down Gee, I guess that relay should have rejected the spam instead of relaying it, right? Then, it wouldn't feel a compulsion to issue a completely inappropriate bounce [sic] message to a forged sender. Do I win a prize, or was that just a qualifying round, and the real questions, that actually require thinking, will come later? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): Yeah, big difference. If the spam is going through a relay, the relay will send the same bounce and the same person will get the bounce message. Oh, oh! jumps up and down Gee, I guess that relay should have rejected the spam instead of relaying it, right? Then, it wouldn't feel a compulsion to issue a completely inappropriate bounce [sic] message to a forged sender. Do I win a prize, or was that just a qualifying round, and the real questions, that actually require thinking, will come later? Are you suggesting then, that we should not relay mail at all?, not even to/from our customers? Blu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: Gee, I guess that relay should have rejected the spam instead of relaying it, right? Then, it wouldn't feel a compulsion to issue a completely inappropriate bounce [sic] message to a forged sender. I'm sure the guy who got joe jobbed is happy that you can point out the source of his misforture. Must be real comforting and all. Do I win a prize, or was that just a qualifying round, and the real questions, that actually require thinking, will come later? I'm not sure you'd qualify for the thinking round. Seems like you're just a big ball of spam hating fury, no? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
On Thu, 3 Jun 2004, s. keeling wrote: I actually meant the typical worst practices for which spammers are so well known. Spammers use these things to avoid detection. Average maybe we should reject misspelled email subject lines :-) users do them without even realizing it. For instance, Alvin automatically deep-sixes html mail. Ordinary users don't even know when they're sending html mails. corp users dont care or need to care where incoming business mails are coming from in whatever format and languages ( and *.tld ) - lot harder to define spam in a corp environment personal email .. you can proably reject alll html emails and whitelist all your friends that are sending html emails No, it was just an example since Alvin mentioned it. because html based email is the devil ... carrying spam and virii :-) and most people dont care that they send text and html emails Uhh, what? My original starting point in all this was to find out if Alvin's suggestions had merit. has merit only if you agree with the strict or dumb antispam rules and conversely, a bad set of rules if one doesnt agree with it Following on that, what would it take to implement them? some of the typical antispam rules are 5 minutes to solve, solved once for everybody ... My favourite admin is loathe to do _anything_ that could cause his users to complain of lost mail. How he cuts out the %60-%80 of crap without causing a riot is all I wanted to know. lost emails is a bad thing ... nobody likes to be told they didnt get their emails BTW, regarding 2. above. Remember the days when there was such reticence on the part of Sendmail's maintainers to actually change Sendmail to comply with RFCs? It was pretty well a given then that doing so would turn half the planet dark overnight because so many admins were still running Sendmail versions that had been obsoleted years before. things should go dark .. so that one understands what a bigger hole we're digging, but its too late now ... c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
On Thu, Jun 03, 2004 at 04:24:35PM -0700, Rick Moen wrote: One can pretend that the matter's open for debate, but that would be a waste of time: It's happening. Sure it is. How do you manage to sleep, fixing all the email systems in the world *and* evangelizing at the same time? Must be tough. People who put significant stock in content-based filtering are pursuing a losing antispam strategy. All antispam strategies are a losing strategy, unless you're a zealot who believes that everyone else in the world (and human nature) will change. Every time you come up with a new fix someone else will come up with a new strategy to avoid it. What's your strategy to cope with perfectly valid smtp messages that just happen to contain spam? They'll probably figure that out by themselves, eventually. In either case, not my problem. Yet you can't seem to stop making it your problem. Curious. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): I'm sure the guy who got joe jobbed is happy that you can point out the source of his misforture. Must be real comforting and all. Was there a particular part of the immediately preceding reference to SPF that you didn't get, or was it the concept as a whole? (Kid, I was in the thick of the eponymous incident on NANAE when Joe Doll got hit. You have nothing to teach me about joe-jobs.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Blu ([EMAIL PROTECTED]): If my relay server (not open, but relay for customers) has no means to verify recipients, what to do when the destination server rejects that mail already accepted by my server?. Bounce. (Implicit assumption that you have no option but to accept forged-sender spam noted without further comment.) Well, you will increasingly find your MTA put on a teergrube this chump list, if it keeps doing that. I'm not telling you what to do; I'm just predicting what's going to happen. In your shoes, out of self-interest, I'd work at making my system behave like that as little as possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 05:32:17PM -0700, Rick Moen wrote: Was there a particular part of the immediately preceding reference to SPF that you didn't get, or was it the concept as a whole? I get the concept of vaporware. Seen a lot of it over the years. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Quoting Michael Stone ([EMAIL PROTECTED]): On Thu, Jun 03, 2004 at 04:24:35PM -0700, Rick Moen wrote: One can pretend that the matter's open for debate, but that would be a waste of time: It's happening. Sure it is. How do you manage to sleep, fixing all the email systems in the world *and* evangelizing at the same time? Must be tough. (Troll duly noted and ignored.) People who put significant stock in content-based filtering are pursuing a losing antispam strategy. All antispam strategies are a losing strategy, unless you're a zealot who believes that everyone else in the world (and human nature) will change. My, you _are_ a veritable fount of non-perspective, aren't you? Some antispam strategies are by relative measures non-starters relative to others. In particular, doing all of your primary processing via content-based filtering, particularly at the MDA/MUA level, has proven over time to be particularly ineffective, and tempts people to do dumb things like /dev/nulling all HTML mail. Every time you come up with a new fix someone else will come up with a new strategy to avoid it. What's your strategy to cope with perfectly valid smtp messages that just happen to contain spam? DNSBLs, collaborative detection, and several measures that include Bayesian recognition during SMTP time as a _secondary_ measure. (Was there a particular part of the word primary that you didn't get, earlier?) Ultimately, it would be good to collectively whitelist IPs that show willingness to be responsible for mail they send, and bandwidth-throttle others. There are proposals being worked on for this. See, for example: http://www.templetons.com/brad/spam/endspam.html They'll probably figure that out by themselves, eventually. In either case, not my problem. Yet you can't seem to stop making it your problem. Curious. What part of my describing strictly local measures, and insisting that other people's misbehaviour is their problem, were you not quite understanding? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): On Thu, Jun 03, 2004 at 05:32:17PM -0700, Rick Moen wrote: Was there a particular part of the immediately preceding reference to SPF that you didn't get, or was it the concept as a whole? I get the concept of vaporware. Seen a lot of it over the years. Sorry to hear about your sysadmin shortage, then. -- Cheers, Rick MoenBu^so^stopu min per kulero. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: Are you suggesting then, that we should not relay mail at all?, not even to/from our customers? If you relay mail from your customers, you have to deliver them their bounces if they spam. If you relay to your customers you better make sure the backup mx is trying to pipeline the mail to the primary and also forward the reject in case of spam or inapropriate destination. But thats quite normal mail setup, nowadays. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess - recipients
hi ya blu On Thu, 3 Jun 2004, Blu wrote: I agree, but it was suggested that any mail server should reject spam at SMTP time, and not bounce it at all. yupp ... best to do at smtp time If my relay server (not open, but relay for customers) has no means to verify recipients, what to do when the destination server rejects that mail already accepted by my server?. make it part of your overall services and policy, that you require a list of authorized users .. if you dont know about [EMAIL PROTECTED] than you will consider it a forged acct - you now have a list of all valid email accounts and any unknown address is rejected/bounced/fried/devnulled ( the users does NOT have to have a shell acct ... ( gazillion ways to do this - you reject unknown users on incoming email addressed to joe - you reject outgoing mail from joe ( ez to do with wireless laptops ) - and if joe is using a borrowed laptop from the spouse or sitting at a different office pc ... humm .. more isssues Bounce. back. c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Incoming from Alvin Oga: On Thu, 3 Jun 2004, s. keeling wrote: personal email .. you can proably reject alll html emails and whitelist all your friends that are sending html emails ... Assuming you can see into the future and can predict where all your future mail will be coming from. That's an impossible assumption. I get personal replies from Usenet, from debian-*, from headhunters, from friends of my friends, from people I've never heard of who landed on my homepage, ... I'm sick of whitelisting. It doesn't work if you care about communicating with people you've never met. Besides, the simple way to deal with html is with mutt and a .mailcap: text/html; /usr/bin/w3m -dump %s; copiousoutput; nametemplate=%s.html -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Incoming from Michael Stone: It's not misbehaving to generate a bounce message. Glad I could clear that up. s/bounce/valid bounce/ You're welcome. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
While I am sure finding out whose is bigger is exciting to you. I feel comfortable in speaking for the rest of the list when I say this thread has become WAY OT. Please mark it as such (in the subject) or take your discussion elsewhere. Thanks On Thu, 03 Jun 2004 at 09:11:57PM -0400, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): On Thu, Jun 03, 2004 at 05:32:17PM -0700, Rick Moen wrote: Was there a particular part of the immediately preceding reference to SPF that you didn't get, or was it the concept as a whole? I get the concept of vaporware. Seen a lot of it over the years. Sorry to hear about your sysadmin shortage, then. -- Cheers, Rick MoenBu^so^stopu min per kulero. [EMAIL PROTECTED] -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Jun 2004 at 07:26:30PM -0400, s. keeling wrote: Let me warn you. Bogofilter requires training a database. You may not Much appreciated. That prompted me to read the man page before I let it bite me. :-) NP. handful of a few hundred spam messages and a few hundred ham messages to shoot at it right away. use cat to pipe the messages/MBOX files through bogofilter -n and bogofilter -s. That would be bogofilter -Mn ~/Mail/spam for mbox style, no? Yes, the -M option would indicate to bogo that this is an MBOX. If you are interested I can try bzip2ing my wordlist.db and sending it to you via http. Email me off-list if you would like this. This Again, much appreciated. I'll just start banging my head on it and see what I can come up with. You can visit http://www.spamarchive.org/ and download other people's spam to train your filters G. Warning: Just throwing a bunch of spam at your filters w/o giving it any ham will likely result in falsely high bogosity scores (false-rejects) since there is no ham tokens to reduce the score. HTH, - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Key available at http://www.zionlth.org/~plhofmei/key.asc iD8DBQFAv+OsS3Jybf3L5MQRAjjpAJ4q5u3JQ10jx8Ey/g2XF8ncTFvU8gCcCQaz 53qpMlf3kiA4Hfgvl8uyRCs= =wJAI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
hiya david On Thu, 3 Jun 2004, David Stanaway wrote: X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from host-69-145-228-124.client.bresnan.net (unknown [69.145.228.124]) by david.dialmex.net (Postfix) with SMTP id CF733146132E for [EMAIL PROTECTED]; Thu, 3 Jun 2004 09:31:35 -0500 (CDT) X-Message-Info: 8+ggs369/bIdvoHulUPnaKEY41Q[1 Message-Id: [EMAIL PROTECTED] Date: Thu, 3 Jun 2004 09:31:35 -0500 (CDT) From: [EMAIL PROTECTED] To: undisclosed-recipients:; why is your spam filter allowing 3 basic spam signs thru ?? - email to undisclosed-recipients should be bounced - email from non-existent hosts should be bounced host-69-145-228-124.client.bresnan.net - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net c ya alvin
Re: Unusual spam recently - hummm
Incoming from Alvin Oga: On Thu, 3 Jun 2004, David Stanaway wrote: X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from host-69-145-228-124.client.bresnan.net (unknown [69.145.228.124]) by david.dialmex.net (Postfix) with SMTP id CF733146132E for [EMAIL PROTECTED]; Thu, 3 Jun 2004 09:31:35 -0500 (CDT) X-Message-Info: 8+ggs369/bIdvoHulUPnaKEY41Q[1 Message-Id: [EMAIL PROTECTED] Date: Thu, 3 Jun 2004 09:31:35 -0500 (CDT) From: [EMAIL PROTECTED] To: undisclosed-recipients:; why is your spam filter allowing 3 basic spam signs thru ?? - email to undisclosed-recipients should be bounced - email from non-existent hosts should be bounced host-69-145-228-124.client.bresnan.net - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net Assuming my incoming mail is POPped off my ISP's mailhost and my outgoing mail goes to my ISP's mailhost, how do I implement this? If I can't, what does my ISP have to do to implement this? Is it feasible for busy sites to implement this or is this going to cost them too much, in comparison to simply accepting it and dropping it? In other words, what's my ISP's busy admin likely to say when I suggest this? That's at least one good reason why this crap gets through. I'd love to implement this, or have my ISP implement this, but I doubt it's going to happen soon. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: Unusual spam recently - hummm
On Thu, 03 Jun 2004 at 12:57:46PM -0400, Alvin Oga wrote: - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net This is a bad suggestion. My ISP requires us (by blocking port 25 outbound) to use their SMTP server. Therefore I cannot connect to the normal SMTP Server for the zionlth.org domain. Implementing your suggestion wide spread would cause my emails (and all emails from people in my situation) to be rejected just because their ISP has their head on backwards and thinks blocking port 25 outbound will reduce spam abuse. -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import
Re: Unusual spam recently - hummm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 03 Jun 2004 at 01:32:55PM -0400, s. keeling wrote: Assuming my incoming mail is POPped off my ISP's mailhost and my outgoing mail goes to my ISP's mailhost, how do I implement this? If I can't, what does my ISP have to do to implement this? Is it feasible for busy sites to implement this or is this going to cost them too much, in comparison to simply accepting it and dropping it? In other words, what's my ISP's busy admin likely to say when I suggest this? That's at least one good reason why this crap gets through. I'd love to implement this, or have my ISP implement this, but I doubt it's going to happen soon. User-Agent: Mutt/1.3.28i You use Mutt, a wonderful MUA if I must say so myself... I don't know how you currently handle your email. Whether you use IMAP folders in Mutt or fetchmail to fetch your mail and store it locally. If you do the later you can easily implement bogofilter and spamassisin on your local machine. I have all my suspect email deposited in ~/Mail/Junk. I don't use spamassisin, just bogofilter. Here is my relevant procmailrc snippet... :0 f | bogofilter -p -u -l :0 c * ^X-Bogosity: Yes Mail/Junk :0: * ^X-Bogosity: Unsure Mail/Unsure Hope this helps! - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Key available at http://www.zionlth.org/~plhofmei/key.asc iD8DBQFAv2X6S3Jybf3L5MQRAhZqAJwPbSpLrGU3pIS4oWFrfXIucfPQMgCfYlK0 ewGnt+M5C8ovvCb/uj1YTP8= =PYjD -END PGP SIGNATURE-
Re: Unusual spam recently - hummm
Incoming from Alvin Oga: On Thu, 3 Jun 2004, s. keeling wrote: why is your spam filter allowing 3 basic spam signs thru ?? - email to undisclosed-recipients should be bounced - email from non-existent hosts should be bounced host-69-145-228-124.client.bresnan.net - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net If I can't, what does my ISP have to do to implement this? ISP will probably NOT provide spam filtering, becuase of legal issues My ISP does provide spam filtering; spamassassin marks crap on the mailhost and procmail moves it to my spamfile. I can review it there via webmail and blow it away without downloading it. However, I _would_ like to STOP it from being delivered at all, as defined by simple rules like those above. As far as I can tell, this must be done in the SMTP negotiation phase. What's it going to cost my ISP to implement this? Is it feasible for an ISP to implement this? -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: Unusual spam recently - hummm
Quoting s. keeling ([EMAIL PROTECTED]): However, I _would_ like to STOP it from being delivered at all, as defined by simple rules like those above. As far as I can tell, this must be done in the SMTP negotiation phase. Mostly. What's it going to cost my ISP to implement this? Is it feasible for an ISP to implement this? Is it feasible for them _not_ to? ;-
Re: Unusual spam recently - hummm
Quoting Phillip Hofmeister ([EMAIL PROTECTED]): On Thu, 03 Jun 2004 at 12:57:46PM -0400, Alvin Oga wrote: - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net This is a bad suggestion. My ISP requires us (by blocking port 25 outbound) to use their SMTP server. Therefore I cannot connect to the normal SMTP Server for the zionlth.org domain. Implementing your suggestion wide spread would cause my emails (and all emails from people in my situation) to be rejected just because their ISP has their head on backwards and thinks blocking port 25 outbound will reduce spam abuse. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328 (Tell your ISP: Adapt or die. ;- ) -- Cheers, find / -user your -name base -print | xargs chown us:us Rick Moen [EMAIL PROTECTED]
Re: Unusual spam recently - hummm
Incoming from Phillip Hofmeister: On Thu, 03 Jun 2004 at 12:57:46PM -0400, Alvin Oga wrote: - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net This is a bad suggestion. My ISP requires us (by blocking port 25 outbound) to use their SMTP server. Therefore I cannot connect to the Considering 60% - 80% of the traffic these days is crap, this is beginning to look like a fairly reasonable restriction. If you can figure out how to have SMTP negotiate that your ISP legitimately handles mail for your domain, that's the only way around it I can see. There are a lot of spam friendlies out there for whom no amount of reporting spam will have any effect on their actions. Refusing forgeries is the only solution for those. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: Unusual spam recently - hummm
On Thu, 3 Jun 2004, s. keeling wrote: why is your spam filter allowing 3 basic spam signs thru ?? - email to undisclosed-recipients should be bounced - email from non-existent hosts should be bounced host-69-145-228-124.client.bresnan.net - email from [EMAIL PROTECTED] should be bounced since its not coming from bresnan.net Assuming my incoming mail is POPped off my ISP's mailhost and my outgoing mail goes to my ISP's mailhost, how do I implement this? if you do NOT have control of your own MTA for your domain, than you're on your own and yes .. everybody has different anti-spam rules one implements depending on your tolerance level, or network configs If I can't, what does my ISP have to do to implement this? ISP will probably NOT provide spam filtering, becuase of legal issues that they can easily be in deep kaa-kaa if they start editing what users can send/receive ( long running legal issues vs just letting thing flow un-touched c ya alvin
Re: Unusual spam recently - hummm
On torsdag 3. juni 2004, 20:24, s. keeling wrote: This is a bad suggestion. My ISP requires us (by blocking port 25 outbound) to use their SMTP server. Therefore I cannot connect to the Considering 60% - 80% of the traffic these days is crap, this is beginning to look like a fairly reasonable restriction. If you can figure out how to have SMTP negotiate that your ISP legitimately handles mail for your domain, that's the only way around it I can see. There are a lot of spam friendlies out there for whom no amount of reporting spam will have any effect on their actions. Refusing forgeries is the only solution for those. Then I think it is much more reasonable to let SpamAssassin or some other good spam scanner have a look at it, then reject in the SMTP dialogue based on not only a single characteristic. SA will also give hammy scores, so even if there is one spammy thing about the message, a few hammy things can let it pass through nevertheless. It is straightforward to set this up using the Exim4 backports and SA. Vennlig Tiddeli-bom, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Re: Unusual spam recently - hummm
hi ya s. On Thu, 3 Jun 2004, s. keeling wrote: If I can't, what does my ISP have to do to implement this? ISP will probably NOT provide spam filtering, becuase of legal issues My ISP does provide spam filtering; spamassassin marks crap on the mailhost and procmail moves it to my spamfile. I can review it there via webmail and blow it away without downloading it. However, I _would_ like to STOP it from being delivered at all, run your own mta .. as defined by simple rules like those above. As far as I can tell, this must be done in the SMTP negotiation phase. yup What's it going to cost my ISP to implement this? Is it feasible for an ISP to implement this? about 5 minutes of time to configure sendmail/exim/postfix etc - and worry about censoring issues from the legal side of the world when the lawayers for the spammers comes knocking implementing antispam rules would depend on the rules you want to use to call it spam before you even see it my antispam rules http://www.linux-sec.net/Mail/AntiSpam/ i call it 5 minute antispam rules, to implement my list of about dozen antispam rules ... ( and i use sendmail :-) - no incoming html is one of my rules :-) ( but, its obviously not for work related mta servers ) if you do not have control of the mta .. you're costs is lot more ( 100x - 1000x ) since you have to post process your emails after you already received it. further, each user has to also implement those same antispam rules in their mua if the mta is just for you and your policies, antispam costs is trivial if the mta is like mta.hotmail.com, or your corp server, would become in a non-trivial anti-spam set of rules .. because what is considered by spam to one user is i want that same identical email by another user - catalogs and price lists is a common issue - some things are still spam, even for 10 or 1000 users - if one uses someone elses MTA and pop from it, i suppose one has to be willing to find a harder solution to not get the spam ( harder solution - more than 5 or 10 minutes to implement ) c ya alvin
Re: Unusual spam recently - hummm
On torsdag 3. juni 2004, 20:53, Alvin Oga wrote: you have to post process your emails after you already received it. ...and then it is a bit late to bounce, isn't it...? Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/OpenPGP KeyID: 6A6A0BBC
Re: Unusual spam recently - hummm
Incoming from Phillip Hofmeister: On Thu, 03 Jun 2004 at 01:32:55PM -0400, s. keeling wrote: Assuming my incoming mail is POPped off my ISP's mailhost and my outgoing mail goes to my ISP's mailhost, how do I implement this? If I can't, what does my ISP have to do to implement this? User-Agent: Mutt/1.3.28i You use Mutt, a wonderful MUA if I must say so myself... I agree. It's only failing that I can see is it encourages insufferable smugness on the part of its users (Nyaa, nyaa. My mailer is marter, more conformant, faster, more configurable, and better documented and supported than your mailer! Nyaa, nyaa! Pthbthbthbthb! :-) I don't know how you currently handle your email. Whether you use IMAP My ISP has SA installed and running globally. I have a procmail recipe in my shell account on the ISP pluck out the crap and segregate it in a spamfile on my ISP. I can view it with webmail and blow it all away without DLing it. I have procmail here on my own machine splitting mail into folders locally and some more spam matching recipes to handle whatever manages to make it past SA. It has been slowly building up to the point that this system is verging on the unmanageable. So much crap (unsubscribes, viruses, worms, ...) are coming in from mailing lists, I now have two passes filtering out crap, before and after mailing list processing. Add to that false positives, whitelisting known senders, ... and it's becoming annoying. Most people would be very happy with the result but I've come to the conclusion it's no longer good enough for me. So, time for a re-org. I don't use spamassisin, just bogofilter. Here is my relevant procmailrc snippet... Downloading it now, thanks. Hopefully this gets me back to a maintainable system without all the exception handling, whitelisting, false positives etc. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: Unusual spam recently - hummm
Incoming from Rick Moen: Quoting s. keeling ([EMAIL PROTECTED]): However, I _would_ like to STOP it from being delivered at all, as [snip] What's it going to cost my ISP to implement this? Is it feasible for an ISP to implement this? Is it feasible for them _not_ to? ;- Yes. The problem with Alvin's solution is it only looks at the crap that spammers send. A lot of legitimate mail does all the silly things that spammers do, and users do want to receive that mail. Add to that all the broken-ness of many mail systems and you're left with little to count on. You and I may see no legitimate point to html mail, but ordinary users do. I ordinarily couldn't care less about html mail, but if it contains a job offer you bet I want to see it. The same is true for undisclosed-recipients: and From 's that don't match mailhosts. For a big organization with thousands of users, what's Spam is not really all that easy to quantify. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
Re: Unusual spam recently - hummm
On Thu, 03 Jun 2004 at 04:10:30PM -0400, s. keeling wrote: I don't use spamassisin, just bogofilter. Here is my relevant procmailrc snippet... Downloading it now, thanks. Hopefully this gets me back to a maintainable system without all the exception handling, whitelisting, false positives etc. Let me warn you. Bogofilter requires training a database. You may not get accurate results for the first few weeks or a month+ (depending on your spam volume and your ham volume). It would be great if you have a handful of a few hundred spam messages and a few hundred ham messages to shoot at it right away. use cat to pipe the messages/MBOX files through bogofilter -n and bogofilter -s. I would adjust the ~/.bogofilter.cf defaults as well. Here is mine: robx= 0.415000 robs= 0.01 min_dev = 0.10 ham_cutoff = 0.50 spam_cutoff = 0.70 block_on_subnets = yes replace_nonascii_characters = no timestamp=Y spam_header_name = X-Bogosity header_format = %h: %c, tests=bogofilter, spamicity=%p, version=%v terse_format = %1.1c %f log_header_format = %h: %c, spamicity=%p, version=%v log_update_format = register-%r, %w words, %m messages spamicity_tags= Yes, No, Unsure spamicity_formats = %0.6f, %0.6f If you are interested I can try bzip2ing my wordlist.db and sending it to you via http. Email me off-list if you would like this. This database is of coursed tuned to MY spam preferences. I have found it very reliable (for me). -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import
Re: Unusual spam recently - hummm
Quoting s. keeling ([EMAIL PROTECTED]): Yes. The problem with Alvin's solution is it only looks at the crap that spammers send. A lot of legitimate mail does all the silly things that spammers do, and users do want to receive that mail. 1. Content-based filtering doesn't work very well (if that's what you mean, which you probably don't). 2. Most silly things legitimate mail does can be accomodated by an efficient antispam regime; a few cannot. Remember the screams of outrage when people started being told You shouldn't run open relays any more? We're entering another round of that. Some of the you-can't-do-that-any-more items will be RFC violations (lack of postmaster@ and abuse@ addresses, failure to accept DSN mail, lack of deliverability to the alleged sender), others are not (lack of DNS RRs sufficient to serve as SPF data, support for revised forwarding standards such as SRS). Exactly as with open relays, the Net will be full of admins saying I don't have to do that; screw you. Increasingly, they'll find their mail refused at SMTP time, or stuffed into spamboxes and neglected. Some admins learn only when struck forcefully by Papa Darwin. So, that's how reality works. Deal, or be dealt. Add to that all the broken-ness of many mail systems and you're left with little to count on. I have no problem with my MTA issuing 55x Reject to broken systems. If you feel otherwise, cool. Go for it. You and I may see no legitimate point to html mail, but ordinary users do. Delightful red colour on that herring of yours. (If you think this discussion concerns HTML mail, you have badly misunderstood. See also point #1, supra.) The same is true for undisclosed-recipients: and From 's that don't match mailhosts. Whoever said block mail for undisclosed-recipients has rocks in his head and needs to reconsider. (I have no time to debate with such people.) And, hey, de-facto standards for forwarded mail handling (and thus envelope sender headers) have recently changed. Adapt or die. Die in this case means expect to see your mail rejected at an accelerating rate. Nobody's going to insist that you not die. If death becomes you, enjoy! For a big organization with thousands of users, what's Spam is not really all that easy to quantify. And another fine, ruddy herring! Delicious, thanks. -- Cheers, Rick Moen Age, baro, fac ut gaudeam. [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, 3 Jun 2004, Kjetil Kjernsmo wrote: On torsdag 3. juni 2004, 20:53, Alvin Oga wrote: you have to post process your emails after you already received it. ...and then it is a bit late to bounce, isn't it...? i typically dont need to post process... i never got the spam post processing is for the birds in my limited world of 10,000+ mails per day ... most of which are spam - the original posts spam assassin didnt reject the incoming spam to undisclosed recepient - once they validate the email addy is good, you're promptly added to a new more expensive spam list - receiving spam is a bad thing c ya alvin
