Re: power in Korea..
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] write s: >>Lest someone get a nasty surprise by believing everything you read >>on the Internet, if you are staying in the IETF hotel, click through >>from the IETF meeting accommodation page, follow the instructions >>to find the Lotte Seoul, click "rooms" and then "standard and deluxe >>rooms". There you will find the interesting statement: >> >>- Voltage in Main Buliding rooms is 110v. New Wing rooms is 220v. > > the above description is correct. my room is in main building and all > outlets are 110V, US/JP style. > > now, the question is, how to plug in my rental CDMA-with-SIM > phone charger (which has round-shaped pins like european > countries) :-) i found shape changers behind the TV set > so i'm using it (charger is 100-220V capable). > I had the same problem, so I just asked at the front desk -- they gave me a round->flat converter. The outlet surprise I've run into is British-style outlets in the hallways. If you have converters for such outlets, bring them. --Steve Bellovin, http://www.research.att.com/~smb
Re: power in Korea..
>Lest someone get a nasty surprise by believing everything you read >on the Internet, if you are staying in the IETF hotel, click through >from the IETF meeting accommodation page, follow the instructions >to find the Lotte Seoul, click "rooms" and then "standard and deluxe >rooms". There you will find the interesting statement: > >- Voltage in Main Buliding rooms is 110v. New Wing rooms is 220v. the above description is correct. my room is in main building and all outlets are 110V, US/JP style. now, the question is, how to plug in my rental CDMA-with-SIM phone charger (which has round-shaped pins like european countries) :-) i found shape changers behind the TV set so i'm using it (charger is 100-220V capable). [EMAIL PROTECTED] in seoul
places to visit
if you are looking for computers/gadgets: - technomart (Gangbyeon st. on line #2) - yongsan electric town (Yongsan st. on line #1) if you are looking for korean books: - books libro (north-east corner from lotte hotel/good selection of japanese manga translated to korean) - kyobo bookstore (near Kwanghwamun on line #5) - youngpoon bookstore (near Jonggak st. on line #1) i'm looking for musical instruments shops (bookshops do carry sheet music but i could not find what i have been looking for). if any of you have suggestion please drop me a note. tnx. itojun
Flayers among us
<>
RE: power in Korea..
FWIW, I'm roaming with my U.S. AT&T (AWS) SIM just fine here in Seoul. It took less than 5 minutes to pick up the phone at the airport with a pre-reservation. At 04:36 PM 2/27/2004, Joel Jaeggli wrote: t-mobile usa doesn't appear to have a roaming agreement with anyone. t-mobile germany has one with sk-telecom... It really continues to annoy me that the US carries can continue to bung up international roaming like they do. joelja On Thu, 26 Feb 2004, Adam Roach wrote: > > -Original Message- > > From: Aaron Falk [mailto:[EMAIL PROTECTED] > > > > Has anybody tried this kind of trick (putting the SIM in > > another phone) > > with a T-mobile sim? I know that T-mobile binds the phone to the sim > > but don't know if they bind the sim to the phone. > > > > --aaron > > > > As of three years ago, they did not. On the other hand, > my research so far has failed to turn up a roaming partner > for T-Mobile USA in Korea, so I don't think it will do > much good. > > /a > -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Travel from Inchon Airport to Best Western "New Seoul" hotel
Eric Burger wrote: Best bet is KAL Airport Limousine (actually, it's a bus). Tickets are W12,000. You can buy them in the arrivals hall (just before the exits) or on the bus. Bus is cash only. Stop 4B or 11A (depending on your arrival airline) http://www.airport.or.kr/Eng/transportation/bus.jsp Instructions for people staying in New Seoul: Use the same KAL Airport Limousine (#1). The first stop is Koreana Hotel. Best Western is just across the street (but don't try to cross ;-)). Alexey
nbearnote: you're infected...
Whoever is at the IETF meeting and has a machine named nbearnote (218.37.225.246) -- it's banging on my NetBIOS ports. Admittedly, this isn't going to be productive for whatever worm is doing this, since I don't run Windows, but that sort of thing can mess up the wireless. --Steve Bellovin, http://www.research.att.com/~smb
Re: Principles of Spam-abatement
Vernon Schryver <[EMAIL PROTECTED]> wrote: >> From: John Leslie <[EMAIL PROTECTED]> > >> But I, at least, am thinking in terms of an implementation where we >> notify the SMTP-sending-server during the SMTP session, with a message >> including a URL for more information. IMHO, this would tend to converge >> to a situation where end-users understood the issue -- and learned to >> route around it. ;^) > > Where is the business of the main IETF mailing list in that suggestion? That statement -- outlining my personal thinking -- was intended to solicit consensus on Iljitsch's principle from Dave Crocker and/or those who think like him. (I know most people have given up on ever finding consensus from Dave, but I'm a slow learner...) > It is already a de facto standard. (Most people, when they say "de facto standard", mean something already done by a strong majority. But, of course, that's not what the words mean, so I won't argue your usage.) I'm frankly not concerned whether that practice is endorsed as a standard. > Many and probably most well run SMTP servers include an appropriate > message in their 5yz rejection messages when spam detection is the > issue. Today an appropriate message is often a URL. Agreed. Enough people are doing it that the idea will surely spread. Even the dinosaurs (cable companies and incumbent phone companies) will catch on eventually. > There are details that could be officially standardized such as formats > that MUAs could more easily recognize and present to end users. The > bounces generated by the near-end MTA after a failed SMTP session are > incomprehensible to many people. Some MTAs (e.g. Hotmail's when I last > checked) include random text in their session transcripts apparently > drawn from random SMTP sessions during that last several hours. All items which I'd be happy to see discussed in MARID. > However, this sort of standardization seems more appropriate for some > SMTP WG or the ASRG than here. There is no MARID mailing-list yet, so we're stuck here for a few more days. (ASRG is not an IETF group.) In the meantime, I'm trying to solicit consensus -- no matter how "rough" -- on principles of spam abatement, not details of its implementation. -- John Leslie <[EMAIL PROTECTED]>
RE: power in Korea..
t-mobile usa doesn't appear to have a roaming agreement with anyone. t-mobile germany has one with sk-telecom... It really continues to annoy me that the US carries can continue to bung up international roaming like they do. joelja On Thu, 26 Feb 2004, Adam Roach wrote: > > -Original Message- > > From: Aaron Falk [mailto:[EMAIL PROTECTED] > > > > Has anybody tried this kind of trick (putting the SIM in > > another phone) > > with a T-mobile sim? I know that T-mobile binds the phone to the sim > > but don't know if they bind the sim to the phone. > > > > --aaron > > > > As of three years ago, they did not. On the other hand, > my research so far has failed to turn up a roaming partner > for T-Mobile USA in Korea, so I don't think it will do > much good. > > /a > -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: Principles of Spam-abatement
> From: John Leslie <[EMAIL PROTECTED]> > ... >But I, at least, am thinking in terms of an implementation where we > notify the SMTP-sending-server during the SMTP session, with a message > including a URL for more information. IMHO, this would tend to converge > to a situation where end-users understood the issue -- and learned to > route around it. ;^) Where is the business of the main IETF mailing list in that suggestion? It is already a de facto standard. Many and probably most well run SMTP servers include an appropriate message in their 5yz rejection messages when spam detection is the issue. Today an appropriate message is often a URL. There are details that could be officially standardized such as formats that MUAs could more easily recognize and present to end users. The bounces generated by the near-end MTA after a failed SMTP session are incomprehensible to many people. Some MTAs (e.g. Hotmail's when I last checked) include random text in their session transcripts apparently drawn from random SMTP sessions during that last several hours. However, this sort of standardization seems more appropriate for some SMTP WG or the ASRG than here. Vernon Schryver[EMAIL PROTECTED]
Re: Principles of Spam-abatement
Dave Crocker <[EMAIL PROTECTED]> wrote: > > The difference is that there are practicalities of implementation and > use that we have to anticipate. This falls under the unfortunate > reality that the real-world is not conducted so carefully. I have great respect for Dave's viewpoint on that issue. But I do think there's a principle here that doesn't depend upon the implementation: that silently dropping a false-positive _does_ create problems as perceived by the end users -- and that those problems would be significantly reduced if the innocent sender of the false-positive email were notified of the failure to deliver. > On the average, user-level Internet mechanisms need to be pretty > simple and straightforward, if they are to be successful. Omigosh yes! I've taken far too many support calls: "Is the Internet down?" to think otherwise... But I, at least, am thinking in terms of an implementation where we notify the SMTP-sending-server during the SMTP session, with a message including a URL for more information. IMHO, this would tend to converge to a situation where end-users understood the issue -- and learned to route around it. ;^) -- John Leslie <[EMAIL PROTECTED]>
MARID-BoF
Ted Hardie <[EMAIL PROTECTED]> wrote: > > http://www.ietf.org/ietf/04mar/marid.txt In particular: ] Thursday, March 4 at 0900-1130 ] ... ] Current Proposals (1 hour together) ]MTAMARK - draft-stumpf-dns-mtamark-01.txt MTAMARK (17 pages) proposes DNS records in in-addr.arpa to indicate that a particular IP address (or range) is or is not intended to be a Mail-Transfer-Agent. The details of what record formats to use, IMHO, deserve to be discussed by an IETF Working Group. This proposal depends on the authenticity of the in-addr.arpa delegations; thus poorly-maintained regions of in-addr.arpa will necessarily authorize too much or too little. Further discussion of how to determine which regions are well-maintained will be needed, although clearly that can be a local decision. I would suggest the possibility of specifying a similar mechanism not under in-addr.arpa -- but instead under the domain records of any domain one might wish to trust -- showing whether that region of in-addr.arpa is considered well-maintained and trustworthy. ]DRIP - draft-brand-drip-02.txt DRIP (21 pages) proposes adding A(ddress) records for named subdomains to indicate which IP addresses are assigned to SMTP servers authorized to send mail for that domain. This proposal gives a far better presentation of how to implement for IPv6. At first blush, it seems easier to classify well-behaved domains that well-maintained regions of in-addr.arpa; but IMHO the problems are similar, and the implementation of DRIP within MTA software seems more complicated. In any case, I would suggest a parallel specification of vouching for the behavior of domains, under the domain records of any domain one might choose to trust. ]RMX - draft-danisch-dns-rr-smtp-03.txt RMX (35 pages) proposes adding RMX records to return various kinds of methods to determine whether a particular SMTP sender is authorized to send mail for particular email addresses. Adding new DNS record types, of course, is fatal for quick deploying. Thus RMX also presents an alternative to accomplish this with TXT records. IMHO, this scheme is even more complicated, and solves less of the problem. ]DMP - draft-fecyk-dmp-01.txt DMP (36 pages) proposes adding DMP records to identify computers authorized to send SMTP email in the name of a domain, using TXT records in a named subdomain. I'm getting bleary-eyed -- I'm no longer sure which of these proposals is most complicated. This one, at least, appears to present complete details sufficient to implement from. However, I doubt that forcing email with particular From addresses to use a limited set of servers will be considered acceptable. ]SPF - draft-mengwong-spf-00.txt SPF introduces a language for "email-related declarations" in DNS. Messages which do not satisfy the "description" advertised are considered "not legitimate." SPF specifically allows caching the DNS replies. Caching is a general problem in DNS, in that the controls on expiring DNS information are weak. IMHO, the weaknesses of DNS in withdrawing no-longer-valid entries MUST be a charter item for MARID. ]FSV - draft-levine-fsv-00.txt FSV (7 pages -- thanks, John!) proposes both "block" and "factored" DNS records, as A(ddress) records under a _fsv subdomain of the "sending" domain, returning a code for a valid SMTP sendor address. This, IMHO, is subject to the usual comments about end-users accepting limits on which SMTP servers they may use. >> The BoF will explicitly consider how DNS-based MTA authentication >> mechanisms would be implemented and deployed, and it will consider >> the impact on the overall DNS infrastructure of this deployment. In general, I predict a very boring BoF if only those who read every page of every proposal are allowed to speak. ;^) IMHO, the central issue is the level of trust to be given to a particular SMTP sender (by IP address) not well-known to the SMTP receiver. I published my thoughts on this in http://www.jlc.net/whitecap.html (Although it's obvious how to recast this into a DNS-dependent proposal, I do not intend to do so.) I'd like to add a warning to limit the time you spend listening to proposals that the speaker may describe as "the only way" to "cure the spam problem". There is, however, no room for question that _some_ IETF Working Group with a charter relating to spam-abatement is justified. I hope those present will agree that a charter allowing discussion of all these drafts is appropriate. -- John Leslie <[EMAIL PROTECTED]>
Re: Principles of Spam-abatement
On Fri February 27 2004 11:26, John Leslie wrote: > Dave Aronson <[EMAIL PROTECTED]> wrote: > > On Fri February 27 2004 09:29, Tom Petch wrote: > >> If sending 1M messages got back a 1% response saying 'you failed' > >> with no clue as to which 1% failed, we might cut down on the spam. [...] > > What incentive do the 10K new DSNs give him, > > to mend his evil ways, or even just to scale back? > >No incentive to "mend his evil ways"; but a cost which may reduce > the total amount of spam. (Recall that many believe a one-cent-per- > spam cost would essentially eliminate the problem.) Again, I don't see how this imposes a non-negligible new cost on him. He's probably already receiving tens of thousands of now-typical DSNs, not to mention out-of-office notes, angry replies, etc. The "this looks like spam" DSNs therefore would probably not incur significant additional normal email processing costs (bandwidth, disk, CPU, etc.). He has no need to do anything with them, so they don't incur any, let alone significant, additional special processing costs. Indeed, if they're readily identifiable as such, they can easily just be filtered out, so they don't even take his "human bandwidth" (attention). (Gee, sounds just like fighting spam!) Where's the beef? > > Indeed, it seems to me that if anything, it helps him see what > > does or does not work against spam filters, so he can tune his > > filter-evasion strategies. > >I claim that benefit is minimal -- spammers have other ways of > gathering the data to tune their filter-evasion. Fair enough. >The benefit to the false-positive-sender, OTOH, is major. Oh, agreed, absolutely. I understand how this mechanism would allow people to tighten their spam filters, which could cut down on the spam that person receives. I'm just arguing over how the spammer receiving X number of "bugger off, spambreath!" DSNs per Y spams sent (whether using the original 1% or what), is going to "cut down on the spam" (which I am interpreting as "the spam that spammer sends" or possibly spam in general). > S/he knows that the email never got through, and can use one of > the many available out-of-band methods to communicate the message. ...assuming that an OOB method has been established already, or is given in the DSN. (E.g., "this looked spam; if it really was legit and you want to contact me, call me at 1-900-SPAMSUX".) -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.
Re: DIAMETER
Thank You - Original Message - From: "David Frascone" <[EMAIL PROTECTED]> To: "Giacomo Pisano" <[EMAIL PROTECTED]> Cc: "IETF Discussion" <[EMAIL PROTECTED]> Sent: Friday, February 27, 2004 5:40 PM Subject: Re: DIAMETER > http://www.ietf.org/html.charters/aaa-charter.html > http://www.diameter.org > > -Dave > > > On Friday, 27 Feb 2004, Giacomo Pisano wrote: > > I'd like to receive info about the topic in the subject. > > > > > > Giacomo Pisano > -- > David Frascone > > Wait! Clinton's "How to Serve Taxpayers" -- it's a COOKBOOK!
Re: DIAMETER
http://www.ietf.org/html.charters/aaa-charter.html http://www.diameter.org -Dave On Friday, 27 Feb 2004, Giacomo Pisano wrote: > I'd like to receive info about the topic in the subject. > > > Giacomo Pisano -- David Frascone Wait! Clinton's "How to Serve Taxpayers" -- it's a COOKBOOK!
Re: Principles of Spam-abatement
Dave Aronson <[EMAIL PROTECTED]> wrote: > > On Fri February 27 2004 09:29, Tom Petch wrote: > >> If sending 1M messages got back a 1% response saying 'you failed' >> with no clue as to which 1% failed, we might cut down on the spam. > > Maybe I just have too much blood in my caffeine stream, ;^) > but I don't see the connection. J. Random Spammer spews 1M spams, > and receives back (assuming he used a valid sending address) Yes, let us assume the actual sender gets the "spam-refused" error. > 10K "this looked like spam" DSNs, in addition to the usual load of > angry replies, removal requests, "no such user", "no such domain", > "over quota", etc., plus the occasional purchase. What incentive do > the 10K new DSNs give him, to mend his evil ways, or even just to > scale back? No incentive to "mend his evil ways"; but a cost which may reduce the total amount of spam. (Recall that many believe a one-cent-per- spam cost would essentially eliminate the problem.) > Indeed, it seems to me that if anything, it helps him see what does or > does not work against spam filters, so he can tune his filter-evasion > strategies. I claim that benefit is minimal -- spammers have other ways of gathering the data to tune their filter-evasion. The benefit to the false-positive-sender, OTOH, is major. S/he knows that the email never got through, and can use one of the many available out-of-band methods to communicate the message. Iljitsch's point was that the false-positive problem is much less serious if senders of non-spam learn their email was discarded as spam. (I'd rather not speculate on whether the minimal benefit to the spammer is greater or less than the admittedly-minimal cost.) -- John Leslie <[EMAIL PROTECTED]>
Re: Principles of Spam-abatement
At 9:29 AM -0500 02/27/2004, John Leslie wrote: While I am _very_ sympathetic to the need to limit the discussion, I really don't see how anything useful can be accomplished if the chair rules "principles of spam-abatement" to be irrelevant. Perhaps this would be clearer: The BoF proposes that the IETF take on a particular engineering task, with a specific scope and an intended effect. It is within the purview of the BoF to discuss whether that is the right scope, whether the intended effect is a good idea, and so on. General discussion of the "principles of spam-abatement" , however, is out of scope (largely because such discussions tend to be non-terminating and will swamp the more focused engineering discussion). But the context of the "is this the right scope, and a good idea" no doubt includes the participants understandings of those principles. regards, Ted Hardie
DIAMETER
I'd like to receive info about the topic in the subject. Giacomo Pisano
DIAMETER
I'd like to receive info about the topic in the subject. Giacomo Pisano
Re: Principles of Spam-abatement
On Fri February 27 2004 09:29, Tom Petch wrote: > If sending 1M messages got back a 1% response > saying 'you failed' with no clue as to which 1% failed, we might cut > down on the spam. Maybe I just have too much blood in my caffeine stream, but I don't see the connection. J. Random Spammer spews 1M spams, and receives back (assuming he used a valid sending address) 10K "this looked like spam" DSNs, in addition to the usual load of angry replies, removal requests, "no such user", "no such domain", "over quota", etc., plus the occasional purchase. What incentive do the 10K new DSNs give him, to mend his evil ways, or even just to scale back? Indeed, it seems to me that if anything, it helps him see what does or does not work against spam filters, so he can tune his filter-evasion strategies. -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.
Re: Principles of Spam-abatement
Tom Petch <[EMAIL PROTECTED]> wrote: > From: Dave Crocker <[EMAIL PROTECTED]> > If we can communicate the fact that a message is discarded because it was categorized as spam back to the sender without adverse side >> >> unfortunately, that act of communication _is_ the adverse side >> effect. it tells the spammer that yours is an active, responsive >> email account. > > So send it back from a different e-mail address, with headers which > disguise its real origin. It is not obvious to me that there is any way to do that. Nothing in the (SMTP) envelope info is trustworthy except the IP address of the SMTP sender. Using _anything_ other than that IP address (which isn't even required to accept email at all) will likely generate _more_ "spam". Thus I'd like a Principle to the effect of: " Errors returned after the close of the SMTP transaction are likely " to go to (and confuse) an innocent party; thus such errors should " be deprecated for any email identified as spam. > One reason why spam works is that it is so cheap to send 1M messages > that even if 99.99% fail to reach a destination, the operation is still > a success. If sending 1M messages got back a 1% response saying 'you > failed' with no clue as to which 1% failed, we might cut down on the > spam. There may be a Principle there, about any "cost" imposed upon spammers tending to reduce the spam problem... -- John Leslie <[EMAIL PROTECTED]>
Re: Principles of Spam-abatement
From: Dave Crocker <[EMAIL PROTECTED]> To: John Leslie <[EMAIL PROTECTED]> Cc: Iljitsch van Beijnum <[EMAIL PROTECTED]>; IETF Discussion <[EMAIL PROTECTED]> Date: 27 February 2004 07:38 Subject: Re: Principles of Spam-abatement >John, > >>> If we can communicate the fact that a message is discarded because it >>> was categorized as spam back to the sender without adverse side > >unfortunately, that act of communication _is_ the adverse side >effect. it tells the spammer that yours is an active, responsive >email account. > So send it back from a different e-mail address, with headers which disguise its real origin. One reason why spam works is that it is so cheap to send 1M messages that even if 99.99% fail to reach a destination, the operation is still a success. If sending 1M messages got back a 1% response saying 'you failed' with no clue as to which 1% failed, we might cut down on the spam. Tom Petch >-- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA
Re: Principles of Spam-abatement
Ted Hardie <[EMAIL PROTECTED]> wrote: > > Please note that the BoF scheduled for Korea, MARID, has a > very specific topic and that discussion of other spam-related > issues is not appropriate for that session. While I am _very_ sympathetic to the need to limit the discussion, I really don't see how anything useful can be accomplished if the chair rules "principles of spam-abatement" to be irrelevant. Regardless, "principles of spam-abatement" don't need to be _discussed_ at this BoF in order to "enlighten" it. Thus, if Ted meant to indicate such principles shouldn't be discussed here, I respectfully disagree. > At 3:59 PM -0500 02/26/2004, John Leslie wrote: >> I strongly recommend gathering some principles of spam-abatement to >> enlighten the spam BOF at IETF-59. (I'd be happy to edit such a >> document, but it might be better to chose someone who will attend >> IETF-59... >> >> Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: >>> >>> If we can communicate the fact that a message is discarded because >>> it was categorized as spam back to the sender without adverse side >>> effects, then occasional false positives aren't much of a problem. -- John Leslie <[EMAIL PROTECTED]>
Re: Principles of Spam-abatement
Dave Crocker <[EMAIL PROTECTED]> wrote: > >>> If we can communicate the fact that a message is discarded because it >>> was categorized as spam back to the sender without adverse side > [ effects, then occasional false positives aren't much of a problem.] > > unfortunately, that act of communication _is_ the adverse side > effect. it tells the spammer that yours is an active, responsive > email account. I must disagree. Iljitsch stated it precisely and well: "the fact that a message is discarded as spam" need not give any information about whether the recipient is an active email account -- least of all "responsive". -- John Leslie <[EMAIL PROTECTED]>
Re: digital signature request
Folks, I think this thread has deviated enough from its original intent that the best place to continue it is on the ASRG list -- there's no point in bothering the entire IETF with yet another anti-spam discussion. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 25 February, 2004 04:50 Subject: digital signature request > this is a request for this list to be digitally > signed by the list processor. > > to all list members. if after reading this post > you would like the list processor to digitally > sign all posts please say so (and tell the list > owner) so that the level of interest can be > gauged. thanks. > > i'm making this request because i need a way to > positively id the messages from this list. i'm > spending way too much of my time culling spam from > my real email even though i'm employing the latest > spam filtering tools. please give me the one > simple tool i know of that will allow me to > positively differentiate the mail from this list > from all others - a digital signature. > > signing all list messages won't be detrimental to > list recipients not interested. it will however > allow folks wishing to implement anti-spam > measures around digital signatures to do so. > mailing lists often require that recipients > confirm their email address as an anti-spam > measure for the list. please help list recipients > implement their own anti-spam measures by allowing > the list messages to be positively identified. > > to be clear, this is a limited scope spam > solution, but it works. and it will continue to > work provided the underlying cryptography is sound > (unlike many other anti-spam technologies that are > simply clever hacks in an escalating spam/anti- > spam arms race). > > some folks say that there will be no spam solution > as long as email is free. i say there will be no > spam solution as long as you expect anyone to be > able to send email to you without first proving > they are not a spammer. > > part of finding a solution is to revision what > email is. i argue that email can no longer be a > method of unfettered *initial* contact. once that > is accepted then this solution doesn't seem > painful. i suspect that there won't be a solution > until email is seen from this perspective. as > noted above, mailing lists are essentially > adopting this perspective (to better manage spam > on the list side), it would be helpful if they > took an additional small step that would enable > list recipients to better manage spam on their end > too. > > there's no need for a larger web of trust other > than one that is personally maintained when using > digital signatures to defend against the onslaught > of spam. your personal web of trust (a.k.a. your > keyring) is your unspoofable anti-spam whitelist. > this is where the revisioning of email occurs. > instead of email being the way you initially make > contact with an entity, with digital signatures it > can serve as a reliable communications channel > *once* contact has been established. > > my intention is to implement a procmail recipe at > the mail server level. the procmail recipe will > be used to check incoming mail for whitelisted > digital signatures that have been uploaded from > each individual user. > > mailing lists could use the same recipe, no > messages would be handed over to the listserv > software unless it was signed by a whitelisted > signature. again, this won't stop machines from > being compromised but as soon as a machine is > compromised that entity will be *immediately* > notified by their peers. in the case of a mailing > list *many* people will suddenly know who's > compromised and the list can even have a mechanism > that allows a whitelisted key to be removed once > it becomes compromised. this would also serve the > dual function of indirectly alerting the owner of > the compromised host since they will investigate > why they are no longer receiving list traffic. > > regarding whether to utilize inline or mime GPG, i > say use either. the preferred solution will self- > select over time. it is possible to create a > procmail recipe that can handle both methods. > > Two key benefits of this anti-spam technology: > > 1. it works and will likely continue to work > beyond the foreseeable future > > 2. it can be implemented without the consensus, > from the bottom up > > below are my responses to posts in a few mailing > list threads regarding digital signatures and > spam. please read my responses as they will > likely answer many of the questions that may > result from reading what i wrote above. apologies > to the folks whose comments i'm replying to for > not referencing their names (i didn't have the > time). > > looking forwar
