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
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 - 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
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
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 - 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]
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
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
* David Stanaway: > Has anyone else been receiving unusual spam recently which contains no > content? Yes, I've seen it, too. > Is this some spam engine checking MTAs to see if the addresses are > accepted? Looks like a mass-mailer bug to me. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.
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
Re: Unusual spam recently
* David Stanaway: > Has anyone else been receiving unusual spam recently which contains no > content? Yes, I've seen it, too. > Is this some spam engine checking MTAs to see if the addresses are > accepted? Looks like a mass-mailer bug to me. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com. -- 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
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 - 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 -- 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]): > What name calling? There's a difference. 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
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
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 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 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. 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
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
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
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
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
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
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
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
> 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. 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
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 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
Quoting Michael Stone ([EMAIL PROTECTED]): > What name calling? There's a difference. 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
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
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 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 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. 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
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
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
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
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
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
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
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
> 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. 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
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
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
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. -- 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. -- 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 . 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-
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
Re: Unusual spam recently - hummm - postprocess
Incoming from Bernd Eckenfels: > 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 What?!? If they spam, you cut them off, surely! And charge their credit card for cleanup costs!! -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - -
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 - -
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 - -
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
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/
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]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): > The end result is the same in a lot of cases. I'm sorry, what part of "fixing local problems first, and understanding the scope of one's responsibility" are you not quite getting? > The point is that you shouldn't take a holier-than-thou attitude about > when people should send bounces. I merely note that sending bounces of forged spam is a bad thing, for perfectly obvious reasons, and personally take measures to prevent being guilty of doing so. Moreover, I treat sites that visit that upon me in significant amounts as spam sources, regardless of their excuses. I'm sorry you don't like that. Your opinion is noted and duly ignored. > In the case of viruses, when it's unequivocal that a message is > garbage you should just drop it on the floor. I'd much rather refuse it. For: > If you're going to take any kind of action to reject the message, > OTOH, you've got the possibility of a bounce going to the wrong > person. Sorry, this is a dementedly wrong notion of responsibility. Refusing the mail doesn't generate a bounce message; it just refuses it. I am not going to take responsibility for someone else's misbehaviour (e.g., an upstream MTA). If the other site is sufficiently obnoxious in its behaviour, it's likely to end up getting whapped hard, in ways beyond mere refusal. > That's life until there's a system in place for validating envelope > addresses. SPF may or may not be that way in the future. At the moment > it is not. 1. Irrelevant to the question of responsibility. 2. Speak for yourself. I do implement SPF. Please see earlier citations for implementation details, if interested. > It's not misbehaving to generate a bounce message. Glad I could clear > that up. Send out "bounce messages" [sic] of forged mail in sufficiently large numbers, and you're likely to end up being treated as a spam source. That's a fact. Deal.
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?
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
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 05:29:25PM -0700, Rick Moen wrote: Earlier, I mentioned (to summarise and review) that I take care to have my MTA reject mail it considers inherently objectionable on various grounds, as a superior alternative to performing such processing after acceptance. (Among other things, it allows my system to say "no" without being guilty of generating bogus bounces to forged addresses.) Mr. Stone then opined that he saw no advantage because an upstream MTA might (e.g., if it was a relay) react to my 55X Reject by issuing a bogus bounce of its own. The end result is the same in a lot of cases. The point is that you shouldn't take a holier-than-thou attitude about when people should send bounces. In the case of viruses, when it's unequivocal that a message is garbage you should just drop it on the floor. If you're going to take any kind of action to reject the message, OTOH, you've got the possibility of a bounce going to the wrong person. That's life until there's a system in place for validating envelope addresses. SPF may or may not be that way in the future. At the moment it is not. I've heard this sort of comment before from people who really ought to know better, and who actually _do_ understand the concept of local responsibility. Maybe they're bored and are trolling; it's difficult to say. Or maybe they're just following the ever-popular philosophy of post first, think later. To spell it out, I'm responsible for making sure _my_ MTA isn't misbehaving. I'm not responsible for _your_ MTA misbehaving. It's not misbehaving to generate a bounce message. Glad I could clear that up. Mike Stone
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 . 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 - 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 - 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.
Re: Unusual spam recently - hummm - postprocess
On Thu, 3 Jun 2004, Blu wrote: > On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: > > Do I win a prize, yup :-) > 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? you're taking it too far dude ... violating common sense and assumptions is a bad thing ;-) i think the "reject mail from open relay" is a good thing and is totally different than "relay your own or customers mail" c ya alvin
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.)
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 05:16:10PM -0700, Alvin Oga wrote: > > On Thu, 3 Jun 2004, Blu wrote: > > > On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: > > > > Do I win a prize, > > yup :-) > > > 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? > > you're taking it too far dude ... > violating common sense and assumptions is a bad thing ;-) > > i think the "reject mail from open relay" is a good thing > and is totally different than "relay your own or customers mail" I agree, but it was suggested that any mail server should reject spam at SMTP time, and not bounce it at all. 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. Blu.
Re: Unusual spam recently - hummm - postprocess
Quoting Blu ([EMAIL PROTECTED]): > Are you suggesting then, that we should not relay mail at all?, not even > to/from our customers? I'm quite non-plussed at this question, since it seems to suggest that you weren't following the thread. Earlier, I mentioned (to summarise and review) that I take care to have my MTA reject mail it considers inherently objectionable on various grounds, as a superior alternative to performing such processing after acceptance. (Among other things, it allows my system to say "no" without being guilty of generating bogus bounces to forged addresses.) Mr. Stone then opined that he saw no advantage because an upstream MTA might (e.g., if it was a relay) react to my 55X Reject by issuing a bogus bounce of its own. I've heard this sort of comment before from people who really ought to know better, and who actually _do_ understand the concept of local responsibility. Maybe they're bored and are trolling; it's difficult to say. Or maybe they're just following the ever-popular philosophy of post first, think later. To spell it out, I'm responsible for making sure _my_ MTA isn't misbehaving. I'm not responsible for _your_ MTA misbehaving. If some upstream MTA (such as, hypothetically, yours) decides to take do something irresponsible and socially destructive (such as sending spam to a forged alleged sender) in reaction to my MTA saying "No, I don't accept that mail", then that _other_ MTA's admin is accountable for _his_ system's misbehaviour, and I hope and expect that we will all (figuratively) LART him until he bleeds. Now, if that MTA's admin says "Hey, I'm not responsible; I'm just a poor innocent relay", I'd say he'd better get accustomed to being accountable for mail his system sends out, since other admins _are_ clear on that point, even if he isn't. If the admin has no other way of making sure his system doesn't incontinently issue bogus "bounce" messages to forged addresses when spam/malware is refused downstream, then he'd be well advised to improve his _own_ ability to reject bogus mail, making its subsequent relaying a non-issue. Please also (since you're a relay) read the prior posted links about SRS.
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
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
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
Re: Unusual spam recently - hummm - postprocess
Incoming from Bernd Eckenfels: > 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 What?!? If they spam, you cut them off, surely! And charge their credit card for cleanup costs!! -- 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
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! > > 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.
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! 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?
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 - -
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
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]
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 - 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 - 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
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
Quoting Michael Stone ([EMAIL PROTECTED]): > The end result is the same in a lot of cases. I'm sorry, what part of "fixing local problems first, and understanding the scope of one's responsibility" are you not quite getting? > The point is that you shouldn't take a holier-than-thou attitude about > when people should send bounces. I merely note that sending bounces of forged spam is a bad thing, for perfectly obvious reasons, and personally take measures to prevent being guilty of doing so. Moreover, I treat sites that visit that upon me in significant amounts as spam sources, regardless of their excuses. I'm sorry you don't like that. Your opinion is noted and duly ignored. > In the case of viruses, when it's unequivocal that a message is > garbage you should just drop it on the floor. I'd much rather refuse it. For: > If you're going to take any kind of action to reject the message, > OTOH, you've got the possibility of a bounce going to the wrong > person. Sorry, this is a dementedly wrong notion of responsibility. Refusing the mail doesn't generate a bounce message; it just refuses it. I am not going to take responsibility for someone else's misbehaviour (e.g., an upstream MTA). If the other site is sufficiently obnoxious in its behaviour, it's likely to end up getting whapped hard, in ways beyond mere refusal. > That's life until there's a system in place for validating envelope > addresses. SPF may or may not be that way in the future. At the moment > it is not. 1. Irrelevant to the question of responsibility. 2. Speak for yourself. I do implement SPF. Please see earlier citations for implementation details, if interested. > It's not misbehaving to generate a bounce message. Glad I could clear > that up. Send out "bounce messages" [sic] of forged mail in sufficiently large numbers, and you're likely to end up being treated as a spam source. That's a fact. Deal. -- 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
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 - postprocess
On Thu, Jun 03, 2004 at 05:29:25PM -0700, Rick Moen wrote: Earlier, I mentioned (to summarise and review) that I take care to have my MTA reject mail it considers inherently objectionable on various grounds, as a superior alternative to performing such processing after acceptance. (Among other things, it allows my system to say "no" without being guilty of generating bogus bounces to forged addresses.) Mr. Stone then opined that he saw no advantage because an upstream MTA might (e.g., if it was a relay) react to my 55X Reject by issuing a bogus bounce of its own. The end result is the same in a lot of cases. The point is that you shouldn't take a holier-than-thou attitude about when people should send bounces. In the case of viruses, when it's unequivocal that a message is garbage you should just drop it on the floor. If you're going to take any kind of action to reject the message, OTOH, you've got the possibility of a bounce going to the wrong person. That's life until there's a system in place for validating envelope addresses. SPF may or may not be that way in the future. At the moment it is not. I've heard this sort of comment before from people who really ought to know better, and who actually _do_ understand the concept of local responsibility. Maybe they're bored and are trolling; it's difficult to say. Or maybe they're just following the ever-popular philosophy of post first, think later. To spell it out, I'm responsible for making sure _my_ MTA isn't misbehaving. I'm not responsible for _your_ MTA misbehaving. It's not misbehaving to generate a bounce message. Glad I could clear that up. Mike Stone -- 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, 3 Jun 2004, Blu wrote: > On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: > > Do I win a prize, yup :-) > 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? you're taking it too far dude ... violating common sense and assumptions is a bad thing ;-) i think the "reject mail from open relay" is a good thing and is totally different than "relay your own or customers mail" 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 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 - -
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
On Thu, Jun 03, 2004 at 05:16:10PM -0700, Alvin Oga wrote: > > On Thu, 3 Jun 2004, Blu wrote: > > > On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: > > > > Do I win a prize, > > yup :-) > > > 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? > > you're taking it too far dude ... > violating common sense and assumptions is a bad thing ;-) > > i think the "reject mail from open relay" is a good thing > and is totally different than "relay your own or customers mail" I agree, but it was suggested that any mail server should reject spam at SMTP time, and not bounce it at all. 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. Blu. -- 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]): > Are you suggesting then, that we should not relay mail at all?, not even > to/from our customers? I'm quite non-plussed at this question, since it seems to suggest that you weren't following the thread. Earlier, I mentioned (to summarise and review) that I take care to have my MTA reject mail it considers inherently objectionable on various grounds, as a superior alternative to performing such processing after acceptance. (Among other things, it allows my system to say "no" without being guilty of generating bogus bounces to forged addresses.) Mr. Stone then opined that he saw no advantage because an upstream MTA might (e.g., if it was a relay) react to my 55X Reject by issuing a bogus bounce of its own. I've heard this sort of comment before from people who really ought to know better, and who actually _do_ understand the concept of local responsibility. Maybe they're bored and are trolling; it's difficult to say. Or maybe they're just following the ever-popular philosophy of post first, think later. To spell it out, I'm responsible for making sure _my_ MTA isn't misbehaving. I'm not responsible for _your_ MTA misbehaving. If some upstream MTA (such as, hypothetically, yours) decides to take do something irresponsible and socially destructive (such as sending spam to a forged alleged sender) in reaction to my MTA saying "No, I don't accept that mail", then that _other_ MTA's admin is accountable for _his_ system's misbehaviour, and I hope and expect that we will all (figuratively) LART him until he bleeds. Now, if that MTA's admin says "Hey, I'm not responsible; I'm just a poor innocent relay", I'd say he'd better get accustomed to being accountable for mail his system sends out, since other admins _are_ clear on that point, even if he isn't. If the admin has no other way of making sure his system doesn't incontinently issue bogus "bounce" messages to forged addresses when spam/malware is refused downstream, then he'd be well advised to improve his _own_ ability to reject bogus mail, making its subsequent relaying a non-issue. Please also (since you're a relay) read the prior posted links about SRS. -- 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
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 - 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]
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 - 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).
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! > > 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
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! 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
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
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]
