Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): You're talking about SPF. That's a concept, not an implementation. Implementation details have already been posted. Effective use of SPF requires widespread adoption. Until/unless widespread adoption happens the promises of SPF are vaporware. Reasons why early adoption yields large benefits have already been posted. (Further attempt to redefine the word vaporware duly ignored as of secondary concern.) I expect we're done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): You're talking about SPF. That's a concept, not an implementation. Implementation details have already been posted. Effective use of SPF requires widespread adoption. Until/unless widespread adoption happens the promises of SPF are vaporware. Reasons why early adoption yields large benefits have already been posted. (Further attempt to redefine the word vaporware duly ignored as of secondary concern.) I expect we're done.
Re: Unusual spam recently - hummm - postprocess
On Sat, 5 Jun 2004 08:52, Michael Stone [EMAIL PROTECTED] wrote: So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Which leads to more spam that uses addresses from small domains in the From: field, and thus more need for administrators of small servers to implement SPF records to counter it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Sat, 5 Jun 2004 08:52, Michael Stone [EMAIL PROTECTED] wrote: So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Which leads to more spam that uses addresses from small domains in the From: field, and thus more need for administrators of small servers to implement SPF records to counter it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
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]
vapaorware Re: Unusual spam recently - hummm - postprocess
hi ya On Fri, 4 Jun 2004, Michael Stone wrote: On Fri, Jun 04, 2004 at 05:26:07PM -0700, Rick Moen wrote: You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. vaporware is good and bad ... good, because if its features gets implemented right and if it is needed, it will get widely adopted vaporware is bad, when its something that is sold, that is not yet fully functional to end users and in the old days, to generate revenue for the company and commissions to the sales droids think back to the stone ages .. even the linux kernel was vaporware in the beginning and there were other equivalent options to choose from c ya alvin
Re: Unusual spam recently - hummm - postprocess
Quoting Phillip Hofmeister ([EMAIL PROTECTED]): While I am sure finding out whose is bigger is exciting to you. I feel comfortable in speaking for the rest of the list when I say this thread has become WAY OT. I'm surprised that an allegation that SPF -- highly relevant to SMTP security -- is vapourware, not to mention refutations of that assertion, are off-topic. Nonetheless, I apologise for reacting with irritation to Michael's claim to that effect: It's just that I expected better from a Security Team member. Much better. Why is SPF important? Because it eliminates joe-jobs. That is, it allows mail admins to absolutely validate the envelope return path -- significant because spammers have recently gotten around to forging sender envelope information, allowing forged mail that appears to be credibly from your domain or mine, etc. -- and as such began defeating even quite good security regimes. Why is it not vapourware? Because prepackaged kits exist to trivially add support to -=all=- of common MTAs: Postfix, Exim, sendmail, qmail, Courier-MTA, and MS-Exchange Server. I posted the link twice earlier in the conversation, well before Michael dismissed it as vapourware. Here it is again: http://spf.pobox.com/downloads.html If using Exim4 on Debian, the required daemon (perl module Mail::SPF::Query) is available as Debian package libmail-spf-query-perl . The Exim4 ACL that invokes it can be found on the above-cited page, and a SysVInit script can be pulled down from http://www.jcdigita.com/eximconfig/ . If all that's vapourware, then it's amazing how much functional and well-debugged vapourware can be located in three minutes of googling. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 11:50:09AM -0700, Rick Moen wrote: I'm surprised that an allegation that SPF -- highly relevant to SMTP security -- is vapourware, not to mention refutations of that assertion, are off-topic. Nonetheless, I apologise for reacting with irritation to Michael's claim to that effect: It's just that I expected better from a Security Team member. Much better. Well, it is vaporware. Until it's used by a noticable percentage of hosts, it's irrelevant. I've had spf records on my own domain for some time, but that doesn't mean I believe that there is enough critical mass behind the idea to actually make it useful. I'm not yet pushing for spf records at my day job, for example, because there's not yet a benefit which would justify the effort on that scale. Why is it not vapourware? Because prepackaged kits exist to trivially add support to -=all=- of common MTAs: Postfix, Exim, sendmail, qmail, Courier-MTA, and MS-Exchange Server. That doesn't matter, unless a large enough fraction of people at both ends of smtp conversations actually use the stuff. An implementation that is not deployed is no more useful than a standard which isn't implemented. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
snip from='Michael Stone' date='2004-06-04 18:25:47 -0400' That doesn't matter, unless a large enough fraction of people at both ends of smtp conversations actually use the stuff. An implementation that is not deployed is no more useful than a standard which isn't implemented. /snip Fair enough, but it's up to people like us to push it, surely? J. -- +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ www:http://www.azazel.net/ public key: http://www.azazel.net/home/az-gpg.txt geek code: http://www.azazel.net/home/geekcode.txt +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate. Well, fisrt of all, I accept mail for outgoing relay only from verified sources, this includes SMTP AUTH or based on ip address. This is of course not 100% secure. And second, you should try to not generate bounces. This includes spam rejects, unknown mailboxes and virus alerts. All those must be rejcted on the smtp level. This is all one can do in his own local responsibility. For backup MX or centralized mail gateways it is therefore a matter of good service to do all those rejections at the smtp level, which might involve replicated addressbooks or even pipelining. A lot of organisations forget to include their backup mx into their mail concept and are the main reaons for bounce-floods caused by malware or faked-sender spam. (of course with open relays it does not help if you do not bounce, but those are note the biggest source of spam). Direct delivery from dialups or open proxies are much more common, at least for the large mail providers. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: Why is SPF important? Because it eliminates joe-jobs. That is, it allows mail admins to absolutely validate the envelope return path -- significant because spammers have recently gotten around to forging sender envelope information, allowing forged mail that appears to be credibly from your domain or mine, etc. -- and as such began defeating even quite good security regimes. Solutions like yahoos DomainKeys header signature is much better suited for that, I think. http://antispam.yahoo.com/domainkeys Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): Well, it is vaporware. Until it's used by a noticable percentage of hosts, it's irrelevant. (1) Where I come from, the term vapourware means software touted far in advance of its availability. As noted, such is most emphatically not the case, here. However, moving on: (2) A relevant index for usefulness wouldn't be the percentage of _hosts_, but rather the percentage of _mail_ for which it's useful. This distinction is important: The utility of SPF lies in its ability to eliminate joe-jobbing, providing a means to validate MXes -- and, as I'm reasonably sure you'll have observed, forged mail's envelopes strongly tend to forge the domains of major (very large) mail-handling sites. Those sites happen to have been among the earliest adopters of SPF RRs in their DNS, largely because they are particularly motivated to protect their trademarks and their names. So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. And that's a whole lot of spam, right there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 11:38:02PM +0100, Azazel wrote: Fair enough, but it's up to people like us to push it, surely? There's a line between advocacy and zealotry. At this point I'm not convinced that it's worth the effort. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 03:47:55PM -0700, Rick Moen wrote: The utility of SPF lies in its ability to eliminate joe-jobbing, providing a means to validate MXes -- and, as I'm reasonably sure you'll have observed, forged mail's envelopes strongly tend to forge the domains of major (very large) mail-handling sites. Those sites happen to have been among the earliest adopters of SPF RRs in their DNS, largely because they are particularly motivated to protect their trademarks and their names. yeah, aol's pleased as punch about it. they also don't have much interest in customers sending email with @aol from off their own system unless they use an obnoxious webmail client. same goes for hotmail. anyone with users who isn't aol and whose users don't particularly want a webmail client needs to give things more thought. So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): yeah, aol's pleased as punch about it. they also don't have much interest in customers sending email with @aol from off their own system unless they use an obnoxious webmail client. same goes for hotmail. anyone with users who isn't aol and whose users don't particularly want a webmail client needs to give things more thought. Not that I'm objecting, but I can't help noticing that you're ignoring the point I just made, and changing the subject. Well, I guess the spammers will have to use different addresses. That shouldn't take long. That's where reputations schemes (RHSBLs, greylisting, etc.) come in. See: Throwaway Domains on http://spf.pobox.com/objections.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): There's a line between advocacy and zealotry. Still stuck in name-calling mode? Pity. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. Are there any remaining MUAs that can't support SASL? Can't think of any, offhand, but perhaps there are some. In any event, nobody says you as an MTA admin ought to /dev/null mail whose sending MX cannot be verified. Your local policy might be to merely subject those to more-careful checks, for example. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
snip from='Michael Stone' date='2004-06-04 18:49:05 -0400' On Fri, Jun 04, 2004 at 11:38:02PM +0100, Azazel wrote: Fair enough, but it's up to people like us to push it, surely? There's a line between advocacy and zealotry. At this point I'm not convinced that it's worth the effort. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. /snip Oh, you're right. I have SPF records for my domains, but I haven't enabled it on my MTA, 'cause I'm not sure whether it's worth it yet. I do feel a degree of guilt about that though: SPF does have vulnerabili- ties, but it's as good a solution as I've come across, and, if I just trust to my Bayesian filter to keep my inbox clean, I'm not really helping. I was reading pobox.com's faq the other day, and the impression that I got was that somebody somewhere is going to have to make an effort at some point. That point, however, is likely to turn out to be something we can identify with hindsight and explain with statistics. J. -- +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ www:http://www.azazel.net/ public key: http://www.azazel.net/home/az-gpg.txt geek code: http://www.azazel.net/home/geekcode.txt +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 04:00:32PM -0700, Rick Moen wrote: Not that I'm objecting, but I can't help noticing that you're ignoring the point I just made, and changing the subject. No, I'm not. I'm pointing out that the world is more complicated than you seem to think. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 04:09:32PM -0700, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): There's a line between advocacy and zealotry. Still stuck in name-calling mode? Pity. What name calling? There's a difference. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. Are there any remaining MUAs that can't support SASL? Can't think of any, offhand, but perhaps there are some. You're assuming unrestricted outbound connections. Might even be true in your environment. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328 Not applicable. That requires not only a change on the part of the organization implementing SPF, but also a change at any location where a user wants to send mail. I know, I know, the zealous answer would be that everyone should just implement everything right now--but some of us live in the real world. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Sat, Jun 05, 2004 at 12:23:14AM +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate. Well, fisrt of all, I accept mail for outgoing relay only from verified sources, this includes SMTP AUTH or based on ip address. This is of course not 100% secure. And second, you should try to not generate bounces. This includes spam rejects, unknown mailboxes and virus alerts. All those must be rejcted on the smtp level. This is all one can do in his own local responsibility. For backup MX or centralized mail gateways it is therefore a matter of good service to do all those rejections at the smtp level, which might involve replicated addressbooks or even pipelining. A lot of organisations forget to include their backup mx into their mail concept and are the main reaons for bounce-floods caused by malware or faked-sender spam. (of course with open relays it does not help if you do not bounce, but those are note the biggest source of spam). Direct delivery from dialups or open proxies are much more common, at least for the large mail providers. None of this (and the rest of the thread too, not picking on anyone in particulary) has much to do with Debian-security. Pehaps there is a more general place this thread can be taken. pgpOcbYht1Sk4.pgp Description: PGP signature
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): What name calling? There's a difference. snort Cute. Ah, well. You're assuming unrestricted outbound connections. Might even be true in your environment. It's true that there will be interim problems with corporate firewalls (etc.) closing off outbound access to 587/tcp (but allowing access to 25/tcp). Should diminish over time. I suppose that's why alternatives like POP-before-SMTP persist. [SRS references:] Not applicable. That requires not only a change on the part of the organization implementing SPF, but also a change at any location where a user wants to send mail. Not really, only relays. On relay sites, implementation requires installing /usr/bin/srs (the Perl Mail::SRS module) or equivalent, then using it as a wrapper for .forward and /etc/alias entries. Over the longer term, it may end up being supported inline in MTAs. Ditto for SPF itself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): No, I'm not. You _weren't_ ignoring the point I just made and changing the subject? Then, some villain apparently snuck into your MTA and substituted different text that did, for the original message you tried to send. You should sue! ;- I'm pointing out that the world is more complicated than you seem to think. You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 05:26:07PM -0700, Rick Moen wrote: You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. You're talking about SPF. That's a concept, not an implementation. Effective use of SPF requires widespread adoption. Until/unless widespread adoption happens the promises of SPF are vaporware. Pointing to a bunch of implementations of SPF doesn't speak to whether it's been widely adopted. There have been many failed implementations of many forgotten concepts over the years and only time will tell whether SPF extensions to various MTA's will fall into that category. I think this thread's been beaten to death; have fun with your evangelizing, hopefully on a more applicable forum. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Bernd Eckenfels ([EMAIL PROTECTED]): If you relay mail from your customers, you have to deliver them their bounces if they spam. Well, that's the trick, isn't it? If they're sending spam (either deliberately or -- much more likely of late -- because customer hosts have been zombified by malware), then the sender addresses and (of late) the envelope return path will almost certainly be forged. It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate.
Re: Unusual spam recently - hummm - postprocess
Quoting Phillip Hofmeister ([EMAIL PROTECTED]): While I am sure finding out whose is bigger is exciting to you. I feel comfortable in speaking for the rest of the list when I say this thread has become WAY OT. I'm surprised that an allegation that SPF -- highly relevant to SMTP security -- is vapourware, not to mention refutations of that assertion, are off-topic. Nonetheless, I apologise for reacting with irritation to Michael's claim to that effect: It's just that I expected better from a Security Team member. Much better. Why is SPF important? Because it eliminates joe-jobs. That is, it allows mail admins to absolutely validate the envelope return path -- significant because spammers have recently gotten around to forging sender envelope information, allowing forged mail that appears to be credibly from your domain or mine, etc. -- and as such began defeating even quite good security regimes. Why is it not vapourware? Because prepackaged kits exist to trivially add support to -=all=- of common MTAs: Postfix, Exim, sendmail, qmail, Courier-MTA, and MS-Exchange Server. I posted the link twice earlier in the conversation, well before Michael dismissed it as vapourware. Here it is again: http://spf.pobox.com/downloads.html If using Exim4 on Debian, the required daemon (perl module Mail::SPF::Query) is available as Debian package libmail-spf-query-perl . The Exim4 ACL that invokes it can be found on the above-cited page, and a SysVInit script can be pulled down from http://www.jcdigita.com/eximconfig/ . If all that's vapourware, then it's amazing how much functional and well-debugged vapourware can be located in three minutes of googling.
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 11:50:09AM -0700, Rick Moen wrote: I'm surprised that an allegation that SPF -- highly relevant to SMTP security -- is vapourware, not to mention refutations of that assertion, are off-topic. Nonetheless, I apologise for reacting with irritation to Michael's claim to that effect: It's just that I expected better from a Security Team member. Much better. Well, it is vaporware. Until it's used by a noticable percentage of hosts, it's irrelevant. I've had spf records on my own domain for some time, but that doesn't mean I believe that there is enough critical mass behind the idea to actually make it useful. I'm not yet pushing for spf records at my day job, for example, because there's not yet a benefit which would justify the effort on that scale. Why is it not vapourware? Because prepackaged kits exist to trivially add support to -=all=- of common MTAs: Postfix, Exim, sendmail, qmail, Courier-MTA, and MS-Exchange Server. That doesn't matter, unless a large enough fraction of people at both ends of smtp conversations actually use the stuff. An implementation that is not deployed is no more useful than a standard which isn't implemented. Mike Stone
Re: Unusual spam recently - hummm - postprocess
snip from='Michael Stone' date='2004-06-04 18:25:47 -0400' That doesn't matter, unless a large enough fraction of people at both ends of smtp conversations actually use the stuff. An implementation that is not deployed is no more useful than a standard which isn't implemented. /snip Fair enough, but it's up to people like us to push it, surely? J. -- +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ www:http://www.azazel.net/ public key: http://www.azazel.net/home/az-gpg.txt geek code: http://www.azazel.net/home/geekcode.txt +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate. Well, fisrt of all, I accept mail for outgoing relay only from verified sources, this includes SMTP AUTH or based on ip address. This is of course not 100% secure. And second, you should try to not generate bounces. This includes spam rejects, unknown mailboxes and virus alerts. All those must be rejcted on the smtp level. This is all one can do in his own local responsibility. For backup MX or centralized mail gateways it is therefore a matter of good service to do all those rejections at the smtp level, which might involve replicated addressbooks or even pipelining. A lot of organisations forget to include their backup mx into their mail concept and are the main reaons for bounce-floods caused by malware or faked-sender spam. (of course with open relays it does not help if you do not bounce, but those are note the biggest source of spam). Direct delivery from dialups or open proxies are much more common, at least for the large mail providers. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: Why is SPF important? Because it eliminates joe-jobs. That is, it allows mail admins to absolutely validate the envelope return path -- significant because spammers have recently gotten around to forging sender envelope information, allowing forged mail that appears to be credibly from your domain or mine, etc. -- and as such began defeating even quite good security regimes. Solutions like yahoos DomainKeys header signature is much better suited for that, I think. http://antispam.yahoo.com/domainkeys Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): Well, it is vaporware. Until it's used by a noticable percentage of hosts, it's irrelevant. (1) Where I come from, the term vapourware means software touted far in advance of its availability. As noted, such is most emphatically not the case, here. However, moving on: (2) A relevant index for usefulness wouldn't be the percentage of _hosts_, but rather the percentage of _mail_ for which it's useful. This distinction is important: The utility of SPF lies in its ability to eliminate joe-jobbing, providing a means to validate MXes -- and, as I'm reasonably sure you'll have observed, forged mail's envelopes strongly tend to forge the domains of major (very large) mail-handling sites. Those sites happen to have been among the earliest adopters of SPF RRs in their DNS, largely because they are particularly motivated to protect their trademarks and their names. So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. And that's a whole lot of spam, right there.
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 11:38:02PM +0100, Azazel wrote: Fair enough, but it's up to people like us to push it, surely? There's a line between advocacy and zealotry. At this point I'm not convinced that it's worth the effort. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. Mike Stone
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 03:47:55PM -0700, Rick Moen wrote: The utility of SPF lies in its ability to eliminate joe-jobbing, providing a means to validate MXes -- and, as I'm reasonably sure you'll have observed, forged mail's envelopes strongly tend to forge the domains of major (very large) mail-handling sites. Those sites happen to have been among the earliest adopters of SPF RRs in their DNS, largely because they are particularly motivated to protect their trademarks and their names. yeah, aol's pleased as punch about it. they also don't have much interest in customers sending email with @aol from off their own system unless they use an obnoxious webmail client. same goes for hotmail. anyone with users who isn't aol and whose users don't particularly want a webmail client needs to give things more thought. So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Mike Stone
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): yeah, aol's pleased as punch about it. they also don't have much interest in customers sending email with @aol from off their own system unless they use an obnoxious webmail client. same goes for hotmail. anyone with users who isn't aol and whose users don't particularly want a webmail client needs to give things more thought. Not that I'm objecting, but I can't help noticing that you're ignoring the point I just made, and changing the subject. Well, I guess the spammers will have to use different addresses. That shouldn't take long. That's where reputations schemes (RHSBLs, greylisting, etc.) come in. See: Throwaway Domains on http://spf.pobox.com/objections.html
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): There's a line between advocacy and zealotry. Still stuck in name-calling mode? Pity. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. Are there any remaining MUAs that can't support SASL? Can't think of any, offhand, but perhaps there are some. In any event, nobody says you as an MTA admin ought to /dev/null mail whose sending MX cannot be verified. Your local policy might be to merely subject those to more-careful checks, for example. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328
Re: Unusual spam recently - hummm - postprocess
snip from='Michael Stone' date='2004-06-04 18:49:05 -0400' On Fri, Jun 04, 2004 at 11:38:02PM +0100, Azazel wrote: Fair enough, but it's up to people like us to push it, surely? There's a line between advocacy and zealotry. At this point I'm not convinced that it's worth the effort. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. /snip Oh, you're right. I have SPF records for my domains, but I haven't enabled it on my MTA, 'cause I'm not sure whether it's worth it yet. I do feel a degree of guilt about that though: SPF does have vulnerabili- ties, but it's as good a solution as I've come across, and, if I just trust to my Bayesian filter to keep my inbox clean, I'm not really helping. I was reading pobox.com's faq the other day, and the impression that I got was that somebody somewhere is going to have to make an effort at some point. That point, however, is likely to turn out to be something we can identify with hindsight and explain with statistics. J. -- +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+ www:http://www.azazel.net/ public key: http://www.azazel.net/home/az-gpg.txt geek code: http://www.azazel.net/home/geekcode.txt +0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+0+
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 04:00:32PM -0700, Rick Moen wrote: Not that I'm objecting, but I can't help noticing that you're ignoring the point I just made, and changing the subject. No, I'm not. I'm pointing out that the world is more complicated than you seem to think. Mike Stone
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 04:09:32PM -0700, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): There's a line between advocacy and zealotry. Still stuck in name-calling mode? Pity. What name calling? There's a difference. It's fine for a home user to implement it quickly but it's not so easy for a lot of large organizations that currently allow people to send mail from offsite locations. Are there any remaining MUAs that can't support SASL? Can't think of any, offhand, but perhaps there are some. You're assuming unrestricted outbound connections. Might even be true in your environment. The problem is even bigger when you consider that a lot of places are blocking outbound smtp except through their own relays--which makes the just implement smtp auth argument a bit harder to swallow. http://spf.pobox.com/srs.html http://www.linuxjournal.com/article.php?sid=7328 Not applicable. That requires not only a change on the part of the organization implementing SPF, but also a change at any location where a user wants to send mail. I know, I know, the zealous answer would be that everyone should just implement everything right now--but some of us live in the real world. Mike Stone
Re: Unusual spam recently - hummm - postprocess
On Sat, Jun 05, 2004 at 12:23:14AM +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: It's possible you're taking that fact into account: I'd be curious to hear how you (or others) are ensuring that such bounces go somewhere appropriate. Well, fisrt of all, I accept mail for outgoing relay only from verified sources, this includes SMTP AUTH or based on ip address. This is of course not 100% secure. And second, you should try to not generate bounces. This includes spam rejects, unknown mailboxes and virus alerts. All those must be rejcted on the smtp level. This is all one can do in his own local responsibility. For backup MX or centralized mail gateways it is therefore a matter of good service to do all those rejections at the smtp level, which might involve replicated addressbooks or even pipelining. A lot of organisations forget to include their backup mx into their mail concept and are the main reaons for bounce-floods caused by malware or faked-sender spam. (of course with open relays it does not help if you do not bounce, but those are note the biggest source of spam). Direct delivery from dialups or open proxies are much more common, at least for the large mail providers. None of this (and the rest of the thread too, not picking on anyone in particulary) has much to do with Debian-security. Pehaps there is a more general place this thread can be taken. pgpXDZTqUymGy.pgp Description: PGP signature
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): What name calling? There's a difference. snort Cute. Ah, well. You're assuming unrestricted outbound connections. Might even be true in your environment. It's true that there will be interim problems with corporate firewalls (etc.) closing off outbound access to 587/tcp (but allowing access to 25/tcp). Should diminish over time. I suppose that's why alternatives like POP-before-SMTP persist. [SRS references:] Not applicable. That requires not only a change on the part of the organization implementing SPF, but also a change at any location where a user wants to send mail. Not really, only relays. On relay sites, implementation requires installing /usr/bin/srs (the Perl Mail::SRS module) or equivalent, then using it as a wrapper for .forward and /etc/alias entries. Over the longer term, it may end up being supported inline in MTAs. Ditto for SPF itself.
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): No, I'm not. You _weren't_ ignoring the point I just made and changing the subject? Then, some villain apparently snuck into your MTA and substituted different text that did, for the original message you tried to send. You should sue! ;- I'm pointing out that the world is more complicated than you seem to think. You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK.
Re: Unusual spam recently - hummm - postprocess
On Fri, Jun 04, 2004 at 05:26:07PM -0700, Rick Moen wrote: You mean like having extra meanings of the term vaporware, ones that you alone are aware of? OK. You're talking about SPF. That's a concept, not an implementation. Effective use of SPF requires widespread adoption. Until/unless widespread adoption happens the promises of SPF are vaporware. Pointing to a bunch of implementations of SPF doesn't speak to whether it's been widely adopted. There have been many failed implementations of many forgotten concepts over the years and only time will tell whether SPF extensions to various MTA's will fall into that category. I think this thread's been beaten to death; have fun with your evangelizing, hopefully on a more applicable forum. Mike Stone
Re: Unusual spam recently - hummm - postprocess
On Thu, 3 Jun 2004, Kjetil Kjernsmo wrote: On torsdag 3. juni 2004, 20:53, Alvin Oga wrote: you have to post process your emails after you already received it. ...and then it is a bit late to bounce, isn't it...? i typically dont need to post process... i never got the spam post processing is for the birds in my limited world of 10,000+ mails per day ... most of which are spam - the original posts spam assassin didnt reject the incoming spam to undisclosed recepient - once they validate the email addy is good, you're promptly added to a new more expensive spam list - receiving spam is a bad thing c ya alvin
Re: Unusual spam recently - hummm - postprocess
On Jun 3, 2004, at 3:07 PM, Alvin Oga wrote: post processing is for the birds in my limited world of 10,000+ mails per day ... most of which are spam - the original posts spam assassin didnt reject the incoming spam to undisclosed recepient - once they validate the email addy is good, you're promptly added to a new more expensive spam list - receiving spam is a bad thing My mail system has a number of users, and I prefer to let the recipient decide what is spam. The question was really about the empty spams that are showing up in the last month or so, and what they are intended for. Weather it was a prelude to an MTA exploiting worm strike, or just spammers assessing the value of their spam lists before using them to deliver their spamloads. My content filtering mostly works. It catches over 99% of spam and I have only had 1 false positive, and I think I will stick with it. Some list servers such as yahoogroups (May it rot in pieces) have the annoying behavior of deactivating your subscription on hard bounces from MTAs so whenever a list I am subscribed to with lax attachment policies gets a worm, and I hard bounce it with mime-header-checks, I get deactivated. So this is just one example of hard bouncing spam not being a great system wide policy right now (Unless you don't like your users :P). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting David Stanaway ([EMAIL PROTECTED]): My mail system has a number of users, and I prefer to let the recipient decide what is spam. There's a minor problem with this, about which more below. Some list servers such as yahoogroups (May it rot in pieces) have the annoying behavior of deactivating your subscription on hard bounces from MTAs so whenever a list I am subscribed to with lax attachment policies gets a worm, and I hard bounce it with mime-header-checks, I get deactivated. So this is just one example of hard bouncing spam not being a great system wide policy right now (Unless you don't like your users :P). Bouncing spam at all, in any way, is irresponsible admin behaviour. Consider: Essentially all spam forges as much header information as possible, and the newer generation even forges the envelope return-path data. Therefore, if you bounce spam, it is almost 100% guaranteed to be sent out to a forged address -- a party (extant or not) that did not send the original spam in the first place. In effect, you are generating _additional_ spam with each and every such bounce. However, if your system is able to determine _during the SMTP session_ that the mail is unwanted (as spam or for some other reason), it can issue a 55X Reject error and refuse delivery, instead of accepting the mail and then having to make the poor choice between /dev/nulling the received mail and issuing an almost certainly inappropriate bounce message. Smarter and better remedies are possible during SMTP time, than they are after delivery. A number of other steps are possible, beyond what I've mentioned. And, of course, by the time your users have a chance to apply their judgement on the matter, the MTA has already accepted the mail and handed it off to an LDA or MDA -- so the opportunity is lost. -- Cheers, Rick MoenBu^so^stopu min per kulero. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 03:23:51PM -0700, Rick Moen wrote: However, if your system is able to determine _during the SMTP session_ that the mail is unwanted (as spam or for some other reason), it can issue a 55X Reject error and refuse delivery, instead of accepting the mail and then having to make the poor choice between /dev/nulling the received mail and issuing an almost certainly inappropriate bounce message. Yeah, big difference. If the spam is going through a relay, the relay will send the same bounce and the same person will get the bounce message. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): Yeah, big difference. If the spam is going through a relay, the relay will send the same bounce and the same person will get the bounce message. Oh, oh! jumps up and down Gee, I guess that relay should have rejected the spam instead of relaying it, right? Then, it wouldn't feel a compulsion to issue a completely inappropriate bounce [sic] message to a forged sender. Do I win a prize, or was that just a qualifying round, and the real questions, that actually require thinking, will come later? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): Yeah, big difference. If the spam is going through a relay, the relay will send the same bounce and the same person will get the bounce message. Oh, oh! jumps up and down Gee, I guess that relay should have rejected the spam instead of relaying it, right? Then, it wouldn't feel a compulsion to issue a completely inappropriate bounce [sic] message to a forged sender. Do I win a prize, or was that just a qualifying round, and the real questions, that actually require thinking, will come later? Are you suggesting then, that we should not relay mail at all?, not even to/from our customers? Blu. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: Gee, I guess that relay should have rejected the spam instead of relaying it, right? Then, it wouldn't feel a compulsion to issue a completely inappropriate bounce [sic] message to a forged sender. I'm sure the guy who got joe jobbed is happy that you can point out the source of his misforture. Must be real comforting and all. Do I win a prize, or was that just a qualifying round, and the real questions, that actually require thinking, will come later? I'm not sure you'd qualify for the thinking round. Seems like you're just a big ball of spam hating fury, no? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): I'm sure the guy who got joe jobbed is happy that you can point out the source of his misforture. Must be real comforting and all. Was there a particular part of the immediately preceding reference to SPF that you didn't get, or was it the concept as a whole? (Kid, I was in the thick of the eponymous incident on NANAE when Joe Doll got hit. You have nothing to teach me about joe-jobs.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Blu ([EMAIL PROTECTED]): If my relay server (not open, but relay for customers) has no means to verify recipients, what to do when the destination server rejects that mail already accepted by my server?. Bounce. (Implicit assumption that you have no option but to accept forged-sender spam noted without further comment.) Well, you will increasingly find your MTA put on a teergrube this chump list, if it keeps doing that. I'm not telling you what to do; I'm just predicting what's going to happen. In your shoes, out of self-interest, I'd work at making my system behave like that as little as possible. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 05:32:17PM -0700, Rick Moen wrote: Was there a particular part of the immediately preceding reference to SPF that you didn't get, or was it the concept as a whole? I get the concept of vaporware. Seen a lot of it over the years. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): On Thu, Jun 03, 2004 at 05:32:17PM -0700, Rick Moen wrote: Was there a particular part of the immediately preceding reference to SPF that you didn't get, or was it the concept as a whole? I get the concept of vaporware. Seen a lot of it over the years. Sorry to hear about your sysadmin shortage, then. -- Cheers, Rick MoenBu^so^stopu min per kulero. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
In article [EMAIL PROTECTED] you wrote: Are you suggesting then, that we should not relay mail at all?, not even to/from our customers? If you relay mail from your customers, you have to deliver them their bounces if they spam. If you relay to your customers you better make sure the backup mx is trying to pipeline the mail to the primary and also forward the reject in case of spam or inapropriate destination. But thats quite normal mail setup, nowadays. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess - recipients
hi ya blu On Thu, 3 Jun 2004, Blu wrote: I agree, but it was suggested that any mail server should reject spam at SMTP time, and not bounce it at all. yupp ... best to do at smtp time If my relay server (not open, but relay for customers) has no means to verify recipients, what to do when the destination server rejects that mail already accepted by my server?. make it part of your overall services and policy, that you require a list of authorized users .. if you dont know about [EMAIL PROTECTED] than you will consider it a forged acct - you now have a list of all valid email accounts and any unknown address is rejected/bounced/fried/devnulled ( the users does NOT have to have a shell acct ... ( gazillion ways to do this - you reject unknown users on incoming email addressed to joe - you reject outgoing mail from joe ( ez to do with wireless laptops ) - and if joe is using a borrowed laptop from the spouse or sitting at a different office pc ... humm .. more isssues Bounce. back. c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
Incoming from Michael Stone: It's not misbehaving to generate a bounce message. Glad I could clear that up. s/bounce/valid bounce/ You're welcome. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
While I am sure finding out whose is bigger is exciting to you. I feel comfortable in speaking for the rest of the list when I say this thread has become WAY OT. Please mark it as such (in the subject) or take your discussion elsewhere. Thanks On Thu, 03 Jun 2004 at 09:11:57PM -0400, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): On Thu, Jun 03, 2004 at 05:32:17PM -0700, Rick Moen wrote: Was there a particular part of the immediately preceding reference to SPF that you didn't get, or was it the concept as a whole? I get the concept of vaporware. Seen a lot of it over the years. Sorry to hear about your sysadmin shortage, then. -- Cheers, Rick MoenBu^so^stopu min per kulero. [EMAIL PROTECTED] -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Thu, 3 Jun 2004, Kjetil Kjernsmo wrote: On torsdag 3. juni 2004, 20:53, Alvin Oga wrote: you have to post process your emails after you already received it. ...and then it is a bit late to bounce, isn't it...? i typically dont need to post process... i never got the spam post processing is for the birds in my limited world of 10,000+ mails per day ... most of which are spam - the original posts spam assassin didnt reject the incoming spam to undisclosed recepient - once they validate the email addy is good, you're promptly added to a new more expensive spam list - receiving spam is a bad thing c ya alvin
Re: Unusual spam recently - hummm - postprocess
On Jun 3, 2004, at 3:07 PM, Alvin Oga wrote: post processing is for the birds in my limited world of 10,000+ mails per day ... most of which are spam - the original posts spam assassin didnt reject the incoming spam to undisclosed recepient - once they validate the email addy is good, you're promptly added to a new more expensive spam list - receiving spam is a bad thing My mail system has a number of users, and I prefer to let the recipient decide what is spam. The question was really about the empty spams that are showing up in the last month or so, and what they are intended for. Weather it was a prelude to an MTA exploiting worm strike, or just spammers assessing the value of their spam lists before using them to deliver their spamloads. My content filtering mostly works. It catches over 99% of spam and I have only had 1 false positive, and I think I will stick with it. Some list servers such as yahoogroups (May it rot in pieces) have the annoying behavior of deactivating your subscription on hard bounces from MTAs so whenever a list I am subscribed to with lax attachment policies gets a worm, and I hard bounce it with mime-header-checks, I get deactivated. So this is just one example of hard bouncing spam not being a great system wide policy right now (Unless you don't like your users :P).
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 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 - postprocess
Quoting Michael Stone ([EMAIL PROTECTED]): Yeah, big difference. If the spam is going through a relay, the relay will send the same bounce and the same person will get the bounce message. Oh, oh! jumps up and down Gee, I guess that relay should have rejected the spam instead of relaying it, right? Then, it wouldn't feel a compulsion to issue a completely inappropriate bounce [sic] message to a forged sender. Do I win a prize, or was that just a qualifying round, and the real questions, that actually require thinking, will come later?
Re: Unusual spam recently - hummm - postprocess
On Thu, Jun 03, 2004 at 04:34:44PM -0700, Rick Moen wrote: Quoting Michael Stone ([EMAIL PROTECTED]): Yeah, big difference. If the spam is going through a relay, the relay will send the same bounce and the same person will get the bounce message. Oh, oh! jumps up and down Gee, I guess that relay should have rejected the spam instead of relaying it, right? Then, it wouldn't feel a compulsion to issue a completely inappropriate bounce [sic] message to a forged sender. Do I win a prize, or was that just a qualifying round, and the real questions, that actually require thinking, will come later? Are you suggesting then, that we should not relay mail at all?, not even to/from our customers? Blu.
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
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 - 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 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, 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 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, 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 - 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
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 - 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
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 - 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
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 - 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
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
