Re: spoofing email addresses
On 27-mei-04, at 20:51, Vernon Schryver wrote: The vast majority of the spam that sender validating systems might block after they have been installed in most SMTP clients 5 or 10 years from now is rejected today at any organization that really cares about spam using any of various tactics including DNS blacklists (e.g. the CBL or the so called "dynamic IP" lists) and greylisting. I'd say "back this up" but then we're once again having one of these unproductive spam discussions. Why don't we all do this on our personal favorite anti-spam list and revist the issue here only when there is a pertinent draft in last call? One last remark: block port 25 This is evil for several reasons: 1. blocking ports reduces the functionality of the internet 2. doing work per-packet rather than per-session is inefficient (especially considering that only a small fraction of all packets is email to begin with) 3. requiring others to clean up their act rather than do something yourself is ineffective ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> From: [EMAIL PROTECTED] > > "The people who claim that something can't be done shouldn't get in the > > way of the people doing it." > > I didn't say it *cant* be done. I said there were known problems that any > successful solution would have to address. Another response is to point out that all of the sender validating systems are today only proposals that can be seen as getting in the way of effective tactics. The talkers trying to get in the way of the doers are, as usual, those who endless prescribe spam solutions that they themselves have not thought out, not to mention documented, tested, or deployed. The vast majority of the spam that sender validating systems might block after they have been installed in most SMTP clients 5 or 10 years from now is rejected today at any organization that really cares about spam using any of various tactics including DNS blacklists (e.g. the CBL or the so called "dynamic IP" lists) and greylisting. Essentially all of the spam that any sender validating system might someday block after large outfits like Comcast have installed validating code on their SMTP clients and servers would be blocked today at the source if those same outfits would block port 25 for all types of IP service except the one that draft-klensin-ip-service-terms-01.txt calls "Full Internet Connectivity." That is because current spam that would be blocked by sender validating comes "trojan proxies." The current state of the art in spam defenses reject more than 99% of spam with less than 1% false positives (or variations of those numbers such as 95% and 0.1%). No one who is actually do anything about spam is content with those numbers or confident that new tactics will not be needed, but please don't tell the experts who don't know the difference betwee an SMTP rejection and a bounce, lest they be encouraged to tell us some more what we really should be doing. As usual, the usual suspects who might someday get around to reading an RFC, any RFC, tell us that The Final Ultimate Solution to the Spam Problem is just around the corner. Their Finual Ultimate Solution is waiting for the obstructionists to get out of the way of those who will realsoonnow write the FUSSP RFC. Of course, the usual suspects can't be bothered to come down from Mt. Olympus to write a I-D or learn the relationship between I-Ds and RFCs. They don't care about the differences among documenting, testing, or deploying, or the chasm between practice and sidewalk superintendent theory. Probably the best response is to send people to the MADID mailing list. I've often said that the IETF is well served by working groups that do no more than absorb the energies of standards committee goers. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
On Thu, 27 May 2004 18:23:17 +0200, Iljitsch van Beijnum said: > There is also the possibility of blacklisting known bad credentials. Anybody who's had to get themselves out of 3,000 private blacklists, and anybody who's had to fight with places that were blackholing the 69/8 address space, knows that private blacklists are a bad idea. And nobody seems to want to trust anybody to run a public blacklist to everybody's satisfaction. Consider that we as an industry haven't even figured out how to pick an organization to supervise the DNS to everybody's satisfaction. Think about ICANN and "how many TLD's should there be?" and Verisign's "Site Finder". Add in Matt Blaze's adage about "A CA can protect you from anybody they're not accepting money from", and the various jurisdictional issues. Then ask yourself if we're in any position to let *anybody* decide "You can't send/receive email". (Notice, I haven't said it's impossible - I said that we as a community don't know how to do it. There's a big and very important distinction there...) > Yes, spammers can steal credentials, but this is several orders of > magnitude more difficult than just generating a random from address as > can be done today. The question is whether spammers can obtain new > credentials (stolen or otherwise) faster than others can blacklist > them. For user-based credentials this could very well be the case > (although I'm not conceding to that), but for MTA-based credentials it > should be possible to rate limit the obtaining of a new identity such > that spammers can no longer reach critical mass. (I.e., wait a week > before you can use an MTA with a certain address, then spam an hour > before you're blacklisted reduces the amount of spam that can be sent > from an address by a factor 169.) There's two problems with this: 1) Waiting a week probably isn't a sellable to the user community. If you don't believe me, consider how fast people bailed their domain registrations away from a registrar that had a reputation of taking a week to do anything, and going to registrars that promised setup times measured in hours. 2) The assumption that you can catch, verify, and deploy a blacklist for a spammer in an hour is highly suspect, for several reasons: (a) it means that the *effective* TTL of a DNS MX entry is much lower than an hour (as everybody will have to re-fetch at least 2-3 times an hour to verify they're not blacklisted - a once-an-hour update means that on the *average* there will be a 30 minute delay, and up to 59 minutes at worst case). Notice how few software products that use X.509 certs actually implement CRL's *correctly*... (b) "Under an hour" deployment almost certainly implies an automated process to blacklist.. That has "denial of service" written all over it Again, I haven't said it's *impossible* - merely that we've not seen a concrete proposal that actually has the right scaling and uptake characteristics... > "The people who claim that something can't be done shouldn't get in the > way of the people doing it." I didn't say it *cant* be done. I said there were known problems that any successful solution would have to address. Solving the spam problem is like solving global warming - neither is a problem that demonstrably *cant* be done, but both are problems that we don't know how to solve and which don't have anybody actively solving the problem in a production mode (the fact that both are still perceived as a problem is proof that neither is actually being solved). pgpangt26HJPm.pgp Description: PGP signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
Hello Paul , On Wed, 26 May 2004, Paul Vixie wrote: > > > In fact, there isn't any sane way to detect "inconsistent" header > > > information without external hints - this is the reason why there's the > > > SPF proposal, the Yahoo domain-keys proposal, and Microsoft's proposal. > > And MARID. > > and don't forget http://sa.vix.com/~vixie/mailfrom.txt";>MAIL-FROM. I do not see a draft in the ietf process anyplace . Was this ever submitted ? I do notice that several of the other proposal's make mention of this work , But in none of them do they mention it as a draft or other ietf work . Any plans to submit it as a draft . Tia , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkEngineer | 3542 Broken Yoke Dr. | Give me Linux | | [EMAIL PROTECTED] | Billings , MT. 59105 | only on AXP | +--+ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
On 27-mei-04, at 16:56, [EMAIL PROTECTED] wrote: the proposals aren't even a workable solution to the real problem (I've yet to see a proposal that works if the spammers start utilizing zombie machines that snarf the already-stored credentials of the user to send mail) It amazes me how many people are eager to declare defeat on the spam problem. Regardless of anything else, having authenticated mail allows whitelisting. If credentials are compromised they're simply removed from the whitelist. This should work well for all non-huge whitelists. There is also the possibility of blacklisting known bad credentials. Yes, spammers can steal credentials, but this is several orders of magnitude more difficult than just generating a random from address as can be done today. The question is whether spammers can obtain new credentials (stolen or otherwise) faster than others can blacklist them. For user-based credentials this could very well be the case (although I'm not conceding to that), but for MTA-based credentials it should be possible to rate limit the obtaining of a new identity such that spammers can no longer reach critical mass. (I.e., wait a week before you can use an MTA with a certain address, then spam an hour before you're blacklisted reduces the amount of spam that can be sent from an address by a factor 169.) "The people who claim that something can't be done shouldn't get in the way of the people doing it." ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
On Wed, 26 May 2004 15:00:00 MDT, Vernon Schryver <[EMAIL PROTECTED]> said: > I don't see any of those proposals and their competitors as sane. Oh, I wasn't addressing whether the proposals were workable, merely listing proposals motivated by the fact that verifying the legitimacy of a sending machine is difficult. As you correctly note below, the proposals aren't even a workable solution to the real problem (I've yet to see a proposal that works if the spammers start utilizing zombie machines that snarf the already-stored credentials of the user to send mail) > Some of them, such as SPF, do not even meet their own design goals > as stated informally by their advocates. Others such as domain-keys > do not seem to do anything that is not already done by SMTP-TLS, despite > the goals in the I-D that seem to be closer to S/MIME. None of them > have much to do with spam, but only with a currently popular mode of > attack used by spammers. None have any hope of affecting even that > particular attack mode for years, because none can have any significant > effect until deployed on most SMTP clients. Many seem to be based on > insufficient familiarity with the nature of SMTP (e.g. SPF's incredible > source-routing scheme) and the urge to Do Something Now regardless of > actual results. Do you realize how *difficult* it is to create a workable anti-spam scheme that doesn't run afoul of at least one line item of your "you-might-be" checklist? :) (Thanks for writing it, BTW - I've decided it's the canonical answer to the question "Why is stopping spam so hard?") pgpZqY6aaLdid.pgp Description: PGP signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
> > In fact, there isn't any sane way to detect "inconsistent" header > > information without external hints - this is the reason why there's the > > SPF proposal, the Yahoo domain-keys proposal, and Microsoft's proposal. > > And MARID. and don't forget http://sa.vix.com/~vixie/mailfrom.txt";>MAIL-FROM. -- Paul Vixie ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
