- Test - lists.nanog.org

is this true or... ?
by Tomas Daniska 30 Mar '03

30 Mar '03

http://www.theinquirer.net/?article=8595 -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.

13 19

OUTAGE: Known Iraq public Internet service
by Sean Donelan 30 Mar '03

30 Mar '03

In the last few hours, all the public Internet hosts I knew were physically in Iraq (i.e. connected through the Iraqi state provider), have stopped responding. I don't know the cause (power failure, telecom failure, physical damage, shutdown by administrator, etc). Of course, this does not mean there are no IP-enabled devices operating within Iraq's physical borders. The Iraq government and military may have private IP networks, not connected to the Internet or connected in ways I don't know about. Likewise the US military and various news media are carrying IP enabled devices in southern Iraq, but I don't know their IP addresses. I also believe in Kurdish controlled areas have seperate Internet connections.

1 1

Re: State Super-DMCA Too True
by Kevin Loch 30 Mar '03

30 Mar '03

----- Original Message ----- From: Jack Bates <jbates(a)brightok.net> Date: Sunday, March 30, 2003 0:22 am Subject: Re: State Super-DMCA Too True > > (Some DSL/cable companies try to charge per machine, and record > the > > machine address of the devices connected.) > > And to use NAT to circumvent this should be illegal. It is theft of > service. The ISP has the right to setup a business model and sell > as it > wishes. Technology has allowed ways to bypass or steal extra > service. > This law now protects the ISP. There will be some ISPs that > continue to > allow and support NAT. If you can tell the difference between NAT and non-NAT traffic you don't need this law. If you can't, the law is completely unenforcable. The same goes for VPN's. So what's the point other than to discourage good business models? KL

1 0

Typo's in DNS, Al Jazeera back online
by Sean Donelan 30 Mar '03

30 Mar '03

In spite of typo's in their DNS records, Al Jazeera's web site has moved to France and back online. Be sure you get the current IP address for aljazeera.net (213.30.180.219). Al Jazeera's name server records are still a mess, and I don't think you can really blame the Pentagon for them aljazeera.net. 15M IN SOA ns3.aljazeera.net. dnsadmin.nav-link.net. ( 2003032802 ; serial 3H ; refresh 1H ; retry 1W ; expiry 15M ) ; minimum aljazeera.net. 15M IN NS ns1sa.navlink.com. aljazeera.net. 15M IN NS ns3.aljazeera.net. aljazeera.net. 15M IN MX 10 mail.aljazeera.net. aljazeera.net. 15M IN A 213.30.180.219 The NS record for ns1sa.navlink.com appears to be a typo, no such server exists. I suspect the correct NS is ns1sa.nav-link.net (217.26.192.26), which is not responding or the NS in the NSI registery aljns1sa.nav-link.net (217.26.193.15) which also isn't responding.

1 0

sendmail 8.12.9 available (fwd)
by bmanning＠karoshi.com 30 Mar '03

30 Mar '03

For your edification and weekend enjoyment... > -----BEGIN PGP SIGNED MESSAGE----- > > Sendmail, Inc., and the Sendmail Consortium announce the availability > of sendmail 8.12.9. It contains a fix for a critical security > problem discovered by Michal Zalewski whom we thank for bringing > this problem to our attention. Sendmail urges all users to either > upgrade to sendmail 8.12.9 or apply a patch for your sendmail version > that is part of this announcement. Remember to check the PGP > signatures of patches or releases obtained via FTP or HTTP (to check > the correctness of the patches in this announcement please verify > the PGP signature of it). For those not running the open source > version, check with your vendor for a patch. > > We apologize for releasing this information today (2003-03-29) but > we were forced to do so by an e-mail on a public mailing list (that > has been sent by an irresponsible individual) which contains > information about the security flaw. > > For a complete list of changes see the release notes down below. > > Please send bug reports to sendmail-bugs(a)sendmail.org as usual. > > Note: We have changed the way we digitally sign the source code > distributions to simplify verification: in contrast to earlier > versions two .sig files are provided, one each for the gzip'ed > version and the compressed version. That is, instead of signing the > tar file, we sign the compressed/gzip'ed files, so you do not need > to uncompress the file before checking the signature. > > This version can be found at > > ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.gz > ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.gz.sig > ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.Z > ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.9.tar.Z.sig > > and the usual mirror sites. > > MD5 signatures: > > 3dba3b6d769b3681640d0a38b0eba48c sendmail.8.12.9.tar.gz > 19e39c9e9bc8fae288245c546639e1f4 sendmail.8.12.9.tar.gz.sig > 268fc4045ba3eac6dfd9dc95d889ba5f sendmail.8.12.9.tar.Z > 19e39c9e9bc8fae288245c546639e1f4 sendmail.8.12.9.tar.Z.sig > > You either need the first two files or the third and fourth, i.e., > the gzip'ed version or the compressed version and the corresponding > .sig file. The PGP signature was created using the Sendmail Signing > Key/2003, available on the web site (http://www.sendmail.org/) or > on the public key servers. > > Since sendmail 8.11 and later includes hooks to cryptography, the > following information from OpenSSL applies to sendmail as well. > > PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY > SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING > TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME > PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR > COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL > SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE > YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT > AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS ARE NOT LIABLE FOR > ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY. > > > SENDMAIL RELEASE NOTES > $Id: RELEASE_NOTES,v 8.1340.2.132 2003/03/29 14:02:26 ca Exp $ > > > This listing shows the version of the sendmail binary, the version > of the sendmail configuration files, the date of release, and a > summary of the changes in that release. > > 8.12.9/8.12.9 2003/03/29 > SECURITY: Fix a buffer overflow in address parsing due to > a char to int conversion problem which is potentially > remotely exploitable. Problem found by Michal Zalewski. > Note: an MTA that is not patched might be vulnerable to > data that it receives from untrusted sources, which > includes DNS. > To provide partial protection to internal, unpatched sendmail MTAs, > 8.12.9 changes by default (char)0xff to (char)0x7f in > headers etc. To turn off this conversion compile with > -DALLOW_255 or use the command line option -d82.101. > To provide partial protection for internal, unpatched MTAs that may be > performing 7->8 or 8->7 bit MIME conversions, the default > for MaxMimeHeaderLength has been changed to 2048/1024. > Note: this does have a performance impact, and it only > protects against frontal attacks from the outside. > To disable the checks and return to pre-8.12.9 defaults, > set MaxMimeHeaderLength to 0/0. > Do not complain about -ba when submitting mail. Problem noted > by Derek Wueppelmann. > Fix compilation with Berkeley DB 1.85 on systems that do not > have flock(2). Problem noted by Andy Harper of Kings > College London. > Properly initialize data structure for dns maps to avoid various > errors, e.g., looping processes. Problem noted by > Maurice Makaay. > CONFIG: Prevent multiple application of rule to add smart host. > Patch from Andrzej Filip. > CONFIG: Fix queue group declaration in MAILER(`usenet'). > CONTRIB: buildvirtuser: New option -t builds the virtusertable > text file instead of the database map. > Portability: > Revert wrong change made in 8.12.7 and actually use the > builtin getopt() version in sendmail on Linux. > This can be overridden by using -DSM_CONF_GETOPT=0 > in which case the OS supplied version will be used. > > > Instructions to extract and apply the patches for sendmail: > > The data below is a uuencoded, gzip'ed tar file. Store the data > between "========= begin patch ========" and "========= end patch > ==========" into a file called "patch.sm" and apply the following > command: > > uudecode -p < patch.sm | gunzip -c | tar -xf - > > This will give you these files (explanation for each file is on > the left, only "prescan.VERSION.patch" are the files). > > prescan.8.12.8.patch only for 8.12.8, changes version string to 8.12.8p1 > prescan.8.12.patch for 8.12.0 - 8.12.7, does not change version string > prescan.8.11.6.patch only for 8.11.6, changes version string to 8.11.6p2 > prescan.8.11.patch for 8.11.0 - 8.11.5, does not change version string > prescan.8.9.3.patch only for 8.9.3, changes version string to 8.9.3p2 > prescan.8.9.patch for 8.9.0 - 8.9.2, does not change version string > > Apply the appropriate patch to your version of the sendmail source > code (change the version number below to the right one!), e.g., > > cd sendmail-8.12.8/sendmail > patch < prescan.8.12.8.patch > > recompile sendmail, and install the new binary. > > ========= begin patch ======== > begin 644 prescan.tar.gz > M'XL("%)UA#X"`W!R97-C86XN=&%R`.U<?5/;1A/G7_,I%J<%&V3[3CJ],FD? > MIX&!#B84T_:9)\DPPCYC38SD2#(A3]OOWCV]&XSI3(&0<!MF9-W=WN[=[=WN > M3RME&O)HX/IMJTUIVVA/W7@P7KEGHH08C,$*@$JH+JY()+L"&*K&`$R#46*J > MFFD`4)6:^@J0E4>@612[(<#*P%W>[M.8\\G*-T?[_I!?.3`(_%%[L/KRW]/J > M\4]]&'D3[D!G<!EU(NX/+UQOTDE%*)>K(8]#CU]Z_CF$>(F\P`>K;3"CK2;_ > M+//.)K:Z.O1&(V@-H!7.\UXKP):;FYO9^&HJ@9]G$S1#0D'5'-UP=!5:!*EV > M38-6JU4P6=!#$T$F#8CA$-5AQ@*F5%*5$LF:117-,B`I$+VF!1;@[]8J0.UU > MX,<'P>##,7>'NSAO$;R$D^-?=[;3RMG9A+\*9OZ`=X?#$.OJTR"*+]PHYF$] > M:=-SK_:0EX?1`??/XS&VZ77_N_?ZN'^P<[B]NI6TZ'D7/&U5;72P?[A3;;'K > M\<FP;+"`K0-J+G0W"#^YX7#'%VLEM":BYH4W@GZW?R`:=6?QN,<'8]?WH@O1 > MPN>?HCAL='\]V3OM[?RTUSW<[_?ZS>W5S`RG;ABAM&'XP+98D7.K0>*IU&9M > MJBVOMN8,,>>IWEB)&50DUBB#[NR\L$)B.8(C,ZA"K+"5*I=JEF9(;8<1AZK7 > MN:R%)LB8H3`T]*0`X"^Q3.)O#5X,^<CS.1R^P;4XKM5:M-;9A,@[]]T)^$$\ > M%H/V?)@$P0=WC)I`''S@/FQVTBYP:4-(.IVF?J0AE%5@R"?>A0+3R^G9;)1> > M(^__/*N8QM(a)$.XK=LV8RS%S!;$LL4;#1HLU'5W'1G.J:JNB:66[KM*#<UDA" > M3\X!-T0\YB'^B"`,@HM4-=$`:QH?X8>7L)ZJ\3;7`K"_]\VLU1]B@PJEXR"8 > M!/ZYDY779E'(P[!1UW4-]#9M4Q!'!(\BU#P`T;3>W,X;"UFX]R8\G8`F_`"- > M_O[_=DY/FN(D..SV=G*!M43:VZST/>[;C7=D8WOQ/#!-$?(SVQ+,?Z43G\_` > MQYD7AGP"7(a)SN)_=S.?K-CUM;V/<@4[%D0ZY0+*0KS@M<V^DL3I;1'>"9)_C7 > M1*L!\FY.M[8R=C$^+$IUS4;R1ZG&T'//_2#BX/I#2*(<F$WA#*5$G_W8O1+= > M)LO(&(YG;AGO'L]6<NJM=0\.WOQ^JNJZ6+!,I890O`F)9MGO%H7U=5B+3X8- > M2U6`$MIL9APXJ'4\1Z_,D3B57^!QA7V@T++K>YV^AIB_)JRC1$)&H_N;R466 > M8A!5,4AEQ^"-8F`\>&VJQ95/HF3?H!YKJ,?:!OSY)V"@%G.AUR_]D[F]<<=> > MVRHWP++-EC6KG0=Q`)7M5NR@;,(WWKW;*,HP1(@]?\:WBP$L'+IE*(9-*T.W > MF6(2M1PZJB\6JW)TI0IC@9B!C^EXL]'>-=9_-M);QEF,DFQ4[$$8JXK&JAG- > MPB(RGWV)@0>ZQ`?VV(646_TUT]`#:O:</\[**CJ*Y2CN1#Q8>&+*'*8["$5R > MGYIW*!:L9*%VZ895ZJBVHV5N>.'24UVA5GXZ"@OV!JE+\H9OQ<E:_T_C1?.[ > M_6%E'I7+<C2):AUB=5#30L'S:.Q.O3"`G:LI?)<$@96C`B:>'V?N;RV15?LM > M[3H5F"(]Y!+C2M7+S/`)J3=5D6]%TH/3M(K_'P3]WXG_=6)J!?['%@+_$\HD > M_I?X7^)_B?\E_I?X7^)_B?\E_I?X7^+_)X3_)7CZMO`?QKU?)O]+6(G_-%5/ > M\[]$XK]GA?]L,X%1YM)J39\+MW.>R@VVJ.`]M+:?7;^(F:GIT/+Y7B'Q-JRG > M(]!SB'V-(95P,\@V,(8U*V=\6J#-X;RC,#CC^S[ZX9$[2##3ZZ/]TZ/C-Z]V > MT,-_I8BOMHNJ]:<3#(A>`IW#@$\0UFFZC8O(EM8:<U:6<51^&S<AG54:&B$. > MHPZS"KO)12Y#=$1U--O1M6M,QBVAE(61$WNZ@"Y7\"L"="(D,VS[>HQ&OB9` > M]R]PG$ETQ<3C\EO!<28Q%%,E$L?=.X[#0$TQC<I&P1O%-,UG@.,L9BN6SLJA > M6[JI6(8N\[CWF,>EA*'CHVS.!^>%MV9RYR(]T]$Q=BM]:='ETE0NLFGTGZ9R > M\:_?.\51[K]NW)8D+906$CJ$=E#)0K>!F^5'FTLRH0C)%B5J'TWXE,HT[#/" > M_U\J_TL*_$\R_$^H)O&_Q/\2_TO\+_&_Q/\2_TO\+_&_Q/\2_\L\KJ2'P7]V > M6WL@`'@7_C,Q;,[SOTQ+WO^EU)#X[UGA/Z8;M]<(G#;_88=NY->DKH+Y3-CE > M9XCV,)8CIJ,:CJ:7GW2@D"5O]FJ.JE;;YEW?<`2J92AJ]86>M$#[RE_JC?QI > MZ/GQJ)%$T,+3!"-(?M>_C[Z/ALC3GO!8**DDWN/TJ'NR=_I;]_BD=W2SY&W6 > M0[4,79?Z/(a)E*.AOP(]3KX$"]4W^:KP!3W;Z]1CP*F']&K=OY-:F[CA%O&"8C > MY1-JW;[SA5_54;4J0R[DYJ,(HBF,V(O@(3R1%WXS#1?@0WBJ`)'A%F?5/9\6 > MJ%\*(#[^N[[,-A4]?X/S&\"(S+84G:H2(]X[1M1U0]&-RE[!&RRPG\.[OIJI > M&$RM/$=BNF+HFLP1WW#-<QG<=A!ZY[63\2SQDL"`8N1FB4^MA,>\EKG]G0\3 > MWTCMI)DF8CSA)Q?G;9E"S46?X$:#053]SK7L/T5#%!JO>/B!3_CG)J@=UA&: > M7/N>%?W1W5^T8F=Y&C?19<'WMH^I2_7CVBK^>Z#TW]WY/V86^(^(_PN*4E.7 > M[_]*_"?QG\1_$O])_"?QG\1_$O])_"?QG\P12I(D29(D29(D29(D29(D29(D > ?29(D29(D29(D29(D29(D29(D29JCOP%S5E@?`'@``)(D > ` > end > ========= end patch ========== > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (OpenBSD) > > iQCVAwUBPoXFgyGD4bE5bweJAQEk9gQAvhx73sgGCLaUiNkDRKiPECbrDcgn9fH0 > JncwWXpYNlLoVFgk1VHbBTeFqtGwTVXIFUOyQvIwO8Vh53iHbffv/4NZCsZuWwpT > L7v+uCAN0IvYQUZUUvvcJJJsEUkyYzSKCnNewYhFGDmLa1Sx6x59fYw2hfseZ/HK > hjC59XbAdSk= > =t4zn > -----END PGP SIGNATURE----- >

2 1

more sendmail fun.
by Len Rose 29 Mar '03

29 Mar '03

Local root vulnerability in sendmail. See http://www.netsys.com/cgi-bin/displaynews?a=556 which contains links to: http://lists.netsys.com/pipermail/full-disclosure/2003-March/008972.html http://www.netsys.com/library/alerts/sendmail-2003-03-29.txt http://lists.netsys.com/pipermail/full-disclosure/2003-March/008973.html Len

1 0

Re: is this true or... ?
by Steven M. Bellovin 29 Mar '03

29 Mar '03

In message <20030329003124.AAA24442@shell.webmaster.com@whenever>, David Schwar tz writes: > >On Fri, 28 Mar 2003 12:06:56 -0500, blitz wrote: > >>If it is, it reveals how utterly clueless our legislators really >>are.... > > The text I saw talks about a device's "primary purpose". I'm not sure what text you saw. The Texas bill (I posted the URL earlier today) does not speak of "primary purpose". The section Felten warned about (Section 6) criminalizes the following things: manufacture, sale, etc., of a "communications device" with an intent to *either* defraud, *or* conceal origin, destination, etc.; manufacture, sale, etc., of an "unauthorized access divce"; or manufacture, sale, etc., of plans or instructions for such devices with the knowledge that the intent of the end user is illegal. The word "primary" does not occur in the text of the bill, according to both my reading and Acrobat's "find" fucntion. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

2 1

Re: Allegiance telecom boston colo down?
by Dave Israel 28 Mar '03

28 Mar '03

On 3/28/2003 at 16:19:03 -0500, Sean Donelan said: > On Fri, 28 Mar 2003, Dave Israel wrote: > > I seriously doubt that, if a 12-year-old from Nebraska called the NOC > > at AT&T and asked for a list of all their network failures in the past > > two years, the NOC person would feel obliged to spend their time on > > I try to point out when providers are doing a good job. > > AT&T has set up their system so their NOC people don't have to get bogged > down answering phones. AT&T has a very nice news system where you can > read about network issues. AT&T's customer care people post regular > updates about POP problems, circuits down, etc. I suppose if the 12-year > old from Nebraska archived the news system for two years, he could read > about all their network issues. That may be true. However, we weren't talking about network outage notifications in general, we were talking specifically about calling our NOCC to ask about an outage. No, it isn't apples to oranges, but it is Red Deliciouses to Granny Smiths. ;-) > While there is always room for improvement, and some providers have > goofed up, there are providers who attempt to keep their network users > (even if they aren't direct customers) informed. And if you're a network operator who is flinging packets across our network and they aren't arriving, and you want to know why, that generally fits the descripton of "good reason," in my book. I'll admit, it isn't perfect. As somebody else pointed out, "good reason" is not an easy metric; it depends on who you are, who you have reached, the nature of the outage, how busy the NOCC is, the phase of the moon, etc, etc. -Dave

2 1

Re: Using Policy Routing to stop DoS attacks
by Andre Chapuis 28 Mar '03

28 Mar '03

We could ask Cisco and Juniper to add a way of 'artificially' remove networks from the CEF table (with an ACL or so). That way, even with loose-RPF, the packet will be dropped based on source-address at the ingress without consuming CPU. Or maybe such a feature already exist André At 09:06 25.03.2003 -0500, Christian Liendo wrote: >Looking for advice. > >I am sorry if this was discussed before, but I cannot seem to find this. >I want to use source routing as a way to stop a DoS rather than use access-lists. > >In other words, lets say I know the source IP (range of IPs) of an attack and they do not change. > >If the destination stays the same I can easily null route the destination, but what if the destination constantly changes. So I have to work based on the source IP. > >Depending on the router and the code, if I implement an access-list then the CPU utilization shoots through the roof. >What I would like to try and do is use source routing to route that traffic to null. I figured it would be easier on the router than an access-list. > >Has anyone else tried this successfully on ciscos and junipers? >Is it easier on the CPU than access-lists? >Is there a link I cannot find on cisco or google? > >Thanks >Christian Liendo > --------------------- Andre Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 chapuis(a)ip-plus.net CCIE #6023 ----------------------

4 3

RE: [OT: FW: About your using mailer]
by Mike Damm 28 Mar '03

28 Mar '03

As I figured. Here was my official reply I sent to him: "RFC-2822 is a Proposed Standard according to the Official Internet Protocol Standards. We are completely compliant with RFC822, which is the current standard for MAIL. If your software in unable to handle older standards, it is suggested that you upgrade. In regards to what mail platform we are using, we do run Microsoft Exchange 5.5. If you would like us to upgrade, I can forward you bank details so you can wire us $45,000 - the cost of switching to another product. Until then, please discontinue these unsolicited memos, for the public good." --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Joshua Smith [mailto:joshua.ej.smith@usa.net] Sent: Friday, March 28, 2003 10:01 AM To: Mike Damm; nanog(a)merit.edu Subject: Re: [OT: FW: About your using mailer] i got one too - i was going to ask if anyone else minded that my mua was fully rfc 2822 compliant (before telling usa.net that they have to rewrite their webmail app)... i like how the examples cited are crap-html/mime oriented (msn, exchange, and aol?) Mike Damm <MikeD(a)irwinresearch.com> wrote: > > > Is anyone else getting this junk regarding the list? And can we put a stop > to it? > > Granted in a perfect world everyone runs software throughout the entire > enterprise that is on the bleeding edge of the latest proposed standards, > but some of us only have so big of a budget. > > --- > Michael Damm, MIS Department, Irwin Research & Development > V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com > > > -----Original Message----- > From: Miyoko Shioda [mailto:wjxv4y@k3.dion.ne.jp] > Sent: Friday, March 28, 2003 9:30 AM > To: Mike Damm > Subject: Re: About your using mailer > > > dear Mike Damm, > > Sorry, I am talking about NANOG mailing list. > Please please change your MUA in mainling list... > > Regards, > > On Fri, 28 Mar 2003 09:28:17 -0800 > Mike Damm <MikeD(a)irwinresearch.com> wrote: > > > What mailing list are you talking about? > > > > --- > > Michael Damm, MIS Department, Irwin Research & Development > > V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com > > > > > > -----Original Message----- > > From: Miyoko Shioda [mailto:wjxv4y@k3.dion.ne.jp] > > Sent: Thursday, March 27, 2003 5:16 PM > > To: MikeD(a)irwinresearch.com > > Subject: About your using mailer > > > > > > Hi, > > I read your messages in mailing list. > > > > Your using mailer(MUA) does not seems to support In-Reply-To nor > References > > field. These field is defined in RFC-2822. > > If these field does not be outputted when you reply, tree construction > > will be break every time you post the messages to mailing list. > > It is inconvenient for the others. > > > > Please please change your mailer for the public good, > > at least when you post to mailing list. > > > > Today almost mailers support these field(at least In-Reply-To) > > except for the following mailers. > > > > MSN hotmail > > Exchange Server <= 2000 (Exchange Server 2003 will support In-Reply-To.) > > Lotus Notes < 6.0 > > MIME-Tools > > AOL mailer > > dtmail > > Novell GroupWise > > foxmail > > > > regards, > > > > -- > > Miyoko Shioda > > wjxv4y(a)k3.dion.ne.jp > > > > -- > Miyoko Shioda <wjxv4y(a)k3.dion.ne.jp> > "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

2 1