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 HREF=http://sa.vix.com/~vixie/mailfrom.txt;MAIL-FROM/A. -- Paul Vixie ___ 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
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
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 HREF=http://sa.vix.com/~vixie/mailfrom.txt;MAIL-FROM/A. 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 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
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 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
RFC 3778 on The application/pdf Media Type
A new Request for Comments is now available in online RFC libraries. RFC 3778 Title: The application/pdf Media Type Author(s): E. Taft, J. Pravetz, S. Zilles, L. Masinter Status: Informational Date: May 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 14 Characters: 29891 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-zilles-pdf-03.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3778.txt PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3778.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
