From xtzuzktst@hanwha.co.kr Tue Feb 1 00:33:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26073; Tue, 1 Feb 2005 00:33:39 -0500 (EST) Received: from bzq-218-33-160.cablep.bezeqint.net ([81.218.33.160]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CvqxX-0006Hg-JK; Tue, 01 Feb 2005 00:52:24 -0500 X-Message-Info: 00O4Uxwxg382WX5FstuMUjlOJD69uaqEW71fIYpgBYQ365YAPA4 Received: (from latus@81.218.33.160) by badge3.208.82.44.32 (2.87.5/A.2D.1) id v20RHqSC14A7; Tue, 01 Feb 2005 01:31:13 -0400 Message-ID: <475361C43F41.084D0@81.218.33.160> Reply-To: "Kerri David" From: "Kerri David" To: rohc@ietf.org Subject: 2005 doctors medicaldirectory, physiciansguide, 7,000 hospitals, 25,000 nursing homes and 400,000 doctors. Date: Mon, 31 Jan 2005 23:25:13 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6855F412200D829E7EC" X-Spam-Score: 12.6 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----6855F412200D829E7EC Content-Type: text/plain; charset="iso-C0D8-7" Content-Transfer-Encoding: quoted-printable 2005 EDITION United States Healthcare Database. PRE-PUBLICATION PRICE OF $195. LIMITED TIME. In a rapidly-changing industry, current healthcare information is an invaluable resource to businesses and organizations. The United States Healthcare Database includes comprehensive information on more than 7,000 hospitals, 25,000 nursing homes and 400,000 doctors. It is the most extensive and reliable mailing list and database of key decision makers in the health care market. Each record is indexed by such features as name, address, phone and fax. The database is available in Excel format on CD Rom. It is designed for mailing lists and merges. The data can be selected by state or other criteria such as type of practice. It can be used on an unlimited basis. Price of $195 (reg. $745). BONUS OFFER: FREE OF CHARGE ORDER NOW AND RECEIVE THE AMERICAN DIRECTORY OF 200,000 DENTISTS ON CD-ROM FREE OF CHARGE ($375 value).. (Each record is indexed by such features as name, address, phone/fax, county, year licensed, type of practice, type of dentist as well as specialty.) To order, please print this e-mail, complete the information below and fax it to 416-765-0029 (tel: 416-765-0028). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: STATE: POSTAL: TEL: FAX: EMAIL: MedCom 4410 Massachusettes Ave. NW, #201 Washington, DC 20016 To be removed from the database please follow this link, http://notinuse.biz/takeoff/takeoff.html ----6855F412200D829E7EC-- From klclmmvs@msn.com Tue Feb 1 09:19:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07087; Tue, 1 Feb 2005 09:19:03 -0500 (EST) Received: from host16-102.pool80183.interbusiness.it ([80.183.102.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cvz9y-0002zO-Ou; Tue, 01 Feb 2005 09:37:53 -0500 Received: from solicitude.webhost5.alterusa.com id CFB66254DE; Tue, 01 Feb 2005 13:15:03 -0100 Received: by bushmaster.webhost1.starnetusa.net (Postfix, from userid 735) id CFB64904DE; Tue, 01 Feb 2005 08:18:03 -0600 Date: Tue, 01 Feb 2005 20:15:03 +0600 Message-Id: <25111130090241.CFB5042DE@areaway.starnetusa.net> From: "Stacey Chu" To: saad@ietf.org, saad-admin@ietf.org, saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org, seamoby@ietf.org, seamoby-admin@ietf.org, seamoby-archive@ietf.org, seamoby-request@ietf.org, seamoby-web-archive@ietf.org, secdir@ietf.org, secdir-admin@ietf.org Subject: SU-per Hu^ge 0ffers Saad X-Spam-Score: 2.3 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 The L0west price of all med's is here. Viicodin - $199.95 Codeine - $189.95 V1a'gra - $199.95 Va|ium - $259.95 Cia|is - $189.95 Xa'nax - $233.95 and many m0reeee..... We are the bes't available nowadays http://uhviagra.info/in.php?aid=56 This is 1 tiime maillling. N0-removalll are requiired gmB2u3yiTjB2AvBNzKG8MRoPiGxp5VXRQUvylgb From Hopkins@doneasy.com Tue Feb 1 11:22:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21909; Tue, 1 Feb 2005 11:22:58 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw160-0006Vn-Qe; Tue, 01 Feb 2005 11:41:48 -0500 Received: from m154.net81-66-128.noos.fr ([81.66.128.154]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cw0nn-0007SN-4L; Tue, 01 Feb 2005 11:22:55 -0500 Received: from [155.8.120.194] by becalm%DIGITS.brawl.81.66.128.154 via HTTP; Tue, 01 Feb 2005 11:22:23 -0800 Reply-To: "l Reeves Limited" From: "l Reeves Limited" To: Subject: Match Found Date: Tue, 01 Feb 2005 11:22:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8156894658sblv5321" Message-Id: X-Spam-Score: 14.6 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----8156894658sblv5321 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 unfaithful wives have been matched for you in your area: 1) Melissa, 134 lbs, 5'8, 36c, 21 miles away, available Jan 31- Feb 7rd 2) Jennifer, 120 lbs, 5'6, 36d, 12 miles away, available Jan 30- Feb 5rd 3) Courtney, 124 lbs, 5'9, 34b, 12 miles away, available most nights (husb= and works midnights) 4) Rebecca, 127 lbs, 5'9, 36c, 10 miles away, available most week nights (= looking for side-fling) All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://godatetomorrow.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatetomorrow.com/out/=20 ----8156894658sblv5321-- From Green@hushmail.com Tue Feb 1 19:10:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19782; Tue, 1 Feb 2005 19:10:29 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw8OZ-0005IH-4G; Tue, 01 Feb 2005 19:29:24 -0500 Received: from adsl-68-253-33-17.dsl.ipltin.ameritech.net ([68.253.33.17]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cw86H-0005vF-7e; Tue, 01 Feb 2005 19:10:29 -0500 Received: from [83.196.240.229] by princeton%DIGITS.deduce.68.253.33.17 via HTTP; Tue, 01 Feb 2005 19:09:54 -0800 Reply-To: "graffiti.net" From: "graffiti.net" To: Subject: Heyllooo, it's me Date: Tue, 01 Feb 2005 19:09:54 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3040218448xbsg4586" Message-Id: X-Spam-Score: 2.4 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ----3040218448xbsg4586 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Would you like to keep me some company? My Husband doesn't love me anymore, I'm looking for some excitement withou= t breaking up our family. Safe way to contact me: http://godatetonight.com/d/1.php Sincerely Yours, Kayla i ----3040218448xbsg4586-- From Lindsay@nuukiemail.com Tue Feb 1 21:59:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05631; Tue, 1 Feb 2005 21:59:52 -0500 (EST) Message-Id: <200502020259.VAA05631@ietf.org> Received: from c-24-23-115-167.client.comcast.net ([24.23.115.167]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwB2V-0000kt-TC; Tue, 01 Feb 2005 22:18:49 -0500 Received: from [58.200.50.98] by campbell%DIGITS.chivalry.24.23.115.167 via HTTP; Tue, 01 Feb 2005 21:59:25 -0800 Reply-To: "a Miranda Inc." From: "a Miranda Inc." To: Subject: Four beautiful matches Date: Tue, 01 Feb 2005 21:59:25 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4494588404xhxa0433" X-Spam-Score: 3.6 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----4494588404xhxa0433 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 Cheating House Wife have been matched for you in your area: 1: Rebecca, 128 lbs, 5'5, 36c, 10 miles away, available most nights (husba= nd works midnights) 2: Tiffany, 131 lbs, 5'7, 36d, 19 miles away, available most nights (husba= nd works midnights) 3: Rebecca, 134 lbs, 5'8, 34b, 19 miles away, available most week nights (= looking for side-fling) 4: Alyssa, 120 lbs, 5'5, 36c, 8 miles away, available Jan29-31th All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://godatetomorrow.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatetomorrow.com/out/=20 ----4494588404xhxa0433-- From gwwgbi@dbi-berlin.de Wed Feb 2 00:17:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28481; Wed, 2 Feb 2005 00:17:33 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwDBl-0003ie-UP; Wed, 02 Feb 2005 00:36:30 -0500 Received: from 66-168-69-41.wb.wi.charter.com ([66.168.69.41]) by mx2.foretec.com with smtp (Exim 4.24) id 1CwCtM-0000Mu-8P; Wed, 02 Feb 2005 00:17:28 -0500 X-Message-Info: 8CM56SRw63BQDA3E7vHBvuIR4AucrGXQAB8vwGLDfN8BNDF Received: (from reprimand@66.168.69.41) by transshippingC.224.224.126.190 (C.CB.6/C.50.2) id orB38YBhAD2B4; Wed, 02 Feb 2005 01:11:27 -0400 Message-ID: <494C0906FE61B.116BF@gwwgbi@dbi-berlin.de> Reply-To: "Reuben Branch" From: "Reuben Branch" To: "Sip" Subject: real-time trading alert on flying penny stock Date: Wed, 02 Feb 2005 08:09:27 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--36E1D4F7066A84FEF93B" X-Spam-Score: 7.0 (+++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----36E1D4F7066A84FEF93B Content-Type: text/plain; charset="iso-501E-6" Content-Transfer-Encoding: quoted-printable Urgent Buy Recommendation OTC: ACNI American IDC Corp. to make Millions with Launch of Broadband Internet TV, Technologically Superior to AOL TV Clips and Movie Trailers Price: .04 Immediate Breakout: .15 in 5 days ACNI is the Internet Success story for 2005 making them the hottest undervalued _st0ck_ at this price level where shares are ready to explode on huge investor attention. ACNI has completed the worldwide launch of its revolutionary Broadband Internet Television, solidifying explosive revenues for this proprietary video technology powerhouse. ACNI is positioned much like today's cable TV giants that invested heavily in their technology over 20 years ago and are now earning a thousand times over what was initially spent each year from their current subscribers. The driving force behind ACNI's technology that enables streaming 24/7 Broadband Internet Television, by comparison, is more highly sophisticated than the partial movie trailers or 15-second clips from "Top TV Moments" shown by AOL to subscribers. Combine the fact that ACNI is continuously providing thousands of revenue generating Hollywood classic movies, with expanding content of Sports, Music, Educational, Television Series, and Children's Programming, clearly provides a superior cutting-edge advantage keeping the Company at the forefront in the fastest growing sector of the Internet. ACNI's programming through its 100% Company-owned network, E-TVHollywood, is the first full-screen Broadband Digital streaming channel on the Internet in High-Definition (HD) Quality. The technological breakthrough that supplies the groundwork for record setting multi-millions for ACNI is powered by MPEG2 using movie industry code which allows for the necessary transcoding into video for Broadband. ACNI is the perfect play for explosive short-term gains with a small float estimated at under 20 million shares and a market value at around $1.5 million. We expect massive block buying with record setting price and volume breakouts. We are advising urgent accumulation by our subscribers as huge news is due to be released that will send share prices soaring. Required Info- This is an independent news-letter with the goal of giving readers the necessary knowledge to make rational and profitable decisions. This publication does not provide an analysis of the company's financial position and is not an offer to buy or sell securities. Investing in securities is speculative and carries risk. It is recommended that any investment should be made after consulting with your investment advisor and after reviewing the financial statements of the company. The information presented in this online report is believed to be reliable, but its accuracy cannot be assured. Past performance does not insure similar future results. The publisher has received fifteen thousand dollars from an unaffiliated third party with respect to the preparation of this special online report as an effort to build awareness for American IDC Corp. The information reported herein contains future-looking statements and information within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934, including statements regarding expected continual growth of the featured company. Future-looking statements are based on expectations, estimates, and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results to differ materially from those presently anticipated. ----36E1D4F7066A84FEF93B-- From GDRJIR@erols.com Wed Feb 2 09:32:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08607; Wed, 2 Feb 2005 09:32:47 -0500 (EST) Received: from [218.235.34.95] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwLrB-0000WN-Da; Wed, 02 Feb 2005 09:51:51 -0500 X-Message-Info: FvbrMQ8ygnKKW8SCjMU9UOPjeX972LH61FNN6ys9WOT Received: (from i68appointe@localhost) by xp9-partake805.f4p.air7seas.com (7.92.26/9.83.99) id t1ULS1a684890; Wed, 02 Feb 2005 10:26:06 -0400 GMT X-Authentication-Warning: kd96-crawford9.dq7s.air7seas.com: h8rotor set sender to GDRJIR@erols.com using -l MIME-Version: 1.0 Date: Wed, 02 Feb 2005 15:30:06 +0100 From: Eliseo Weaver Subject: Who's the new player in the pherma biz! saint To: scoya@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--1136565826646013080" X-Spam-Score: 10.7 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ----1136565826646013080 Content-Type: text/html; Content-Transfer-Encoding: 7Bit There's a new player in the hood - and you're gonna like it.
Yep, nomore the old fashion, this one is new, good and will
give it to you like with prjjces you never knew you can get.
I'm talking about the new shoop.
Come iin to observe more!
We can't wait till the winter comes :)

naa h enfant appraise

styli radish edward thermionic cheyenne. breastplate collie canvass bugaboo prop punditry. electrify dyad hydrometer aboard hygrometer. blockhouse mosquito gyro triton scuttle motorcycle colt.
analyses forgiven bugaboo simonson health congresswoman reversal concomitant. fuchsia severn silhouette gyro servile demure diabetes. hershel strawflower architect activism gypsy truce so.
bookkeep one gyro anhydrite thereby wakeup weatherbeaten. weigh bugaboo divalent capacitive dragonhead. sentient bugaboo grassland dip colonnade parquet. villain corp pretoria heptane abstention denunciate toiletry. napoleonic tough adore gaelic strawflower fermium cleave prototypic countersink.
gel declarative gyro depredate anomaly shroud. lawrencium avocate bugaboo sailfish riemann journeyman. life edward appetite wilcox smoke khrushchev. work circumflex hotshot gyro fringe levulose un. command pearson crank edition gyro mayo columbine.
applied dam camaraderie corp conferring chicagoan alan decor sport. delimit therein edward waist jolly archibald baseline hedgehog. abyssinia chokeberry quickie shotbush hydrometer cursor autonomic radiotelegraph pole. you invertebrate lion strawflower armload corpse.
actress handiwork cayuga gyro encryption ovary handset. lea dismissal edward fillet bricklay buzzer pleistocene empower. belle tedium pneumococcus pumpkin hydrometer gabbro mafia angela motorcycle texan. cardiac nathan edward clifton condemn imbrue. ----1136565826646013080-- From Ellison@inbox.ru Wed Feb 2 11:30:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24662; Wed, 2 Feb 2005 11:30:19 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNgx-0004Xe-Et; Wed, 02 Feb 2005 11:49:25 -0500 Received: from [210.205.180.202] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CwNOV-0008Ab-9Z; Wed, 02 Feb 2005 11:30:20 -0500 Received: from [132.216.72.114] by deficient%DIGITS.capo.210.205.180.202 via HTTP; Wed, 02 Feb 2005 11:29:40 -0800 Reply-To: "f Neal Corporation" From: "f Neal Corporation" To: Subject: Find them here Date: Wed, 02 Feb 2005 11:29:40 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9440656567plcs4450" Message-Id: X-Spam-Score: 16.5 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----9440656567plcs4450 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 Wives looking to Cheat,=20 have been matched for you in your area: 1: Stephanie, 132 lbs, 5'8, 36c, 18 miles away, available Jan 31- Feb 7rd 2: Rachel, 129 lbs, 5'6, 36d, 10 miles away, available Jan 31- Feb 7rd 3: Melissa, 130 lbs, 5'7, 34b, 7 miles away, available most week nights ( = looking for side-fling) 4: Brittany, 131 lbs, 5'7, 36c, 18 miles away, available most nights (husb= and works midnights) All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://godatesoon.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatesoon.com/out/=20 ----9440656567plcs4450-- From iago@absolutemotion.com Wed Feb 2 15:56:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28149 for ; Wed, 2 Feb 2005 15:56:07 -0500 (EST) Received: from 212-182-178-174-mx.xdsl.tiscali.nl ([212.182.178.174]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwRqD-0005au-CO for sctp-impl-archive@ietf.org; Wed, 02 Feb 2005 16:15:14 -0500 Message-ID: <11b301c50967$77e2bc29$e8045704@absolutemotion.com> From: "Jennifer A. Clark" To: sctp-impl-archive@ietf.org Subject: =?iso-8859-1?B?V2luZG93cyBYUCAtIHdob2xlc2FsZSBwcmljZQ==?= Date: Wed, 02 Feb 2005 20:39:51 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_BD9826F6.C9F2601D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 5.3 (+++++) X-Spam-Flag: YES X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_BD9826F6.C9F2601D Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_0043A4CF.615C1210" ------=_NextPart_001_0001_0043A4CF.615C1210 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get all the software you need for prices substantially lower than in stores! Our software is 2-10 times cheaper than sold by our competitors. Examples: $70 Windows XP Professional (Including: Service Pack 2) $80 Microsoft Office 2003 Professional $90 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $160 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $70 Adobe Acrobat 6.0 Professional Special Offers: $80 Windows XP Professional + Office XP Professional $140 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $120 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Go visit us at: http://www.quadrasoft.org Best regards, Jennifer Clark _____________________________________________________ To stop further mailings, go: http://www.quadrasoft.org/uns.htm _____________________________________________________ ------=_NextPart_001_0001_0043A4CF.615C1210 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Get access to all the software you need for bottom prices!
Our software is 2-10 times cheaper than sold by our competitors.

A few examples:
$70 Windows XP Professional (Including: Service Pack 2)
$80 Microsoft Office 2003 Professional
$90 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$160 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$70 Adobe Acrobat 6.0 Professional

Special Offers:
$80 Windows XP Professional + Office XP Professional
$140 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
$120 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... To view full list of products go:

http://www.quadrasoft.org

Regards,
Jennifer Clark


_____________________________________________________
To change your mail details, go here: http://www.quadrasoft.org/uns.htm
_____________________________________________________

------=_NextPart_001_0001_0043A4CF.615C1210-- ------=_NextPart_000_0000_BD9826F6.C9F2601D-- From mamjfaasap@danet.de Thu Feb 3 09:39:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27246; Thu, 3 Feb 2005 09:39:30 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwiRP-00081E-Ci; Thu, 03 Feb 2005 09:58:45 -0500 Received: from [211.138.246.55] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Cwi8i-0007ki-Kt; Thu, 03 Feb 2005 09:39:26 -0500 X-Message-Info: 8FG90Jexftt7Z4AniGhICHE27maGEC2C9zpzFxxxYJ9EZCB94 Received: from mail pickup service by 211.138.246.55 with Microsoft SMTPSVC; Thu, 03 Feb 2005 10:32:49 -0400 Content-Class: urn:content-classes:message Reply-To: "Jerry Sutton" From: "Jerry Sutton" To: "Sip-admin" Subject: current analysis on hot pick from our watch list Date: Thu, 03 Feb 2005 19:34:49 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--C485B30C46606AE780" Message-Id: X-Spam-Score: 25.6 (+++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----C485B30C46606AE780 Content-Type: text/plain; charset="iso-7005-2" Content-Transfer-Encoding: quoted-printable Urgent Buy Recommendation OTC: ACNI American IDC Corp. to make Millions with Launch of Broadband Internet TV, Technologically Superior to AOL TV Clips and Movie Trailers Price: .04 Immediate Breakout: .15 in 5 days ACNI is the Internet Success story for 2005 making them the hottest undervalued _st0ck_ at this price level where shares are ready to explode on huge investor attention. ACNI has completed the worldwide launch of its revolutionary Broadband Internet Television, solidifying explosive revenues for this proprietary video technology powerhouse. ACNI is positioned much like today's cable TV giants that invested heavily in their technology over 20 years ago and are now earning a thousand times over what was initially spent each year from their current subscribers. The driving force behind ACNI's technology that enables streaming 24/7 Broadband Internet Television, by comparison, is more highly sophisticated than the partial movie trailers or 15-second clips from "Top TV Moments" shown by AOL to subscribers. Combine the fact that ACNI is continuously providing thousands of revenue generating Hollywood classic movies, with expanding content of Sports, Music, Educational, Television Series, and Children's Programming, clearly provides a superior cutting-edge advantage keeping the Company at the forefront in the fastest growing sector of the Internet. ACNI's programming through its 100% Company-owned network, E-TVHollywood, is the first full-screen Broadband Digital streaming channel on the Internet in High-Definition (HD) Quality. The technological breakthrough that supplies the groundwork for record setting multi-millions for ACNI is powered by MPEG2 using movie industry code which allows for the necessary transcoding into video for Broadband. ACNI is the perfect play for explosive short-term gains with a small float estimated at under 20 million shares and a market value at around $1.5 million. We expect massive block buying with record setting price and volume breakouts. We are advising urgent accumulation by our subscribers as huge news is due to be released that will send share prices soaring. Required Info- This is an independent news-letter with the goal of giving readers the necessary knowledge to make rational and profitable decisions. This publication does not provide an analysis of the company's financial position and is not an offer to buy or sell securities. Investing in securities is speculative and carries risk. It is recommended that any investment should be made after consulting with your investment advisor and after reviewing the financial statements of the company. The information presented in this online report is believed to be reliable, but its accuracy cannot be assured. Past performance does not insure similar future results. The publisher has received fifteen thousand dollars from an unaffiliated third party with respect to the preparation of this special online report as an effort to build awareness for American IDC Corp. The information reported herein contains future-looking statements and information within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934, including statements regarding expected continual growth of the featured company. Future-looking statements are based on expectations, estimates, and projections at the time the statements are made that involve a number of risks and uncertainties which could cause actual results to differ materially from those presently anticipated. ----C485B30C46606AE780-- From Stokes@didamail.com Thu Feb 3 15:37:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06280; Thu, 3 Feb 2005 15:37:15 -0500 (EST) Message-Id: <200502032037.PAA06280@ietf.org> Received: from [61.33.194.207] (helo=KING3) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cwo1f-0003I9-7h; Thu, 03 Feb 2005 15:56:33 -0500 Received: from [12.67.12.106] by during%DIGITS.bethlehem.61.33.194.207 via HTTP; Thu, 03 Feb 2005 15:36:36 -0800 Reply-To: "fastermail.com" From: "fastermail.com" To: Subject: Heyyy,, me again Date: Thu, 03 Feb 2005 15:36:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9882475875qjpl8568" X-Spam-Score: 8.6 (++++++++) X-Spam-Flag: YES X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ----9882475875qjpl8568 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Would you like to keep me some company? My Sack of shit husband=20 works night shifts, which makes me very lonely = at night. To contact me please go here: http://godatesunday.com/d/1.php P.S. it's me Sarah c ----9882475875qjpl8568-- From penoff@cs.ubc.ca Fri Feb 4 03:09:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01178 for ; Fri, 4 Feb 2005 03:09:20 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwypY-0000tc-AI for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 03:28:44 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2005 00:16:30 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1488DF1029201; Fri, 4 Feb 2005 00:08:13 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1486F7U006934 for sctp-impl-filtered; Fri, 4 Feb 2005 00:06:17 -0800 (PST) Message-Id: <200502040806.j1486F7U006934@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107504375-6932-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Jan24-2005snap+Patch24 loopback source value ? List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Brad Penoff X-Nails-Approved: penoff@cs.ubc.ca Date: Thu, 3 Feb 2005 23:54:44 -0800 (PST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format... ------------=_1107504375-6932-0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Greetings, I wanted to inquire about some behavior I'm seeing when running a client and server on the SAME HOST via kame sctp with either one-to-one or one-to-many style. I've reduce the problem to this trivial example where I used one-to-many style. Essentially the difference is that 127.0.0.1 comes up often in kame sctp but NEVER in similar tests on lksctp, BSD TCP, nor Linux TCP. Say the server does this: socket, bind(INADDR_ANY), listen, sctp_recvmsg, close While the client, when passed an IP from the command line, does this: socket, puts given-IP into sockaddr_in, sctp_sendmsg, close I run this with "client 192.168.10.x" on the following examples. All the data was gotten by snooping on the loopback interface. When running on kame sctp, I get something like: # Source Destination Info a 127.0.0.1 192.168.10.200 [Short frame] b 127.0.0.1 127.0.0.1 [Short frame] c 127.0.0.1 192.168.10.200 [Short frame] d 127.0.0.1 127.0.0.1 COOKIE_ACK e 127.0.0.1 192.168.10.200 DATA f 127.0.0.1 127.0.0.1 SACK g 127.0.0.1 127.0.0.1 SHUTDOWN h 127.0.0.1 192.168.10.200 SHUTDOWN_ACK i 127.0.0.1 127.0.0.1 SHUTDOWN_COMPLETE Whereas with lksctp, I get: j 192.168.10.112 192.168.10.112 [Short frame] k 192.168.10.112 192.168.10.112 [Short frame] l 192.168.10.112 192.168.10.112 [Short frame] m 192.168.10.112 192.168.10.112 COOKIE_ACK n 192.168.10.112 192.168.10.112 SACK o 192.168.10.112 192.168.10.112 SHUTDOWN p 192.168.10.112 192.168.10.112 SHUTDOWN_ACK q 192.168.10.112 192.168.10.112 SHUTDOWN_COMPLETE I'm not exactly sure why I'm getting these "Short frame"s. They'd be nice to see in full to see the interfaces in the INITs but honestly they are somewhat irrelevant to my exact concern... This same test ran over TCP on either BSD or Linux ends up looking like the lksctp data above (i.e. they NEVER show 127.0.0.1). And these tests were run on the EXACT hosts so it isn't a routing or name resolution issue. Is kame sctp acting incorrectly here (should it NOT be having 127.0.0.1 ever as the others on the loopback interface when an application itself does not use 127.0.0.1)? Thanks, brad ------------=_1107504375-6932-0-- From Michael.Tuexen@micmac.franken.de Fri Feb 4 04:26:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05693 for ; Fri, 4 Feb 2005 04:26:34 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx02G-0002r8-V4 for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 04:45:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2005 01:35:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j149PYoQ011839; Fri, 4 Feb 2005 01:25:34 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j149ON7U008095 for sctp-impl-filtered; Fri, 4 Feb 2005 01:24:25 -0800 (PST) Message-Id: <200502040924.j149ON7U008095@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107509063-8087-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Jan24-2005snap+Patch24 loopback source value ? List-Id: sctp-impl To: Brad Penoff From: Michael Tuexen Cc: sctp-impl@external.cisco.com X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Fri, 4 Feb 2005 09:44:04 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format... ------------=_1107509063-8087-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi Brad, what tool are you using for capturing the traffic? It looks like it uses a small snaplen such that the long packets containing the INIT, INIT-ACK and COOKIE-ECHO are not completely captured. Can you specify a long snaplen and post the capture file? Best regards Michael On Feb 4, 2005, at 8:54 Uhr, Brad Penoff wrote: > Greetings, > > I wanted to inquire about some behavior I'm seeing when running a > client and server on the SAME HOST via kame sctp with either > one-to-one or one-to-many style. I've reduce the problem to this > trivial example where I used one-to-many style. Essentially the > difference is that 127.0.0.1 comes up often in kame sctp but NEVER in > similar tests on lksctp, BSD TCP, nor Linux TCP. > > Say the server does this: > > socket, bind(INADDR_ANY), listen, sctp_recvmsg, close > > While the client, when passed an IP from the command line, does this: > > socket, puts given-IP into sockaddr_in, sctp_sendmsg, close > > I run this with "client 192.168.10.x" on the following examples. All > the data was gotten by snooping on the loopback interface. > > When running on kame sctp, I get something like: > > # Source Destination Info > > a 127.0.0.1 192.168.10.200 [Short frame] > b 127.0.0.1 127.0.0.1 [Short frame] > c 127.0.0.1 192.168.10.200 [Short frame] > d 127.0.0.1 127.0.0.1 COOKIE_ACK > e 127.0.0.1 192.168.10.200 DATA > f 127.0.0.1 127.0.0.1 SACK > g 127.0.0.1 127.0.0.1 SHUTDOWN > h 127.0.0.1 192.168.10.200 SHUTDOWN_ACK > i 127.0.0.1 127.0.0.1 SHUTDOWN_COMPLETE > > > Whereas with lksctp, I get: > > j 192.168.10.112 192.168.10.112 [Short frame] > k 192.168.10.112 192.168.10.112 [Short frame] > l 192.168.10.112 192.168.10.112 [Short frame] > m 192.168.10.112 192.168.10.112 COOKIE_ACK > n 192.168.10.112 192.168.10.112 SACK > o 192.168.10.112 192.168.10.112 SHUTDOWN > p 192.168.10.112 192.168.10.112 SHUTDOWN_ACK > q 192.168.10.112 192.168.10.112 SHUTDOWN_COMPLETE > > I'm not exactly sure why I'm getting these "Short frame"s. They'd be > nice to see in full to see the interfaces in the INITs but honestly > they are somewhat irrelevant to my exact concern... > > This same test ran over TCP on either BSD or Linux ends up looking > like the lksctp data above (i.e. they NEVER show 127.0.0.1). And > these tests were run on the EXACT hosts so it isn't a routing or name > resolution issue. Is kame sctp acting incorrectly here (should it NOT > be having 127.0.0.1 ever as the others on the loopback interface when > an application itself does not use 127.0.0.1)? > > > Thanks, > brad ------------=_1107509063-8087-0-- From rrs@cisco.com Fri Feb 4 05:25:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09976 for ; Fri, 4 Feb 2005 05:25:10 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx0x0-0004aO-Iv for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 05:44:35 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 04 Feb 2005 03:35:22 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j14ANq82002732; Fri, 4 Feb 2005 02:23:52 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j14AMg7U008970 for sctp-impl-filtered; Fri, 4 Feb 2005 02:22:44 -0800 (PST) Message-Id: <200502041022.j14AMg7U008970@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107512561-8968-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Jan24-2005snap+Patch24 loopback source value ? List-Id: sctp-impl To: Brad Penoff From: Randall Stewart Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Fri, 04 Feb 2005 05:20:04 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a This is a multi-part message in MIME format... ------------=_1107512561-8968-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Brad: A couple of things.. 1) I don't think the behavior is invalid... if all addresses are bound its ok... since any source address is valid. 2) I believe this was due to an issue with source address selection.. which has been completely re-written since patch24.. so I am not sure if you would still see this behavior in a more "current" release.. even though I have not released patch25 yet :-0... still struggling with SMP issues R Brad Penoff wrote: > Greetings, > > I wanted to inquire about some behavior I'm seeing when running a client > and server on the SAME HOST via kame sctp with either one-to-one or > one-to-many style. I've reduce the problem to this trivial example > where I used one-to-many style. Essentially the difference is that > 127.0.0.1 comes up often in kame sctp but NEVER in similar tests on > lksctp, BSD TCP, nor Linux TCP. > > Say the server does this: > > socket, bind(INADDR_ANY), listen, sctp_recvmsg, close > > While the client, when passed an IP from the command line, does this: > > socket, puts given-IP into sockaddr_in, sctp_sendmsg, close > > I run this with "client 192.168.10.x" on the following examples. All > the data was gotten by snooping on the loopback interface. > > When running on kame sctp, I get something like: > > # Source Destination Info > > a 127.0.0.1 192.168.10.200 [Short frame] > b 127.0.0.1 127.0.0.1 [Short frame] > c 127.0.0.1 192.168.10.200 [Short frame] > d 127.0.0.1 127.0.0.1 COOKIE_ACK > e 127.0.0.1 192.168.10.200 DATA > f 127.0.0.1 127.0.0.1 SACK > g 127.0.0.1 127.0.0.1 SHUTDOWN > h 127.0.0.1 192.168.10.200 SHUTDOWN_ACK > i 127.0.0.1 127.0.0.1 SHUTDOWN_COMPLETE > > > Whereas with lksctp, I get: > > j 192.168.10.112 192.168.10.112 [Short frame] > k 192.168.10.112 192.168.10.112 [Short frame] > l 192.168.10.112 192.168.10.112 [Short frame] > m 192.168.10.112 192.168.10.112 COOKIE_ACK > n 192.168.10.112 192.168.10.112 SACK > o 192.168.10.112 192.168.10.112 SHUTDOWN > p 192.168.10.112 192.168.10.112 SHUTDOWN_ACK > q 192.168.10.112 192.168.10.112 SHUTDOWN_COMPLETE > > I'm not exactly sure why I'm getting these "Short frame"s. They'd be > nice to see in full to see the interfaces in the INITs but honestly they > are somewhat irrelevant to my exact concern... > > This same test ran over TCP on either BSD or Linux ends up looking like > the lksctp data above (i.e. they NEVER show 127.0.0.1). And these tests > were run on the EXACT hosts so it isn't a routing or name resolution > issue. Is kame sctp acting incorrectly here (should it NOT be having > 127.0.0.1 ever as the others on the loopback interface when an > application itself does not use 127.0.0.1)? > > > Thanks, > brad > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1107512561-8968-0-- From penoff@cs.ubc.ca Fri Feb 4 05:58:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12538 for ; Fri, 4 Feb 2005 05:58:19 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx1T7-0005R2-33 for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 06:17:45 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2005 03:05:31 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j14AvPoQ016405; Fri, 4 Feb 2005 02:57:26 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j14Au57U009501 for sctp-impl-filtered; Fri, 4 Feb 2005 02:56:07 -0800 (PST) Message-Id: <200502041056.j14Au57U009501@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107514565-9499-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Jan24-2005snap+Patch24 loopback source value ? List-Id: sctp-impl To: Michael Tuexen From: Brad Penoff Cc: sctp-impl@external.cisco.com X-Nails-Approved: penoff@cs.ubc.ca Date: Fri, 4 Feb 2005 02:44:30 -0800 (PST) X-Spam-Score: 0.3 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 This is a multi-part message in MIME format... ------------=_1107514565-9499-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary hey Michael, I increased the snaplen and got full frames now. It appears as if on the lksctp run, 127.0.0.1 isn't one of the IPv4 address parameters, whereas on kame sctp, it is. I've attached each trace for you to take a gander, if you want. Just curious, but what would be your opinion as to if 127.0.0.1 should be there or not? While this is a simple example, where we're seeing this become an issue is with a vanilla port of LAM-MPI; when it gets items from 127.0.0.1 it gets confused and doesn't make it past lamboot... it may just mean we'll have to change this confusion within the MPI middleware, but overall this just made me curious as to what was "right" within any SCTP since such loopback tests have different behaviors from lksctp to kame sctp. As I write this I just saw Randall's response... any clues for how I might be able to edit the kame sctp patch 24 code to NOT include 127.0.0.1 as one of its IPv4 address parameters? I've only been a user up until this point so I haven't really dove into the kernel code yet... bedtime :-), brad On Fri, 4 Feb 2005, Michael Tuexen wrote: > Hi Brad, > > what tool are you using for capturing the traffic? It looks like > it uses a small snaplen such that the long packets containing the > INIT, INIT-ACK and COOKIE-ECHO are not completely captured. > > Can you specify a long snaplen and post the capture file? > > Best regards > Michael > > On Feb 4, 2005, at 8:54 Uhr, Brad Penoff wrote: > >> Greetings, >> >> I wanted to inquire about some behavior I'm seeing when running a client >> and server on the SAME HOST via kame sctp with either one-to-one or >> one-to-many style. I've reduce the problem to this trivial example where >> I used one-to-many style. Essentially the difference is that 127.0.0.1 >> comes up often in kame sctp but NEVER in similar tests on lksctp, BSD TCP, >> nor Linux TCP. >> >> Say the server does this: >> >> socket, bind(INADDR_ANY), listen, sctp_recvmsg, close >> >> While the client, when passed an IP from the command line, does this: >> >> socket, puts given-IP into sockaddr_in, sctp_sendmsg, close >> >> I run this with "client 192.168.10.x" on the following examples. All the >> data was gotten by snooping on the loopback interface. >> >> When running on kame sctp, I get something like: >> >> # Source Destination Info >> >> a 127.0.0.1 192.168.10.200 [Short frame] >> b 127.0.0.1 127.0.0.1 [Short frame] >> c 127.0.0.1 192.168.10.200 [Short frame] >> d 127.0.0.1 127.0.0.1 COOKIE_ACK >> e 127.0.0.1 192.168.10.200 DATA >> f 127.0.0.1 127.0.0.1 SACK >> g 127.0.0.1 127.0.0.1 SHUTDOWN >> h 127.0.0.1 192.168.10.200 SHUTDOWN_ACK >> i 127.0.0.1 127.0.0.1 SHUTDOWN_COMPLETE >> >> >> Whereas with lksctp, I get: >> >> j 192.168.10.112 192.168.10.112 [Short frame] >> k 192.168.10.112 192.168.10.112 [Short frame] >> l 192.168.10.112 192.168.10.112 [Short frame] >> m 192.168.10.112 192.168.10.112 COOKIE_ACK >> n 192.168.10.112 192.168.10.112 SACK >> o 192.168.10.112 192.168.10.112 SHUTDOWN >> p 192.168.10.112 192.168.10.112 SHUTDOWN_ACK >> q 192.168.10.112 192.168.10.112 SHUTDOWN_COMPLETE >> >> I'm not exactly sure why I'm getting these "Short frame"s. They'd be nice >> to see in full to see the interfaces in the INITs but honestly they are >> somewhat irrelevant to my exact concern... >> >> This same test ran over TCP on either BSD or Linux ends up looking like >> the lksctp data above (i.e. they NEVER show 127.0.0.1). And these tests >> were run on the EXACT hosts so it isn't a routing or name resolution >> issue. Is kame sctp acting incorrectly here (should it NOT be having >> 127.0.0.1 ever as the others on the loopback interface when an application >> itself does not use 127.0.0.1)? >> >> >> Thanks, >> brad > ------------=_1107514565-9499-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary 1MOyoQIABAAAAAAAAAAAAJABAAABAAAA2EwDQhmmDABqAAAAagAAAAAAAAAA AAAAAAAAAAgARQIAXAAAQABAhKPrwKgKcMCoCnCBbRYuAAAAAG9P8PwBAAA8 d8cQsAABsAAACv//mI/6QgAFAAiOZwp6AAUACMCoCnAABQAIwKgBFQAMAAYA BQAAgAAABMAAAATYTANCJqcMACYBAAAmAQAAAAAAAAAAAAAAAAAACABFAgEY AABAAECEoy/AqApwwKgKcBYugW13xxCwVY2CeAIAAPj6n8VgAAGwAAAKAAor Nxu8AAUACI5nCnoABQAIwKgKcAAFAAjAqAEVAAcAxAUNPzEgc655Ph5Kf620 AmQAAAAAAAAAAAAAAAAAAAAAYMWf+rAQx3cAAAAAAAAAABRNA0LNpgwACgAK ALwbNysCAG2BwKgKcAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABgAAAABAAA8 d8cQsAABsAAACv//mI/6QgAFAAiOZwp6AAUACMCoCnAABQAIwKgBFQAMAAYA BQAAgAAABMAAAAQABQAIjmcKegAFAAjAqApwAAUACMCoARUAAAAAAAAAAIAA AATAAAAE2EwDQvOnDAAiAQAAIgEAAAAAAAAAAAAAAAAAAAgARQIBFAAAQABA hKMzwKgKcMCoCnCBbRYu+p/FYKQHn1QKAADEBQ0/MSBzrnk+Hkp/rbQCZAAA AAAAAAAAAAAAAAAAAABgxZ/6sBDHdwAAAAAAAAAAFE0DQs2mDAAKAAoAvBs3 KwIAbYHAqApwAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAGAAAAAEAADx3xxCw AAGwAAAK//+Yj/pCAAUACI5nCnoABQAIwKgKcAAFAAjAqAEVAAwABgAFAACA AAAEwAAABAAFAAiOZwp6AAUACMCoCnAABQAIwKgBFQAAAAAAAAAAAAMALpiP +kIAAQAAAAAAADExMQAAAAAAqPn/v6qHBAgAAAAAmOkVQAAAAACY6QAA2EwD QrWoDAAyAAAAMgAAAAAAAAAAAAAAAAAAAAgARQIAJAAAQABAhKQjwKgKcMCo CnAWLoFtd8cQsIkCCCgLAAAE2EwDQg2pDAA+AAAAPgAAAAAAAAAAAAAAAAAA AAgARQIAMAAAQABAhKQXwKgKcMCoCnAWLoFtd8cQsA4VE8wDAAAQmI/6QgAB r+IAAAAA2EwDQvqrDAA2AAAANgAAAAAAAAAAAAAAAAAAAAgARQIAKAAAQABA hKQfwKgKcMCoCnAWLoFtd8cQsPy5UNsHAAAImI/6QthMA0JmrAwAMgAAADIA AAAAAAAAAAAAAAAAAAAIAEUCACQAAEAAQISkI8CoCnDAqApwgW0WLvqfxWCC nWUqCAAABNhMA0K1rAwAMgAAADIAAAAAAAAAAAAAAAAAAAAIAEUCACQAAEAA QISkI8CoCnDAqApwFi6BbXfHELDCmW+ODgAABA== ------------=_1107514565-9499-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary 1MOyoQIABAAAAAAAAAAAAJABAAAAAAAAGFoDQk6MBwBsAAAAbAAAAAIAAABF AABoANUAAECELsx/AAABwKgKyARXFi4AAAAAAAAAAAEAAEhEAbAdAAOOOAAK CADrmQ61AAwACAAFAAbABgAIUExSU4AAAATAAAAEgAgACcGAwIGCAAAAAAUA CMCoCsgABQAIfwAAARhaA0IMjQcAaAEAAGgBAAACAAAARQABZADWAABAhHo+ fwAAAX8AAAEWLgRXRAGwHfTC5XoCAAFEOe5jwAADjjgACggAE08JlMAGAAhQ TFJTgAAABMAAAASACAAJwYDAgYIAAAAABQAIwKgKyAAFAAh/AAABAAcBBEtB TUUtQlNEIDEuMQAAAAA8AAAAAAAAAAAAAABEAbAdOe5jwN6uAgBZ0ggAfwAA AQAAAAAAAAAAAAAAAAUAAAB/AAABAAAAAAAAAAAAAAAABQAAAAAAAAAEVxYu AQABAQEBAAABAABIRAGwHQADjjgACggA65kOtQAMAAgABQAGwAYACFBMUlOA AAAEwAAABIAIAAnBgMCBggAAAAAFAAjAqArIAAUACH8AAAECAAFEOe5jwAAD jjgACggAE08JlMAGAAhQTFJTgAAABMAAAASACAAJwYDAgYIAAAAABQAIwKgK yAAFAAh/AAABAJVXgwvZIECyhfKLgSKcQnylK6wYWgNCgo0HACgBAAAoAQAA AgAAAEUAASQA10AAQITuDX8AAAHAqArIBFcWLjnuY8AAAAAACgABBEtBTUUt QlNEIDEuMQAAAAA8AAAAAAAAAAAAAABEAbAdOe5jwN6uAgBZ0ggAfwAAAQAA AAAAAAAAAAAAAAUAAAB/AAABAAAAAAAAAAAAAAAABQAAAAAAAAAEVxYuAQAB AQEBAAABAABIRAGwHQADjjgACggA65kOtQAMAAgABQAGwAYACFBMUlOAAAAE wAAABIAIAAnBgMCBggAAAAAFAAjAqArIAAUACH8AAAECAAFEOe5jwAADjjgA CggAE08JlMAGAAhQTFJTgAAABMAAAASACAAJwYDAgYIAAAAABQAIwKgKyAAF AAh/AAABAJVXgwvZIECyhfKLgSKcQnylK6wYWgNCVo4HACgAAAAoAAAAAgAA AEUAACQA2EAAQIQ7fH8AAAF/AAABFi4EV0QBsB0AAAAACwAABBhaA0LFjgcA VAAAAFQAAAACAAAARQIAUADZQABAhO7dfwAAAcCoCsgEVxYuOe5jwAAAAAAA AwAu65kOtQABAAAAAAAAMTExAHz7v79w+7+/AAAAAAAhBiho+7+/hcUEKAIA AAAYWgNCHY8HADQAAAA0AAAAAgAAAEUAADAA2kAAQIQ7bn8AAAF/AAABFi4E V0QBsB0AAAAAAwEAEOuZDrUAA43eAAAAABhaA0L3lAcALAAAACwAAAACAAAA RQAAKADbQABAhDt1fwAAAX8AAAEWLgRXRAGwHQAAAAAHAAAI65kOtRhaA0JE lQcAKAAAACgAAAACAAAARQAAJADcQABAhO8IfwAAAcCoCsgEVxYuOe5jwAAA AAAIAAAEGFoDQnyVBwAoAAAAKAAAAAIAAABFAAAkAN1AAECEO3d/AAABfwAA ARYuBFdEAbAdAAAAAA4AAAQ= ------------=_1107514565-9499-0-- From disgruntle7behave@accesswave.com Fri Feb 4 07:17:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18009; Fri, 4 Feb 2005 07:17:47 -0500 (EST) Received: from [61.76.22.131] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cx2i1-0007Lt-TT; Fri, 04 Feb 2005 07:37:15 -0500 Received: from mail.kimchee.net (61.76.22.131) by 61.76.22.131 (turbofanv.4) with SMTP id <43863861a07p> (Authid: 2186760); Fri, 04 Feb 2005 06:15:49 -0600 Message-ID: <01932.XOAR@kimchee.net> Reply-To: "Velemir Suzin" From: "Velemir Suzin" To: sctp-impl-archive@ietf.org Cc: seamoby@ietf.org, seamoby-admin@ietf.org, seamoby-archive@ietf.org, seamoby-request@ietf.org, seamoby-web-archive@ietf.org, secdir@ietf.org, secdir-admin@ietf.org Subject: Payment confirmation: $851515 Date: Fri, 04 Feb 2005 07:19:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6348546_2593746.wb483" X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----6348546_2593746.wb483 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 405,000 with a 2.8% rate. Please verify your information here: http://scare12.gsvdvs.info:443/azbrg We look forward to hearing from you. Velemir Suzin, Account Manager TJK Associates r*mv - http//gsvdvs.info:443/index.php ----6348546_2593746.wb483-- From piggy@timesys.com Fri Feb 4 10:43:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07923 for ; Fri, 4 Feb 2005 10:43:48 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx5vQ-0004gi-Po for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 11:03:17 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 04 Feb 2005 07:43:35 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j14FgePA022882; Fri, 4 Feb 2005 07:42:41 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j14Ff27U014384 for sctp-impl-filtered; Fri, 4 Feb 2005 07:41:04 -0800 (PST) Message-Id: <200502041541.j14Ff27U014384@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107531662-14382-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: Jan24-2005snap+Patch24 loopback source value ? List-Id: sctp-impl To: Brad Penoff From: "La Monte H.P. Yarroll" Cc: Randall Stewart , sctp-impl@external.cisco.com X-Nails-Approved: piggy@timesys.com Date: Fri, 04 Feb 2005 10:36:21 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f This is a multi-part message in MIME format... ------------=_1107531662-14382-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: > > Brad: > > A couple of things.. > > 1) I don't think the behavior is invalid... if all > addresses are bound its ok... since any source > address is valid. As long as the address is "in scope" for the correspondant... Randy's code puts a lot more effort into deciding valid scope than lksctp. In lksctp we simply always remove loopback from the list of valid addresses. On a Linux box, bring down all interfaces except lo and you'll see behavior closer to the Kame behavior. > > 2) I believe this was due to an issue with source address > selection.. which has been completely re-written since > patch24.. so I am not sure if you would still see this > behavior in a more "current" release.. even though I have > not released patch25 yet :-0... still struggling with > SMP issues > > R > > Brad Penoff wrote: > >> Greetings, >> >> I wanted to inquire about some behavior I'm seeing when running a >> client and server on the SAME HOST via kame sctp with either >> one-to-one or one-to-many style. I've reduce the problem to this >> trivial example where I used one-to-many style. Essentially the >> difference is that 127.0.0.1 comes up often in kame sctp but NEVER in >> similar tests on lksctp, BSD TCP, nor Linux TCP. >> >> Say the server does this: >> >> socket, bind(INADDR_ANY), listen, sctp_recvmsg, close >> >> While the client, when passed an IP from the command line, does this: >> >> socket, puts given-IP into sockaddr_in, sctp_sendmsg, close >> >> I run this with "client 192.168.10.x" on the following examples. All >> the data was gotten by snooping on the loopback interface. >> >> When running on kame sctp, I get something like: >> >> # Source Destination Info >> >> a 127.0.0.1 192.168.10.200 [Short frame] >> b 127.0.0.1 127.0.0.1 [Short frame] >> c 127.0.0.1 192.168.10.200 [Short frame] >> d 127.0.0.1 127.0.0.1 COOKIE_ACK >> e 127.0.0.1 192.168.10.200 DATA >> f 127.0.0.1 127.0.0.1 SACK >> g 127.0.0.1 127.0.0.1 SHUTDOWN >> h 127.0.0.1 192.168.10.200 SHUTDOWN_ACK >> i 127.0.0.1 127.0.0.1 SHUTDOWN_COMPLETE >> >> >> Whereas with lksctp, I get: >> >> j 192.168.10.112 192.168.10.112 [Short frame] >> k 192.168.10.112 192.168.10.112 [Short frame] >> l 192.168.10.112 192.168.10.112 [Short frame] >> m 192.168.10.112 192.168.10.112 COOKIE_ACK >> n 192.168.10.112 192.168.10.112 SACK >> o 192.168.10.112 192.168.10.112 SHUTDOWN >> p 192.168.10.112 192.168.10.112 SHUTDOWN_ACK >> q 192.168.10.112 192.168.10.112 SHUTDOWN_COMPLETE >> >> I'm not exactly sure why I'm getting these "Short frame"s. They'd be >> nice to see in full to see the interfaces in the INITs but honestly >> they are somewhat irrelevant to my exact concern... >> >> This same test ran over TCP on either BSD or Linux ends up looking >> like the lksctp data above (i.e. they NEVER show 127.0.0.1). And >> these tests were run on the EXACT hosts so it isn't a routing or name >> resolution issue. Is kame sctp acting incorrectly here (should it >> NOT be having 127.0.0.1 ever as the others on the loopback interface >> when an application itself does not use 127.0.0.1)? >> >> >> Thanks, >> brad >> > > -- "Beware of bugs in the above code; I have only proven it correct, not tried it." -Donald Knuth ------------=_1107531662-14382-0-- From Egan@mailpride.com Fri Feb 4 10:59:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09456; Fri, 4 Feb 2005 10:58:57 -0500 (EST) Message-Id: <200502041558.KAA09456@ietf.org> Received: from [211.36.177.210] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cx6A3-00055M-T6; Fri, 04 Feb 2005 11:18:26 -0500 Received: from [160.191.16.23] by economy%DIGITS.paramus.211.36.177.210 via HTTP; Fri, 04 Feb 2005 10:58:19 -0800 Reply-To: "h Mayes Ltd." From: "h Mayes Ltd." To: Subject: Night life Date: Fri, 04 Feb 2005 10:58:19 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4016876913taep4726" X-Spam-Score: 18.2 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----4016876913taep4726 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 Wives looking for fun have been matched for you in your area: 1) Lauren, 130 lbs, 5'9, 36c, 18 miles away, available most nights (husban= d works midnights) 2) Kayla, 120 lbs, 5'9, 36d, 12 miles away, available most nights (husband= works midnights) 3) Morgan, 125 lbs, 5'6, 34b, 18 miles away, available Jan 31- Feb 3rd 4) Rebecca, 131 lbs, 5'9, 36c, 19 miles away, available Jan 31- Feb 7rd All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://godatesoon.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatesoon.com/out/=20 ----4016876913taep4726-- From DMFRVL@verizon.net Fri Feb 4 17:04:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11723; Fri, 4 Feb 2005 17:04:59 -0500 (EST) Received: from [222.114.57.75] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CxBsJ-0005iS-Nv; Fri, 04 Feb 2005 17:24:31 -0500 X-Message-Info: EVSP1sdlDHcohUt4a21+CRFhn494kgZRK Received: from mail4893.dmyax.de.kaercher.com (246.250.120.255) by r42-tu7.de.kaercher.com with Microsoft SMTPSVC(5.0.2195.6824); Fri, 04 Feb 2005 19:03:46 -0300 Received: from RHHL183 (c84.216.41.107.bglp443.n.de.kaercher.com 38.52.236.40) by mail15.k.de.kaercher.com (04.2.83nk9/61.360.650) with SMTP id hp0UG0YEPpnk52560; Fri, 04 Feb 2005 21:00:46 -0100 Message-ID: <64vi98wa15bjq963y$hrm85e6w8$dv41kyh3@EGXG07> From: "Ruby Boston" To: "Scoya" References: Subject: He's here the new player in the pherma biz! fatal Date: Sat, 05 Feb 2005 01:58:46 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9306332767901980" X-Spam-Score: 17.8 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ----9306332767901980 Content-Type: text/html; Content-Transfer-Encoding: 7Bit There's a new player in the hood - and you're gonna like it.
Yep, nomore the old fashion, this one is new, good and will
give it to you like with prjjces you never knew you can get.
I'm talking about the new shoop.
Come iin to observe more!
We can't wait till the winter comes :)

naa h asteroidal durer

decreeing ointment herringbone advisable peel farmland brood. staircase land warhead tremulous jorge blood semi.
vaccinate meaningful speakeasy tremulous brazen grumman circuitous syllabic. diagnosable depressant nomad bathurst double.
moire nomad surfactant montgomery papua. bullseye burgundian tremulous accident marry bittersweet bedim. papaw gnarl retrospect tx tremulous comrade elusive dynastic. hen alberta depository cincinnati specie camille tree. eldest corvette maw ballard tuscaloosa yamaha jingle.
fourth drosophila hookup catchword depository dereference scowl. feudatory musician maw eyebrow ryder flop perfumery. watchful trim intellectual request tremulous bluebush presuppose. beguile druid corporate depository geese automat.
impregnate bade perfect bourbaki depository aides karp ulysses drab ebony. cummins bolivia sound corpsman nomad dianne jejune atlas bellow primordial.
dada tremulous hayden cedilla dive parke. sour parliamentarian hindmost audio tremulous clinic smudge bonaparte predatory fredericksburg. stone astronomic quandary investigate maw crowley preparatory abrade. ache maw lackey bushmaster oratorio. bawd deliverance cozy could maw hyde backbone decisional mussel polytope. ----9306332767901980-- From service@paypal.com Fri Feb 4 19:25:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24111 for ; Fri, 4 Feb 2005 19:25:53 -0500 (EST) Received: from [209.213.123.118] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CxE4l-0000YW-Tc for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 19:45:28 -0500 Received: from jdgkk.1sjssl.net ([24.223.230.183]) by 132.151.6.1 with SMTP; Fri, 04 Feb 2005 17:24:58 -0700 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Fri, 04 Feb 05 17:24:58 GMT X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="ED_5A34_F84_0_7.C87B" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 20.7 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --ED_5A34_F84_0_7.C87B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--ED_5A34_F84_0_7.C87B-- From aobjvczRhea@uni-goettingen.de Fri Feb 4 20:17:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27673 for ; Fri, 4 Feb 2005 20:17:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxEsZ-0001lk-Eo for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 20:36:56 -0500 Received: from pc-229-232-104-200.cm.vtr.net ([200.104.232.229]) by mx2.foretec.com with smtp (Exim 4.24) id 1CxEZa-0007vC-UW for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 20:17:21 -0500 X-Message-Info: 73SCE3ACNqvzkd4C5RD4ABcnBNKpXAA4FaN44uZQvVXL6C6JEBC3 Received: (from lockian@200.104.232.229) by crumble0.48.80.112.124 (0.FA.F/7.3E.8) id cfECCLZfG7F2076; Fri, 04 Feb 2005 19:09:16 -0600 Message-ID: Reply-To: "Alfonso King" From: "Alfonso King" To: sctp-impl-archive@ietf.org Subject: News: This is for real Date: Sat, 05 Feb 2005 05:10:16 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9FA917B6A2C835962571" X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----9FA917B6A2C835962571 Content-Type: text/html; charset="iso-C04D-A" Content-Transfer-Encoding: quoted-printable

Tired of being passed over for promotions because you don't have the co= rrect schooling, or paperwork.
Discover a little known secret to maximise your employability and prestig= e.
We have the ultimate solution for anybody who needs to get a d gree instan= tly!



Find out more her= e.

 

to purge your email addy f= rom our list
a hybrid "by showing that; ""all consistent axiomatic formulations of number theory= include undecidable propositions."" (Hofstadter 1999" bulletinsboards or homepages sadness ----9FA917B6A2C835962571-- From service@paypal.com Fri Feb 4 20:30:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28325 for ; Fri, 4 Feb 2005 20:30:23 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxF58-0001y1-UP for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 20:49:56 -0500 Received: from [209.213.123.118] (helo=209.213.123.118) by mx2.foretec.com with smtp (Exim 4.24) id 1CxEmE-0008Jb-Vu for sctp-impl-archive@ietf.org; Fri, 04 Feb 2005 20:30:23 -0500 Received: from 188.228.39.77 by 65.246.255.50; Fri, 04 Feb 2005 20:30:24 -0500 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal - Flagged Account Date: Fri, 04 Feb 2005 20:27:24 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--03101320320231622555" X-Priority: 3 X-CS-IP: 192.80.175.109 X-Spam-Score: 9.6 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----03101320320231622555 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----03101320320231622555-- From service@paypal.com Sat Feb 5 06:35:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22628 for ; Sat, 5 Feb 2005 06:35:53 -0500 (EST) Received: from [209.213.123.118] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CxOXA-0005Tb-2H for sctp-impl-archive@ietf.org; Sat, 05 Feb 2005 06:55:32 -0500 Received: from nv0ff.b4770g.com [168.10.104.154] by 132.151.6.1; Sat, 05 Feb 2005 05:31:53 -0600 Message-ID: <343$p0rst-7-v$8kt$b$87@dm1ax> From: "PayPal" To: Subject: PayPal Account Security Measures Date: Sat, 05 Feb 05 05:31:53 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="90EC8__52D" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 24.7 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --90EC8__52D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--90EC8__52D-- From service@paypal.com Sat Feb 5 08:32:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00308 for ; Sat, 5 Feb 2005 08:32:22 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxQLx-0007zw-3c for sctp-impl-archive@ietf.org; Sat, 05 Feb 2005 08:52:01 -0500 Received: from [209.213.123.118] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CxQ2x-0000oA-Ld for sctp-impl-archive@ietf.org; Sat, 05 Feb 2005 08:32:23 -0500 Received: from mig.0mqmgy3.com ([210.246.173.79]) by 65.246.255.50 with ESMTP id <250453-26624>; Sat, 05 Feb 2005 15:31:24 +0200 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Sat, 05 Feb 05 15:31:24 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CCD9A.6118723A84.4C.5" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 22.3 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --CCD9A.6118723A84.4C.5 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--CCD9A.6118723A84.4C.5-- From uxzxuwi@excite.com Sat Feb 5 16:58:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02949; Sat, 5 Feb 2005 16:58:01 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxYFM-0000TC-Cu; Sat, 05 Feb 2005 17:17:45 -0500 Received: from wbar2.chi1-4-10-099-229.chi1.dsl-verizon.net ([4.10.99.229]) by mx2.foretec.com with smtp (Exim 4.24) id 1CxXwH-0007YN-4z; Sat, 05 Feb 2005 16:58:01 -0500 Message-ID: <313333115237539152571.573t6571pds@fuse.net> Received: from 28.106.188.25 by hc938-aq89.auvc103.fuse.net with DAV; Sun, 06 Feb 2005 01:55:50 +0400 Reply-To: "Amos Ford" From: "Amos Ford" To: Subject: Want to Meaat saaxy women in your area? orthodontic Date: Sat, 05 Feb 2005 18:55:50 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6515134039285773520" X-Spam-Score: 9.9 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ----6515134039285773520 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi my name is roy and Id like to invite you to my favorite
pick-up site. Since I fiirst sow this site, 4 months ago, I felt
a MAJOR change in my ljfe - I met more womeen then I've
ever dreamt of! You can enter now too, since the site is open
to the public for free. Feel free to enter!
take me now continuous

mossy serape angelo groin roebuck forty diatomaceous carp affront. guffaw iran solon bust despair chi. typhoid resistible ephemerides aromatic homologous brest swanson. constitutive pizza buck remark beware gluing cacti vector vista cave.
heroine ephemerides vocate sweaty anywhere arraign compensatory. mackinac beware iconic lipstick clothesman doorman. blanchard bellman sprite sympathetic solon infight ketch permian gardner bauxite. lexical introspect appalachia approximant dissipate get cathedra teach. beloit beware nurture metabolite hellgrammite.
jilt protectorate lobar beware cryostat hiroshima help. confocal confess ephemerides faculty suny slimy globe biotic. setback beware apprehend damage cavort surprise.
delude buchanan zoe ephemerides bedraggle axial limpet animal hearst. blister egg gazelle paraboloid ephemerides sliver truancy boone. longitude roebuck acre mcconnell earthenware. postulate fireboat solon venturi clone entirety flex.
radiate rupee caloric dissipate guiana acadia. stacy ballroom roebuck curvaceous hexadecimal effort knew maid.
bacteria bustle dissipate dear coprinus. blaze anneal ephemerides landis penis. eightfold smithson doctoral roebuck cahoot galatea protege. len roebuck annalen rune wastage annalen warlike. ----6515134039285773520-- From service@paypal.com Sun Feb 6 07:14:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16451 for ; Sun, 6 Feb 2005 07:14:29 -0500 (EST) Received: from [209.213.123.118] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CxlcI-0003u2-17 for sctp-impl-archive@ietf.org; Sun, 06 Feb 2005 07:34:21 -0500 Received: from zd.lkvv.net [65.97.225.179] by 132.151.6.1 with ESMTP id 6D2AC3E3EB3; Sun, 06 Feb 2005 17:09:29 +0500 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Sun, 06 Feb 05 17:09:29 GMT X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0AF.C2A.5042.C1" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 26.2 (++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --0AF.C2A.5042.C1 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--0AF.C2A.5042.C1-- From Ware@awemail.com Sun Feb 6 09:39:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26248; Sun, 6 Feb 2005 09:39:33 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cxnsg-0006ha-LV; Sun, 06 Feb 2005 09:59:25 -0500 Received: from [69.65.131.42] (helo=SANTIAGO) by mx2.foretec.com with smtp (Exim 4.24) id 1CxnZK-0007iq-KN; Sun, 06 Feb 2005 09:39:28 -0500 Received: from [131.204.75.178] by may%DIGITS.autotransformer.69.65.131.42 via HTTP; Sun, 06 Feb 2005 09:38:15 -0800 Reply-To: "mail2world.com" From: "mail2world.com" To: Subject: Heyyy,, me again Date: Sun, 06 Feb 2005 09:38:15 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9233949790dltz8200" Message-Id: X-Spam-Score: 3.6 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c ----9233949790dltz8200 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable I just wanted to know if you would like to accompany me. My Husband works night shifts, which makes me very lonely at night. To contact me please go here: http://www.godatesaturday.com/d/1.php P.S. it's me Katherine t ----9233949790dltz8200-- From Puckett@mailAccount.com Sun Feb 6 18:23:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08257; Sun, 6 Feb 2005 18:23:06 -0500 (EST) Message-Id: <200502062323.SAA08257@ietf.org> Received: from [211.38.24.17] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cxw3S-0000Lh-E3; Sun, 06 Feb 2005 18:43:04 -0500 Received: from [53.76.144.149] by delaware%DIGITS.mason.211.38.24.17 via HTTP; Sun, 06 Feb 2005 18:22:32 -0800 Reply-To: "w Fields Inc." From: "w Fields Inc." To: Subject: Four beautiful matches Date: Sun, 06 Feb 2005 18:22:32 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7818843804vwvb3977" X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----7818843804vwvb3977 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 Cheating House Wife have been matched for you in your area: 1) Amber, 127 lbs, 5'5, 36c, 14 miles away, available most week nights ( l= ooking for side-fling) 2) Amber, 130 lbs, 5'9, 36d, 5 miles away, available Jan29-31th 3) Kayla, 125 lbs, 5'6, 34b, 13 miles away, available Jan 31- Feb 3rd 4) Alexis, 120 lbs, 5'5, 36c, 9 miles away, available Jan29-31th All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://www.godatequickly.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatequickly.com/out/=20 ----7818843804vwvb3977-- From service@paypal.com Sun Feb 6 18:46:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09663 for ; Sun, 6 Feb 2005 18:46:13 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxwPr-0000lj-D8 for sctp-impl-archive@ietf.org; Sun, 06 Feb 2005 19:06:11 -0500 Received: from [66.98.166.50] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Cxw6Q-0002A7-8R for sctp-impl-archive@ietf.org; Sun, 06 Feb 2005 18:46:06 -0500 Received: from xdnk.lfriuu.org (HELO m03zu) ([159.140.9.189]) by 65.246.255.50 id <3077423-85596>; Sun, 06 Feb 2005 22:37:06 -0100 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Sun, 06 Feb 05 22:37:06 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B.BCFBCA_C" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 17.0 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --B.BCFBCA_C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--B.BCFBCA_C-- From colmanMCWalina@soloellas.com Sun Feb 6 23:50:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01140; Sun, 6 Feb 2005 23:50:22 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy1AF-0006LI-Hn; Mon, 07 Feb 2005 00:10:23 -0500 Received: from [221.154.144.74] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Cy0qs-0008Hv-LT; Sun, 06 Feb 2005 23:50:23 -0500 Received: from box78.crescentlakelodge.com (221.154.144.74) by 221.154.144.74 (SimpleMailer v8.21) with SMTP id <96445gt7guw>; Mon, 07 Feb 2005 07:50:20 +0300 Reply-To: "beatriz cara" From: "beatriz cara" To: sctp-impl-archive@ietf.org Cc: dccp-request@ietf.org, midcom@ietf.org, ep@ietf.org, mipshop-admin@ietf.org, proval@ietf.org, ipr-wg-admin@ietf.org Subject: Attention: Account #5347 Date: Mon, 07 Feb 2005 00:41:20 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--785733_6184201.zyW011" Message-Id: X-Spam-Score: 8.2 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----785733_6184201.zyW011 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #7378909, We tried contacting you awhile ago about your low interest mort[g]age rate. You have qualified for the lowest rate in years. You could get over $400,000 for as little as $300 a month! Have Bad cr[e]dit? No Problem! Low rates are fixed no matter what. To get a free, no obligation consultation please visit: http://hotbed.wexvd.info:443/azwmlosteopathy Regards, beatriz cara, Account Manager JNM Associates Inc. r*mv. -> http://groulx.wexvd.info:443/index.php ----785733_6184201.zyW011-- From llgfiosl@biophys.uni-duesseldorf.de Mon Feb 7 02:03:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13034; Mon, 7 Feb 2005 02:03:38 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy3FD-0000NM-GJ; Mon, 07 Feb 2005 02:23:39 -0500 Received: from 242862hfc108.tampabay.rr.com ([24.28.62.108]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cy2vm-0002Pt-1q; Mon, 07 Feb 2005 02:03:34 -0500 X-Message-Info: A0KL1TOSvlD9AVDAybMWjGN91BypLVZ5AxOWlIGRCE7DB Received: (from roughshod@localhost) by sharpshootbevy1.llgfiosl@biophys.uni-duesseldorf.de (C.62.E/1.83.2) id ab12BZSlGD6C50; Mon, 07 Feb 2005 01:02:15 -0600 Message-ID: <71992AE833.015B7@llgfiosl@biophys.uni-duesseldorf.de> Reply-To: "Bessie Mayfield" From: "Bessie Mayfield" To: "Ssm-request" Subject: we catch the breakouts on the charts for you Date: Mon, 07 Feb 2005 02:57:15 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--368F2CD70BE2CE89" X-Spam-Score: 7.0 (+++++++) X-Spam-Flag: YES X-Scan-Signature: a8a20a483a84f747e56475e290ee868e ----368F2CD70BE2CE89 Content-Type: text/plain; charset="iso-BFDA-A" Content-Transfer-Encoding: quoted-printable Traders' Monthly Alert January Pick (BMXG) exploded from .20 to 2.07, a gain of over 900% in 6 days (1/18 - 1/24)! Our next pick is an incredible find that will outperform all others based on their solid numbers, huge sales backlog,$2 Billion in financing, low outstanding shares, and a deal with Chinese Government-run companies totaling $10 Billion! Urgent Buy at any Price: Global Environmental Energy Corp. OTCBB - GEEC Current Price - 1.90 Running To - 6.00 GEEC is CBS Marketwatch.com's #1 Best Performer in the DJ Diversified Industrials Index in the last 2 months. This is a Dow Jones Industry Index that also contains 3M, GE, and Honeywell. We are sending this URGENT INVESTOR BULLETIN REVEALING THE MOST UNDERVALUED PICK ON THE OTCBB to our millions of subscribers for substantial profits immediately! GEEC has experienced a recent spike in price and volume indicating heavy accumulation of shares. This is a sign of even bigger things to come for this emerging world leader in the conversion of waste materials into electrical energy, an industry with such high global demand that it is impossible to assign a value to the size of the market. GEEC is utilizing the unique proprietary technology of their Biosphere Process System for the disposal of a wide variety of waste products at 5 to 7 tons per hour, making a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. GEEC generates 5 to 10 mega-watts per hour of electricity from the waste conversion on a continuous basis which is then sold to replenish the local or national grid. The Biosphere Process succeeds in filling an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. GEEC has secured international acceptance for a revolutionary product designed to significantly impact the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. GEEC just announced a $10 Billion, 5-year joint venture with Chinese Government-operated companies, including Yanzhou Coal Mining (NYSE - YZC, $74). The deal is structured to have 1,300 GEEC Biosphere Systems deployed throughout China to fulfill an urgent need for waste disposal and energy generation, two critical areas for a country with a population exceeding 1.3 billion people. As China's rapid economic advance continues, a shortfall of 500 million kilowatts exists annually, prompting periodic blackouts in all Chinese Provinces. GEEC is in line to profit substantially while providing relief from unmanageable Municpal Solid Waste disposal and simultaneously helping China meet its energy needs. The forecast for GEEC is crystal clear, and this is just the tip of the iceberg for this emerging worldwide leader where shares should be added immediately to every portfolio. We expect a continuous flow of huge news announcements while shares still represent an uncommon value for a Company of this caliber. Look for the continuation of strong positive developments that will ignite GEEC, which earns our highest rating for the most explosive gains on Wall Street. Traders' Monthly Alert (TMA) is not a registered investment advisor or broker dealer. Certain statements contained in this newsletter may be forward-looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", "may", "will", and "intend" or similar terms may identify these statements. Past performance is not an indicator of future results. This is not an offer to buy or sell securities. TMA is an independent publication that was paid nine thousand dollars by a third party for the continuing coverage and dissemination of this company information. Investors are advised to seek proper guidance from a financial advisor or a registered financial broker. Investors should use the information provided in this newsletter as a starting point for gathering additional information on the profiled company to allow the investor to form their own opinion regarding investment. Investing in micro-cap securities is highly speculative and carries an extremely high degree of risk and may result in the loss of some or all of the investment. ----368F2CD70BE2CE89-- From bnmghwyvsfoaqo@concentric.net Mon Feb 7 10:19:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07204; Mon, 7 Feb 2005 10:19:48 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyAzQ-0002iU-Sj; Mon, 07 Feb 2005 10:39:55 -0500 Received: from [201.138.95.240] (helo=dsl-201-138-95-240.prod-infinitum.com.mx) by mx2.foretec.com with smtp (Exim 4.24) id 1CyAfw-0006rq-Pa; Mon, 07 Feb 2005 10:19:45 -0500 X-Message-Info: 7dso71jqVYL/goWHIjoSJIxiIGwauHZ8RBq Received: from seventh (32.120.252.215) by r593.zoology.crowbait.cooky.yeah.net (InterMail vZ.9.54.57.40 016-6960-940-2-682-3789744) with ESMTP id <2192807340.BATEP4719.srrr972-mail.halpern.collegial.net.cable.rogers.com@guarantor> for ; Mon, 07 Feb 2005 10:16:35 -0500 Message-ID: <56010hgq64944vo$2429ybt386$53106ev97spr62@pemmican> Reply-To: "Lucas Ford" From: "Lucas Ford" To: Subject: Clap tp the new player in the pherma biz! slew Date: Mon, 07 Feb 2005 09:10:35 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6679620707726851726" X-Spam-Score: 21.1 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ----6679620707726851726 Content-Type: text/html; Content-Transfer-Encoding: 7Bit There's a new player in the hood - and you're gonna like it.
Yep, nomore the old fashion, this one is new, good and will
give it to you like with prjjces you never knew you can get.
I'm talking about the new shoop.
Come iin to observe more!
We can't wait till the winter comes :)

naa h dessicate draftsman

denotation akron inn elliott springtime fan armature. absolute inn gus wilhelmina anorthite joyce bedspring. decorum asterisk inn jacobs safe daisy.
plaque dearborn bonze carbonic deposit gideon bangor calcify incandescent. eastbound halpern giddy mail cetus blacken. richmond balzac inn dirac pontiac.
diaphragm produce obsequious inn corrosion fiancee b's. residuum groundsel anastasia faucet ax downriver deforestation leopard week.
limitate diffract dartmouth nabisco inn hit sanderling bookseller. fable backpack persevere suppressor faucet erik jot petrology. show coddington halpern drink inundate. affiliate inn radices barton depredate.
birmingham rant carbonic mettlesome referral filamentary kinetic. daybreak staid align denunciation confucianism skeletal. faulkner pintail wrongful broom dreamboat advert madison aorta. illusive inn primitivism aeneas ak canadian binuclear.
opulent chummy vulture brushy denunciation contingent aileen permian carleton roundup. bicentennial capistrano faucet wolfish frankel bologna wrote infix. leone heterodyne thor affectate halpern erie human curfew rufus. counterbalance hostler carbonic abstention atlantes. ----6679620707726851726-- From lehmann@ulticom.com Mon Feb 7 14:35:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03575 for ; Mon, 7 Feb 2005 14:35:30 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyEyw-0000ZH-1z for sctp-impl-archive@ietf.org; Mon, 07 Feb 2005 14:55:38 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 07 Feb 2005 11:45:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j17JYPuC028885; Mon, 7 Feb 2005 11:34:25 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j17JWw7U023352 for sctp-impl-filtered; Mon, 7 Feb 2005 11:33:00 -0800 (PST) Message-Id: <200502071933.j17JWw7U023352@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107804778-23350-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: bind/sctp_bindx API - binding to all IPv4 and IPv6 addresses List-Id: sctp-impl To: SCTP Implementors From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Mon, 07 Feb 2005 14:09:11 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 This is a multi-part message in MIME format... ------------=_1107804778-23350-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hello, In the SCTP API draft, section 4.1.2, it states: If addr is specified as a wildcard (INADDR_ANY for an IPv4 address, or as IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the operating system will associate the endpoint with an optimal address set of the available interfaces. If an app passes the AF_INET6 wildcard address to bind() with a PF_INET6 socket, does it bind to all IPv4 _and_ IPv6 addresses since an PF_INET6 socket "can use both IPv6 and IPv4 addresses"? If not, how does an app bind to all IPv6 and IPv4 addresses? -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1107804778-23350-0-- From lehmann@ulticom.com Mon Feb 7 16:38:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24392 for ; Mon, 7 Feb 2005 16:38:02 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyGtX-0006HB-Ba for sctp-impl-archive@ietf.org; Mon, 07 Feb 2005 16:58:12 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2005 13:46:07 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j17LbGTj021277; Mon, 7 Feb 2005 13:37:17 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j17LZp7U025259 for sctp-impl-filtered; Mon, 7 Feb 2005 13:35:53 -0800 (PST) Message-Id: <200502072135.j17LZp7U025259@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107812151-25255-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: bind/sctp_bindx API - binding to all IPv4 and IPv6 addresses List-Id: sctp-impl To: Michael Tuexen From: David Lehmann Cc: SCTP Implementors X-Nails-Approved: lehmann@ulticom.com Date: Mon, 07 Feb 2005 16:12:08 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 This is a multi-part message in MIME format... ------------=_1107812151-25255-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Michael Tuexen wrote: > Hi David, > > my understanding is that > if you specify the IPv4 wildcard address you get only IPv4 addresses > if you specify the IPv6 wildcard address you get IPv4 and IPv6 addresses. Thanks. Maybe the spec should explicitly state this. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1107812151-25255-0-- From Michael.Tuexen@micmac.franken.de Mon Feb 7 16:45:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26217 for ; Mon, 7 Feb 2005 16:45:09 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyH0R-0006rn-P0 for sctp-impl-archive@ietf.org; Mon, 07 Feb 2005 17:05:20 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2005 13:44:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j17LiMuC011003; Mon, 7 Feb 2005 13:44:22 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j17LhI7U025373 for sctp-impl-filtered; Mon, 7 Feb 2005 13:43:20 -0800 (PST) Message-Id: <200502072143.j17LhI7U025373@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107812598-25371-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: bind/sctp_bindx API - binding to all IPv4 and IPv6 addresses List-Id: sctp-impl To: David Lehmann From: Michael Tuexen Cc: SCTP Implementors X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Mon, 7 Feb 2005 22:02:00 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format... ------------=_1107812598-25371-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hi David, my understanding is that if you specify the IPv4 wildcard address you get only IPv4 addresses if you specify the IPv6 wildcard address you get IPv4 and IPv6 addresses. Best regards Michael On Feb 7, 2005, at 20:09 Uhr, David Lehmann wrote: > Hello, > > In the SCTP API draft, section 4.1.2, it states: > If addr is specified as a wildcard (INADDR_ANY for an IPv4 address, > or as IN6ADDR_ANY_INIT or in6addr_any for an IPv6 address), the > operating system will associate the endpoint with an optimal address > set of the available interfaces. > > If an app passes the AF_INET6 wildcard address to bind() with a > PF_INET6 > socket, does it bind to all IPv4 _and_ IPv6 addresses since an PF_INET6 > socket "can use both IPv6 and IPv4 addresses"? > > If not, how does an app bind to all IPv6 and IPv4 addresses? > > -- > > David Lehmann Ulticom, Inc. > AOL/Yahoo IM: davidULCM 1020 Briggs Road > 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1107812598-25371-0-- From vechcccfnqoXUQuh@grunenthal.com Tue Feb 8 06:02:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26872; Tue, 8 Feb 2005 06:02:55 -0500 (EST) Message-Id: <200502081102.GAA26872@ietf.org> Received: from [219.241.91.251] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CyTSS-0001AN-0h; Tue, 08 Feb 2005 06:23:12 -0500 Received: from terminalo5.remaxmail.com (219.241.91.251) by 219.241.91.251 (MediaMailer 88) with SMTP id <780O19j>; Tue, 08 Feb 2005 05:57:10 -0500 Reply-To: "chrystal elwood" From: "chrystal elwood" To: bmanet@ietf.org Cc: g-admin@ietf.org, sctp-impl-archive@ietf.org, dccp-request@ietf.org, midcom@ietf.org, ep@ietf.org, mipshop-admin@ietf.org, proval@ietf.org, ipr-wg-admin@ietf.org, bipv6@ietf.org, ipr-wg-web-archive@ietf.org, xmldsig-archive@ietf.org, ma-admin@ietf.org Subject: Notice: Congrats. You have been accepted Date: Tue, 08 Feb 2005 04:00:10 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--384700_592140.ZK665" X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----384700_592140.ZK665 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #7985196, Your application was approved. You are eligible for $400,000 with a 3.7 % rate. Please confirm your information here: http://arouse.wexvd.info:443/azwmlluxuriant We look forward to hearing from you. Regards, chrystal elwood, Senior Account Manager KNM Financial Group r*mv. -> http://craggie.wexvd.info:443/index.php ----384700_592140.ZK665-- From lehmann@ulticom.com Tue Feb 8 09:52:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14036 for ; Tue, 8 Feb 2005 09:52:32 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyX2o-0006I8-0C for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 10:12:50 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2005 08:03:32 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j18EpZTj010411; Tue, 8 Feb 2005 06:51:35 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18EnZ7U011264 for sctp-impl-filtered; Tue, 8 Feb 2005 06:49:37 -0800 (PST) Message-Id: <200502081449.j18EnZ7U011264@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107874174-11256-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: SCTP Implementors From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Tue, 08 Feb 2005 09:25:39 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format... ------------=_1107874174-11256-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hello, Sections 8.3 and 8.5 are not clear on exactly what structures are being returned. It states: On return, addrs will point to a dynamically allocated array of sockaddr structures of the appropriate type for the socket type. The caller should use sctp_freeladdrs() to free the memory. Note that the in/out parameter addrs must not be NULL. If sd is an IPv4 socket, the addresses returned will be all IPv4 addresses. If sd is an IPv6 socket, the addresses returned can be a mix of IPv4 or IPv6 addresses. IMHO, something similar to the following would be more explicit: On return, addrs will point to a dynamically allocated array of sockaddr structures of the appropriate type for the socket type. If sd is an IPv4 socket, 'addrs' will point to an array of struct sockaddr_in and the addresses returned will be all IPv4 addresses. If sd is an IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6 and the addresses returned will be IPv6 addresses and/or IPv4 mapped addresses. The caller should use sctp_freeladdrs() to free the memory. Note that the in/out parameter 'addrs' must not be NULL. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1107874174-11256-0-- From rrs@cisco.com Tue Feb 8 11:28:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22162 for ; Tue, 8 Feb 2005 11:28:46 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyYXx-0008OS-4c for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 11:49:06 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2005 08:30:36 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j18GRaYO019923; Tue, 8 Feb 2005 08:27:36 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18GQF7U012703 for sctp-impl-filtered; Tue, 8 Feb 2005 08:26:17 -0800 (PST) Message-Id: <200502081626.j18GQF7U012703@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107879975-12701-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: bind/sctp_bindx API - binding to all IPv4 and IPv6 addresses List-Id: sctp-impl To: David Lehmann From: Randall Stewart Cc: Michael Tuexen , SCTP Implementors X-Nails-Approved: rrs@cisco.com Date: Tue, 08 Feb 2005 11:23:52 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format... ------------=_1107879975-12701-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Michael Tuexen wrote: > >> Hi David, >> >> my understanding is that >> if you specify the IPv4 wildcard address you get only IPv4 addresses >> if you specify the IPv6 wildcard address you get IPv4 and IPv6 addresses. > > > Thanks. Maybe the spec should explicitly state this. > Actually.. some os's have an option as well that tells it NOT to include V4 addresses... aka a V6_ONLY option.. I know its that way in FreeBSD and NetBSD... R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1107879975-12701-0-- From rrs@cisco.com Tue Feb 8 11:31:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22349 for ; Tue, 8 Feb 2005 11:31:22 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyYaU-0008RY-7j for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 11:51:42 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 08 Feb 2005 08:41:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j18GUYuC017561; Tue, 8 Feb 2005 08:30:34 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18GTE7U012759 for sctp-impl-filtered; Tue, 8 Feb 2005 08:29:16 -0800 (PST) Message-Id: <200502081629.j18GTE7U012759@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107880154-12757-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: David Lehmann From: Randall Stewart Cc: SCTP Implementors X-Nails-Approved: rrs@cisco.com Date: Tue, 08 Feb 2005 11:26:51 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format... ------------=_1107880154-12757-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Hello, > > Sections 8.3 and 8.5 are not clear on exactly what structures are being > returned. It states: > On return, addrs will point to a dynamically allocated array of > sockaddr structures of the appropriate type for the socket type. The > caller should use sctp_freeladdrs() to free the memory. Note that > the in/out parameter addrs must not be NULL. > > If sd is an IPv4 socket, the addresses returned will be all IPv4 > addresses. If sd is an IPv6 socket, the addresses returned can be a > mix of IPv4 or IPv6 addresses. > > IMHO, something similar to the following would be more explicit: > On return, addrs will point to a dynamically allocated array of > sockaddr structures of the appropriate type for the socket type. > If sd is an IPv4 socket, 'addrs' will point to an array of struct > sockaddr_in > and the addresses returned will be all IPv4 addresses. If sd is an > IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6 > and the > addresses returned will be IPv6 addresses and/or IPv4 mapped addresses. > > The caller should use sctp_freeladdrs() to free the memory. Note that > the in/out parameter 'addrs' must not be NULL. > > Except that if an implementation supports the SCTP_I_WANT_MAPPED_V4_ADDR And this is turned OFF Then you would get a mix of V4 and V6 addresses (what Kacheong hates).. which is why it is vague... For some O/S's (such as Kacheongs) you cannto turn SCTP_I_WANT_MAPPED_V4_ADDR Off... and thats fine.. then your statements above would be completely true.. For other OS's.. aka BSD.. you CAN disable that option so you would get back a mix.. R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1107880154-12757-0-- From peterlei@cisco.com Tue Feb 8 11:33:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22703 for ; Tue, 8 Feb 2005 11:33:23 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyYcR-000088-5m for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 11:53:43 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2005 08:35:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j18GWHYO023562; Tue, 8 Feb 2005 08:32:17 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18GVK7U012802 for sctp-impl-filtered; Tue, 8 Feb 2005 08:31:22 -0800 (PST) Message-Id: <200502081631.j18GVK7U012802@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107880280-12794-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: bind/sctp_bindx API - binding to all IPv4 and IPv6 addresses List-Id: sctp-impl To: David Lehmann From: "Peter Lei (peterlei)" Cc: Michael Tuexen , SCTP Implementors X-Nails-Approved: peterlei@cisco.com Date: Tue, 08 Feb 2005 10:31:12 -0600 X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f This is a multi-part message in MIME format... ------------=_1107880280-12794-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary There are IPv6 socket options and kernel sysctl's (in BSD and MacOS X) that allow you to turn off allowing mapped-v4 addresses from being bound to or used on a PF_INET6 socket, so the behavior below isn't always true. regards, --peter David Lehmann wrote: > Michael Tuexen wrote: > >> Hi David, >> >> my understanding is that >> if you specify the IPv4 wildcard address you get only IPv4 addresses >> if you specify the IPv6 wildcard address you get IPv4 and IPv6 addresses. > > > Thanks. Maybe the spec should explicitly state this. > ------------=_1107880280-12794-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIII7TCCAtEwggI6oAMCAQICAwxyhzANBgkqhkiG9w0BAQQFADBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDQwNjA1MDQ1NTQ0WhcNMDUwNjA1MDQ1NTQ0WjBEMR8wHQYD VQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJw ZXRlcmxlaUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQC9rZ9kcVLLLaGH+l9F6povc84U8YI7yBX3y2xYvjQaF9wSaQEyQH1M C+NuugQbT2LCxhgY9926wQfmvxhlnUF1+1EI6YXC2MYO8qSn96BKmlwGdcOK atnxsxIHSENsLzJD5wEi030wBXG9hMkBZ69ltNpfcntG5zXPxizP4Xq3jYEW 9d2zRhvImbS8r3j1VoeGA5wTWe56+oGr6muyElAveS8Krx84riDColSJTmY0 rVPABcL4/po9qKuuvPvdSDeWJaYcj8jYYzPxxpmIGHe4zJdY3Qd/lhprf/ng QE54KpJqvgaithVcCGNbv6WQj1OIo7dp1pvLDS+K+uLD1MVvAgMBAAGjLzAt MB0GA1UdEQQWMBSBEnBldGVybGVpQGNpc2NvLmNvbTAMBgNVHRMBAf8EAjAA MA0GCSqGSIb3DQEBBAUAA4GBAF7JfZeV9FgJbi3fZc8cfInP5HUq0FClGa6W wFu7cYQ0IScUn9mv5ZU8g9yFL7AtL5HaRUUehPG81Aa2jMhD2LkJTk+VdIEB aRPM8aUaiSuJGl7DOCrstRolFfgkQZXuYLQ72JlR52/KNakDe2Dpd+1i1Rd9 ox6E3AU5c6UGnTRGMIIC0TCCAjqgAwIBAgIDDHKHMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQTAeFw0wNDA2MDUwNDU1NDRaFw0wNTA2MDUwNDU1NDRaMEQx HzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0B CQEWEnBldGVybGVpQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAL2tn2RxUsstoYf6X0Xqmi9zzhTxgjvIFffLbFi+NBoX3BJp ATJAfUwL4266BBtPYsLGGBj33brBB+a/GGWdQXX7UQjphcLYxg7ypKf3oEqa XAZ1w4pq2fGzEgdIQ2wvMkPnASLTfTAFcb2EyQFnr2W02l9ye0bnNc/GLM/h ereNgRb13bNGG8iZtLyvePVWh4YDnBNZ7nr6gavqa7ISUC95LwqvHziuIMKi VIlOZjStU8AFwvj+mj2oq668+91IN5YlphyPyNhjM/HGmYgYd7jMl1jdB3+W Gmt/+eBATngqkmq+BqK2FVwIY1u/pZCPU4ijt2nWm8sNL4r64sPUxW8CAwEA AaMvMC0wHQYDVR0RBBYwFIEScGV0ZXJsZWlAY2lzY28uY29tMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAXsl9l5X0WAluLd9lzxx8ic/kdSrQ UKUZrpbAW7txhDQhJxSf2a/llTyD3IUvsC0vkdpFRR6E8bzUBraMyEPYuQlO T5V0gQFpE8zxpRqJK4kaXsM4Kuy1GiUV+CRBle5gtDvYmVHnb8o1qQN7YOl3 7WLVF32jHoTcBTlzpQadNEYwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEB BQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIw EAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG 9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3 MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb 8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20Txh BEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNV HR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVy c29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBP ZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYID OzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxyhzAJBgUrDgMCGgUAoIIBpzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAyMDgx NjMxMTJaMCMGCSqGSIb3DQEJBDEWBBRHgJydZVr0GlPIqTWrmCb7V+HjSDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEE AYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDDHKHMHoGCyqGSIb3DQEJEAILMWugaTBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAwxyhzANBgkqhkiG9w0BAQEFAASCAQBrk4mu258vF5jr0zIZ +IuSpjEyfuwSllqaXiVCTeJvugWVT4+QpJOs8VkLDr78fBDmMxnzOzKAPPbz JJ5SV2WdT+IwuLuuhczrkSts1uO9bqKDYn+QJMi3dqh5qdLZOnaqZvh7l3g0 gWz8dmCRIsafEAUOtsIRkiVusYqf3dRigAkbdnIxAB7NLPcJrZctIshfLzJY CsQXb9jFfvdfvEzeVDEvMk8EvobflqavH9qPFlXZqcOBZ2x2tslLVzyFvfkL YPgUxv02X17raLlEHLZw7YdxjhOV9wEDWcA7Qn/dmDoL+6h+HWb7H0jJYCJy Y6pQ+1Js+0i6C+SgUGlrwMlkAAAAAAAA ------------=_1107880280-12794-0-- From peterlei@cisco.com Tue Feb 8 11:35:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22960 for ; Tue, 8 Feb 2005 11:35:49 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyYem-0000DM-Om for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 11:56:09 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2005 09:46:52 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j18GZ3uC019166; Tue, 8 Feb 2005 08:35:03 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18GY57U012864 for sctp-impl-filtered; Tue, 8 Feb 2005 08:34:07 -0800 (PST) Message-Id: <200502081634.j18GY57U012864@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107880444-12862-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: bind/sctp_bindx API - binding to all IPv4 and IPv6 addresses List-Id: sctp-impl To: David Lehmann From: "Peter Lei (peterlei)" Cc: Michael Tuexen , SCTP Implementors X-Nails-Approved: peterlei@cisco.com Date: Tue, 08 Feb 2005 10:33:58 -0600 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 This is a multi-part message in MIME format... ------------=_1107880444-12862-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary There are IPv6 socket options and kernel sysctl's (in BSD and MacOS X) that allow you to turn off allowing mapped-v4 addresses from being bound to or used on a PF_INET6 socket, so the behavior below isn't always true. regards, --peter David Lehmann wrote: > Michael Tuexen wrote: > >> Hi David, >> >> my understanding is that >> if you specify the IPv4 wildcard address you get only IPv4 addresses >> if you specify the IPv6 wildcard address you get IPv4 and IPv6 addresses. > > > Thanks. Maybe the spec should explicitly state this. > ------------=_1107880444-12862-0-- From peterlei@cisco.com Tue Feb 8 11:46:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23756 for ; Tue, 8 Feb 2005 11:46:54 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyYpV-0000Ta-KK for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 12:07:14 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Feb 2005 08:46:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j18GjvwN017872; Tue, 8 Feb 2005 08:45:58 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18Gio7U013048 for sctp-impl-filtered; Tue, 8 Feb 2005 08:44:52 -0800 (PST) Message-Id: <200502081644.j18Gio7U013048@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107881090-13040-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: David Lehmann From: "Peter Lei (peterlei)" Cc: SCTP Implementors X-Nails-Approved: peterlei@cisco.com Date: Tue, 08 Feb 2005 10:44:43 -0600 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 This is a multi-part message in MIME format... ------------=_1107881090-13040-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Hello, > > Sections 8.3 and 8.5 are not clear on exactly what structures are being > returned. It states: > On return, addrs will point to a dynamically allocated array of > sockaddr structures of the appropriate type for the socket type. The > caller should use sctp_freeladdrs() to free the memory. Note that > the in/out parameter addrs must not be NULL. > > If sd is an IPv4 socket, the addresses returned will be all IPv4 > addresses. If sd is an IPv6 socket, the addresses returned can be a > mix of IPv4 or IPv6 addresses. > > IMHO, something similar to the following would be more explicit: > On return, addrs will point to a dynamically allocated array of > sockaddr structures of the appropriate type for the socket type. > If sd is an IPv4 socket, 'addrs' will point to an array of struct > sockaddr_in > and the addresses returned will be all IPv4 addresses. If sd is an > IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6 > and the > addresses returned will be IPv6 addresses and/or IPv4 mapped addresses. It is not necessarily v4-mapped addresses that are returned (if allowed/enabled). The SCTP_I_WANT_MAPPED_V4_ADDRESSES option determines what kind of v4 addresses are returned: v4 addresses (if "off"), or v4-mapped addresses (if "on"). See section 7.1.16. Our BSD implementation (in KAME) supports this option. regards, --peter > The caller should use sctp_freeladdrs() to free the memory. Note that > the in/out parameter 'addrs' must not be NULL. > > ------------=_1107881090-13040-0-- From TWRFTMGGKK@sm.ee Tue Feb 8 14:23:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06413; Tue, 8 Feb 2005 14:22:57 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CybGV-0003ua-HI; Tue, 08 Feb 2005 14:43:18 -0500 Received: from [170.94.166.173] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Cyawn-0003TT-BV; Tue, 08 Feb 2005 14:22:53 -0500 X-Message-Info: 3E7BJ23Oljws81ATAcfTElsNTFD5wMSU1DCgbLGNdchQ310EG18 Received: from 152.183.148.22 by F2-sq6E.989.TWRFTMGGKK@sm.ee with DAV; Tue, 08 Feb 2005 12:22:44 -0700 Message-ID: X-Originating-IP: [85.212.170.60] X-Originating-Email: [TWRFTMGGKK@sm.ee] X-Sender: TWRFTMGGKK@sm.ee Reply-To: "Garrett Bradley" From: "Garrett Bradley" To: "Rserpool" Subject: we catch the breakouts on the charts for you Date: Wed, 09 Feb 2005 00:13:44 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--158ECA3CA7D0C2316" X-Spam-Score: 14.4 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: a8a20a483a84f747e56475e290ee868e ----158ECA3CA7D0C2316 Content-Type: text/plain; charset="iso-121D-C" Content-Transfer-Encoding: quoted-printable Traders' Monthly Alert January Pick (BMXG) exploded from .20 to 2.07, a gain of over 900% in 6 days (1/18 - 1/24)! Our next pick is an incredible find that will outperform all others based on their solid numbers, huge sales backlog,$2 Billion in financing, low outstanding shares, and a deal with Chinese Government-run companies totaling $10 Billion! Urgent Buy at any Price: Global Environmental Energy Corp. OTCBB - GEEC Current Price - 1.90 Running To - 6.00 GEEC is CBS Marketwatch.com's #1 Best Performer in the DJ Diversified Industrials Index in the last 2 months. This is a Dow Jones Industry Index that also contains 3M, GE, and Honeywell. We are sending this URGENT INVESTOR BULLETIN REVEALING THE MOST UNDERVALUED PICK ON THE OTCBB to our millions of subscribers for substantial profits immediately! GEEC has experienced a recent spike in price and volume indicating heavy accumulation of shares. This is a sign of even bigger things to come for this emerging world leader in the conversion of waste materials into electrical energy, an industry with such high global demand that it is impossible to assign a value to the size of the market. GEEC is utilizing the unique proprietary technology of their Biosphere Process System for the disposal of a wide variety of waste products at 5 to 7 tons per hour, making a major impact on the global waste problem. This profitable and environmentally safe process converts into clean, "green" electricity such waste materials as Municipal Solid Waste, agricultural wastes, forestry wastes, medical wastes, industrial wastes, sewage sludge, shale oil, sour natural gas, and the huge market of used tires. GEEC generates 5 to 10 mega-watts per hour of electricity from the waste conversion on a continuous basis which is then sold to replenish the local or national grid. The Biosphere Process succeeds in filling an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. GEEC has secured international acceptance for a revolutionary product designed to significantly impact the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. GEEC just announced a $10 Billion, 5-year joint venture with Chinese Government-operated companies, including Yanzhou Coal Mining (NYSE - YZC, $74). The deal is structured to have 1,300 GEEC Biosphere Systems deployed throughout China to fulfill an urgent need for waste disposal and energy generation, two critical areas for a country with a population exceeding 1.3 billion people. As China's rapid economic advance continues, a shortfall of 500 million kilowatts exists annually, prompting periodic blackouts in all Chinese Provinces. GEEC is in line to profit substantially while providing relief from unmanageable Municpal Solid Waste disposal and simultaneously helping China meet its energy needs. The forecast for GEEC is crystal clear, and this is just the tip of the iceberg for this emerging worldwide leader where shares should be added immediately to every portfolio. We expect a continuous flow of huge news announcements while shares still represent an uncommon value for a Company of this caliber. Look for the continuation of strong positive developments that will ignite GEEC, which earns our highest rating for the most explosive gains on Wall Street. Traders' Monthly Alert (TMA) is not a registered investment advisor or broker dealer. Certain statements contained in this newsletter may be forward-looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", "may", "will", and "intend" or similar terms may identify these statements. Past performance is not an indicator of future results. This is not an offer to buy or sell securities. TMA is an independent publication that was paid nine thousand dollars by a third party for the continuing coverage and dissemination of this company information. Investors are advised to seek proper guidance from a financial advisor or a registered financial broker. Investors should use the information provided in this newsletter as a starting point for gathering additional information on the profiled company to allow the investor to form their own opinion regarding investment. Investing in micro-cap securities is highly speculative and carries an extremely high degree of risk and may result in the loss of some or all of the investment. ----158ECA3CA7D0C2316-- From lehmann@ulticom.com Tue Feb 8 14:37:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07665 for ; Tue, 8 Feb 2005 14:37:52 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CybUy-0004Fr-Gc for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 14:58:12 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Feb 2005 11:37:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j18JanwN026640; Tue, 8 Feb 2005 11:36:49 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18JZ77U015623 for sctp-impl-filtered; Tue, 8 Feb 2005 11:35:09 -0800 (PST) Message-Id: <200502081935.j18JZ77U015623@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107891307-15621-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: SCTP Implementors From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Tue, 08 Feb 2005 14:12:04 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This is a multi-part message in MIME format... ------------=_1107891307-15621-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: > David Lehmann wrote: > >> Hello, >> >> Sections 8.3 and 8.5 are not clear on exactly what structures are being >> returned. It states: >> On return, addrs will point to a dynamically allocated array of >> sockaddr structures of the appropriate type for the socket type. The >> caller should use sctp_freeladdrs() to free the memory. Note that >> the in/out parameter addrs must not be NULL. >> >> If sd is an IPv4 socket, the addresses returned will be all IPv4 >> addresses. If sd is an IPv6 socket, the addresses returned can be a >> mix of IPv4 or IPv6 addresses. >> >> IMHO, something similar to the following would be more explicit: >> On return, addrs will point to a dynamically allocated array of >> sockaddr structures of the appropriate type for the socket type. >> If sd is an IPv4 socket, 'addrs' will point to an array of struct >> sockaddr_in >> and the addresses returned will be all IPv4 addresses. If sd is an >> IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6 >> and the >> addresses returned will be IPv6 addresses and/or IPv4 mapped >> addresses. >> >> The caller should use sctp_freeladdrs() to free the memory. Note that >> the in/out parameter 'addrs' must not be NULL. >> >> > Except that if an implementation supports the > SCTP_I_WANT_MAPPED_V4_ADDR > > And this is turned OFF > > Then you would get a mix of V4 and V6 addresses (what Kacheong hates).. > which is why it is vague... > > For some O/S's (such as Kacheongs) you cannto turn > SCTP_I_WANT_MAPPED_V4_ADDR > Off... and thats fine.. then your statements above would be completely > true.. > > For other OS's.. aka BSD.. you CAN disable that option so you would > get back a mix.. OK then, explain to me what the "mixed" return data is. Are you stating that there could be sockaddr_in6 elements _and_ sockaddr_in elements returned? i.e. I can't index into the "array" buy rather have to move the pointer down the appropriate number of bytes depending on the record? e.g. struct sockaddr *addrs; int count; count = sctp_getpaddrs(sd, id, &addrs); while (count-- >= 0) { if (addrs->sa_family == AF_INET) { struct sockaddr_in *sin = (struct sockaddr_in *)addrs; /* Do something with returned address */ ... /* go to next addr */ addrs = (struct sockaddr *)(sin + 1) } else if (addrs->sa_family == AF_INET6) { struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)addrs; /* Do something with returned address */ ... /* go to next addr */ addrs = (struct sockaddr *)(sin6 + 1) } else { /* bogus family */ } } -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1107891307-15621-0-- From kacheong.poon@sun.com Tue Feb 8 14:47:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08362 for ; Tue, 8 Feb 2005 14:47:01 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cybdo-0004Ty-Cz for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 15:07:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2005 12:58:02 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,187,1102291200"; d="scan'208"; a="224324125:sNHT68244140" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j18Jk0q8025125; Tue, 8 Feb 2005 11:46:00 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18Jic7U015768 for sctp-impl-filtered; Tue, 8 Feb 2005 11:44:40 -0800 (PST) Message-Id: <200502081944.j18Jic7U015768@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107891878-15766-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: bind/sctp_bindx API - binding to all IPv4 and IPv6 addresses List-Id: sctp-impl To: SCTP Implementors From: Kacheong Poon X-Nails-Approved: kacheong.poon@sun.com Date: Tue, 08 Feb 2005 11:43:51 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a This is a multi-part message in MIME format... ------------=_1107891878-15766-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: > Actually.. some os's have an option as well that tells > it NOT to include V4 addresses... > > aka a V6_ONLY option.. I know its that way in FreeBSD and > NetBSD... It is the IPPROTO_IPV6 level option IPV6_V6ONLY. It is specified in RFC 3493. So I think most socket based v6 implementations have that. -- K. Poon. kacheong.poon@sun.com ------------=_1107891878-15766-0-- From kacheong.poon@sun.com Tue Feb 8 14:50:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08769 for ; Tue, 8 Feb 2005 14:50:54 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cybha-0004Zv-PI for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 15:11:15 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2005 13:01:54 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,187,1102291200"; d="scan'208"; a="224326177:sNHT36908652" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j18JnvTj012533; Tue, 8 Feb 2005 11:49:57 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18Jme7U015833 for sctp-impl-filtered; Tue, 8 Feb 2005 11:48:42 -0800 (PST) Message-Id: <200502081948.j18Jme7U015833@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107892120-15831-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: SCTP Implementors From: Kacheong Poon X-Nails-Approved: kacheong.poon@sun.com Date: Tue, 08 Feb 2005 11:46:51 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format... ------------=_1107892120-15831-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: > Except that if an implementation supports the > SCTP_I_WANT_MAPPED_V4_ADDR > > And this is turned OFF > > Then you would get a mix of V4 and V6 addresses (what Kacheong hates).. > which is why it is vague... I think this is more about programming practise. It is better to have an array of the same type struct than a list of mixed type struct because of alignment issues among other things. > For some O/S's (such as Kacheongs) you cannto turn > SCTP_I_WANT_MAPPED_V4_ADDR > Off... and thats fine.. then your statements above would be completely > true.. > > For other OS's.. aka BSD.. you CAN disable that option so you would > get back a mix.. > > R > -- K. Poon. kacheong.poon@sun.com ------------=_1107892120-15831-0-- From kacheong.poon@sun.com Tue Feb 8 16:07:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20200 for ; Tue, 8 Feb 2005 16:07:59 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CycuB-0007fb-HQ for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 16:28:20 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2005 14:19:02 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,187,1102291200"; d="scan'208"; a="224362531:sNHT29450388" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j18L6xq8014455; Tue, 8 Feb 2005 13:06:59 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18L5i7U017106 for sctp-impl-filtered; Tue, 8 Feb 2005 13:05:46 -0800 (PST) Message-Id: <200502082105.j18L5i7U017106@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107896744-17104-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: SCTP Implementors From: Kacheong Poon X-Nails-Approved: kacheong.poon@sun.com Date: Tue, 08 Feb 2005 13:05:01 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format... ------------=_1107896744-17104-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > OK then, explain to me what the "mixed" return data is. > Are you stating that there could be sockaddr_in6 elements _and_ > sockaddr_in elements returned? i.e. I can't index into the > "array" buy rather have to move the pointer down the appropriate > number of bytes depending on the record? The type cast of addrs to (struct sockaddr_in *) and (struct sockaddr_in6 *) in the following code may have problem because of alignment issue. So it is safer to copy from addrs to a local sockaddr variable and use the local instead. > e.g. > struct sockaddr *addrs; > int count; > > count = sctp_getpaddrs(sd, id, &addrs); > > while (count-- >= 0) > { > if (addrs->sa_family == AF_INET) > { > struct sockaddr_in *sin = (struct sockaddr_in *)addrs; > > /* Do something with returned address */ > ... > > /* go to next addr */ > addrs = (struct sockaddr *)(sin + 1) > } > else if (addrs->sa_family == AF_INET6) > { > struct sockaddr_in6 *sin6 = > (struct sockaddr_in6 *)addrs; > > /* Do something with returned address */ > ... > > /* go to next addr */ > addrs = (struct sockaddr *)(sin6 + 1) > } > else > { > /* bogus family */ > } > } > -- K. Poon. kacheong.poon@sun.com ------------=_1107896744-17104-0-- From rrs@cisco.com Tue Feb 8 17:12:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05931 for ; Tue, 8 Feb 2005 17:12:14 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyduO-0004LB-MU for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 17:32:37 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 08 Feb 2005 14:22:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,187,1102320000"; d="scan'208"; a="613062355:sNHT30881126" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j18MBQTj015646; Tue, 8 Feb 2005 14:11:27 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18MA87U018102 for sctp-impl-filtered; Tue, 8 Feb 2005 14:10:10 -0800 (PST) Message-Id: <200502082210.j18MA87U018102@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107900608-18094-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: David Lehmann From: Randall Stewart Cc: SCTP Implementors X-Nails-Approved: rrs@cisco.com Date: Tue, 08 Feb 2005 17:07:37 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e This is a multi-part message in MIME format... ------------=_1107900608-18094-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Randall Stewart wrote: > >> David Lehmann wrote: >> >>> Hello, >>> >>> Sections 8.3 and 8.5 are not clear on exactly what structures are being >>> returned. It states: >>> On return, addrs will point to a dynamically allocated array of >>> sockaddr structures of the appropriate type for the socket type. The >>> caller should use sctp_freeladdrs() to free the memory. Note that >>> the in/out parameter addrs must not be NULL. >>> >>> If sd is an IPv4 socket, the addresses returned will be all IPv4 >>> addresses. If sd is an IPv6 socket, the addresses returned can be a >>> mix of IPv4 or IPv6 addresses. >>> >>> IMHO, something similar to the following would be more explicit: >>> On return, addrs will point to a dynamically allocated array of >>> sockaddr structures of the appropriate type for the socket type. >>> If sd is an IPv4 socket, 'addrs' will point to an array of struct >>> sockaddr_in >>> and the addresses returned will be all IPv4 addresses. If sd is an >>> IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6 >>> and the >>> addresses returned will be IPv6 addresses and/or IPv4 mapped >>> addresses. >>> >>> The caller should use sctp_freeladdrs() to free the memory. Note >>> that >>> the in/out parameter 'addrs' must not be NULL. >>> >>> >> Except that if an implementation supports the >> SCTP_I_WANT_MAPPED_V4_ADDR >> >> And this is turned OFF >> >> Then you would get a mix of V4 and V6 addresses (what Kacheong hates).. >> which is why it is vague... >> >> For some O/S's (such as Kacheongs) you cannto turn >> SCTP_I_WANT_MAPPED_V4_ADDR >> Off... and thats fine.. then your statements above would be completely >> true.. >> >> For other OS's.. aka BSD.. you CAN disable that option so you would >> get back a mix.. > > > OK then, explain to me what the "mixed" return data is. > Are you stating that there could be sockaddr_in6 elements _and_ > sockaddr_in elements returned? i.e. I can't index into the > "array" buy rather have to move the pointer down the appropriate > number of bytes depending on the record? > > e.g. > struct sockaddr *addrs; > int count; > > count = sctp_getpaddrs(sd, id, &addrs); > > while (count-- >= 0) > { > if (addrs->sa_family == AF_INET) > { > struct sockaddr_in *sin = (struct sockaddr_in *)addrs; > > /* Do something with returned address */ > ... > > /* go to next addr */ > addrs = (struct sockaddr *)(sin + 1) > } > else if (addrs->sa_family == AF_INET6) > { > struct sockaddr_in6 *sin6 = > (struct sockaddr_in6 *)addrs; > > /* Do something with returned address */ > ... > > /* go to next addr */ > addrs = (struct sockaddr *)(sin6 + 1) > } > else > { > /* bogus family */ > } > } > Or in BSD land you can use the sa_len field.. thats what it is for. R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1107900608-18094-0-- From lehmann@ulticom.com Tue Feb 8 17:40:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09270 for ; Tue, 8 Feb 2005 17:40:16 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyeLW-0005TK-Uv for sctp-impl-archive@ietf.org; Tue, 08 Feb 2005 18:00:39 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2005 15:51:13 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,187,1102291200"; d="scan'208"; a="224399853:sNHT29093724" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j18MdFq8009658; Tue, 8 Feb 2005 14:39:16 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j18Mbw7U018526 for sctp-impl-filtered; Tue, 8 Feb 2005 14:38:00 -0800 (PST) Message-Id: <200502082238.j18Mbw7U018526@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107902278-18524-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: SCTP Implementors From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Tue, 08 Feb 2005 17:15:08 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format... ------------=_1107902278-18524-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: > David Lehmann wrote: > >> Hello, >> >> Sections 8.3 and 8.5 are not clear on exactly what structures are being >> returned. It states: >> On return, addrs will point to a dynamically allocated array of >> sockaddr structures of the appropriate type for the socket type. The >> caller should use sctp_freeladdrs() to free the memory. Note that >> the in/out parameter addrs must not be NULL. >> >> If sd is an IPv4 socket, the addresses returned will be all IPv4 >> addresses. If sd is an IPv6 socket, the addresses returned can be a >> mix of IPv4 or IPv6 addresses. >> >> IMHO, something similar to the following would be more explicit: >> On return, addrs will point to a dynamically allocated array of >> sockaddr structures of the appropriate type for the socket type. >> If sd is an IPv4 socket, 'addrs' will point to an array of struct >> sockaddr_in >> and the addresses returned will be all IPv4 addresses. If sd is an >> IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6 >> and the >> addresses returned will be IPv6 addresses and/or IPv4 mapped >> addresses. >> >> The caller should use sctp_freeladdrs() to free the memory. Note that >> the in/out parameter 'addrs' must not be NULL. >> >> > Except that if an implementation supports the > SCTP_I_WANT_MAPPED_V4_ADDR > > And this is turned OFF > > Then you would get a mix of V4 and V6 addresses (what Kacheong hates).. > which is why it is vague... Given Randall's and Kacheong's confirmation of what "mix" means, I think that I would have to side with Kacheong on this. It is not elegant (the user has to decode a block of variable length records) and is dangerous (considering the alignment issues). ..not that my opinion matters much, especially this late in the game. So I will spare the group the rehashing the argument. :-) Nonetheless, the spec should not be vague. On the contrary, given the confusing nature of the returned data, the spec should be very clear. Refering to the returned data as an "array" is a misnomer. Arrays in C refer to a list of fixed-length records/data-types. Arrays can be index with an integer through array subscripting. It seems that we only get an array when SCTP_I_WANT_MAPPED_V4_ADDR is on. Otherwise, we get a list of variable-length records. IMHO, the spec should expound upon the usage of these functions, explaining its relationship with SCTP_I_WANT_MAPPED_V4_ADDR. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1107902278-18524-0-- From rrs@cisco.com Wed Feb 9 06:38:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21330 for ; Wed, 9 Feb 2005 06:38:39 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyqUv-0004jQ-UD for sctp-impl-archive@ietf.org; Wed, 09 Feb 2005 06:59:10 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 09 Feb 2005 03:38:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j19BbKwN014940; Wed, 9 Feb 2005 03:37:20 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j19BZh7U001536 for sctp-impl-filtered; Wed, 9 Feb 2005 03:35:45 -0800 (PST) Message-Id: <200502091135.j19BZh7U001536@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1107948943-1534-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: API draft: section 8.3 and 8.5 List-Id: sctp-impl To: David Lehmann From: Randall Stewart Cc: SCTP Implementors X-Nails-Approved: rrs@cisco.com Date: Wed, 09 Feb 2005 06:33:14 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 This is a multi-part message in MIME format... ------------=_1107948943-1534-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Randall Stewart wrote: > >> David Lehmann wrote: >> >>> Hello, >>> >>> Sections 8.3 and 8.5 are not clear on exactly what structures are being >>> returned. It states: >>> On return, addrs will point to a dynamically allocated array of >>> sockaddr structures of the appropriate type for the socket type. The >>> caller should use sctp_freeladdrs() to free the memory. Note that >>> the in/out parameter addrs must not be NULL. >>> >>> If sd is an IPv4 socket, the addresses returned will be all IPv4 >>> addresses. If sd is an IPv6 socket, the addresses returned can be a >>> mix of IPv4 or IPv6 addresses. >>> >>> IMHO, something similar to the following would be more explicit: >>> On return, addrs will point to a dynamically allocated array of >>> sockaddr structures of the appropriate type for the socket type. >>> If sd is an IPv4 socket, 'addrs' will point to an array of struct >>> sockaddr_in >>> and the addresses returned will be all IPv4 addresses. If sd is an >>> IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6 >>> and the >>> addresses returned will be IPv6 addresses and/or IPv4 mapped >>> addresses. >>> >>> The caller should use sctp_freeladdrs() to free the memory. Note >>> that >>> the in/out parameter 'addrs' must not be NULL. >>> >>> >> Except that if an implementation supports the >> SCTP_I_WANT_MAPPED_V4_ADDR >> >> And this is turned OFF >> >> Then you would get a mix of V4 and V6 addresses (what Kacheong hates).. >> which is why it is vague... > > > Given Randall's and Kacheong's confirmation of what "mix" means, I think > that I would have to side with Kacheong on this. It is not elegant > (the user has to decode a block of variable length records) and is > dangerous (considering the alignment issues). And that is why there is a socket option to turn it on and off.. You must change the socket option to get this behavior. > > ..not that my opinion matters much, especially this late in the game. > So I will spare the group the rehashing the argument. :-) > > Nonetheless, the spec should not be vague. On the contrary, given the > confusing nature of the returned data, the spec should be very clear. > Refering to the returned data as an "array" is a misnomer. > Arrays in C refer to a list of fixed-length records/data-types. > Arrays can be index with an integer through array subscripting. > It seems that we only get an array when SCTP_I_WANT_MAPPED_V4_ADDR > is on. Otherwise, we get a list of variable-length records. > Which is the default > IMHO, the spec should expound upon the usage of these functions, > explaining its relationship with SCTP_I_WANT_MAPPED_V4_ADDR. > That can be added :-D R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1107948943-1534-0-- From support@paypal.com Wed Feb 9 13:39:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25417 for ; Wed, 9 Feb 2005 13:39:19 -0500 (EST) Received: from [216.117.176.236] (helo=216.117.176.236) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cyx43-0005sm-Fo for sctp-impl-archive@ietf.org; Wed, 09 Feb 2005 13:59:53 -0500 Received: from 160.2.14.112 by ; Wed, 09 Feb 2005 11:32:15 -0700 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Wed, 09 Feb 2005 11:33:15 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--767194751538087755" X-Originating-IP: 132.151.6.1 X-Spam-Score: 10.9 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----767194751538087755 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----767194751538087755-- From AIMLHBJJZBWWL@yeah.net Wed Feb 9 23:09:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00539; Wed, 9 Feb 2005 23:09:48 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz5yD-0000ar-Qm; Wed, 09 Feb 2005 23:30:27 -0500 Received: from [218.190.54.101] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Cz5eB-0000hH-FH; Wed, 09 Feb 2005 23:09:44 -0500 X-Message-Info: GlkWVU593xrpCQT46NxfGT68VWBlVJV04AG5GK401s32W Received: (from a633cabot@localhost) by zqu51-convalesce951.mz1bm.attglobal.net (5.33.40/5.83.99) id kg1ZQO5ip405299; Thu, 10 Feb 2005 00:01:33 -0400 GMT X-Authentication-Warning: j18-anthem3.vx74ylyx.attglobal.net: lta5gerber set sender to AIMLHBJJZBWWL@yeah.net using -d MIME-Version: 1.0 Date: Thu, 10 Feb 2005 02:09:33 -0200 From: Myra Villanueva Subject: Obtain all the TWC3 you naed today! hunter To: scoya@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--9974818824248142464" X-Spam-Score: 13.0 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ----9974818824248142464 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Hi and welcome to our phaarmeecy!
You can obtain TWC3 aka Tylenol No. 3 at very faair prjices.
Get the fait prjces nooww



betty aye u.n sabscjbe trashy hacksaw
canticle skeet harm carthage. schlesinger bacilli argive upholstery esprit. afoot alumna brandon inefficacy cretan cloud cute. humboldt apron fatima impersonate schelling prelude dwarves harp augite.
subtle lawyer orange pageantry top frill aborigine maloney pintail. chancy everglades yearbook cohesion. bombay ovary salaam sentence argive algebra nadir repairmen.
immature everglades equal pearl brainchildren arcsin velvety. extremum everglades beryl persevere symptom elinor cryptography. portia chinatown cinema circumlocution pageantry shrapnel parallelogram singleton insular. haul erskine trigonal impersonate bindery dodo halve rhenium gemini.
bypath prorate argive deere anionic congenital downtrodden demark. bespeak everglades regretful crappie christenson couscous corrigible. atkinson homily impersonate cocoa automorphic mullah jules arson. wile bema glenda skeet lame chantey. abbreviate eaten kurt barney skeet anise coniferous andover ductwork.
liverpudlian inefficacy dewar egyptian. desuetude butterfield antagonistic skeet lank csnet. till curie thwart cascara argive lectern closet. ----9974818824248142464-- From aydin@mail.eecis.udel.edu Wed Feb 9 23:50:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02968 for ; Wed, 9 Feb 2005 23:50:34 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz6bh-0001N5-JO for sctp-impl-archive@ietf.org; Thu, 10 Feb 2005 00:11:13 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2005 21:00:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,191,1102320000"; d="scan'208"; a="613503875:sNHT24238976" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1A4nOuC029750; Wed, 9 Feb 2005 20:49:24 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1A4lj7U019157 for sctp-impl-filtered; Wed, 9 Feb 2005 20:47:47 -0800 (PST) Message-Id: <200502100447.j1A4lj7U019157@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108010865-19154-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: how to get sctp ... List-Id: sctp-impl To: sctp-impl@external.cisco.com From: Ilknur Aydin X-Nails-Approved: aydin@mail.eecis.udel.edu Date: Wed, 9 Feb 2005 23:34:08 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab This is a multi-part message in MIME format... ------------=_1108010865-19154-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hello all: we need a free sctp real implementation in linux kernel (version 2.4.20) or in user-space with Dynamic Address Reconfiguration extension. Where could we get it ? Which one would you suggest ? Also, where could we get a real multimedia application (may be video) -hopefully- with source code that uses SCTP? thanks, ilknur ------------=_1108010865-19154-0-- From rrs@cisco.com Thu Feb 10 04:32:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10283 for ; Thu, 10 Feb 2005 04:32:47 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzB0o-0006gS-Os for sctp-impl-archive@ietf.org; Thu, 10 Feb 2005 04:53:29 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2005 01:32:53 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1A9VRwN010092; Thu, 10 Feb 2005 01:31:27 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1A9Tp7U023907 for sctp-impl-filtered; Thu, 10 Feb 2005 01:29:53 -0800 (PST) Message-Id: <200502100929.j1A9Tp7U023907@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108027790-23904-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: A call for research List-Id: sctp-impl To: SCTP Implementors From: Randall Stewart X-Nails-Approved: rrs@cisco.com Date: Thu, 10 Feb 2005 04:27:17 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 This is a multi-part message in MIME format... ------------=_1108027790-23904-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Greetings SCTP'ers: I am looking to collect a list of ongoing SCTP research and place it on the sctp.org web site. If you are doing research into SCTP could you send me: a) A brief research description b) Web pointers/links etc c) research organization d) email contacts e) any other misc stuff you would like to share If you know of someone who is doing research but not on the mailing list.. please forward this email to them. I will compile together all resulting respones and try to put together a "research" tab on sctp.org Thanks R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108027790-23904-0-- From kevina.861darius@quest-solutions.com Thu Feb 10 04:47:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12360; Thu, 10 Feb 2005 04:47:52 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzBFQ-000744-Th; Thu, 10 Feb 2005 05:08:33 -0500 Received: from [221.164.177.110] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CzAvJ-0007em-AK; Thu, 10 Feb 2005 04:47:46 -0500 Received: from home86.cerberus.engr.sgi.com (221.164.177.110) by 221.164.177.110 (CloseForm 5328) with SMTP id <363tt683tyqqat>; Thu, 10 Feb 2005 15:40:16 +0600 Message-ID: Reply-To: "julia yun" From: "julia yun" To: rafts@ietf.org Cc: haa11894@ietf.org, srg@ietf.org, anet@ietf.org, bmanet@ietf.org, g-admin@ietf.org, sctp-impl-archive@ietf.org, dccp-request@ietf.org, midcom@ietf.org, ep@ietf.org, mipshop-admin@ietf.org Subject: Confirmation of your approval Date: Thu, 10 Feb 2005 02:41:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5880262_75732308.yz986" X-Spam-Score: 15.3 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 ----5880262_75732308.yz986 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #2106996, Your application was approved. You are eligible for $500,000 with a 3.7 % rate. Please confirm your information here: http://murdoch.dfgsgs.info:443/ajrmllimit We look forward to hearing from you. Regards, julia yun, Senior Account Manager SLP Financial Group r*mv. -> http://griddle.dfgsgs.info:443/index.php ----5880262_75732308.yz986-- From pasbxytviygw@ga2.so-net.ne.jp Thu Feb 10 10:01:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06097; Thu, 10 Feb 2005 10:01:19 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzG8m-0005oH-A6; Thu, 10 Feb 2005 10:22:03 -0500 Received: from [210.90.166.2] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CzFof-000630-VI; Thu, 10 Feb 2005 10:01:14 -0500 X-Message-Info: AEAZ4BSp9DBTV1DiPVUfxeIZY2gLE7ajTYqfMSFB6I1C Received: from 9 (5F.8E.7A3.41) by mail4.pasbxytviygw@ga2.so-net.ne.jp (Bluewin AG D.F.EDF) id 31CEC0JIAQ22BCEEXTB7434 for saad@ietf.org; Thu, 10 Feb 2005 11:59:56 -0300 Message-ID: <5A7B0883B6E3B.AF214@pasbxytviygw@ga2.so-net.ne.jp> Reply-To: "Harold Kirkpatrick" From: "Harold Kirkpatrick" To: "Saad" Subject: highest rated market picks and tips service Date: Thu, 10 Feb 2005 10:57:56 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7ECB679E09CD53EE12" X-Spam-Score: 22.0 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----7ECB679E09CD53EE12 Content-Type: text/plain; charset="iso-4E77-1" Content-Transfer-Encoding: quoted-printable ***GEEC*****GEEC*****GEEC*****GEEC*****GEEC*** Global Environmental Energy Corp. (OTC-BB: GEEC) Shares Outstanding : 35 million Approx. Float : 9 million 30 Day Target : $6.25 6 Month Price Projection : $15.00 Recent News and Major Share-Price Driving Milestones: GEEC just announced a $10 Billion, 5-year joint venture with several companies operated by the Chinese Government. GEEC uses their Biosphere Process System to convert various types of waste into clean, "green" electricity at 5 to 10 mega-watts per hour. GEEC Chairman, former Prime Minister of Ireland Dr. Albert Reynolds, has secured a $2 Billion line of credit for GEEC and opened doors in over a dozen countries through political contacts at the highest level. Global Environmental Energy is CBS Marketwatch.com's #1 Best Performer in the DJ Diversified Industrials Index in the last 2 months. This Dow Jones Index also contains 3M, GE, and Honeywell. Conservative estimates value the company at One Billion Dollars Future Milestones: 1. GEEC had a $100 Million backlog of sales orders for the Biosphere before the China joint-venture with 26 completed Biospheres in operation. The backlog is now into the Billions with complete financing to be provided by China and 1,300 Biospheres to be deployed throughout the country. 2. GEEC's present assets of $35 Million will conservatively jump into the $300 Million range, a 10-times increase. 3. GEEC is in advanced stages of agreement on at least 6 major international projects which could add $50 Million to the bottom-line or $1.42 per share. 4. P/E on average for this Industry Group is 20 to 1 putting GEEC in the $13 dollar range without any future business expansion. 5. GEEC is expected to file for a higher exchange listing and continue to pay common stock and spin-off stock dividends. Worldwide Market Potential $15 to $25 Billion over next 5 years with no other known company that can match their technology, leadership, or explosive sales growth. Up until now GEEC has been one of Wall Street's best kept secrets, yet now it seems the cat is coming out of the bag and the release of this new Investor Awareness Campaign should be excellent timing in regards to some new PR's forthcoming which will Rocket GEEC. This power-play has nowhere to go but up, according to most insiders, and there's still a bit of time to get in before the boom. DISCLOSURE: The information and opinions in this feature profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past-results is not an indicator of future-results. This report is a paid profile and is for information purposes only and should not be used as the basis for any investment decision. Ten thousand dollars has been paid for the preparation of this profile and for continuing coverage of the featured company. We are not an investment advisor and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains forward-look-ing statements and is subject to significant risks and uncertainties. There are no shares held and there will be no participation in the trading of shares of any profiled company. ----7ECB679E09CD53EE12-- From lpgzn@alumnidirector.com Thu Feb 10 23:38:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28967; Thu, 10 Feb 2005 23:38:42 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzStw-0004Gw-VF; Thu, 10 Feb 2005 23:59:33 -0500 Received: from 62-221-204-22.dsl.uwadslprovider.nl ([62.221.204.22]) by mx2.foretec.com with smtp (Exim 4.24) id 1CzSZh-0006c3-3g; Thu, 10 Feb 2005 23:38:37 -0500 Received: from vhhktew.utah.com [179.19.152.221] by 62.221.204.22 with xnnxwcz aojavlc sacktqvrv swkrmdpf; Thu, 10 Feb 2005 23:41:37 -0500 From: "BSDI Ser." Reply-To: "BSDI Ser." Message-ID: <503412159.05245000066424@utah.com> Date: Thu, 10 Feb 2005 23:41:37 -0500 To: "Rtg-bfd-request" Subject: Useful Programs For Computer MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----3812308004388775744" X-Spam-Score: 14.6 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c ------3812308004388775744 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Not selling trial, incomplete or academic product - It'll be fully functional product

Good Programs

canonicalizing excelling bridle finishing brows empowering convince deduction mats geologists myoglobin Knightsbridge abysmal neatness laundering bombarded lexicographical contours oboist groundsel baring crusaders jeopardize matings accountants iceberg folders fail conceives emasculate achievement's executrix multiprocessor familiarities compartmentalizes mullah constructed eyesight incursion inspire nests instill butte Medea osmosis knits exotic hypocrite's notebooks gins farces chewers disposal ballyhoo fur's cisterns demeanor canal aspire Barnhard errs infrastructure mucus combined excused belly Vicksburg Maddox khaki nonterminal nondeterminate occludes Vatican copper's demonstrator Cowan gaiters astronomers brochure's conjunction escadrille capacitor's alma PR forgive Gleason drafty corpora conspired gibe frescoes ostracism incoherent batteries minimizations Artie miraculously article's afterthoughts Mira braid denudation Rumania Velasquez jig's metering humorously L'vov Wisconsin breakthroughes fatten electricity nimbleness ethers directs jeans inconveniences indenting anesthetizes botched pad Furman noxious bugger's Ned hypothesize Weller auctioneer's ------3812308004388775744 Content-Type: image/gif; name="haunches.gif" Content-ID: <2315798561@utah.com> Content-Transfer-Encoding: base64 R0lGODlh0gESAcQAAAYF6gMD+PEEBAcG4gkIwAcG2uIGBgwKb6sICcAICAsJkggH0gsJn+oFBQsK gtsGBwUE8QoItvJO2DnbSla6EvGBfDzhOt0lrnmw6yjO7WTWYXDsCf8AAAAA/wAAAP///yH5BAAA AAAALAAAAADSARIBAAX/4CeOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY5+CA8C HJQCDwgllJqbmyKclBSenxwzCAYUoAYJFiaRk5WXmaOds5+omxIfF5oNHxKcoSO1GbK1DRgVwrWa j81REq+jArmiy6QfsxUZszINtQYj0LXTysvY1pQGnKzqzBac4CLvswnFyxTU6NfO/EveywLKmTv3 yQICbjASLIv34d84gdz0cVC4qZ5DUhQ11ROxa1YvEhIfVBvYr6SRg+gw/xEcSC8jpxjRRsVDaU0l upXL5mkSySkDhnUjYn6yZ21kLZNIiTzQJxInwlkG2g2FYS3eUnRNb0qswKkB100ZpFJK9uFrLZVG r9Fk5nRU0rdAhF7QxSmg0xSzKAhl++ITMRNy6W6yOxXvSxK3NG3btCExh2Af1o7CAPIwzmCF4WoG 8imZWbb60t6EIZRCVAzUnHqeOhriPhFiJ3LqqInhVV51K3eKzIly28ybg9MozHq0xN0vXBZM61q0 ZeYklLf7J3TjB8ccfnFKre/j7+fCw1O1XLzo96Mxbn/6SPxwa+gjdHJSromVL2AfYm9w3Rvteb7i BdhCdR8oR5hxx1EyQ/8FFiRAG1sEGugccvCJ8Bkto5BF3yhN/WfdhBQKKCIK6tWSFXi61bZJbK+1 gAFai+1W4iwnklShCNhx0MtFoIzAIkJOxZbaXSMW6YJks9iEIGNMorjCj5rYheQoSoZoAnD5fULZ T/DwN8tfn0jm3X8KGmkmCTx+YheZ13yiHSVvAtgClJT41pA1a2JJVIsFfrLfBp9sJJ81c91FIIhy nlmkBGlGyd2SzLwSkJ4q0Dkmo+M8auWeJgzKATEx1sfRbCOIyRx9+bynqJmuRBlLiugN1dFclKqA AAZiqXJCq7D4R6RhVl64T2ciCGUfdOXxgmiZqzbr7LPQRivttNRWa+3/tdhmq+223Hbr7bfghivu uOSWa+656Kar7rrstuvuu/DGK++89NZr77345qvvvvz26++/AAcs8MAEF2zwwQgnrPDCDDfs8MMQ RyzxxBT/4QEJHlycMQob35DxxTuAzHHHH3z8cckkn6yCyiiL/ILLL8McBMlP0HyCzSHLLALORPBc Asw+64zxxixfAfTOP48g9Ms7L82DyFAr3bTSTlNt9RBRp1B1DFuv0LXUSSPt9cxhl7zE12aLrfXa ahudtthHtz1D1kLErfHQV3sNNdo10H3z0x7DILPfHJONMdhJoE24CU7frYXjcA8NssaTD1755S0T TTnKU2+ON+eIw03z/92Qr2w25ClXzrnmoJtM9eStY271ybR7/nrTQHuuctGZx+7y7rH/nLrqNnfM esuSI2187qur3vzxKc9Oueawjz792r+z7rMRpcN+eOdp/4649+Er/z3RcpeevvlSk96C+96Lv7ro p68PPtiDs1//2+UTjn7Wdisf/9T2v7ZVD38DxJ/7Bri3/TEPfQp04PkmGL/Zha1q8pMgE0wGwLJV j3cQFGD/HAe83p0vg5FL2gJvd7gFug55Aqwg6L4XQ+MxToQkpGDo+odA4eGOfONTXtEOSMCb2VCD QTwdCFNYwhzCUHwQJB8QRVi4IE4RCXSbYgeXhroiMvGLf7Pf2zpIRf+2yRCMMlRfEp2osyMikYf2 6yIDaSi3MepPh5ELIBzjBscb7jGP7NOiF8nYQ7YV8Yrco17mrIc8ReZtd8tL4SKXlz3e4e51tSPd 9i55vSdycHocnKQPa9c7nFUSk5Lr5O0cOUMTQnKU2ive3oiXu1BSL3uNVGUun+e6W05SfphT5PBa xzjrzZJv+1pc36SgzIqVy5I02KQSoOnMalrzmtjMpja3yc1zIXNqHpOmDHr5wh58k2t1C9zTzrnN ZjKtlerEISO2xk4X1DOb7rTnDpfpxzoWgp7pVNj/ZgnOWNrukkoE5+cgCcrNQU+TZaNjLQt6vUzG 8oef65xDdUdOhYL/b3ivJCVHR6pR4cnOkwiL4h9jWMYGOtGL8uxj+F6aQP4B84QFZaILw6jTPxLx gYG8YwMLKccQ9jGHiATY5brXxJkWD4HlvF9MHYrQpdIxdCh8ohV76LzkcRWQEoyqU7vqvCy6sagG pCFSqfkvIGY1i1WUqQqJ+lWW8lSKET0jLr/YxrTaFal3nOAOCZnG9tXVr2FNGEOr6shT4k2kjGRs WQn4SYR6NZTFXGomx2dLzKISkxbtJDkda9FFSs+qwqRkKxeL0RJ2ExEA9Sc/Z3vP11ZLnJbNAVvt iVvb+va3wA2ucIdL3OIa97jITa5yl8vc5jr3udCNrnSnS93qWve6/9jNrna3y93ueve74NWn9EaG g92O05B6Y0Fl08vANtZ2buL0rAmNWNvNJu6ekY3me3ur2/eq94IeVCd/A1rTfnaNi3HlnmwDbMe7 8tONWHxnRAssYRv4t8L7XOZN1RrPC3f4fRTup4iv2jPBGXZsJBZviEus4qvWV7cRHrGFbWpAG0bS h55saPOCd9DgjdeYQvSoZR860Jw+lcea9XEpJ4rSDKpxxJC1qWpfOT9ZfhSXF2VZ6hg7ZCEjecgb hecMoxxJUpa0nFSmcjRpPMePIpawYKWfIPs6P7XutIWP/auU2yznlQZVkA2WJYQTrMHR0bWGFCae XxX9U8GeuNF+LP8gm+8MYCLyNdJg3XBS1YtmMX7QynBOqOysilPB8vHTfOQqGY9oN1bn1KkUPTIh B/tfPLf00C8cKgtJjcYRqnaMKlWioDPdQk0Ou35RtHHe9Bw/VpvXkLMOdKKlPcheO9jUDH4ytdWH 11sX9qaWLnC388dgA4NxjYVErJ4x7VNsr/TJ346jPwtr19W6G7D1hm9F5ZtaGCqUta7+IWsFblIz a3SjldxsZT85ZYIyXJRLXu8Qfz1xyy2u4mJdrMaPl8qBC/yikh0pSUG4cFA6muS2pOxZLa7K0ZL0 Wvn8MLS5yTcPU+vZ4aTngBs2YJyH9+dAD7rQh070Ptica0ef5rL/Dbf0YrL3CBNHui55O/UmbHLn jrhw0p2w9Zlf23QgDtmEUTxoFXd9zWAXjtbZcPavlxu9aYdxir2O9hUnDsVtIDPqQkpxXecYlkrm aGbDfNAs15LRZc71jU+7yy37EnhATig8texSYxKUos+LoEk5eeMi09fwuRQtwi1XUn/Pl6yLP3jj qVqEqDUbwMRsNJ39x3pisxnRbjUfoBXda0hD9dF4lCK3LZj7xO7T0nIM6htD/frG1bXzi5YkTmma b3wH0PX0U7DyyY3XhAu5289ffMbZiNH2GVuP47Yjqueq/rQGO9pbHKIQoV9pzSvb104epGuD9vyt 3nvzfoZGRpVx//J0Rq0HfAmkV7dHaw32VRW0aeQnbtL3fzBlfEZ0SPImSYAmV3GWbnEGV4VWU8yX V3FFb3tGgb2Xgfi2YGeVb60HUijHeaLXY76zeQZlZlH3cSelgcfmcQ5nXxIFUqZmUKu1b6Y3Zhx3 bChVgw3HZPalcH7zhCWnTKM1eJAVeaXlcTV2TD63QYrQdnOHBmD4OLUmd2Z4Bl2YB2kIX3CwhmkQ X1hHX+U1hkVXh3Z4h3iYh3rYN4pDh4m0YHwIiHa3PWI1hzODX6w0MgxHSaE1UVCoY6a1S/6Wa19o YmvQdsjkfG43Y4IYT+dFTHiHVhrobg04gjAVbf9kiWqAiegEd/+dODcZJnZ1pzilKFQJWG4gSFgG GIt2EFJLaFRgtmthpmSrRHipxEvlJ3lbtlAQpUKEh3D/xjMPBI2C11iZ91jDmFFlZUpNiHmOdXqR l1edVm2jSH2v2IYRBGnS+Gfupz/FV2j5t24PGFjTp4KsF28iyG5l1mfbFkaUhkcNSG1/dTTYd2L0 eIqcJYQYKHzaVgerNn9JtX6OKGfyt31OR2/fpmZVlYzWlka0M2/6qEABt0WFM1A9KFXxCECuxYAX R3ZJdIvZVnx+6DYpOHfhBm4YaG67aJHyCJPWFpI96YH+l36k6HewN3s5eXtEeXywJ5Ca9pLkxmEI CQgA94iTd3n/DNVQl8dCv6SNQJiV/VZwPriIvPRyvZRZoNVY/WaN36dyYolm3BhM3ciVYNmIl5Va ulRxWkWXSDGTPpBqzpBVQOeX5jRMgSmYe5iYirmYjNmYjvmYkBmZkjmZlFmZlnmZmJmZmrmZnNmZ nvmZoBmaojmapFmapnmaqJmaqrmarPlbVkkF0OOFOCZjOQMFPWdOc/g1bgiLhNZivNh0T8eVO4ab FYg17zSTtKh0tElgY7BppXaANfOJHuics/ibxBl2yIlh2jd2xlkGNWedgBOdrRiL1Il2wud0VTaN koVj0SNqIseMO0Z50DhmF0hkXHaD9pd69+mVqLeN8bmDYVlk/313lTtYg6EHeunJW6ann3ynWcPY nldjn6AFivM5Y3c2e9QnabfWkW6Wj3W2gRAWkR1aVPdoewaokn+Te+pYoruHe7Y2U0rpabhmix8q XvkTlZPlkZPmj/8YlOUJYi4Ug2NVfxOIjD5qcZeGixvpjzTqoxApOoZWpB+ZPOvHbCVZfkMliil5 kTOabM1meVHKfVuafQOpRa7WolaqAyB4lLKFfCCJfh3Yf14GVzuZpOSIkW1GZxvaPez4fwgmRkcl fai4PzHlpJaIo1JZkA4oqEkKpzjkYVEoaIp3SqyUX404hSjXUSK4b1qJcUT4d58qhbn1d8eYlRG3 ekCIVQGqlv+F92vROGp6JXG4ZXCReJedKkq35Kn4GXISB1vgGYbj+QOEKS8xZ3WJ0IVxyFPCmqwH s5s9M6ytGa3SOq3U+pnO+k3MWq29eI7c2pvaSgjn9GLfegidNZxQeJ9kNa6+6qIKiKIbpq6pmKb+ V6bdCq/bKq9JOY9lZK8Ww4hXqHob15XQyq8EW7AGe7AIm7AKu7AM27AO+7AQG7ESO7EUW7EWe7EY m7Eau7Ec27Eeq7BVmIxVSJYQR6rgCJeTequL6KpTOpt12XKX+rJBI58kJ2ydykiUCnEre7MKabKo RLM/m6t1mZYRt16rVLRLZ5KTerRWAKHi567+KWXnGXtMhXn/ZLqNUyuNpPVv7BmhzjanqFdjgWe1 SRi1nSeXkhd4Zce1Vkuf5jpZXuu2T9u2+fW2S0qMsLl38EmR3uiMMPpIpDe2KPlBfztv0RNCwFhn RkZCfhdZwGhl2cegwGS2UUuMNtaQiLtX7flQUuWNKGq50ehVVxlkXWV3G6S3cZs+GOe3pbuMHfdI FrS4hVuSrqe3LLdQH9q4mpupsFurcPl5ezu3RUi6WoO6dFtwxwifm5uDb1m7n0W1s/s4e3W82Bi7 IulRrpu6EDq8sCZmyAulGZW8r6ZmdbuP37u8r1q64xVrrpt6ztY40yu466u4BCe3tqO1gGt546uf WVC+6Vq9/14GbNhrlD62vY6rvRUJitwLeK+mtuHLv3v7t5CLv8vIjanbwFcXv+LHwN4LuTCavYBL WeyZtbxWBROsa8xTwHZ2wWJ2tqqKu6E7eRG6bPirwmQbuCBceuj7ZWzrwi2Mwv87nLNJt7RHtuFr vzFcuCunw1OLt1MwfpKKvCvLl887XyVrxSmrZeIrg+NoxUVrtFqpiMd0Q/pbsj2Wsr8UVS73vFoc l4f3vUH7cBzpSl9pqg93lv5qwM76sXzcx378x4D8XWCMlcPEs7xmtEw7xycbdRgqtVy4s6eavnnM cpiav/L5xYPsxnlMtGkMgzErxzsrqT0bx2z8yW8Jx6VciP9emLmXhcA33LUR7L5hy8NxW8FZSlUb TMNma2+et8C1J7iSS142/MppS72Xa8Tum7tgy1lJXLlEPMAxnK2FCYCihr3EDGpD3LraHLr89327 K8A9TM0ufHFALLo/TFTqO7N965XKHMv3M85JHM8WrLs9nM6VF8EFPLAXaH78rL7sa5Tjt89t68AB LbK7m73CVGxV/Lv82Wl1y3i3PMSvO8eOp5FICGyMmLwgjNCkR8/2W8NCbLklHAVl3L017MPWG8CO +83s+8Aaab7D27LgeNEAXc4cScGsPLr7DNPczLgua7ul1846vcAu7c4h3dP4nHh5y8zgnNE+fLju 1Vos/cz/uoyeKy3Ryey5SZvCFw3O3ivSXKvHAx3ClkrTVc3RW13V6AnNSGzBQQ3WR10zZiXC10y5 CkzVV/3Klnq/s5zW9lbXZNrMTazO3KvUhQ2310zLhZ3PQXbOLHzEwivBKWzLsUxLco2XXUzHJBvK bozKBu3QiBrFnz3VMdvJqvt4lazKT8vZKDu0H6eDkCzJncXag7fFtg3FqOXJnr3ItZot0jxN+gzI wR2sgVzcxn3cyJ3cyr3czN3czv3c0B3d0j3d1F3d1n3d2J3d2r3d3N3d3v3d4B3e4o0FHVDe5m3e AEAAI3De7N0BJAAB7R0BJaAABRAA5Q0ACzABJTAB9V3e/wEwAPK93uat3yJw3u8d3yTQ3uYNAQ5Q 4OZtAgr+4C0Q4ekt4Ape4Rbu3iMQAQNg3gOgAQ3+ARFe3iNA3/bdAfhN4DXA4R4O4g5O4hAu4SLA 4uX94SFu4CMA3+VdABMu4yIu4SOu4SOO4T8e4W8R5B2g3kWu4CNwAArO4yPAABE+ACOwABSe4QFw 4zLu5O0N5S9+4V8e40be4xGu5Eiu5Es+AgAw5kEuAlKu4FROA2vO5Gku5hr+AXPe3mEuAgRg3gHg Aji+522+5Apu5iN+5EH+54TO3iMwAejt5ySQ5+wd544+4oaO3nv+AZWO4pCe4XQe6J7O6GSu4BDw 5Qqu6P91HgGHvug4LunnHecyoOps7uMZPuOrjuMOcN4BzgKgjuODjuSKPuhIgeRCvuofUADmHQE6 3gEKkOEEfgARsAAi0OFDbuodIO2Bjuzlrezm3ezWLuqg/u20ngJILu6BjuPU/um3PuAiAO3SPgPp rud1XgLovu4wnuewzus+7uv23u/yPuwyrgCdHu4kcOIdcAAaYN5oft7eXgIG/+5WDuTt/eYw/gEG j/AKX+sfwOUdAOUET/CALuECL/EVP/IdgOr8ft8HsPETEOcgv+QNbwPnDQArfwAtn+kJTvIoXvM3 v+QEoO0nv/Ih/+vjnukmH+xFnxRnbu4anuvlXeoUDwD/at7eAfDuSy70dX7eOm7wTb/gHxD1oe7f Vv/xxr4COH70TJ/kGs/wJzDorn7yVm/nd57z5R3zGk/vOm/35o7moz7rfl/mTI/oF77wq97n5f3u gU7x7O3x+67zii/hhn/tmT7iA6DlFR/2SS/3i2/uRJ71ST/oj2/eXo73Rf/yIJ/yc0/37c33+k70 f8/eRC7sJjHiIR74HxDvE08CE0AABBDxMH7xIuD0HVDqaY77Gm78580Ae87xLj/usq8CQa78rF7e tb/nwN/oti8Cu9/7pg/y16/9OK/x36/pXz4AeR4AWN/6/g7uEV79z98PBg70Un/3pB/hcV/iOA70 UJ7n/4gPAp34HaLZfd+5ikt6pqr5siMc47kuswATwwomQO4mFAEcJAKK19zhFDco9XPsJJfN2siZ umYPTFoXYBpUizPgeqoegXHuNL1uv+Pzet0tYCKwcX0wcJlApAxwEX1MFHYokDUxwRA6HjrVRK5g btbNya35iQAGNlVmct4k1izqnbJo3ty8dt44nETYuckWRqaIdpCmru0VGx8je65FnCgNj2g4ihx8 rLL8pCxwufimQMBES1M7LvY66hLzLTeXxmijnldzYe+9wz53f9jXEk92BKDr0i3eDWYmnMVLpnAh QzxTrJXr9U0EpBhXclkzUYBeigkFRAXYCErgqw8TH5/huPgMAkJBCdN8aodoiMwUCgpMDFkxXkYR Io/dzFlgpyAvMYKK0JnPpEZlAo0SJAYxVsyGVq9izap1K9euXr+CDSt2LNmyZs+iTat2Ldu2bt/C jSt3Lt26du/izat3L9++fv8CDix4MOHChg8jTqx4MePGjh9Djix5MuXKli9jzqx5M+fOnj+DDi16 NOnSpk+jTq16NevWrl/Dji37awgAOw== ------3812308004388775744-- From strawberry@accessed.net Thu Feb 10 23:57:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01480; Thu, 10 Feb 2005 23:57:38 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzTCJ-0004ow-2y; Fri, 11 Feb 2005 00:18:31 -0500 Received: from [211.225.148.90] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CzSs6-0006zy-AQ; Thu, 10 Feb 2005 23:57:38 -0500 Subject: Global projects Message-ID: <%CUSTOM_MESSAGEID> From: "Lupe smith" To: raven-admin@ietf.org Cc: nfsv4@ietf.org, ilserv@ietf.org, ietf-123-outbound.02@ietf.org, iporpr@ietf.org, asrg-request@ietf.org, sip-security-web-archive@ietf.org, rafts@ietf.org, haa11894@ietf.org, srg@ietf.org, anet@ietf.org, bmanet@ietf.org, g-admin@ietf.org, sctp-impl-archive@ietf.org, dccp-request@ietf.org, midcom@ietf.org, ep@ietf.org, mipshop-admin@ietf.org Date: Thu, 10 Feb 2005 20:57:26 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7_YBPOys3E0.sXRebDPpTX4" X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----7_YBPOys3E0.sXRebDPpTX4 Content-Type: text/plain; format=flowed; charset=iso-8859-15 Content-Transfer-Encoding: 7Bit ----7_YBPOys3E0.sXRebDPpTX4 Content-Type: text/html; format=flowed; charset=iso-8859-15 Content-Transfer-Encoding: 7Bit Your the greatest,
While searching google I found a great website that offers quality generic and brand name me-dications at very affordable prices. Shipping is even faster than ever right to your doorstep. Promised savings up to 80% off all prescription drugs. Today Americans pay out over 20 billion dollars yearly in medication costs. Not including doctor fees. The tragedy is that most can not afford to pay these ridiculously high prices. We deliver the same quality drugs you are used to buying from your local pharmacy. The real difference is you don't have to see a doctor and you can save tons of money and start saving for more important things in your life. Feel free to take a look at what could help you greatly. Thank you for your time.

http://lowerhealt.info/in.php?aid=19

Our wishes are with you, Marguerite Peterson | Project Manager

This isn't something I'm interested in recieving - http://lowerhealt.info/fgh.php ----7_YBPOys3E0.sXRebDPpTX4-- From Drwaypeterson@netscape.net Fri Feb 11 01:31:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08938 for ; Fri, 11 Feb 2005 01:31:05 -0500 (EST) From: Drwaypeterson@netscape.net Message-Id: <200502110631.BAA08938@ietf.org> Received: from wbs-165-20-168.telkomadsl.co.za ([165.165.20.168] helo=mydomain.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzUef-0006gK-Uy for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 01:51:56 -0500 Received: from mx3.google.com ([0.62.252.211]) by mx4.excite.com with esmtp (Exim 3.35 #1) id 0EF42FA0; Fri, 11 Feb 2005 16:35:39 -0000 Received: from smtp1.linksynergy.com ([88.213.108.199]) by smtp2.genuity.com with Internet Mail Service id 0002F748; Fri, 11 Feb 2005 16:35:29 -0000 Received: from xmxpita.inreach.com ([216.123.49.220]) by broome1.banelco.com.ar with Microsoft SMTPSVC id 0A4F0903; Fri, 11 Feb 2005 16:35:19 -0000 Date: Fri, 11 Feb 2005 08:35:19 -0800 To: Drwaypeterson@netscape.net Subject: AWARD WINNER!!! MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT GLOBAL FREE LOTTO COMPANY INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT Dear Winner, We are please to announce you as one of the 10 lucky winners in Global the FreeLotto draw held on the 26th of DECEMBER 2004. All 10 winning addresses were randomly selected from a batch of 50,000,000 International emails. Your email address emerged alongside 9 others as a category one winner in this year's Annual FreeLotto Draw. Consequently,you have therefore been approved for a total pay out of 1.4,000,000 British pounds (one million Four hundred Thuosand pounds) only. The following particulars are attached to your lotto payment order: (i) winning numbers: 37-13-43-85-67-11.BV (ii) email ticket number: FL754/22/76 (iii) lotto code number: FL09622UK (iv) the file Ref number: FL/04/736207152/UK Please contact the under listed claims officer as soon as possible for the immediate release of your winnings: Mr. Rook Van Nas Chief financial Director The Free lotto Company TEL:+447040114110 FAX:+447040114112 globalfreelotto@centoper.it info_globallottery@mail2www.com admin_globalloto@virgilio.it Remember, all winning must be claimed not later than 1ST MARCH 2005.After this date all unclaimed funds will be included in the next stake. Please note in order to avoid unnecessary delays and complications please remember to quote your reference number and batch numbers in all correspondence. Furthermore, should there be any change of address do inform our agent as soon as possible. Congratulations once more from our members of staff and thank you for being part of our promotional program. Note: Anybody under the age of 18 is automatically disqualified. yours Sincerely Dr way peterson Promotions ManagerDR From zfppmgcrfwyvdu@lycos.co.uk Fri Feb 11 04:28:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11642; Fri, 11 Feb 2005 04:28:08 -0500 (EST) Received: from [61.132.89.130] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzXQ0-0001rY-0N; Fri, 11 Feb 2005 04:49:02 -0500 X-Message-Info: EVIclH07gPUIsuKSJvc466KTfw378+XUwq4gYEL Received: from pmyjbhgmbav605.de.kaercher.com (19.20.96.201) by raq183-s4.de.kaercher.com with Microsoft SMTPSVC(5.0.2195.6824); Fri, 11 Feb 2005 03:20:38 -0600 Received: from Bobbyrrf0i71s3q (88.133.44.234) by obgmamoffqqyk29.de.kaercher.com (InterMail vM.5.01.06.05 077-962-407-341-935-9610294) with SMTP id <4493128782692975.CWS69.vripb4421.de.kaercher.com@tinfoily7is47cp37q> for ; Fri, 11 Feb 2005 14:21:38 +0500 Message-ID: <1846ztv215vyz343$19986465$z9x639@Bobbywxr999v741dm1ajv> From: "Angelo Irvin" To: Subject: Your P-C is currently under siege - stop this now inviolate Date: Fri, 11 Feb 2005 11:21:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--494476637885154" X-Spam-Score: 29.1 (+++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----494476637885154 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Yes, this is sooo true. Your pc in currently under siege - tons of
spy=wares are running on your box, well known worms and trojans and
much more.
I need to know more
Got some important stuff on your box? Family pics? Secret stuff? Sexy pics
of your g'f? You don't want this to leak, or DO YOU?
I, personally, don't want it. For sure.
I want to stop it

take me uff barbell amidst candlelit mucosa. cauldron taken bernet pomona supposition syllabus leachate stayed. cockcrow tampa pomona magdalene bennett. what'd psychobiology pomona watchman cress irrespective ultra bribery. dater orr hind schedule anchorage bop multipliable bangor aircraft barefaced.
thought marjory speedy otto chiton decomposable partisan narcotic mugho deregulate. exploitation anchorage shrine enzymology beechwood chili. epidemic ferocity anchorage multifarious ballroom bud anhydride. pecos chiton davy coon arrack swum bolshevism. confirmation chiton gypsite picnicker.
causation february chiton buckley bodied delay affricate. hubbard anchorage x's bellicose vulcan. coalition nutrient nursery schofield chiton uruguay tammany. emily exultation hedgehog lessen chiton thwart trimester error stevens strontium. carrion giuseppe fiance anchorage wrath sse landau.
ashman chiton parks inculcate rag ancestral. titillate amidst denature seamstress premise. ----494476637885154-- From service@paypal.com Fri Feb 11 11:29:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12997 for ; Fri, 11 Feb 2005 11:29:43 -0500 (EST) Received: from [216.117.177.39] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cze08-0002oE-Px for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 11:50:42 -0500 Received: from bm4.pjrv9md.net (HELO 9ljw6v) [223.52.25.153] by 132.151.6.1 id <3296129-11402>; Fri, 11 Feb 2005 19:24:44 +0300 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Fri, 11 Feb 05 19:24:44 GMT X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E_1_1.C2D.FB70EB0A203.." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 24.1 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --E_1_1.C2D.FB70EB0A203.. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--E_1_1.C2D.FB70EB0A203..-- From Kilgore@address.com Fri Feb 11 12:12:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16356; Fri, 11 Feb 2005 12:12:34 -0500 (EST) Message-Id: <200502111712.MAA16356@ietf.org> Received: from [61.85.185.215] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Czefa-0003qK-W5; Fri, 11 Feb 2005 12:33:33 -0500 Received: from [192.253.205.176] by lie%DIGITS.cloudy.61.85.185.215 via HTTP; Fri, 11 Feb 2005 09:12:23 -0800 Reply-To: "myfastmail.com," From: "myfastmail.com," To: Subject: Heyyy Honey Date: Fri, 11 Feb 2005 09:12:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1786276780hgps3804" X-Spam-Score: 4.7 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ----1786276780hgps3804 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable How would you like to keep me some company? I am getting divorced from my idiot Husband, and need a part time man in m= y life.=20 Write me back here: http://www.dohernow.com/d/1.php Sincerely Yours, Tiffany y ----1786276780hgps3804-- From anatoly.khusid@ulticom.com Fri Feb 11 12:54:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20253 for ; Fri, 11 Feb 2005 12:54:40 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzfKL-00051j-GW for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 13:15:39 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2005 09:54:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="161160311:sNHT9213806810" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1BHrNuC015285; Fri, 11 Feb 2005 09:53:23 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BHqZ7U025242 for sctp-impl-filtered; Fri, 11 Feb 2005 09:52:37 -0800 (PST) Message-Id: <200502111752.j1BHqZ7U025242@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108144355-25240-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: SCTP failover List-Id: sctp-impl To: From: "Anatoly Khusid" X-Nails-Approved: anatoly.khusid@ulticom.com Date: Fri, 11 Feb 2005 12:29:36 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format... ------------=_1108144355-25240-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary Hello, I am using Linux SCTP implementation (LKSCTP) SLES9 (2.6.5-7.111.19-smp) distribution. I have a client application that is sending data to a server on a remote machine. The machines are connected over two private LANs. When I disconnect a primary interface, I expect SCTP to start using an alternative LAN as soon as possible. Well, it takes about one minute for LKSCTP to detect that LAN is down, before it starts to transmit data messages on another LAN. I don’t have any data messages lost, but I have a 1-minute delay during which time no data is received by a server, after about one minute, the data transmission resumes through the alternative interface. I am curious why it takes so long to detect a LAN failure? I am using all the defaults for SCTP provisioning. (In fact I used getsockopt() to verify that the defaults match SCTP specs). Based on this section in SCTP RFC I would expect the switchover to be in a matter of seconds the most. I am using Ulticom’s SCTP implementation and the switchover only takes about 1 second. Could anyone please shed some light on this? Section 6.4 of SCTP RFC 2960: Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk to an active destination transport address that is different from the last destination address to which the DATA chunk was sent. Thanks, Anatoly Khusid Ulticom Inc. Senior Software Engineer ------------=_1108144355-25240-0-- From rrs@cisco.com Fri Feb 11 13:11:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21570 for ; Fri, 11 Feb 2005 13:11:54 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czfb4-0005SA-6o for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 13:32:54 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 10:20:33 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BIB0q8004437; Fri, 11 Feb 2005 10:11:00 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BIAo7U025518 for sctp-impl-filtered; Fri, 11 Feb 2005 10:10:52 -0800 (PST) Message-Id: <200502111810.j1BIAo7U025518@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108145449-25516-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: Anatoly Khusid From: Randall Stewart Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Fri, 11 Feb 2005 13:08:06 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a This is a multi-part message in MIME format... ------------=_1108145449-25516-0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly: Shridhar can probably shed more light on this than I .. but I have a couple of ideas. In theory the sctp stack SHOULD send retransmissions to the alternate address.. I would think this is NOT happening.. Even if it does happen for some time you will still have some delays in messages... Think of it this way --msg-1---> --msg----> --msg-n--> T.O (1sec) --rsend- msg1-n to alternate --msg-n+1--> --msg-n+..-> --msg-n+m--> T.O (2sec) --resend msg(n-m) to alternate --msg+m-1--> etc.. until you get TO's 1sec 2sec 4sec 8sec 16sec 32sec --- or about 63 seconds after failure the primary will be delcared dead and new transmissions will go to the alternate (which is now the primary). In between the break and the 6 timeouts, messages will be delayed anywhere from 1 - 32 seconds .. but they should still get through. The fact that you don't see any messages for 60 or so second indicates to me that maybe the retransmit to alternate is not working in lk-sctp, or maybe there is an option to turn it on?? In any event the only way to keep the network failover time down is to set RTO.Max to a lower value.. that would make things faster... To have a 1 second failover I would imagine that Ulticom's stack is setting both RTO.Min and RTO.Max to a lower value... aka that adds up to a total of 1 second.. I.e. something like 50ms RTO.Min and 400ms RTO.Max Now, as discused on the tsv, when you do this you need to make sure the receiver is also cranking down its delayed sack timer to be smaller than RTO.Min .. otherwise you are going to get T3-Timeouts on normal sack delay when only one TSN is sent and there is nothing else to send.. Hope that helps.. R Anatoly Khusid wrote: > > Hello, > > I am using Linux SCTP implementation (LKSCTP) SLES9 (2.6.5-7.111.19-smp) > distribution. > I have a client application that is sending data to a server on a remote > machine. The machines are connected over two private LANs. > When I disconnect a primary interface, I expect SCTP to start using an > alternative LAN as soon as possible. Well, it takes about one minute for > LKSCTP to detect that LAN is down, before it starts to transmit data > messages on another LAN. I don’t have any data messages lost, but I have a > 1-minute delay during which time no data is received by a server, after > about one minute, the data transmission resumes through the alternative > interface. > I am curious why it takes so long to detect a LAN failure? I am using all > the defaults for SCTP provisioning. (In fact I used getsockopt() to verify > that the defaults match SCTP specs). > Based on this section in SCTP RFC I would expect the switchover to be in a > matter of seconds the most. I am using Ulticom’s SCTP implementation and > the switchover only takes about 1 second. Could anyone please shed some > light on this? > > Section 6.4 of SCTP RFC 2960: > Furthermore, when its peer is multi-homed, an endpoint SHOULD try to > retransmit a chunk to an active destination transport address that is > different from the last destination address to which the DATA chunk was > sent. > > Thanks, > > Anatoly Khusid > Ulticom Inc. > Senior Software Engineer > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108145449-25516-0-- From bidulock@openss7.org Fri Feb 11 13:57:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26050 for ; Fri, 11 Feb 2005 13:57:28 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzgJ7-0006mP-TK for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 14:18:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 11:07:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="613928504:sNHT33660402" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1BIucuC024063; Fri, 11 Feb 2005 10:56:39 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BIuQ7U026224 for sctp-impl-filtered; Fri, 11 Feb 2005 10:56:28 -0800 (PST) Message-Id: <200502111856.j1BIuQ7U026224@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108148186-26222-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: Anatoly Khusid From: "Brian F. G. Bidulock" Cc: Randall Stewart , sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Fri, 11 Feb 2005 11:50:34 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 This is a multi-part message in MIME format... ------------=_1108148186-26222-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly, One thing that can impact failover performance is the source address and/or transmitting interface on retransmitted messages. If the transmitting interface does not change for retransmitted messages (because there exists a route from each interface to each peer transport address, or due to an error), then retransmitted messages will never appear. This sounds possibly like what is happening. You can play with the routing table a bit to make sure that you have two completely independent subnets described for diagnosis. If the retransmitting interface changes, but the source address placed in the retransmitted packets does not change, then the receiver is likely attempting to send SACKs on the failed path (if following the rule that SACKs are sent to the source address of the data they are acknowledging). So, if the data is one-way and the sender does not change the source address to match the actual outgoing interface on retransmitted messages, SACKs go to the wrong place and it takes multiple retransmissions for the receiver to detect duplicates and suspect that its SACKs are not getting through. If the receiver does not send SACKs to a different destination after receiving duplicates, or gets otherwise confused by the source address in the DATA packets then failover will be slowed. But this doesn't sound like what is happening because you said that you received no data at the receiver. Your description makes be believe that the former is the case: that, although it is retransmitting to an alternate destination address, the source address and originating interface is not changing. Set up your routing tables so that each destination address can only be reached by one interface and see if the problem disappears. Also watch out for default routes. You can try removing default routes for the purposes of testing. If the problem disappears it is a routing problem on retransmissions. Aside from that, slap Ethereal on both interfaces on both hosts and you should see what is happening. A better solution than cranking down RTO.min for increasing failover performance is CMT. At moderate data rates, failover is smooth and immediate and queuing delays impacted only by milliseconds on fast connections. Only a proportion of data is affected by interface/single-path failures and the data on the other paths remains completely unaffected. --brian On Fri, 11 Feb 2005, Randall Stewart wrote: > Anatoly: > > Shridhar can probably shed more light on this than I .. but > I have a couple of ideas. > > In theory the sctp stack SHOULD send retransmissions to the > alternate address.. I would think this is NOT happening.. Even > if it does happen for some time you will still have some > delays in messages... Think of it this way > > --msg-1---> > --msg----> > --msg-n--> > T.O (1sec) > --rsend- msg1-n to alternate > --msg-n+1--> > --msg-n+..-> > --msg-n+m--> > T.O (2sec) > --resend msg(n-m) to alternate > --msg+m-1--> > > etc.. > > until you get > > TO's > 1sec > 2sec > 4sec > 8sec > 16sec > 32sec > --- > or about 63 seconds after failure the primary will be delcared dead > and new transmissions will go to the alternate (which is now > the primary). > > In between the break and the 6 timeouts, messages will be delayed > anywhere from 1 - 32 seconds .. but they should still get through. > > The fact that you don't see any messages for 60 or so second indicates > to me that maybe the retransmit to alternate is not working in lk-sctp, > or maybe there is an option to turn it on?? > > In any event the only way to keep the network failover time > down is to set RTO.Max to a lower value.. that would make things > faster... To have a 1 second failover I would imagine that > Ulticom's stack is setting both RTO.Min and RTO.Max to a > lower value... aka that adds up to a total of 1 second.. > I.e. something like 50ms RTO.Min and 400ms RTO.Max > > Now, as discused on the tsv, when you do this you need to make > sure the receiver is also cranking down its delayed sack timer > to be smaller than RTO.Min .. otherwise you are going to get > T3-Timeouts on normal sack delay when only one TSN is sent > and there is nothing else to send.. > > Hope that helps.. > > R > > Anatoly Khusid wrote: > > > > Hello, > > > > I am using Linux SCTP implementation (LKSCTP) SLES9 (2.6.5-7.111.19-smp) > > distribution. > > I have a client application that is sending data to a server on a remote > > machine. The machines are connected over two private LANs. > > When I disconnect a primary interface, I expect SCTP to start using an > > alternative LAN as soon as possible. Well, it takes about one minute for > > LKSCTP to detect that LAN is down, before it starts to transmit data > > messages on another LAN. I don’t have any data messages lost, but I have a > > 1-minute delay during which time no data is received by a server, after > > about one minute, the data transmission resumes through the alternative > > interface. > > I am curious why it takes so long to detect a LAN failure? I am using all > > the defaults for SCTP provisioning. (In fact I used getsockopt() to verify > > that the defaults match SCTP specs). > > Based on this section in SCTP RFC I would expect the switchover to be in a > > matter of seconds the most. I am using Ulticom’s SCTP implementation and > > the switchover only takes about 1 second. Could anyone please shed some > > light on this? > > > > Section 6.4 of SCTP RFC 2960: > > Furthermore, when its peer is multi-homed, an endpoint SHOULD try to > > retransmit a chunk to an active destination transport address that is > > different from the last destination address to which the DATA chunk was > > sent. > > > > Thanks, > > > > Anatoly Khusid > > Ulticom Inc. > > Senior Software Engineer > > > > > -- > Randall Stewart > ITD > 803-345-0369 815-342-5222 -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108148186-26222-0-- From rrs@cisco.com Fri Feb 11 14:22:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28324 for ; Fri, 11 Feb 2005 14:22:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzghZ-0007RH-DJ for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 14:43:44 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2005 11:23:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1BJLVYO014305; Fri, 11 Feb 2005 11:21:32 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BJLO7U026609 for sctp-impl-filtered; Fri, 11 Feb 2005 11:21:26 -0800 (PST) Message-Id: <200502111921.j1BJLO7U026609@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108149684-26607-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: bidulock@openss7.org From: Randall Stewart Cc: Anatoly Khusid , sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Fri, 11 Feb 2005 14:18:40 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c This is a multi-part message in MIME format... ------------=_1108149684-26607-0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Brian: Good point.. this could be an issue with a default route or non-subnet routes in place.. much like what happens the first few days of the inter-op when folks forget to setup explicit network routes for the two different sub-nets.. Only problem with that theory is that he would not get any traffic ever through unless the interface failed and the route was actually removed. As long as an interface was good .. then the route would have stayed in place and no traffic would have gotten there.. but it is a possiblity.. depending on what type of failure is involved.. R Brian F. G. Bidulock wrote: > Anatoly, > > One thing that can impact failover performance is the source > address and/or transmitting interface on retransmitted messages. > > If the transmitting interface does not change for retransmitted > messages (because there exists a route from each interface to > each peer transport address, or due to an error), then > retransmitted messages will never appear. This sounds possibly > like what is happening. You can play with the routing table a > bit to make sure that you have two completely independent > subnets described for diagnosis. > > If the retransmitting interface changes, but the source address > placed in the retransmitted packets does not change, then the > receiver is likely attempting to send SACKs on the failed path > (if following the rule that SACKs are sent to the source address > of the data they are acknowledging). So, if the data is one-way > and the sender does not change the source address to match the > actual outgoing interface on retransmitted messages, SACKs go to > the wrong place and it takes multiple retransmissions for the > receiver to detect duplicates and suspect that its SACKs are not > getting through. If the receiver does not send SACKs to a > different destination after receiving duplicates, or gets > otherwise confused by the source address in the DATA packets > then failover will be slowed. But this doesn't sound like what > is happening because you said that you received no data at the > receiver. > > Your description makes be believe that the former is the case: > that, although it is retransmitting to an alternate destination > address, the source address and originating interface is not > changing. Set up your routing tables so that each destination > address can only be reached by one interface and see if the > problem disappears. Also watch out for default routes. You can > try removing default routes for the purposes of testing. If the > problem disappears it is a routing problem on retransmissions. > > Aside from that, slap Ethereal on both interfaces on both hosts > and you should see what is happening. > > A better solution than cranking down RTO.min for increasing > failover performance is CMT. At moderate data rates, failover > is smooth and immediate and queuing delays impacted only by > milliseconds on fast connections. Only a proportion of data is > affected by interface/single-path failures and the data on the > other paths remains completely unaffected. > > --brian > > On Fri, 11 Feb 2005, Randall Stewart wrote: > > >>Anatoly: >> >>Shridhar can probably shed more light on this than I .. but >>I have a couple of ideas. >> >>In theory the sctp stack SHOULD send retransmissions to the >>alternate address.. I would think this is NOT happening.. Even >>if it does happen for some time you will still have some >>delays in messages... Think of it this way >> >>--msg-1---> >>--msg----> >>--msg-n--> >>T.O (1sec) >>--rsend- msg1-n to alternate >>--msg-n+1--> >>--msg-n+..-> >>--msg-n+m--> >>T.O (2sec) >>--resend msg(n-m) to alternate >>--msg+m-1--> >> >>etc.. >> >>until you get >> >>TO's >>1sec >>2sec >>4sec >>8sec >>16sec >>32sec >>--- >>or about 63 seconds after failure the primary will be delcared dead >>and new transmissions will go to the alternate (which is now >>the primary). >> >>In between the break and the 6 timeouts, messages will be delayed >>anywhere from 1 - 32 seconds .. but they should still get through. >> >>The fact that you don't see any messages for 60 or so second indicates >>to me that maybe the retransmit to alternate is not working in lk-sctp, >>or maybe there is an option to turn it on?? >> >>In any event the only way to keep the network failover time >>down is to set RTO.Max to a lower value.. that would make things >>faster... To have a 1 second failover I would imagine that >>Ulticom's stack is setting both RTO.Min and RTO.Max to a >>lower value... aka that adds up to a total of 1 second.. >>I.e. something like 50ms RTO.Min and 400ms RTO.Max >> >>Now, as discused on the tsv, when you do this you need to make >>sure the receiver is also cranking down its delayed sack timer >>to be smaller than RTO.Min .. otherwise you are going to get >>T3-Timeouts on normal sack delay when only one TSN is sent >>and there is nothing else to send.. >> >>Hope that helps.. >> >>R >> >>Anatoly Khusid wrote: >> >>>Hello, >>> >>> I am using Linux SCTP implementation (LKSCTP) SLES9 (2.6.5-7.111.19-smp) >>>distribution. >>> I have a client application that is sending data to a server on a remote >>> machine. The machines are connected over two private LANs. >>> When I disconnect a primary interface, I expect SCTP to start using an >>> alternative LAN as soon as possible. Well, it takes about one minute for >>> LKSCTP to detect that LAN is down, before it starts to transmit data >>> messages on another LAN. I don’t have any data messages lost, but I have a >>> 1-minute delay during which time no data is received by a server, after >>> about one minute, the data transmission resumes through the alternative >>> interface. >>> I am curious why it takes so long to detect a LAN failure? I am using all >>> the defaults for SCTP provisioning. (In fact I used getsockopt() to verify >>> that the defaults match SCTP specs). >>> Based on this section in SCTP RFC I would expect the switchover to be in a >>> matter of seconds the most. I am using Ulticom’s SCTP implementation and >>> the switchover only takes about 1 second. Could anyone please shed some >>> light on this? >>> >>> Section 6.4 of SCTP RFC 2960: >>> Furthermore, when its peer is multi-homed, an endpoint SHOULD try to >>> retransmit a chunk to an active destination transport address that is >>> different from the last destination address to which the DATA chunk was >>> sent. >>> >>> Thanks, >>> >>> Anatoly Khusid >>> Ulticom Inc. >>> Senior Software Engineer >>> >> >> >>-- >>Randall Stewart >>ITD >>803-345-0369 815-342-5222 > > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108149684-26607-0-- From lehmann@ulticom.com Fri Feb 11 14:32:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29108 for ; Fri, 11 Feb 2005 14:32:19 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czgqq-0007gd-6b for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 14:53:18 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 11:42:32 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="613941587:sNHT35309552" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BJVSTj014578; Fri, 11 Feb 2005 11:31:28 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BJVL7U026767 for sctp-impl-filtered; Fri, 11 Feb 2005 11:31:23 -0800 (PST) Message-Id: <200502111931.j1BJVL7U026767@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108150281-26759-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: sctp-impl@external.cisco.com From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Fri, 11 Feb 2005 14:08:35 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format... ------------=_1108150281-26759-0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: > In any event the only way to keep the network failover time > down is to set RTO.Max to a lower value.. that would make things > faster... To have a 1 second failover I would imagine that > Ulticom's stack is setting both RTO.Min and RTO.Max to a > lower value... aka that adds up to a total of 1 second.. > I.e. something like 50ms RTO.Min and 400ms RTO.Max Nope. When the error count is greater than 0 on the primary destination, Ulticom uses an alternate destination, until the error is cleared on the primary destination. So, if the user is using the default values, the user will only see a blip for one second. (...assuming an RTO of 1 second) IMHO, waiting around for 1 minute while data trickles through the association is not acceptable and does not give the user of a sense of transparent network redundancy. IMHO, the language in section 6.4 should be changed from: By default, an endpoint SHOULD always transmit to the primary path, unless the SCTP user explicitly specifies the destination transport address (and possibly source transport address) to use. to something like: By default, an endpoint SHOULD always transmit to the primary path, unless the error count on the destination is greater than zero or the SCTP user explicitly specifies the destination transport address (and possibly source transport address) to use. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108150281-26759-0-- From lehmann@ulticom.com Fri Feb 11 14:57:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01151 for ; Fri, 11 Feb 2005 14:57:28 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzhFC-0008Jr-1f for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 15:18:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 12:07:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="613951886:sNHT19910276" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BJuWq8007578; Fri, 11 Feb 2005 11:56:33 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BJuR7U027183 for sctp-impl-filtered; Fri, 11 Feb 2005 11:56:29 -0800 (PST) Message-Id: <200502111956.j1BJuR7U027183@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108151786-27181-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: sctp-impl@external.cisco.com From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Fri, 11 Feb 2005 14:33:41 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format... ------------=_1108151786-27181-0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Randall Stewart wrote: > >> In any event the only way to keep the network failover time >> down is to set RTO.Max to a lower value.. that would make things >> faster... To have a 1 second failover I would imagine that >> Ulticom's stack is setting both RTO.Min and RTO.Max to a >> lower value... aka that adds up to a total of 1 second.. >> I.e. something like 50ms RTO.Min and 400ms RTO.Max > > > Nope. When the error count is greater than 0 on the > primary destination, Ulticom uses an alternate destination, > until the error is cleared on the primary destination. > So, if the user is using the default values, the user > will only see a blip for one second. > (...assuming an RTO of 1 second) I need to correct my former post. Assuming a steady flow of data chunks, the switch-over with Ulticom's stack will actually be in a fraction of a second since the FR will notice the problem long before the RTO. > IMHO, waiting around for 1 minute while data trickles through > the association is not acceptable and does not give the user > of a sense of transparent network redundancy. > > IMHO, the language in section 6.4 should be changed from: > By default, an endpoint SHOULD always transmit to the primary path, > unless the SCTP user explicitly specifies the destination transport > address (and possibly source transport address) to use. > to something like: > By default, an endpoint SHOULD always transmit to the primary path, > unless the error count on the destination is greater than zero or the > SCTP user explicitly specifies the destination transport address (and > possibly source transport address) to use. > -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108151786-27181-0-- From bickhart@cis.udel.edu Fri Feb 11 15:28:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05663 for ; Fri, 11 Feb 2005 15:28:00 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czhil-0000mx-8f for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 15:48:59 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 12:36:38 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BKRAq8023615; Fri, 11 Feb 2005 12:27:10 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BKQw7U027630 for sctp-impl-filtered; Fri, 11 Feb 2005 12:27:00 -0800 (PST) Message-Id: <200502112027.j1BKQw7U027630@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108153618-27622-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: David Lehmann From: Ryan W Bickhart Cc: sctp-impl@external.cisco.com X-Nails-Approved: bickhart@cis.udel.edu Date: Fri, 11 Feb 2005 15:23:06 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format... ------------=_1108153618-27622-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary I'm not sure switching over to the alternate after seeing a single FR is the best approach for all cases though. Imagine a situation where the alternate is significantly slower or less desirable than the primary. A random FR on the primary may not necessarily be grounds for abandoning it right away. If you need faster failover, you could change the Path.Max.Retrans setting to limit the number of consecutive timeouts that will trigger the failover. Rather than 1 + 2 + ... + 32 = 63 seconds, you could set PMR to 0 or 1 and fail over immediately or in about 1 second if desired. I think the suggested change to the wording in 6.4 is actually already covered by the ability to set the PMR. ---Ryan On Fri, 2005-02-11 at 14:33 -0500, David Lehmann wrote: > David Lehmann wrote: > > Randall Stewart wrote: > > > >> In any event the only way to keep the network failover time > >> down is to set RTO.Max to a lower value.. that would make things > >> faster... To have a 1 second failover I would imagine that > >> Ulticom's stack is setting both RTO.Min and RTO.Max to a > >> lower value... aka that adds up to a total of 1 second.. > >> I.e. something like 50ms RTO.Min and 400ms RTO.Max > > > > > > Nope. When the error count is greater than 0 on the > > primary destination, Ulticom uses an alternate destination, > > until the error is cleared on the primary destination. > > So, if the user is using the default values, the user > > will only see a blip for one second. > > (...assuming an RTO of 1 second) > > I need to correct my former post. Assuming a steady flow > of data chunks, the switch-over with Ulticom's stack will > actually be in a fraction of a second since the FR will > notice the problem long before the RTO. > > > IMHO, waiting around for 1 minute while data trickles through > > the association is not acceptable and does not give the user > > of a sense of transparent network redundancy. > > > > IMHO, the language in section 6.4 should be changed from: > > By default, an endpoint SHOULD always transmit to the primary path, > > unless the SCTP user explicitly specifies the destination transport > > address (and possibly source transport address) to use. > > to something like: > > By default, an endpoint SHOULD always transmit to the primary path, > > unless the error count on the destination is greater than zero or the > > SCTP user explicitly specifies the destination transport address (and > > possibly source transport address) to use. > > > > ------------=_1108153618-27622-0-- From me@armandocaro.net Fri Feb 11 15:33:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06523 for ; Fri, 11 Feb 2005 15:33:02 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czhnd-0000vB-Ho for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 15:54:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 12:41:40 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BKWHTj018194; Fri, 11 Feb 2005 12:32:17 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BKW87U027716 for sctp-impl-filtered; Fri, 11 Feb 2005 12:32:10 -0800 (PST) Message-Id: <200502112032.j1BKW87U027716@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108153928-27714-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: David Lehmann From: "Armando L. Caro, Jr." Cc: sctp-impl@external.cisco.com X-Nails-Approved: me@armandocaro.net Date: Fri, 11 Feb 2005 15:20:34 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 This is a multi-part message in MIME format... ------------=_1108153928-27714-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary On Fri, 11 Feb 2005, David Lehmann wrote: > Nope. When the error count is greater than 0 on the > primary destination, Ulticom uses an alternate destination, > until the error is cleared on the primary destination. > So, if the user is using the default values, the user > will only see a blip for one second. > (...assuming an RTO of 1 second) > > IMHO, waiting around for 1 minute while data trickles through > the association is not acceptable and does not give the user > of a sense of transparent network redundancy. I agree. I have simulation results that show that failing over on a single timeout is best. The assumption is that a heartbeat is sent immediately to the primary when a failover occurs. This way, if the primary is still reachable, then the failover will be cancelled as soon as the heartbeat is acked. If not, then useful data transfer can occur on the alternate until a heartbeat sent to the primary gets acked. www.armandocaro.net/papers/2004.TR2005-04.acaro.pdf > IMHO, the language in section 6.4 should be changed from: > By default, an endpoint SHOULD always transmit to the primary path, > unless the SCTP user explicitly specifies the destination transport > address (and possibly source transport address) to use. > to something like: > By default, an endpoint SHOULD always transmit to the primary path, > unless the error count on the destination is greater than zero or the > SCTP user explicitly specifies the destination transport address (and > possibly source transport address) to use. I don't think the RFC needs to be changed at all for this. An implementation can simply lower it's Path.Max.Retrans to 0. ~armando 0-- --0 | Armando L. Caro, Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 ------------=_1108153928-27714-0-- From me@armandocaro.net Fri Feb 11 15:37:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07187 for ; Fri, 11 Feb 2005 15:37:19 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czhrm-00017R-U8 for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 15:58:19 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2005 12:37:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1BKa7wN012553; Fri, 11 Feb 2005 12:36:07 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BKa17U027781 for sctp-impl-filtered; Fri, 11 Feb 2005 12:36:03 -0800 (PST) Message-Id: <200502112036.j1BKa17U027781@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108154161-27773-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: David Lehmann From: "Armando L. Caro, Jr." Cc: sctp-impl@external.cisco.com X-Nails-Approved: me@armandocaro.net Date: Fri, 11 Feb 2005 15:24:33 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 This is a multi-part message in MIME format... ------------=_1108154161-27773-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary On Fri, 11 Feb 2005, David Lehmann wrote: > > Nope. When the error count is greater than 0 on the > > primary destination, Ulticom uses an alternate destination, > > until the error is cleared on the primary destination. > > So, if the user is using the default values, the user > > will only see a blip for one second. > > (...assuming an RTO of 1 second) > > I need to correct my former post. Assuming a steady flow > of data chunks, the switch-over with Ulticom's stack will > actually be in a fraction of a second since the FR will > notice the problem long before the RTO. Hmm... I think that is getting too aggressive. This behavior could cause reordering and induce false fast retransmits. Why would you do that? ~armando 0-- --0 | Armando L. Caro, Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 ------------=_1108154161-27773-0-- From lehmann@ulticom.com Fri Feb 11 15:52:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10161 for ; Fri, 11 Feb 2005 15:52:58 -0500 (EST) From: lehmann@ulticom.com Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czi6v-0002GB-59 for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 16:13:58 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 13:01:31 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1BKq9uC029266; Fri, 11 Feb 2005 12:52:10 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BKq27U028035 for sctp-impl-filtered; Fri, 11 Feb 2005 12:52:04 -0800 (PST) Date: Fri, 11 Feb 2005 12:52:02 -0800 (PST) Message-Id: <200502112052.j1BKq27U028035@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108155122-28027-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: [NAILS REQUESTED PREVIEW]: Re: SCTP failover To: Cc@cisco.com X-Nails-Approved: lehmann@ulticom.com X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 This is a multi-part message in MIME format... ------------=_1108155122-28027-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Armando L. Caro, Jr. wrote: > On Fri, 11 Feb 2005, David Lehmann wrote: > > >>>Nope. When the error count is greater than 0 on the >>>primary destination, Ulticom uses an alternate destination, >>>until the error is cleared on the primary destination. >>>So, if the user is using the default values, the user >>>will only see a blip for one second. >>>(...assuming an RTO of 1 second) >> >>I need to correct my former post. Assuming a steady flow >>of data chunks, the switch-over with Ulticom's stack will >>actually be in a fraction of a second since the FR will >>notice the problem long before the RTO. > > Hmm... I think that is getting too aggressive. This behavior could > cause reordering and induce false fast retransmits. Why would you do that? I don't like to wait! :-) It seems to work well. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108155122-28027-0-- From anatoly.khusid@ulticom.com Fri Feb 11 15:56:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11232 for ; Fri, 11 Feb 2005 15:56:22 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CziAC-0002bQ-28 for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 16:17:22 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 13:06:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="613974204:sNHT24730788" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BKtTTj003666; Fri, 11 Feb 2005 12:55:30 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BKtK7U028084 for sctp-impl-filtered; Fri, 11 Feb 2005 12:55:22 -0800 (PST) Message-Id: <200502112055.j1BKtK7U028084@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108155320-28082-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: RE: SCTP failover List-Id: sctp-impl To: "'Randall Stewart'" From: "Anatoly Khusid" Cc: X-Nails-Approved: anatoly.khusid@ulticom.com Date: Fri, 11 Feb 2005 15:32:09 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 This is a multi-part message in MIME format... ------------=_1108155320-28082-0 Content-Type: text/plain; charset="Windows-1252" Content-Disposition: inline Content-Transfer-Encoding: binary Hi Randall, I was not completely right that during this 60 second interval my peer does not receive any messages. I ran the test again, and noticed that peer DOES receive messages BUT at a very slow rate (just like you suspected that only retransmissions are sent over the alternative interface). So the transmission for each message must fail first, before LKSCTP tries an alternative interface. This causes significant delays for data transmission during this 60 seconds interval(RTO.MAX). I wonder if this could be optimized? Thanks, Anatoly -----Original Message----- From: Randall Stewart [mailto:rrs@cisco.com] Sent: Friday, February 11, 2005 1:08 PM To: Anatoly Khusid Cc: sctp-impl@external.cisco.com Subject: Re: SCTP failover Anatoly: Shridhar can probably shed more light on this than I .. but I have a couple of ideas. In theory the sctp stack SHOULD send retransmissions to the alternate address.. I would think this is NOT happening.. Even if it does happen for some time you will still have some delays in messages... Think of it this way --msg-1---> --msg----> --msg-n--> T.O (1sec) --rsend- msg1-n to alternate --msg-n+1--> --msg-n+..-> --msg-n+m--> T.O (2sec) --resend msg(n-m) to alternate --msg+m-1--> etc.. until you get TO's 1sec 2sec 4sec 8sec 16sec 32sec --- or about 63 seconds after failure the primary will be delcared dead and new transmissions will go to the alternate (which is now the primary). In between the break and the 6 timeouts, messages will be delayed anywhere from 1 - 32 seconds .. but they should still get through. The fact that you don't see any messages for 60 or so second indicates to me that maybe the retransmit to alternate is not working in lk-sctp, or maybe there is an option to turn it on??Hi In any event the only way to keep the network failover time down is to set RTO.Max to a lower value.. that would make things faster... To have a 1 second failover I would imagine that Ulticom's stack is setting both RTO.Min and RTO.Max to a lower value... aka that adds up to a total of 1 second.. I.e. something like 50ms RTO.Min and 400ms RTO.Max Now, as discused on the tsv, when you do this you need to make sure the receiver is also cranking down its delayed sack timer to be smaller than RTO.Min .. otherwise you are going to get T3-Timeouts on normal sack delay when only one TSN is sent and there is nothing else to send.. Hope that helps.. R Anatoly Khusid wrote: > > Hello, > > I am using Linux SCTP implementation (LKSCTP) SLES9 (2.6.5-7.111.19-smp) > distribution. > I have a client application that is sending data to a server on a remote > machine. The machines are connected over two private LANs. > When I disconnect a primary interface, I expect SCTP to start using an > alternative LAN as soon as possible. Well, it takes about one minute for > LKSCTP to detect that LAN is down, before it starts to transmit data > messages on another LAN. I don’t have any data messages lost, but I have a > 1-minute delay during which time no data is received by a server, after > about one minute, the data transmission resumes through the alternative > interface. > I am curious why it takes so long to detect a LAN failure? I am using all > the defaults for SCTP provisioning. (In fact I used getsockopt() to verify > that the defaults match SCTP specs). > Based on this section in SCTP RFC I would expect the switchover to be in a > matter of seconds the most. I am using Ulticom’s SCTP implementation and > the switchover only takes about 1 second. Could anyone please shed some > light on this? > > Section 6.4 of SCTP RFC 2960: > Furthermore, when its peer is multi-homed, an endpoint SHOULD try to > retransmit a chunk to an active destination transport address that is > different from the last destination address to which the DATA chunk was > sent. > > Thanks, > > Anatoly Khusid > Ulticom Inc. > Senior Software Engineer > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108155320-28082-0-- From anatoly.khusid@ulticom.com Fri Feb 11 15:57:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11746 for ; Fri, 11 Feb 2005 15:57:58 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CziBl-0002mE-Nq for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 16:18:58 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 13:08:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="613974866:sNHT57051864" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BKvATj004468; Fri, 11 Feb 2005 12:57:11 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BKv37U028125 for sctp-impl-filtered; Fri, 11 Feb 2005 12:57:05 -0800 (PST) Message-Id: <200502112057.j1BKv37U028125@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108155422-28116-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: RE: SCTP failover List-Id: sctp-impl To: "'Ryan W Bickhart'" From: "Anatoly Khusid" Cc: X-Nails-Approved: anatoly.khusid@ulticom.com Date: Fri, 11 Feb 2005 15:35:08 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format... ------------=_1108155422-28116-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary >If you need faster failover, you could change the >Path.Max.Retrans setting to limit the number of consecutive timeouts >that will trigger the failover. If you modify SCTP provisioning to be something other than the proposed defaults, I thought this might cause significant performance impacts? -----Original Message----- From: Ryan W Bickhart [mailto:bickhart@cis.udel.edu] Sent: Friday, February 11, 2005 3:23 PM To: David Lehmann Cc: sctp-impl@external.cisco.com Subject: Re: SCTP failover I'm not sure switching over to the alternate after seeing a single FR is the best approach for all cases though. Imagine a situation where the alternate is significantly slower or less desirable than the primary. A random FR on the primary may not necessarily be grounds for abandoning it right away. If you need faster failover, you could change the Path.Max.Retrans setting to limit the number of consecutive timeouts that will trigger the failover. Rather than 1 + 2 + ... + 32 = 63 seconds, you could set PMR to 0 or 1 and fail over immediately or in about 1 second if desired. I think the suggested change to the wording in 6.4 is actually already covered by the ability to set the PMR. ---Ryan On Fri, 2005-02-11 at 14:33 -0500, David Lehmann wrote: > David Lehmann wrote: > > Randall Stewart wrote: > > > >> In any event the only way to keep the network failover time > >> down is to set RTO.Max to a lower value.. that would make things > >> faster... To have a 1 second failover I would imagine that > >> Ulticom's stack is setting both RTO.Min and RTO.Max to a > >> lower value... aka that adds up to a total of 1 second.. > >> I.e. something like 50ms RTO.Min and 400ms RTO.Max > > > > > > Nope. When the error count is greater than 0 on the > > primary destination, Ulticom uses an alternate destination, > > until the error is cleared on the primary destination. > > So, if the user is using the default values, the user > > will only see a blip for one second. > > (...assuming an RTO of 1 second) > > I need to correct my former post. Assuming a steady flow > of data chunks, the switch-over with Ulticom's stack will > actually be in a fraction of a second since the FR will > notice the problem long before the RTO. > > > IMHO, waiting around for 1 minute while data trickles through > > the association is not acceptable and does not give the user > > of a sense of transparent network redundancy. > > > > IMHO, the language in section 6.4 should be changed from: > > By default, an endpoint SHOULD always transmit to the primary path, > > unless the SCTP user explicitly specifies the destination transport > > address (and possibly source transport address) to use. > > to something like: > > By default, an endpoint SHOULD always transmit to the primary path, > > unless the error count on the destination is greater than zero or the > > SCTP user explicitly specifies the destination transport address (and > > possibly source transport address) to use. > > > > ------------=_1108155422-28116-0-- From bickhart@cis.udel.edu Fri Feb 11 15:58:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11799 for ; Fri, 11 Feb 2005 15:58:06 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CziBu-0002nh-9J for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 16:19:06 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2005 12:58:32 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1BKvHYO012293; Fri, 11 Feb 2005 12:57:18 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BKv57U028130 for sctp-impl-filtered; Fri, 11 Feb 2005 12:57:07 -0800 (PST) Message-Id: <200502112057.j1BKv57U028130@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108155425-28128-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: RE: SCTP failover List-Id: sctp-impl To: Anatoly Khusid From: Ryan W Bickhart Cc: sctp-impl@external.cisco.com X-Nails-Approved: bickhart@cis.udel.edu Date: Fri, 11 Feb 2005 15:53:22 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 This is a multi-part message in MIME format... ------------=_1108155425-28128-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary On Fri, 2005-02-11 at 15:35 -0500, Anatoly Khusid wrote: > >If you need faster failover, you could change the > >Path.Max.Retrans setting to limit the number of consecutive timeouts > >that will trigger the failover. > > If you modify SCTP provisioning to be something other than the proposed > defaults, I thought this might cause significant performance impacts? The defaults could reamin the same, but since the PMR setting is tunable by the application, it can be adjusted according to the particular needs and network situation where it is deployed. See: 7.1.13 Peer Address Parameters in http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-09.txt ---Ryan ------------=_1108155425-28128-0-- From rrs@cisco.com Fri Feb 11 16:08:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14229 for ; Fri, 11 Feb 2005 16:08:18 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CziLj-0003e1-T6 for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 16:29:18 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2005 13:08:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="161194091:sNHT25191544" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1BL7HYO014921; Fri, 11 Feb 2005 13:07:18 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BL7A7U028296 for sctp-impl-filtered; Fri, 11 Feb 2005 13:07:12 -0800 (PST) Message-Id: <200502112107.j1BL7A7U028296@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108156030-28294-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: Anatoly Khusid From: Randall Stewart Cc: "'Ryan W Bickhart'" , sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Fri, 11 Feb 2005 16:04:21 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 This is a multi-part message in MIME format... ------------=_1108156030-28294-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary IMO considering Armando's work and all.. we really need: 1) 2 levels of failure. a) When you hit a Retranmist limit (set to say 1) you switch to the alternate b) When you hit a Max retransmit you mark the destination as down. c) If the HB sent to the place the t-o happened is sucessful then you clear your count and the primary stays where it was... Note you should send a HB right after a RTO on the place where the RTO happened IMO 2) Always send T-O's to the alternate.. not FR's since Armandos work shows this is not a good idea... and besides you don't switch off due to one loss.. after all you still have an ACK clock or you would not be FR'ing. 3) CMT, which is what Jana is working on, may be even a better method assuming we can find shared bottlenecks. R Anatoly Khusid wrote: >>If you need faster failover, you could change the >>Path.Max.Retrans setting to limit the number of consecutive timeouts >>that will trigger the failover. > > > If you modify SCTP provisioning to be something other than the proposed > defaults, I thought this might cause significant performance impacts? > > -----Original Message----- > From: Ryan W Bickhart [mailto:bickhart@cis.udel.edu] > Sent: Friday, February 11, 2005 3:23 PM > To: David Lehmann > Cc: sctp-impl@external.cisco.com > Subject: Re: SCTP failover > > > I'm not sure switching over to the alternate after seeing a single FR is > the best approach for all cases though. Imagine a situation where the > alternate is significantly slower or less desirable than the primary. A > random FR on the primary may not necessarily be grounds for abandoning > it right away. If you need faster failover, you could change the > Path.Max.Retrans setting to limit the number of consecutive timeouts > that will trigger the failover. Rather than 1 + 2 + ... + 32 = 63 > seconds, you could set PMR to 0 or 1 and fail over immediately or in > about 1 second if desired. I think the suggested change to the wording > in 6.4 is actually already covered by the ability to set the PMR. > > ---Ryan > > > On Fri, 2005-02-11 at 14:33 -0500, David Lehmann wrote: > >>David Lehmann wrote: >> >>>Randall Stewart wrote: >>> >>> >>>>In any event the only way to keep the network failover time >>>>down is to set RTO.Max to a lower value.. that would make things >>>>faster... To have a 1 second failover I would imagine that >>>>Ulticom's stack is setting both RTO.Min and RTO.Max to a >>>>lower value... aka that adds up to a total of 1 second.. >>>>I.e. something like 50ms RTO.Min and 400ms RTO.Max >>> >>> >>>Nope. When the error count is greater than 0 on the >>>primary destination, Ulticom uses an alternate destination, >>>until the error is cleared on the primary destination. >>>So, if the user is using the default values, the user >>>will only see a blip for one second. >>>(...assuming an RTO of 1 second) >> >>I need to correct my former post. Assuming a steady flow >>of data chunks, the switch-over with Ulticom's stack will >>actually be in a fraction of a second since the FR will >>notice the problem long before the RTO. >> >> >>>IMHO, waiting around for 1 minute while data trickles through >>>the association is not acceptable and does not give the user >>>of a sense of transparent network redundancy. >>> >>>IMHO, the language in section 6.4 should be changed from: >>> By default, an endpoint SHOULD always transmit to the primary path, >>> unless the SCTP user explicitly specifies the destination transport >>> address (and possibly source transport address) to use. >>>to something like: >>> By default, an endpoint SHOULD always transmit to the primary path, >>> unless the error count on the destination is greater than zero or the >>> SCTP user explicitly specifies the destination transport address (and >>> possibly source transport address) to use. >>> >> >> > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108156030-28294-0-- From me@armandocaro.net Fri Feb 11 16:28:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20499 for ; Fri, 11 Feb 2005 16:28:24 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzifD-0005iY-MZ for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 16:49:25 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 13:37:31 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BLRxq8024183; Fri, 11 Feb 2005 13:28:00 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BLRw7U028617 for sctp-impl-filtered; Fri, 11 Feb 2005 13:28:00 -0800 (PST) Message-Id: <200502112128.j1BLRw7U028617@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108157278-28615-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP failover List-Id: sctp-impl To: Randall Stewart From: "Armando L. Caro, Jr." Cc: Anatoly Khusid , "'Ryan W Bickhart'" , sctp-impl@external.cisco.com X-Nails-Approved: me@armandocaro.net Date: Fri, 11 Feb 2005 16:16:27 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 This is a multi-part message in MIME format... ------------=_1108157278-28615-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary On Fri, 11 Feb 2005, Randall Stewart wrote: > IMO considering Armando's work and all.. we really need: > > 1) 2 levels of failure. > a) When you hit a Retranmist limit (set to say 1) you > switch to the alternate > b) When you hit a Max retransmit you mark the destination > as down. > c) If the HB sent to the place the t-o happened is sucessful > then you clear your count and the primary stays where it > was... Note you should send a HB right after a RTO on the > place where the RTO happened IMO Yes, I agree. Although you are "failing over" to the alternate on a single timeout, the primary shouldn't be considered failed just yet. However, if the primary is eventually marked as failed (eg, 5-6 consecutive timeouts), then the sender would want to avoid using it as a possible dest to send new data or rtxs until it becomes reachable again. ~armando 0-- --0 | Armando L. Caro, Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 ------------=_1108157278-28615-0-- From iyengar@mail.eecis.udel.edu Fri Feb 11 16:32:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21634 for ; Fri, 11 Feb 2005 16:32:26 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czij8-00069S-AS for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 16:53:27 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2005 13:32:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BLVbTj024389; Fri, 11 Feb 2005 13:31:38 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BLVV7U028675 for sctp-impl-filtered; Fri, 11 Feb 2005 13:31:33 -0800 (PST) Message-Id: <200502112131.j1BLVV7U028675@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108157491-28673-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: lehmann@ulticom.com From: Janardhan Iyengar Cc: sctp-impl@external.cisco.com X-Nails-Approved: iyengar@mail.eecis.udel.edu Date: Fri, 11 Feb 2005 16:20:03 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f This is a multi-part message in MIME format... ------------=_1108157491-28673-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hi David, > >>I need to correct my former post. Assuming a steady flow > >>of data chunks, the switch-over with Ulticom's stack will > >>actually be in a fraction of a second since the FR will > >>notice the problem long before the RTO. > > > > Hmm... I think that is getting too aggressive. This behavior could > > cause reordering and induce false fast retransmits. Why would you do that? > > I don't like to wait! :-) It seems to work well. SCTP (and TCP) increase their cwnds until a sender observes loss. An SCTP sender *has* to see loss to cut its cwnd. Even at equilibrium, an SCTP sender will keep seeing loss. Which means that your sender will keep moving back and forth among the different destinations all the time. Switching over to an alternate on an FR may give you really good failover, but will likely hurt performance when there's no failure (the common case). Optimizing for the common case makes sense. regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- ------------=_1108157491-28673-0-- From anatoly.khusid@ulticom.com Fri Feb 11 16:57:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28057 for ; Fri, 11 Feb 2005 16:57:24 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czj7J-0008G2-5w for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 17:18:25 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2005 13:57:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1BLuKwN009061; Fri, 11 Feb 2005 13:56:21 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BLuC7U029076 for sctp-impl-filtered; Fri, 11 Feb 2005 13:56:14 -0800 (PST) Message-Id: <200502112156.j1BLuC7U029076@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108158972-29068-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: From: "Anatoly Khusid" X-Nails-Approved: anatoly.khusid@ulticom.com Date: Fri, 11 Feb 2005 16:30:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 This is a multi-part message in MIME format... ------------=_1108158972-29068-0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: binary This question deals more with "SCTP Sockets API" draft. I have not seen any explanation in this document regarding the usage of SO_REUSEADDR on SCTP sockets. The following code fails on Solaris 10: ADDR = Some valid address to bind fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) bind(fd1, ADDR) fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) bind(fd2, ADDR) <=== Fails with errno="Address in use" However, the above code works fine on Linux SLES9. Does it mean that Linux has a bug, or this is something implementation dependent? What is the right behavior for SO_REUSEADDR on SCTP sockets? Do you think this should be explained/documented in "SCTP Sockets API"? Thanks, Anatoly Khusid ------------=_1108158972-29068-0-- From me@armandocaro.net Fri Feb 11 17:03:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00045 for ; Fri, 11 Feb 2005 17:03:17 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzjCy-0000RW-RH for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 17:24:18 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 14:13:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="613994184:sNHT50014112" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BM2RTj017411; Fri, 11 Feb 2005 14:02:27 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BM2F7U029170 for sctp-impl-filtered; Fri, 11 Feb 2005 14:02:17 -0800 (PST) Message-Id: <200502112202.j1BM2F7U029170@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108159335-29168-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: Janardhan Iyengar From: "Armando L. Caro, Jr." Cc: lehmann@ulticom.com, sctp-impl@external.cisco.com X-Nails-Approved: me@armandocaro.net Date: Fri, 11 Feb 2005 16:50:46 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 This is a multi-part message in MIME format... ------------=_1108159335-29168-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary On Fri, 11 Feb 2005, Janardhan Iyengar wrote: > SCTP (and TCP) increase their cwnds until a sender observes loss. An SCTP > sender *has* to see loss to cut its cwnd. Even at equilibrium, an SCTP > sender will keep seeing loss. Which means that your sender will keep > moving back and forth among the different destinations all the time. To clarify, even in a "no loss" scenario... a TCP/SCTP sender will eventually see loss if it continues to send and increase its cwnd. In fact, that first loss is how the sender enters congestion avoidance mode. That loss will most likely be detected by the fast rtx algorithm. > Switching over to an alternate on an FR may give you really good failover, > but will likely hurt performance when there's no failure (the common > case). Optimizing for the common case makes sense. Actually, if a failure occurs, you will not be able to fast rtx because the ack clock will be lost. So switching to an alternate on an FR won't even improve failover time. ~armando 0-- --0 | Armando L. Caro, Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 ------------=_1108159335-29168-0-- From bidulock@openss7.org Fri Feb 11 17:10:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00971 for ; Fri, 11 Feb 2005 17:10:15 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzjJj-0000iN-IE for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 17:31:16 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 14:18:54 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BM9Qq8023053; Fri, 11 Feb 2005 14:09:26 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BM9N7U029277 for sctp-impl-filtered; Fri, 11 Feb 2005 14:09:25 -0800 (PST) Message-Id: <200502112209.j1BM9N7U029277@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108159763-29275-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: Anatoly Khusid From: "Brian F. G. Bidulock" Cc: sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Fri, 11 Feb 2005 15:03:38 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 This is a multi-part message in MIME format... ------------=_1108159763-29275-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly, SO_REUSEADDR is described by POSIX and is protocol independent. --brian On Fri, 11 Feb 2005, Anatoly Khusid wrote: > This question deals more with "SCTP Sockets API" draft. I have not seen any > explanation in this document regarding the usage of SO_REUSEADDR on SCTP > sockets. > The following code fails on Solaris 10: > > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > bind(fd1, ADDR) > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > bind(fd2, ADDR) <=== Fails with errno="Address in use" > > > However, the above code works fine on Linux SLES9. Does it mean that Linux > has a bug, or this is something implementation dependent? > What is the right behavior for SO_REUSEADDR on SCTP sockets? > Do you think this should be explained/documented in "SCTP Sockets API"? > > Thanks, > > Anatoly Khusid -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108159763-29275-0-- From iyengar@mail.eecis.udel.edu Fri Feb 11 17:11:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01119 for ; Fri, 11 Feb 2005 17:11:42 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzjL8-0000jq-El for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 17:32:43 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 14:22:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="613998091:sNHT25442260" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1BMAsuC016309; Fri, 11 Feb 2005 14:10:55 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BMAp7U029305 for sctp-impl-filtered; Fri, 11 Feb 2005 14:10:53 -0800 (PST) Message-Id: <200502112210.j1BMAp7U029305@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108159850-29303-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: "Armando L. Caro, Jr." From: Janardhan Iyengar Cc: lehmann@ulticom.com, sctp-impl@external.cisco.com X-Nails-Approved: iyengar@mail.eecis.udel.edu Date: Fri, 11 Feb 2005 16:59:13 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format... ------------=_1108159850-29303-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary > > Switching over to an alternate on an FR may give you really good failover, > > but will likely hurt performance when there's no failure (the common > > case). Optimizing for the common case makes sense. > > Actually, if a failure occurs, you will not be able to fast rtx because > the ack clock will be lost. So switching to an alternate on an FR won't > even improve failover time. Yeah, good point. In fact, turning that reasoning around: when an FR does occur, since an ack clock exists, the ack clock demonstrates that there is no failure! To clarify, an FR occurs only when there are acks coming back; meaning data is getting through and so are acks. Therefore, failure couldn't have happened if an FR happens! regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- ------------=_1108159850-29303-0-- From bidulock@openss7.org Fri Feb 11 17:15:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01467 for ; Fri, 11 Feb 2005 17:15:42 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzjP0-0000qB-Lb for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 17:36:44 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2005 14:15:44 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,195,1102320000"; d="scan'208"; a="161209190:sNHT22054056" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1BMEkYO006529; Fri, 11 Feb 2005 14:14:47 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BMEe7U029376 for sctp-impl-filtered; Fri, 11 Feb 2005 14:14:42 -0800 (PST) Message-Id: <200502112214.j1BMEe7U029376@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108160080-29374-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: "Armando L. Caro, Jr." From: "Brian F. G. Bidulock" Cc: Janardhan Iyengar , lehmann@ulticom.com, sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Fri, 11 Feb 2005 15:09:01 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format... ------------=_1108160080-29374-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Armando, On Fri, 11 Feb 2005, Armando L. Caro, Jr. wrote: > On Fri, 11 Feb 2005, Janardhan Iyengar wrote: > > > SCTP (and TCP) increase their cwnds until a sender observes loss. An SCTP > > sender *has* to see loss to cut its cwnd. Even at equilibrium, an SCTP > > sender will keep seeing loss. Which means that your sender will keep > > moving back and forth among the different destinations all the time. > > To clarify, even in a "no loss" scenario... a TCP/SCTP sender will > eventually see loss if it continues to send and increase its cwnd. In > fact, that first loss is how the sender enters congestion avoidance mode. > That loss will most likely be detected by the fast rtx algorithm. > > > Switching over to an alternate on an FR may give you really good failover, > > but will likely hurt performance when there's no failure (the common > > case). Optimizing for the common case makes sense. > > Actually, if a failure occurs, you will not be able to fast rtx because > the ack clock will be lost. So switching to an alternate on an FR won't > even improve failover time. That's where CMT helps, because the ack clock keeps running (on the other path(s)). The FR can be used to penalize the original transmit transport address, thus shifting traffic on the fly to better performing paths. --brian > > ~armando > > 0-- --0 > | Armando L. Caro, Jr. | Protocol Engineering Lab | > | www.armandocaro.net | University of Delaware | > 0-- --0 -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108160080-29374-0-- From anatoly.khusid@ulticom.com Fri Feb 11 17:26:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03169 for ; Fri, 11 Feb 2005 17:26:52 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzjZo-0001MU-K8 for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 17:47:53 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 14:36:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,196,1102320000"; d="scan'208"; a="614003415:sNHT32757300" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BMP2q8003110; Fri, 11 Feb 2005 14:25:02 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BMP27U029546 for sctp-impl-filtered; Fri, 11 Feb 2005 14:25:04 -0800 (PST) Message-Id: <200502112225.j1BMP27U029546@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108160702-29544-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: SO_REUSEADDR and SCTP socket List-Id: sctp-impl To: From: "Anatoly Khusid" X-Nails-Approved: anatoly.khusid@ulticom.com Date: Fri, 11 Feb 2005 17:00:28 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 This is a multi-part message in MIME format... ------------=_1108160702-29544-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary This question deals more with "SCTP Sockets API" draft. I have not seen any explanation in this document regarding the usage of SO_REUSEADDR on SCTP sockets. The following code fails on Solaris 10: ADDR = Some valid address to bind fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) bind(fd1, ADDR) fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) bind(fd2, ADDR) <=== Fails with errno="Address in use" However, the above code works fine on Linux SLES9. Does it mean that Linux has a bug, or this is something implementation dependent? What is the right behavior for SO_REUSEADDR on SCTP sockets? Do you think this should be explained/documented in "SCTP Sockets API"? Thanks, Anatoly Khusid ------------=_1108160702-29544-0-- From bidulock@openss7.org Fri Feb 11 17:35:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03903 for ; Fri, 11 Feb 2005 17:35:39 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzjiH-0001Zi-TZ for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 17:56:41 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 14:45:58 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,196,1102320000"; d="scan'208"; a="614007985:sNHT20828892" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BMYqq8009973; Fri, 11 Feb 2005 14:34:52 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BMYg7U029697 for sctp-impl-filtered; Fri, 11 Feb 2005 14:34:44 -0800 (PST) Message-Id: <200502112234.j1BMYg7U029697@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108161281-29695-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: Janardhan Iyengar From: "Brian F. G. Bidulock" Cc: "Armando L. Caro, Jr." , lehmann@ulticom.com, sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Fri, 11 Feb 2005 15:28:54 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is a multi-part message in MIME format... ------------=_1108161281-29695-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Janardhan, Except in the CMT case. Success on a good path detects failure on a bad path. --brian On Fri, 11 Feb 2005, Janardhan Iyengar wrote: > > > > Switching over to an alternate on an FR may give you really good failover, > > > but will likely hurt performance when there's no failure (the common > > > case). Optimizing for the common case makes sense. > > > > Actually, if a failure occurs, you will not be able to fast rtx because > > the ack clock will be lost. So switching to an alternate on an FR won't > > even improve failover time. > > Yeah, good point. In fact, turning that reasoning around: when an FR > does occur, since an ack clock exists, the ack clock demonstrates that > there is no failure! > > To clarify, an FR occurs only when there are acks coming back; meaning > data is getting through and so are acks. Therefore, failure couldn't have > happened if an FR happens! > > regards, > jana > > --------------------------------------------------------------- > Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar > Protocol Engineering Lab -- CIS -- University Of Delaware > --------------------------------------------------------------- -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108161281-29695-0-- From anatoly.khusid@ulticom.com Fri Feb 11 17:51:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05231 for ; Fri, 11 Feb 2005 17:51:39 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czjxo-0001wv-Jv for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 18:12:40 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2005 14:52:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1BMohwN027389; Fri, 11 Feb 2005 14:50:43 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BMoZ7U029938 for sctp-impl-filtered; Fri, 11 Feb 2005 14:50:37 -0800 (PST) Message-Id: <200502112250.j1BMoZ7U029938@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108162235-29936-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: RE: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: From: "Anatoly Khusid" Cc: X-Nails-Approved: anatoly.khusid@ulticom.com Date: Fri, 11 Feb 2005 17:28:30 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format... ------------=_1108162235-29936-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary >SO_REUSEADDR is described by POSIX and is protocol independent. It works different on Linux SLES9 vs. Solaris when using SCTP sockets. I provided an example which illustrates the differences. This web site only explains how SO_REUSEADDR work with TCP. Is TCP TIME_WAIT equivalent to SCTP_SHUTDOWN_PENDING ? >You can use setsockopt() to set the SO_REUSEADDR socket option, which explicitly >allows a process to bind to a port which remains in TIME_WAIT (it still only >allows a single process to be bound to that port). This is the both the simplest >and the most effective option for reducing the "address already in use" error. http://hea-www.harvard.edu/~fine/Tech/addrinuse.html -----Original Message----- From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] Sent: Friday, February 11, 2005 5:04 PM To: Anatoly Khusid Cc: sctp-impl@external.cisco.com Subject: Re: SO_REUSEADDR setsockopt() and SCTP Anatoly, SO_REUSEADDR is described by POSIX and is protocol independent. --brian On Fri, 11 Feb 2005, Anatoly Khusid wrote: > This question deals more with "SCTP Sockets API" draft. I have not seen any > explanation in this document regarding the usage of SO_REUSEADDR on SCTP > sockets. > The following code fails on Solaris 10: > > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > bind(fd1, ADDR) > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > bind(fd2, ADDR) <=== Fails with errno="Address in use" > > > However, the above code works fine on Linux SLES9. Does it mean that Linux > has a bug, or this is something implementation dependent? > What is the right behavior for SO_REUSEADDR on SCTP sockets? > Do you think this should be explained/documented in "SCTP Sockets API"? > > Thanks, > > Anatoly Khusid -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108162235-29936-0-- From rrs@cisco.com Fri Feb 11 17:54:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05419 for ; Fri, 11 Feb 2005 17:54:25 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czk0U-000203-N8 for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 18:15:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 15:03:05 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1BMrdq8019477; Fri, 11 Feb 2005 14:53:39 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BMra7U029989 for sctp-impl-filtered; Fri, 11 Feb 2005 14:53:38 -0800 (PST) Message-Id: <200502112253.j1BMra7U029989@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108162415-29987-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: Anatoly Khusid From: Randall Stewart Cc: sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Fri, 11 Feb 2005 17:50:50 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format... ------------=_1108162415-29987-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly: I know for KAME-BSD you would also get a failure. We don't support the concept of SO_REUSADDR. Namely because: a) There is no timed wait with an SCTP endpoint. Thus you don't necessarily need this to reopen a socket. and b) The one-to-many model allows you to peel things off if you want to push associations out to other threads. The sockets API draft does not cover it.. and so it is really implementation dependant.. I don't know why one would want it... R Anatoly Khusid wrote: > This question deals more with "SCTP Sockets API" draft. I have not seen any > explanation in this document regarding the usage of SO_REUSEADDR on SCTP > sockets. > The following code fails on Solaris 10: > > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > bind(fd1, ADDR) > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > bind(fd2, ADDR) <=== Fails with errno="Address in use" > > > However, the above code works fine on Linux SLES9. Does it mean that Linux > has a bug, or this is something implementation dependent? > What is the right behavior for SO_REUSEADDR on SCTP sockets? > Do you think this should be explained/documented in "SCTP Sockets API"? > > Thanks, > > Anatoly Khusid > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108162415-29987-0-- From lehmann@ulticom.com Fri Feb 11 17:59:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05804 for ; Fri, 11 Feb 2005 17:59:32 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czk5Q-00025v-0k for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 18:20:34 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2005 15:09:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,196,1102320000"; d="scan'208"; a="614015741:sNHT55297500" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1BMwhTj015483; Fri, 11 Feb 2005 14:58:43 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BMwa7U000076 for sctp-impl-filtered; Fri, 11 Feb 2005 14:58:38 -0800 (PST) Message-Id: <200502112258.j1BMwa7U000076@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108162716-74-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: sctp-impl@external.cisco.com From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Fri, 11 Feb 2005 17:35:55 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multi-part message in MIME format... ------------=_1108162716-74-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Janardhan Iyengar wrote: >>>Switching over to an alternate on an FR may give you really good failover, >>>but will likely hurt performance when there's no failure (the common >>>case). Optimizing for the common case makes sense. >> >>Actually, if a failure occurs, you will not be able to fast rtx because >>the ack clock will be lost. So switching to an alternate on an FR won't >>even improve failover time. > > > Yeah, good point. In fact, turning that reasoning around: when an FR > does occur, since an ack clock exists, the ack clock demonstrates that > there is no failure! > > To clarify, an FR occurs only when there are acks coming back; meaning > data is getting through and so are acks. Therefore, failure couldn't have > happened if an FR happens! Well, we tested it with a real failure. To be honest, I have not looked at that code in a long time. So maybe my follow-up comment was wrong. I have to look into it. Nonetheless, I do know that the switch-over occurs after the error count on the primary is greater than zero, which gives better switch-over performance. The lk-sctp switch-over time is unacceptable, IMHO. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108162716-74-0-- From rrs@cisco.com Fri Feb 11 18:02:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06013 for ; Fri, 11 Feb 2005 18:02:21 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czk8B-00029p-D3 for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 18:23:23 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 11 Feb 2005 15:02:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1BN1VwN029676; Fri, 11 Feb 2005 15:01:31 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BN1O7U000127 for sctp-impl-filtered; Fri, 11 Feb 2005 15:01:26 -0800 (PST) Message-Id: <200502112301.j1BN1O7U000127@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108162884-125-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: Anatoly Khusid From: Randall Stewart Cc: bidulock@openss7.org, sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Fri, 11 Feb 2005 17:58:39 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab This is a multi-part message in MIME format... ------------=_1108162884-125-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Exactly.. so-reusaddr is to help escape time-wait. SCTP does not have a time-wait.. except maybe on V-tags.. not on ports or connections... Anatoly Khusid wrote: >>SO_REUSEADDR is described by POSIX and is protocol independent. > > > It works different on Linux SLES9 vs. Solaris when using SCTP sockets. > I provided an example which illustrates the differences. > This web site only explains how SO_REUSEADDR work with TCP. > Is TCP TIME_WAIT equivalent to SCTP_SHUTDOWN_PENDING ? No, shutdown-pending is when you the side shutting down does something like: send(sd,...) close(sd) What happens is the data is put out (assuming you have not tweaked the so_linger options) and is still waiting for a SACK.. and you close.. so the association gets a shutdown-pending flagged on it. When the close completes the assoc frees... Of course you don't have quite the same scenario in a 1-2-many model.. you can do sendxx(sd,addr,...data) sendxx(sd,addr, MSG_EOF) (if I remember the right flag here) Which gracefully shuts down the association.. and again since the MSG_EOF comes right after the send.. the data is probably not ack'd.. the associaiton goes into SHUTDOWN-PENDING.... Timed wait happens after all is closed in TCP and you are waiting the 2 MSL's before you can safely reuse the port again.... SCTP does not have this issue due to the v-tags R > > > >>You can use setsockopt() to set the SO_REUSEADDR socket option, which > > explicitly > >>allows a process to bind to a port which remains in TIME_WAIT (it still > > only > >>allows a single process to be bound to that port). This is the both the > > simplest > >>and the most effective option for reducing the "address already in use" > > error. > > http://hea-www.harvard.edu/~fine/Tech/addrinuse.html > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, February 11, 2005 5:04 PM > To: Anatoly Khusid > Cc: sctp-impl@external.cisco.com > Subject: Re: SO_REUSEADDR setsockopt() and SCTP > > > Anatoly, > > SO_REUSEADDR is described by POSIX and is protocol independent. > > --brian > > On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > >>This question deals more with "SCTP Sockets API" draft. I have not seen > > any > >>explanation in this document regarding the usage of SO_REUSEADDR on SCTP >>sockets. >>The following code fails on Solaris 10: >> >> >>ADDR = Some valid address to bind >>fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); >>setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) >>bind(fd1, ADDR) >>fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); >>setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) >>bind(fd2, ADDR) <=== Fails with errno="Address in use" >> >> >>However, the above code works fine on Linux SLES9. Does it mean that > > Linux > >>has a bug, or this is something implementation dependent? >>What is the right behavior for SO_REUSEADDR on SCTP sockets? >>Do you think this should be explained/documented in "SCTP Sockets API"? >> >>Thanks, >> >>Anatoly Khusid > > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108162884-125-0-- From Churchwkfv@concentric.net Fri Feb 11 18:08:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08454; Fri, 11 Feb 2005 18:08:14 -0500 (EST) Date: Fri, 11 Feb 2005 18:08:14 -0500 (EST) From: Churchwkfv@concentric.net Message-Id: <200502112308.SAA08454@ietf.org> Received: from ip-212-166.sn1.eutelia.it ([62.94.212.166]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzkDp-0002J5-M5; Fri, 11 Feb 2005 18:29:16 -0500 Received: from networkone.net ([216.218.186.2]) by eight.netcom.com (InterMail vK.4.04.00.00 985-252-478 license 0xi929hq3430v8fv6f8jew7866p9azw8) with ESMTP id <89980294897132.A[4 X-Spam-Score: 22.6 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From bidulock@openss7.org Fri Feb 11 18:55:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13833 for ; Fri, 11 Feb 2005 18:55:09 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzkxI-0003Rf-02 for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 19:16:12 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 16:03:50 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1BNsDwN011146; Fri, 11 Feb 2005 15:54:14 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1BNrw7U000942 for sctp-impl-filtered; Fri, 11 Feb 2005 15:54:00 -0800 (PST) Message-Id: <200502112354.j1BNrw7U000942@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108166038-934-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: Anatoly Khusid From: "Brian F. G. Bidulock" Cc: sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Fri, 11 Feb 2005 16:48:10 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This is a multi-part message in MIME format... ------------=_1108166038-934-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly, POSIX: SO_REUSEADDR Specifies that the rules used in validating addresses supplied to bind() should allow reuse of local addresses, if this is supported by the protocol. This option takes an int value. This is a boolean option. SO_REUSEADDR is necessary to bind to a protocol address that is already listening or connected (or in the case of TCP in timed wait as well). The former two are perfectly applicable to SCTP. --brian On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > >SO_REUSEADDR is described by POSIX and is protocol independent. > > It works different on Linux SLES9 vs. Solaris when using SCTP sockets. > I provided an example which illustrates the differences. > This web site only explains how SO_REUSEADDR work with TCP. > Is TCP TIME_WAIT equivalent to SCTP_SHUTDOWN_PENDING ? > > > >You can use setsockopt() to set the SO_REUSEADDR socket option, which > explicitly > >allows a process to bind to a port which remains in TIME_WAIT (it still > only > >allows a single process to be bound to that port). This is the both the > simplest > >and the most effective option for reducing the "address already in use" > error. > > http://hea-www.harvard.edu/~fine/Tech/addrinuse.html > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, February 11, 2005 5:04 PM > To: Anatoly Khusid > Cc: sctp-impl@external.cisco.com > Subject: Re: SO_REUSEADDR setsockopt() and SCTP > > > Anatoly, > > SO_REUSEADDR is described by POSIX and is protocol independent. > > --brian > > On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > > This question deals more with "SCTP Sockets API" draft. I have not seen > any > > explanation in this document regarding the usage of SO_REUSEADDR on SCTP > > sockets. > > The following code fails on Solaris 10: > > > > > > ADDR = Some valid address to bind > > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > > bind(fd1, ADDR) > > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > > bind(fd2, ADDR) <=== Fails with errno="Address in use" > > > > > > However, the above code works fine on Linux SLES9. Does it mean that > Linux > > has a bug, or this is something implementation dependent? > > What is the right behavior for SO_REUSEADDR on SCTP sockets? > > Do you think this should be explained/documented in "SCTP Sockets API"? > > > > Thanks, > > > > Anatoly Khusid > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108166038-934-0-- From kacheong.poon@sun.com Fri Feb 11 20:34:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19697 for ; Fri, 11 Feb 2005 20:34:10 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzmV6-0005Ap-Fh for sctp-impl-archive@ietf.org; Fri, 11 Feb 2005 20:55:12 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2005 17:42:50 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1C1XFuC010214; Fri, 11 Feb 2005 17:33:15 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1C1WT7U002463 for sctp-impl-filtered; Fri, 11 Feb 2005 17:32:31 -0800 (PST) Message-Id: <200502120132.j1C1WT7U002463@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108171949-2461-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: Anatoly Khusid From: Kacheong Poon Cc: sctp-impl@external.cisco.com X-Nails-Approved: kacheong.poon@sun.com Date: Fri, 11 Feb 2005 17:29:40 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multi-part message in MIME format... ------------=_1108171949-2461-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly Khusid wrote: > This question deals more with "SCTP Sockets API" draft. I have not seen any > explanation in this document regarding the usage of SO_REUSEADDR on SCTP > sockets. > The following code fails on Solaris 10: > > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > bind(fd1, ADDR) > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > bind(fd2, ADDR) <=== Fails with errno="Address in use" The second bind() fails because the first socket is still in bound state. If the first socket is in, say, established state, the second bind() will succeed. This is the same behavior as a TCP socket. > However, the above code works fine on Linux SLES9. Does it mean that Linux > has a bug, or this is something implementation dependent? > What is the right behavior for SO_REUSEADDR on SCTP sockets? > Do you think this should be explained/documented in "SCTP Sockets API"? -- K. Poon. kacheong.poon@sun.com ------------=_1108171949-2461-0-- From RCYPMGO@k-trade.com.ua Sat Feb 12 00:37:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03822; Sat, 12 Feb 2005 00:37:47 -0500 (EST) Received: from [221.15.5.56] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzqIo-00013I-Vs; Sat, 12 Feb 2005 00:58:53 -0500 X-Message-Info: 1F7OCvygDB2JDDmlZdbNA5sIZ7ibfFQxewYB28BF8 Received: (from australite@localhost) by textbooktheoreticianF.RCYPMGO@k-trade.com.ua (1.27.3/9.95.6) id fo11ADIcK761E; Sat, 12 Feb 2005 10:28:27 +0500 Message-ID: <8312F71E1.D384F@RCYPMGO@k-trade.com.ua> Reply-To: "Will Delgado" From: "Will Delgado" To: "Rohc-request" Subject: healthcare lists, western hemisphere database, and the entire united states Price of $195 (reg. $745). Date: Sat, 12 Feb 2005 04:30:27 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--86285BAEB7A75FBF6" X-Spam-Score: 10.8 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----86285BAEB7A75FBF6 Content-Type: text/plain; charset="iso-2CAF-B" Content-Transfer-Encoding: quoted-printable 2005 EDITION United States Healthcare Database. PRE-PUBLICATION PRICE OF $195. LIMITED TIME. In a rapidly-changing industry, current healthcare information is an invaluable resource to businesses and organizations. The United States Healthcare Database includes comprehensive information on more than 7,000 hospitals, 25,000 nursing homes and 400,000 doctors. It is the most extensive and reliable mailing list and database of key decision makers in the health care market. Each record is indexed by such features as name, address, phone and fax. The database is available in Excel format on CD Rom. It is designed for mailing lists and merges. The data can be selected by state or other criteria such as type of practice. It can be used on an unlimited basis. Price of $195 (reg. $745). BONUS OFFER: FREE OF CHARGE ORDER NOW AND RECEIVE THE AMERICAN DIRECTORY OF 200,000 DENTISTS ON CD-ROM FREE OF CHARGE ($375 value).. (Each record is indexed by such features as name, address, phone/fax, county, year licensed, type of practice, type of dentist as well as specialty.) To order, please print this e-mail, complete the information below and fax it to 416-765-0029 (tel: 416-765-0028). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: STATE: POSTAL: TEL: FAX: EMAIL: MedCom 4410 Massachusettes Ave. NW, #201 Washington, DC 20016 To be removed from the database please follow this link, http://notinuse.biz/takeoff/takeoff.html ----86285BAEB7A75FBF6-- From LYGTUQXVVE@emt.ee Sat Feb 12 00:58:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05475; Sat, 12 Feb 2005 00:58:11 -0500 (EST) Received: from c66.190.110.2.ts46v-01.rckprt.tx.charter.com ([66.190.110.2]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Czqcc-0001YB-CL; Sat, 12 Feb 2005 01:19:17 -0500 X-Message-Info: 8AP7E0BFjchswEAZI1BopYTusWVR1C9afXB3aDnojZSX05HYBF Received: (from @66.190.110.2) by 7.2.159.233.33 (3.4B.9/9.73.6) id ueD1BOHjB3782D; Sat, 12 Feb 2005 00:54:05 -0500 Message-ID: <96740D557A99.2B4A4@66.190.110.2> Reply-To: "Jennie Bonilla" From: "Jennie Bonilla" To: sctp-impl-archive@ietf.org Subject: quick profits will match your investment style Date: Sat, 12 Feb 2005 07:57:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2F558FCCE11C6AEB6E9" X-Spam-Score: 18.3 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----2F558FCCE11C6AEB6E9 Content-Type: text/plain; charset="iso-F693-A" Content-Transfer-Encoding: quoted-printable ***GEEC*****GEEC*****GEEC*****GEEC*****GEEC*** Global Environmental Energy Corp. (OTC-BB: GEEC) Shares Outstanding : 35 million Approx. Float : 9 million 30 Day Target : $6.25 6 Month Price Projection : $15.00 Recent News and Major Share-Price Driving Milestones: GEEC just announced a $10 Billion, 5-year joint venture with several companies operated by the Chinese Government. GEEC uses their Biosphere Process System to convert various types of waste into clean, "green" electricity at 5 to 10 mega-watts per hour. GEEC Chairman, former Prime Minister of Ireland Dr. Albert Reynolds, has secured a $2 Billion line of credit for GEEC and opened doors in over a dozen countries through political contacts at the highest level. Global Environmental Energy is CBS Marketwatch.com's #1 Best Performer in the DJ Diversified Industrials Index in the last 2 months. This Dow Jones Index also contains 3M, GE, and Honeywell. Conservative estimates value the company at One Billion Dollars Future Milestones: 1. GEEC had a $100 Million backlog of sales orders for the Biosphere before the China joint-venture with 26 completed Biospheres in operation. The backlog is now into the Billions with complete financing to be provided by China and 1,300 Biospheres to be deployed throughout the country. 2. GEEC's present assets of $35 Million will conservatively jump into the $300 Million range, a 10-times increase. 3. GEEC is in advanced stages of agreement on at least 6 major international projects which could add $50 Million to the bottom-line or $1.42 per share. 4. P/E on average for this Industry Group is 20 to 1 putting GEEC in the $13 dollar range without any future business expansion. 5. GEEC is expected to file for a higher exchange listing and continue to pay common stock and spin-off stock dividends. Worldwide Market Potential $15 to $25 Billion over next 5 years with no other known company that can match their technology, leadership, or explosive sales growth. Up until now GEEC has been one of Wall Street's best kept secrets, yet now it seems the cat is coming out of the bag and the release of this new Investor Awareness Campaign should be excellent timing in regards to some new PR's forthcoming which will Rocket GEEC. This power-play has nowhere to go but up, according to most insiders, and there's still a bit of time to get in before the boom. DISCLOSURE: The information and opinions in this feature profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past-results is not an indicator of future-results. This report is a paid profile and is for information purposes only and should not be used as the basis for any investment decision. Ten thousand dollars has been paid for the preparation of this profile and for continuing coverage of the featured company. We are not an investment advisor and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains forward-look-ing statements and is subject to significant risks and uncertainties. There are no shares held and there will be no participation in the trading of shares of any profiled company. ----2F558FCCE11C6AEB6E9-- From support@paypal.com Sat Feb 12 02:01:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11317 for ; Sat, 12 Feb 2005 02:01:05 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzrbV-0002wU-GC for sctp-impl-archive@ietf.org; Sat, 12 Feb 2005 02:22:09 -0500 Received: from [216.117.177.39] (helo=216.117.177.39) by mx2.foretec.com with smtp (Exim 4.24) id 1CzrH7-0002ec-L3 for sctp-impl-archive@ietf.org; Sat, 12 Feb 2005 02:01:05 -0500 Received: from 88.204.171.134 by ; Sat, 12 Feb 2005 12:00:03 +0500 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Sat, 12 Feb 2005 10:58:03 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5191802655816924633" X-IP: 118.68.148.21 X-Priority: 3 X-Spam-Score: 8.8 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----5191802655816924633 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----5191802655816924633-- From UMTOKTPSTDTNC@telusplanet.net Sat Feb 12 09:10:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03839; Sat, 12 Feb 2005 09:10:02 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzyIg-0003gM-MN; Sat, 12 Feb 2005 09:31:10 -0500 Received: from dpc691921067.direcpc.com ([69.19.21.67]) by mx2.foretec.com with smtp (Exim 4.24) id 1Czxy6-0005RO-Sh; Sat, 12 Feb 2005 09:09:58 -0500 X-Message-Info: YRQEukYW96cUVguzJLGi9zl15X776WcNSxgr Received: from amyxadmq8.agt.net (77.96.156.168) by q61-g.agt.net with Microsoft SMTPSVC(5.0.2195.6824); Sat, 12 Feb 2005 10:08:07 -0400 Received: from chieftainrl1 (purgation28.41.161.114) by agt.net (tl9) with SMTP id <97990815658q775g> (Authid: SheriBishop); Sat, 12 Feb 2005 16:08:07 +0200 From: "Gwendolyn Porter" To: "'Sctp-impl-archive'" Subject: Your P-C is under siege - stop it now default Date: Sat, 12 Feb 2005 18:02:07 +0400 Message-ID: <767ot127nk75$83ql0ugr702$3i810g@deuteriumdisembowelgrotesqueflg45754> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--02976098773506120" X-Spam-Score: 5.9 (+++++) X-Spam-Flag: YES X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----02976098773506120 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Yes, this is sooo true. Your pc in currently under siege - tons of
spy=wares are running on your box, well known worms and trojans and
much more.
I need to know more
Got some important stuff on your box? Family pics? Secret stuff? Sexy pics
of your g'f? You don't want this to leak, or DO YOU?
I, personally, don't want it. For sure.
I want to stop it

take me uff steady ire mu burglary derrick lift bushwhack duplex resin. cleanse teakwood censorious timeout pacesetting cerebrate. by highway isolate upstart demean confuse befallen.
pilgrimage embargo burglary bittersweet baldy counterproductive julia. send neuritis philodendron mustache ghost. printout burglary boil thunderstorm chump bunkmate fischer. quakeress albumin infrared goode isolate downcast bivalve calais. knurl chard birthplace isolate sleep anselmo acquisition eardrum hypocritic.
hymen centroid liniment denature fredholm degassing loeb doge dicotyledon. publication trilobite mockingbird denature duckling instant franklin. scandalous isolate baud eisner. clifton cryptanalyze teahouse andy elastic bourgeois frothy everyday colatitude stultify. broccoli nomad interruptible elastic wishful libertine newsman.
defend priam denature wisconsin zomba adonis. bliss anorthosite elastic prerequisite bator. loosestrife cowan elastic miscellany berglund sunbonnet. ----02976098773506120-- From support@paypal.com Sat Feb 12 13:50:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21344 for ; Sat, 12 Feb 2005 13:50:28 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D02g8-0000CS-Di for sctp-impl-archive@ietf.org; Sat, 12 Feb 2005 14:11:40 -0500 Received: from [216.117.177.39] (helo=216.117.177.39) by mx2.foretec.com with smtp (Exim 4.24) id 1D02Ld-0003b6-KM for sctp-impl-archive@ietf.org; Sat, 12 Feb 2005 13:50:29 -0500 Received: from 40.176.142.192 by ; Sat, 12 Feb 2005 21:43:27 +0300 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Sat, 12 Feb 2005 17:49:27 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--557890985028019" X-Webmail-Time: Sat, 12 Feb 2005 11:44:27 -0700 X-Spam-Score: 10.9 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----557890985028019 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----557890985028019-- From service@paypal.com Sat Feb 12 15:28:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28169 for ; Sat, 12 Feb 2005 15:28:44 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D04DE-0001x6-Q1 for sctp-impl-archive@ietf.org; Sat, 12 Feb 2005 15:49:57 -0500 Received: from [216.117.177.39] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D03sj-0005xF-GG for sctp-impl-archive@ietf.org; Sat, 12 Feb 2005 15:28:45 -0500 Received: from [230.108.82.53] by 65.246.255.50 with ESMTP id 44601641; Sun, 13 Feb 2005 02:23:43 +0600 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Sun, 13 Feb 05 02:23:43 GMT X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1B584D201FBA84" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 26.7 (++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --1B584D201FBA84 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--1B584D201FBA84-- From Gerold_Gideon@niia.net Sat Feb 12 15:29:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28629; Sat, 12 Feb 2005 15:29:38 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D04E2-0001yr-2J; Sat, 12 Feb 2005 15:50:51 -0500 Received: from [61.32.61.78] (helo=8-JFTI1PFQ914W) by mx2.foretec.com with smtp (Exim 4.24) id 1D03tO-0005xW-1G; Sat, 12 Feb 2005 15:29:27 -0500 Received: from mail.yogajournal.com (61.32.61.78) by 61.32.61.78 (emplacev.568) with SMTP id <0404033n4d> (Authid: 076); Sat, 12 Feb 2005 13:28:13 -0700 Reply-To: "Odd Madge" From: "Odd Madge" To: saad@ietf.org Cc: saad-admin@ietf.org, saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org, seamoby@ietf.org, seamoby-admin@ietf.org, seamoby-archive@ietf.org, seamoby-request@ietf.org, seamoby-web-archive@ietf.org, secdir@ietf.org, secdir-admin@ietf.org, secdir-web-archive@ietf.org Subject: You're approved for $673488 Date: Sat, 12 Feb 2005 16:27:13 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0884943_465682.vmE019" Message-Id: X-Spam-Score: 2.2 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----0884943_465682.vmE019 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. This means that you're eligible for $ 435,000 with a 3.1% rate. Takes a few minutes to see what you can save! Please verify your information here: http://sore.masfre.info:443/ajrrg We look forward to hearing from you. Odd Madge, Account Manager TJK Associates r*mv - http://masfre.info:443/index.php ----0884943_465682.vmE019-- From Michael.Tuexen@micmac.franken.de Sat Feb 12 15:48:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00013 for ; Sat, 12 Feb 2005 15:48:36 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D04WS-0002WN-HO for sctp-impl-archive@ietf.org; Sat, 12 Feb 2005 16:09:49 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2005 12:49:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,197,1102320000"; d="scan'208"; a="161259694:sNHT33185076" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1CKlBwN011149; Sat, 12 Feb 2005 12:47:12 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1CKkR7U019833 for sctp-impl-filtered; Sat, 12 Feb 2005 12:46:29 -0800 (PST) Message-Id: <200502122046.j1CKkR7U019833@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108241187-19830-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: how to get sctp ... List-Id: sctp-impl To: Ilknur Aydin From: Michael Tuexen Cc: sctp-impl@external.cisco.com X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Sat, 12 Feb 2005 21:04:46 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is a multi-part message in MIME format... ------------=_1108241187-19830-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary I would suggest the LKSCTP implementation... Best regards Michael On Feb 10, 2005, at 5:34 Uhr, Ilknur Aydin wrote: > > > Hello all: > > we need a free sctp real implementation in linux kernel (version > 2.4.20) or in user-space with Dynamic Address Reconfiguration > extension. > Where could we get it ? Which one would you suggest ? > > Also, where could we get a real multimedia application (may be video) > -hopefully- with source code that uses SCTP? > > thanks, > ilknur ------------=_1108241187-19830-0-- From tyohnfigs@repairman.com Sat Feb 12 21:11:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20461; Sat, 12 Feb 2005 21:11:31 -0500 (EST) Received: from c-24-22-142-131.client.comcast.net ([24.22.142.131]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D09Ys-0008JB-OF; Sat, 12 Feb 2005 21:32:46 -0500 Received: from dczqq.alabama.com [214.237.103.205] by 24.22.142.131 with tealogk fnqokeasr; Sun, 13 Feb 2005 17:54:57 -0500 From: HEH Mega Reply-To: HEH Mega Message-ID: <471917811.31408028892174@alabama.com> Date: Sun, 13 Feb 2005 17:54:57 -0500 To: "Rmt" Subject: For Your PC - Useful Program Components MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----437187240054721683" X-Spam-Score: 22.0 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c ------437187240054721683 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Program Components on CompDisk with registration key

Not academic or trial - It will be original package

louver bookbind foliage mannerly confluent barrel disquiet lie nanometer bijection hailstone motives continues callousness Crimea midwinter oddly identify heeds astride Shulman mussel's Vietnam citations jab's Gaithersburg belayed Knudson Jewell deviates acculturates nonuniform infuriate Shipley antiquarians alleviater fatter Rabin african London intoxicant ballyhoo apparent dents former Churchillian anodic dragonhead Cohn net's jostles attires extraterrestrial brushlike Mbabane metallic alkali opals Dunkirk claimant's fluorescein ------437187240054721683 Content-Type: image/gif; name="hockey.gif" Content-ID: <9947117175@alabama.com> Content-Transfer-Encoding: base64 R0lGODlh0gESAcQAAAYF6gMD+PEEBAcG4gkIwAcG2uIGBgwKb6sICcAICAsJkggH0gsJn+oFBQsK gtsGBwUE8QoItv3dQ1y3khnAlUe7UIBiwfbnsKOAB4Zzveb5Gfb9Cf8AAAAA/wAAAP///yH5BAAA AAAALAAAAADSARIBAAX/4CeOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY5+CA8C HJQCDwgllJqbmyKclBSenxwzCAYUoAYJFiaRk5WXmaOds5+omxIfF5oNHxKcoSO1GbK1DRgVwrWa j81REq+jArmiy6QfsxUZszINtQYj0LXTysvY1pQGnKzqzBac4CLvswnFyxTU6NfO/EveywLKmTv3 yQICbjASLIv34d84gdz0cVC4qZ5DUhQ11ROxa1YvEhIfVBvYr6SRg+gw/xEcSC8jpxjRRsVDaU0l upXL5mkSySkDhnUjYn6yZ21kLZNIiTzQJxInwlkG2g2FYS3eUnRNb0qswKkB100ZpFJK9uFrLZVG r9Fk5nRU0rdAhF7QxSmg0xSzKAhl++ITMRNy6W6yOxXvSxK3NG3btCExh2Af1o7CAPIwzmCF4WoG 8imZWbb60t6EIZRCVAzUnHqeOhriPhFiJ3LqqInhVV51K3eKzIly28ybg9MozHq0xN0vXBZM61q0 ZeYklLf7J3TjB8ccfnFKre/j7+fCw1O1XLzo96Mxbn/6SPxwa+gjdHJSromVL2AfYm9w3Rvteb7i BdhCdR8oR5hxx1EyQ/8FFiRAG1sEGugccvCJ8Bkto5BF3yhN/WfdhBQKKCIK6tWSFXi61bZJbK+1 gAFai+1W4iwnklShCNhx0MtFoIzAIkJOxZbaXSMW6YJks9iEIGNMorjCj5rYheQoSoZoAnD5fULZ T/DwN8tfn0jm3X8KGmkmCTx+YheZ13yiHSVvAtgClJT41pA1a2JJVIsFfrLfBp9sJJ81c91FIIhy nlmkBGlGyd2SzLwSkJ4q0Dkmo+M8auWeJgzKATEx1sfRbCOIyRx9+bynqJmuRBlLiugN1dFclKqA AAZiqXJCq7D4R6RhVl64T2ciCGUfdOXxgmiZqzbr7LPQRivttNRWa+3/tdhmq+223Hbr7bfghivu uOSWa+656Kar7rrstuvuu/DGK++89NZr77345qvvvvz26++/AAcs8MAEF2zwwQgnrPDCDDfs8MMQ RyzxxBT/4QEJHlycMQob35DxxTuAzHHHH3z8cckkn6yCyiiL/ILLL8McBMlP0HyCzSHLLALORPBc Asw+64zxxixfAfTOP48g9Ms7L82DyFAr3bTSTlNt9RBRp1B1DFuv0LXUSSPt9cxhl7zE12aLrfXa ahudtthHtz1D1kLErfHQV3sNNdo10H3z0x7DILPfHJONMdhJoE24CU7frYXjcA8NssaTD1755S0T TTnKU2+ON+eIw03z/92Qr2w25ClXzrnmoJtM9eStY271ybR7/nrTQHuuctGZx+7y7rH/nLrqNnfM esuSI2187qur3vzxKc9Oueawjz792r+z7rMRpcN+eOdp/4649+Er/z3RcpeevvlSk96C+96Lv7ro p68PPtiDs1//2+UTjn7Wdisf/9T2v7ZVD38DxJ/7Bri3/TEPfQp04PkmGL/Zha1q8pMgE0wGwLJV j3cQFGD/HAe83p0vg5FL2gJvd7gFug55Aqwg6L4XQ+MxToQkpGDo+odA4eGOfONTXtEOSMCb2VCD QTwdCFNYwhzCUHwQJB8QRVi4IE4RCXSbYgeXhroiMvGLf7Pf2zpIRf+2yRCMMlRfEp2osyMikYf2 6yIDaSi3MepPh5ELIBzjBscb7jGP7NOiF8nYQ7YV8Yrco17mrIc8ReZtd8tL4SKXlz3e4e51tSPd 9i55vSdycHocnKQPa9c7nFUSk5Lr5O0cOUMTQnKU2ive3oiXu1BSL3uNVGUun+e6W05SfphT5PBa xzjrzZJv+1pc36SgzIqVy5I02KQSoOnMalrzmtjMpja3yc1zIXNqHpOmDHr5wh58k2t1C9zTzrnN ZjKtlerEISO2xk4X1DOb7rTnDpfpxzoWgp7pVNj/ZgnOWNrukkoE5+cgCcrNQU+TZaNjLQt6vUzG 8oef65xDdUdOhYL/b3ivJCVHR6pR4cnOkwiL4h9jWMYGOtGL8uxj+F6aQP4B84QFZaILw6jTPxLx gYG8YwMLKccQ9jGHiATY5brXxJkWD4HlvF9MHYrQpdIxdCh8ohV76LzkcRWQEoyqU7vqvCy6sagG pCFSqfkvIGY1i1WUqQqJ+lWW8lSKET0jLr/YxrTaFal3nOAOCZnG9tXVr2FNGEOr6shT4k2kjGRs WQn4SYR6NZTFXGomx2dLzKISkxbtJDkda9FFSs+qwqRkKxeL0RJ2ExEA9Sc/Z3vP11ZLnJbNAVvt iVvb+va3wA2ucIdL3OIa97jITa5yl8vc5jr3udCNrnSnS93qWve6/9jNrna3y93ueve74NWn9EaG g92O05B6Y0Fl08vANtZ2buL0rAmNWNvNJu6ekY3me3ur2/eq94IeVCd/A1rTfnaNi3HlnmwDbMe7 8tONWHxnRAssYRv4t8L7XOZN1RrPC3f4fRTup4iv2jPBGXZsJBZviEus4qvWV7cRHrGFbWpAG0bS h55saPOCd9DgjdeYQvSoZR860Jw+lcea9XEpJ4rSDKpxxJC1qWpfOT9ZfhSXF2VZ6hg7ZCEjecgb hecMoxxJUpa0nFSmcjRpPMePIpawYKWfIPs6P7XutIWP/auU2yznlQZVkA2WJYQTrMHR0bWGFCae XxX9U8GeuNF+LP8gm+8MYCLyNdJg3XBS1YtmMX7QynBOqOysilPB8vHTfOQqGY9oN1bn1KkUPTIh B/tfPLf00C8cKgtJjcYRqnaMKlWioDPdQk0Ou35RtHHe9Bw/VpvXkLMOdKKlPcheO9jUDH4ytdWH 11sX9qaWLnC388dgA4NxjYVErJ4x7VNsr/TJ346jPwtr19W6G7D1hm9F5ZtaGCqUta7+IWsFblIz a3SjldxsZT85ZYIyXJRLXu8Qfz1xyy2u4mJdrMaPl8qBC/yikh0pSUG4cFA6muS2pOxZLa7K0ZL0 Wvn8MLS5yTcPU+vZ4aTngBs2YJyH9+dAD7rQh070Ptica0ef5rL/Dbf0YrL3CBNHui55O/UmbHLn jrhw0p2w9Zlf23QgDtmEUTxoFXd9zWAXjtbZcPavlxu9aYdxir2O9hUnDsVtIDPqQkpxXecYlkrm aGbDfNAs15LRZc71jU+7yy37EnhATig8texSYxKUos+LoEk5eeMi09fwuRQtwi1XUn/Pl6yLP3jj qVqEqDUbwMRsNJ39x3pisxnRbjUfoBXda0hD9dF4lCK3LZj7xO7T0nIM6htD/frG1bXzi5YkTmma b3wH0PX0U7DyyY3XhAu5289ffMbZiNH2GVuP47Yjqueq/rQGO9pbHKIQoV9pzSvb104epGuD9vyt 3nvzfoZGRpVx//J0Rq0HfAmkV7dHaw32VRW0aeQnbtL3fzBlfEZ0SPImSYAmV3GWbnEGV4VWU8yX V3FFb3tGgb2Xgfi2YGeVb60HUijHeaLXY76zeQZlZlH3cSelgcfmcQ5nXxIFUqZmUKu1b6Y3Zhx3 bChVgw3HZPalcH7zhCWnTKM1eJAVeaXlcTV2TD63QYrQdnOHBmD4OLUmd2Z4Bl2YB2kIX3CwhmkQ X1hHX+U1hkVXh3Z4h3iYh3rYN4pDh4m0YHwIiHa3PWI1hzODX6w0MgxHSaE1UVCoY6a1S/6Wa19o YmvQdsjkfG43Y4IYT+dFTHiHVhrobg04gjAVbf9kiWqAiegEd/+dODcZJnZ1pzilKFQJWG4gSFgG GIt2EFJLaFRgtmthpmSrRHipxEvlJ3lbtlAQpUKEh3D/xjMPBI2C11iZ91jDmFFlZUpNiHmOdXqR l1edVm2jSH2v2IYRBGnS+Gfupz/FV2j5t24PGFjTp4KsF28iyG5l1mfbFkaUhkcNSG1/dTTYd2L0 eIqcJYQYKHzaVgerNn9JtX6OKGfyt31OR2/fpmZVlYzWlka0M2/6qEABt0WFM1A9KFXxCECuxYAX R3ZJdIvZVnx+6DYpOHfhBm4YaG67aJHyCJPWFpI96YH+l36k6HewN3s5eXtEeXywJ5Ca9pLkxmEI CQgA94iTd3n/DNVQl8dCv6SNQJiV/VZwPriIvPRyvZRZoNVY/WaN36dyYolm3BhM3ciVYNmIl5Va ulRxWkWXSDGTPpBqzpBVQOeX5jRMgSmYe5iYirmYjNmYjvmYkBmZkjmZlFmZlnmZmJmZmrmZnNmZ nvmZoBmaojmapFmapnmaqJmaqrmarPlbVkkF0OOFOCZjOQMFPWdOc/g1bgiLhNZivNh0T8eVO4ab FYg17zSTtKh0tElgY7BppXaANfOJHuics/ibxBl2yIlh2jd2xlkGNWedgBOdrRiL1Il2wud0VTaN koVj0SNqIseMO0Z50DhmF0hkXHaD9pd69+mVqLeN8bmDYVlk/313lTtYg6EHeunJW6ann3ynWcPY nldjn6AFivM5Y3c2e9QnabfWkW6Wj3W2gRAWkR1aVPdoewaokn+Te+pYoruHe7Y2U0rpabhmix8q XvkTlZPlkZPmj/8YlOUJYi4Ug2NVfxOIjD5qcZeGixvpjzTqoxApOoZWpB+ZPOvHbCVZfkMliil5 kTOabM1meVHKfVuafQOpRa7WolaqAyB4lLKFfCCJfh3Yf14GVzuZpOSIkW1GZxvaPez4fwgmRkcl fai4PzHlpJaIo1JZkA4oqEkKpzjkYVEoaIp3SqyUX404hSjXUSK4b1qJcUT4d58qhbn1d8eYlRG3 ekCIVQGqlv+F92vROGp6JXG4ZXCReJedKkq35Kn4GXISB1vgGYbj+QOEKS8xZ3WJ0IVxyFPCmqwH s5s9M6ytGa3SOq3U+pnO+k3MWq29eI7c2pvaSgjn9GLfegidNZxQeJ9kNa6+6qIKiKIbpq6pmKb+ V6bdCq/bKq9JOY9lZK8Ww4hXqHob15XQyq8EW7AGe7AIm7AKu7AM27AO+7AQG7ESO7EUW7EWe7EY m7Eau7Ec27Eeq7BVmIxVSJYQR6rgCJeTequL6KpTOpt12XKX+rJBI58kJ2ydykiUCnEre7MKabKo RLM/m6t1mZYRt16rVLRLZ5KTerRWAKHi567+KWXnGXtMhXn/ZLqNUyuNpPVv7BmhzjanqFdjgWe1 SRi1nSeXkhd4Zce1Vkuf5jpZXuu2T9u2+fW2S0qMsLl38EmR3uiMMPpIpDe2KPlBfztv0RNCwFhn RkZCfhdZwGhl2cegwGS2UUuMNtaQiLtX7flQUuWNKGq50ehVVxlkXWV3G6S3cZs+GOe3pbuMHfdI FrS4hVuSrqe3LLdQH9q4mpupsFurcPl5ezu3RUi6WoO6dFtwxwifm5uDb1m7n0W1s/s4e3W82Bi7 IulRrpu6EDq8sCZmyAulGZW8r6ZmdbuP37u8r1q64xVrrpt6ztY40yu466u4BCe3tqO1gGt546uf WVC+6Vq9/14GbNhrlD62vY6rvRUJitwLeK+mtuHLv3v7t5CLv8vIjanbwFcXv+LHwN4LuTCavYBL WeyZtbxWBROsa8xTwHZ2wWJ2tqqKu6E7eRG6bPirwmQbuCBceuj7ZWzrwi2Mwv87nLNJt7RHtuFr vzFcuCunw1OLt1MwfpKKvCvLl887XyVrxSmrZeIrg+NoxUVrtFqpiMd0Q/pbsj2Wsr8UVS73vFoc l4f3vUH7cBzpSl9pqg93lv5qwM76sXzcx378x4D8XWCMlcPEs7xmtEw7xycbdRgqtVy4s6eavnnM cpiav/L5xYPsxnlMtGkMgzErxzsrqT0bx2z8yW8Jx6VciP9emLmXhcA33LUR7L5hy8NxW8FZSlUb TMNma2+et8C1J7iSS142/MppS72Xa8Tum7tgy1lJXLlEPMAxnK2FCYCihr3EDGpD3LraHLr89327 K8A9TM0ufHFALLo/TFTqO7N965XKHMv3M85JHM8WrLs9nM6VF8EFPLAXaH78rL7sa5Tjt89t68AB LbK7m73CVGxV/Lv82Wl1y3i3PMSvO8eOp5FICGyMmLwgjNCkR8/2W8NCbLklHAVl3L017MPWG8CO +83s+8Aaab7D27LgeNEAXc4cScGsPLr7DNPczLgua7ul1846vcAu7c4h3dP4nHh5y8zgnNE+fLju 1Vos/cz/uoyeKy3Ryey5SZvCFw3O3ivSXKvHAx3ClkrTVc3RW13V6AnNSGzBQQ3WR10zZiXC10y5 CkzVV/3Klnq/s5zW9lbXZNrMTazO3KvUhQ2310zLhZ3PQXbOLHzEwivBKWzLsUxLco2XXUzHJBvK bozKBu3QiBrFnz3VMdvJqvt4lazKT8vZKDu0H6eDkCzJncXag7fFtg3FqOXJnr3ItZot0jxN+gzI wR2sgVzcxn3cyJ3cyr3czN3czv3c0B3d0j3d1F3d1n3d2J3d2r3d3N3d3v3d4B3e4o0FHVDe5m3e AEAAI3De7N0BJAAB7R0BJaAABRAA5Q0ACzABJTAB9V3e/wEwAPK93uat3yJw3u8d3yTQ3uYNAQ5Q 4OZtAgr+4C0Q4ekt4Ape4Rbu3iMQAQNg3gOgAQ3+ARFe3iNA3/bdAfhN4DXA4R4O4g5O4hAu4SLA 4uX94SFu4CMA3+VdABMu4yIu4SOu4SOO4T8e4W8R5B2g3kWu4CNwAArO4yPAABE+ACOwABSe4QFw 4zLu5O0N5S9+4V8e40be4xGu5Eiu5Es+AgAw5kEuAlKu4FROA2vO5Gku5hr+AXPe3mEuAgRg3gHg Aji+522+5Apu5iN+5EH+54TO3iMwAejt5ySQ5+wd544+4oaO3nv+AZWO4pCe4XQe6J7O6GSu4BDw 5Qqu6P91HgGHvug4LunnHecyoOps7uMZPuOrjuMOcN4BzgKgjuODjuSKPuhIgeRCvuofUADmHQE6 3gEKkOEEfgARsAAi0OFDbuodIO2Bjuzlrezm3ezWLuqg/u20ngJILu6BjuPU/um3PuAiAO3SPgPp rud1XgLovu4wnuewzus+7uv23u/yPuwyrgCdHu4kcOIdcAAaYN5oft7eXgIG/+5WDuTt/eYw/gEG j/AKX+sfwOUdAOUET/CALuECL/EVP/IdgOr8ft8HsPETEOcgv+QNbwPnDQArfwAtn+kJTvIoXvM3 v+QEoO0nv/Ih/+vjnukmH+xFnxRnbu4anuvlXeoUDwD/at7eAfDuSy70dX7eOm7wTb/gHxD1oe7f Vv/xxr4COH70TJ/kGs/wJzDorn7yVm/nd57z5R3zGk/vOm/35o7moz7rfl/mTI/oF77wq97n5f3u gU7x7O3x+67zii/hhn/tmT7iA6DlFR/2SS/3i2/uRJ71ST/oj2/eXo73Rf/yIJ/yc0/37c33+k70 f8/eRC7sJjHiIR74HxDvE08CE0AABBDxMH7xIuD0HVDqaY77Gm78580Ae87xLj/usq8CQa78rF7e tb/nwN/oti8Cu9/7pg/y16/9OK/x36/pXz4AeR4AWN/6/g7uEV79z98PBg70Un/3pB/hcV/iOA70 UJ7n/4gPAp34HaLZfd+5ikt6pqr5siMc47kuswATwwomQO4mFAEcJAKK19zhFDco9XPsJJfN2siZ umYPTFoXYBpUizPgeqoegXHuNL1uv+Pzet0tYCKwcX0wcJlApAxwEX1MFHYokDUxwRA6HjrVRK5g btbNya35iQAGNlVmct4k1izqnbJo3ty8dt44nETYuckWRqaIdpCmru0VGx8je65FnCgNj2g4ihx8 rLL8pCxwufimQMBES1M7LvY66hLzLTeXxmijnldzYe+9wz53f9jXEk92BKDr0i3eDWYmnMVLpnAh QzxTrJXr9U0EpBhXclkzUYBeigkFRAXYCErgqw8TH5/huPgMAkJBCdN8aodoiMwUCgpMDFkxXkYR Io/dzFlgpyAvMYKK0JnPpEZlAo0SJAYxVsyGVq9izap1K9euXr+CDSt2LNmyZs+iTat2Ldu2bt/C jSt3Lt26du/izat3L9++fv8CDix4MOHChg8jTqx4MePGjh9Djix5MuXKli9jzqx5M+fOnj+DDi16 NOnSpk+jTq16NevWrl/Dji37awgAOw== ------437187240054721683-- From mariabanda2010@techemail.com Sun Feb 13 11:41:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06341; Sun, 13 Feb 2005 11:41:05 -0500 (EST) From: mariabanda2010@techemail.com Message-Id: <200502131641.LAA06341@ietf.org> Received: from rndf-146-25-88.telkomadsl.co.za ([165.146.25.88] helo=mydomain.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0N8c-0003FK-Fi; Sun, 13 Feb 2005 12:02:28 -0500 Received: from smtp1.google.com ([16.211.91.211]) by smtp2.excite.com with Internet Mail Service id 07A35346; Sun, 13 Feb 2005 16:41:26 -0000 Received: from xmxpita.linksynergy.com ([144.58.216.199]) by broome1.genuity.com with Microsoft SMTPSVC id 1638A57B; Sun, 13 Feb 2005 16:41:16 -0000 Received: from esmtp.inreach.com ([252.70.3.219]) by singularity.banelco.com.ar with SMTP id 13D67336; Sun, 13 Feb 2005 16:41:06 -0000 Date: Sun, 13 Feb 2005 08:41:06 -0800 To: mariabanda2010@techemail.com Subject: FROM: MRS. MARIA BANDA MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Spam-Score: 5.8 (+++++) X-Spam-Flag: YES X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT FROM: MRS. MARIA BANDA TEL: 27-73-589-5594 ATTN: Sir/Madam WE NEED YOUR URGENT HELP I cannot imagine the surprise this will bring to you, but please be rest assured is with good faith and intentions from a family in dare need of your assistance to help us transfer the inheritance sum of US$23.1 million into your account or company account, in which God will bless you for rendering a helping hand to others. I am Mrs. Maria Banda, from Sierra Leone (currently residing in South Africa), the wife to the late Brigadier John Banda. I got your contact details in the course of my discreet search for a reliable and God fearing person from the Johannesburg Trade and Exhibition Center and after going through your profile, I decided to solicit for your kind assistance. I am currently residing with my son here in South Africa as asylum seekers and the South African Fiscal Policy Law and Regulations does not allow us certain financial rights. My husband was a brigadier in charge of Arms and Ammunition procurement for the Sierra Leon Army before his death. After his death I discovered that in his will, he specifically drew my attention to the sum of US$23.1 million, which he had deposited, in a safe box of the Private Security Company here in Johannesburg, South Africa. The lives and future of my family depends on this fund as such I will be grateful if you can assist us. In view of this, I cannot invest this fund in South Africa hence my asking you to assist me to transfer it out of South Africa for investment purposes in your country. For your efforts, I am prepared to offer you 25% of the total sum while 3% will be set aside for expenses incurred during the course of this transaction and the remaining 72% is for the family investment in your country. Please note that this transaction is risk-free and the major thing I ask of you is to assure me the safety of the money when transferred to your account in your country. Further information and arrangement will commence as soon as trust confidence and good relationship is established. I shall be most grateful if you maintain the confidentiality required in this transaction. Do not hesitate to call us on my phone +27-73-589-5594 I wait for your prompt response Thanks and God bless, Mrs. Maria Banda From Marlene_Amy@iglide.net Sun Feb 13 15:37:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23756; Sun, 13 Feb 2005 15:37:05 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0Qp3-0007bk-UX; Sun, 13 Feb 2005 15:58:30 -0500 Received: from [194.204.117.54] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D0QUF-0005Pw-9n; Sun, 13 Feb 2005 15:37:00 -0500 Received: from mail.oui.com (194.204.117.54) by 194.204.117.54 (vermiculitev.154) with SMTP id <60368181h76e> (Authid: 457); Sun, 13 Feb 2005 23:32:43 +0300 Reply-To: "Norga Trina" From: "Norga Trina" To: rsvp-archive@ietf.org Cc: rv@ietf.org, saad@ietf.org, saad-admin@ietf.org, saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org, seamoby@ietf.org, seamoby-admin@ietf.org, seamoby-archive@ietf.org, seamoby-request@ietf.org, seamoby-web-archive@ietf.org Subject: This email will change your life Date: Mon, 14 Feb 2005 02:29:43 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--78475_0295308.TA97" Message-Id: X-Spam-Score: 3.3 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----78475_0295308.TA97 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. This means that you're eligible for $ 500,000 with a 3.2% rate. Take a few minutes to see what you can save! Please verify your information here: http://aruba.gsvdvs.info:443/azdrg We look forward to hearing from you. Norga Trina, Account Manager TJK Associates r.mv - http://gsvdvs.info:443/index.php ----78475_0295308.TA97-- From hinazoiy@glay.org Sun Feb 13 15:37:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23882; Sun, 13 Feb 2005 15:37:27 -0500 (EST) Received: from c-24-21-205-233.client.comcast.net ([24.21.205.233]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D0QpO-0007cB-Ur; Sun, 13 Feb 2005 15:58:52 -0500 X-Message-Info: 803SO2NIsg54QC351krsSwgyY768tdjD278sLYNcwAF472MAK6 Received: (from chestnut@24.21.205.233) by aerospace9.22.220.102.192 (9.73.7/1.44.8) id i063CLZvF8143; Sun, 13 Feb 2005 14:32:35 -0600 Message-ID: <4765758140.78445@hinazoiy@glay.org> Reply-To: "Brenda Morris" From: "Brenda Morris" To: "Seamoby" Subject: capitalize on an undervalued gem Date: Sun, 13 Feb 2005 16:31:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--169201748978780006" X-Spam-Score: 18.6 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----169201748978780006 Content-Type: text/plain; charset="iso-0291-0" Content-Transfer-Encoding: quoted-printable ***GEEC*****GEEC*****GEEC*****GEEC*****GEEC*** Global Environmental Energy Corp. (OTC-BB: GEEC) Shares Outstanding : 35 million Approx. Float : 9 million 30 Day Target : $6.25 6 Month Price Projection : $15.00 Recent News and Major Share-Price Driving Milestones: GEEC just announced a $10 Billion, 5-year joint venture with several companies operated by the Chinese Government. GEEC uses their Biosphere Process System to convert various types of waste into clean, "green" electricity at 5 to 10 mega-watts per hour. GEEC Chairman, former Prime Minister of Ireland Dr. Albert Reynolds, has secured a $2 Billion line of credit for GEEC and opened doors in over a dozen countries through political contacts at the highest level. Global Environmental Energy is CBS Marketwatch.com's #1 Best Performer in the DJ Diversified Industrials Index in the last 2 months. This Dow Jones Index also contains 3M, GE, and Honeywell. Conservative estimates value the company at One Billion Dollars Future Milestones: 1. GEEC had a $100 Million backlog of sales orders for the Biosphere before the China joint-venture with 26 completed Biospheres in operation. The backlog is now into the Billions with complete financing to be provided by China and 1,300 Biospheres to be deployed throughout the country. 2. GEEC's present assets of $35 Million will conservatively jump into the $300 Million range, a 10-times increase. 3. GEEC is in advanced stages of agreement on at least 6 major international projects which could add $50 Million to the bottom-line or $1.42 per share. 4. P/E on average for this Industry Group is 20 to 1 putting GEEC in the $13 dollar range without any future business expansion. 5. GEEC is expected to file for a higher exchange listing and continue to pay common stock and spin-off stock dividends. Worldwide Market Potential $15 to $25 Billion over next 5 years with no other known company that can match their technology, leadership, or explosive sales growth. Up until now GEEC has been one of Wall Street's best kept secrets, yet now it seems the cat is coming out of the bag and the release of this new Investor Awareness Campaign should be excellent timing in regards to some new PR's forthcoming which will Rocket GEEC. This power-play has nowhere to go but up, according to most insiders, and there's still a bit of time to get in before the boom. DISCLOSURE: The information and opinions in this feature profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past-results is not an indicator of future-results. This report is a paid profile and is for information purposes only and should not be used as the basis for any investment decision. Ten thousand dollars has been paid for the preparation of this profile and for continuing coverage of the featured company. We are not an investment advisor and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains forward-look-ing statements and is subject to significant risks and uncertainties. There are no shares held and there will be no participation in the trading of shares of any profiled company. ----169201748978780006-- From ANMMYZAVZZIPcurrent@tutopia.com.br Sun Feb 13 22:05:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19817 for ; Sun, 13 Feb 2005 22:05:39 -0500 (EST) Received: from s0106000ae69fc151.ed.shawcable.net ([68.150.152.159]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D0Wt8-0005zX-On for sctp-impl-archive@ietf.org; Sun, 13 Feb 2005 22:27:08 -0500 X-Message-Info: 66APC0WpcD00X56pgJYYuZPS9C6fhE7vqNUEfhTRFDWHA99 Received: (from crusty@localhost) by arumcommerceB.ANMMYZAVZZIPcurrent@tutopia.com.br (A.F2.1/0.D7.D) id lC7ERoP3C04; Mon, 14 Feb 2005 05:59:37 +0300 Message-ID: <746861DAA2.E8A53@ANMMYZAVZZIPcurrent@tutopia.com.br> Reply-To: "Denise d'oeuvre" From: "Denise d'oeuvre" To: "Sctp-impl-archive" Subject: commercial relocation specialists Date: Mon, 14 Feb 2005 07:05:37 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--147E71890FF734F1A12" X-Spam-Score: 11.9 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ----147E71890FF734F1A12 Content-Type: text/html; charset="iso-E74C-F" Content-Transfer-Encoding: quoted-printable

If you're movjng your office...

Get the best prices and expertise. Come and see us.,

 

 

 

 

 

take of= f your email addy

 

 

"7) In plain English this means that AIBO is an electronic pet robot that= can sense the situation and surroundings of its environment and react acc= ordingly. Reactions are limited to AIBO's ""six emotions: happiness" it would not be empty ----147E71890FF734F1A12-- From rnwaj@flash.net Sun Feb 13 23:29:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25157; Sun, 13 Feb 2005 23:29:43 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0YCW-0007Pc-Ns; Sun, 13 Feb 2005 23:51:14 -0500 Received: from [218.234.143.80] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D0Xrg-0006WV-FB; Sun, 13 Feb 2005 23:29:41 -0500 X-Message-Info: 76apfUYurRQW207PGohoXJI24XIM93IRTqvSwEOLnloOua1FM Received: from sina.com (196.223.60.139) by ujf5-j061.sina.com with Microsoft SMTPSVC(0.9.8393.1824); Mon, 14 Feb 2005 03:29:30 -0100 Received: from sina.com (sina.com 193.167.213.48) by sina.com (8.12.10/8.12.9) with ESMTP id ska977C277 for ; Mon, 14 Feb 2005 06:21:30 +0200 (EST) (envelope-from rnwaj@flash.net) Received: from GSC01562 (modemcable43.50062-5.q.sina.com 133.204.8.236) (authenticated bits=2) by sina.com (8.12.10/8.12.9) with ESMTP id g891C1voi106 for ; Mon, 14 Feb 2005 08:20:30 +0400 (EST) (envelope-from rnwaj@flash.net) Message-ID: <9115uok125f65$kj5l6q5$772qu604jc681@FHY5273242690696> From: "Stan Dennis" To: Subject: Your P-C is under siege - stop it now eccles Date: Mon, 14 Feb 2005 10:27:30 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--602715815710034826" X-Spam-Score: 9.5 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ----602715815710034826 Content-Type: text/html; Content-Transfer-Encoding: 7Bit Yes, this is sooo true. Your pc in currently under siege - tons of
spy=wares are running on your box, well known worms and trojans and
much more.
I need to know more
Got some important stuff on your box? Family pics? Secret stuff? Sexy pics
of your g'f? You don't want this to leak, or DO YOU?
I, personally, don't want it. For sure.
I need to know more

ta-ke me uff weep buffet cubic suffuse wyman brent peterson. guesswork precursor hearse altar bryant earsplitting pretty. plausible tough cubic fiftieth cryptanalyst storey. emigrate cubic congratulatory beman hydrochemistry murder.
alabaster anorthic cubic dandy harvard suggestion acton. cloven sully gusset noose convalesce. wrist stewardess astigmatic sully regional property thespian. hedonism precursor blithe relinquish counselor.
commonplace cubic glenda acrid. cram main bateau bellyfull sully dosimeter contact shell wiry bard. octahedral incongruity cubic gangling autoclave. descant precursor personal beet frigate.
buttress canberra artery atom caribbean librarian citywide. oxidate dutchess ferdinand leaven diatomaceous narcissist dismal. bronchiole moravia cubic gridiron resistant. decrypt apport precursor bricklaying borderline cockroach hayden. ----602715815710034826-- From ColbytalghpGualtiero@atcon.com Mon Feb 14 02:47:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00575; Mon, 14 Feb 2005 02:47:55 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0bII-0002t0-F9; Mon, 14 Feb 2005 03:09:26 -0500 Received: from [213.74.56.50] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D0axQ-0002UO-Ri; Mon, 14 Feb 2005 02:47:50 -0500 Received: from mail.augmed.com (213.74.56.50) by ng33-m.augmed.com with Microsoft SMTPSVC(5.752.57095.2504);Mon, 14 Feb 2005 09:46:32 +0200 Message-ID: <84070.ZSM@augmed.com> Reply-To: "Hampton Zapata" From: "Hampton Zapata" To: rserpool-admin@ietf.org Cc: rserpool-request@ietf.org, rsvp-archive@ietf.org, rv@ietf.org, saad@ietf.org, saad-admin@ietf.org, saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org, seamoby@ietf.org Subject: One minute that could change your life Date: Mon, 14 Feb 2005 13:43:32 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--55952_65161561.vZd036" X-Spam-Score: 20.5 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----55952_65161561.vZd036 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. This means that you're eligible for $ 475,000 with a 3.2% rate. Take a few minutes to see what you can save! Please verify your information here: http://torso.homeloanon.com/?partid=rmiea We look forward to hearing from you. Hampton Zapata, Account Manager TJK Associates r.mv - http://homeloanon.com/st.html ----55952_65161561.vZd036-- From hbeebkbhfgZYCNxix@hobbithall.com Mon Feb 14 05:57:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15800 for ; Mon, 14 Feb 2005 05:57:56 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0eGE-0006kN-4g for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 06:19:30 -0500 Received: from m20.net81-65-224.noos.fr ([81.65.224.20]) by mx2.foretec.com with smtp (Exim 4.24) id 1D0dvK-0006lA-8N for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 05:57:51 -0500 Received: from hostbozc.mid-statetermite.com (81.65.224.20) by hopkins-385VDSRQ.mid-statetermite.com with Microsoft SMTPSVC(09.764.43.6958);Mon, 14 Feb 2005 15:59:08 +0500 Message-ID: Reply-To: "herbert catarina" From: "herbert catarina" To: rafts@ietf.org Cc: haa11894@ietf.org, srg@ietf.org, anet@ietf.org, bmanet@ietf.org, g-admin@ietf.org, sctp-impl-archive@ietf.org Subject: You've been selected for the Low Rates Program Date: Mon, 14 Feb 2005 03:55:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2865346_16390358.ukK687" X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----2865346_16390358.ukK687 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #1147832, Your application was approved. You are eligible for $400,000 with a 3.7 % rate. Please confirm your information here: http://main.lpjsjfv.info:443/ajrmlhpone We look forward to hearing from you. Regards, herbert catarina, Senior Account Manager FTK Financial Group r*mv. -> http://noon.lpjsjfv.info:443/index.php ----2865346_16390358.ukK687-- From anatoly.khusid@ulticom.com Mon Feb 14 07:54:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28086 for ; Mon, 14 Feb 2005 07:54:01 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0g4c-00013p-TS for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 08:15:35 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2005 04:54:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,198,1102320000"; d="scan'208"; a="161351970:sNHT24642792" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1ECqiwN010259; Mon, 14 Feb 2005 04:52:45 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1ECq17U026218 for sctp-impl-filtered; Mon, 14 Feb 2005 04:52:03 -0800 (PST) Message-Id: <200502141252.j1ECq17U026218@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108385521-26216-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: RE: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: "'Brian F. G. Bidulock'" From: "Anatoly Khusid" Cc: X-Nails-Approved: anatoly.khusid@ulticom.com Date: Mon, 14 Feb 2005 07:29:00 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b This is a multi-part message in MIME format... ------------=_1108385521-26216-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: binary Brian, First you say that: >SO_REUSEADDR is described by POSIX and is protocol independent. But then you quote POSIX, which says: "if this is supported by the protocol." So how can it be protocol independent? I agree with Randall that SO_REUSEADDR does not make sense for SCTP. Anatoly Sent: Friday, February 11, 2005 6:48 PM To: Anatoly Khusid Cc: sctp-impl@external.cisco.com Subject: Re: SO_REUSEADDR setsockopt() and SCTP Anatoly, POSIX: SO_REUSEADDR Specifies that the rules used in validating addresses supplied to bind() should allow reuse of local addresses, if this is supported by the protocol. This option takes an int value. This is a boolean option. SO_REUSEADDR is necessary to bind to a protocol address that is already listening or connected (or in the case of TCP in timed wait as well). The former two are perfectly applicable to SCTP. --brian On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > >SO_REUSEADDR is described by POSIX and is protocol independent. > > It works different on Linux SLES9 vs. Solaris when using SCTP sockets. > I provided an example which illustrates the differences. > This web site only explains how SO_REUSEADDR work with TCP. > Is TCP TIME_WAIT equivalent to SCTP_SHUTDOWN_PENDING ? > > > >You can use setsockopt() to set the SO_REUSEADDR socket option, which > explicitly > >allows a process to bind to a port which remains in TIME_WAIT (it still > only > >allows a single process to be bound to that port). This is the both the > simplest > >and the most effective option for reducing the "address already in use" > error. > > http://hea-www.harvard.edu/~fine/Tech/addrinuse.html > > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Friday, February 11, 2005 5:04 PM > To: Anatoly Khusid > Cc: sctp-impl@external.cisco.com > Subject: Re: SO_REUSEADDR setsockopt() and SCTP > > > Anatoly, > > SO_REUSEADDR is described by POSIX and is protocol independent. > > --brian > > On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > > This question deals more with "SCTP Sockets API" draft. I have not seen > any > > explanation in this document regarding the usage of SO_REUSEADDR on SCTP > > sockets. > > The following code fails on Solaris 10: > > > > > > ADDR = Some valid address to bind > > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > > bind(fd1, ADDR) > > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > > bind(fd2, ADDR) <=== Fails with errno="Address in use" > > > > > > However, the above code works fine on Linux SLES9. Does it mean that > Linux > > has a bug, or this is something implementation dependent? > > What is the right behavior for SO_REUSEADDR on SCTP sockets? > > Do you think this should be explained/documented in "SCTP Sockets API"? > > > > Thanks, > > > > Anatoly Khusid > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108385521-26216-0-- From jbmnsu@bot.or.th Mon Feb 14 08:59:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04401 for ; Mon, 14 Feb 2005 08:59:24 -0500 (EST) Message-Id: <200502141359.IAA04401@ietf.org> Received: from [210.212.14.194] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D0h5s-0002gi-8y for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 09:20:58 -0500 X-Message-Info: 082EM719HaEOVBA29qpGBXzcwT1BDreDXV138cKRRpCF43XZ5 Received: from mail pickup service by 210.212.14.194 with Microsoft SMTPSVC; Tue, 15 Feb 2005 00:58:24 +0300 Content-Class: urn:content-classes:message Reply-To: "Stacy expectorant" From: "Stacy expectorant" To: "Sctp-impl-archive" Subject: get your universty d:ploma online Date: Mon, 14 Feb 2005 16:00:24 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--126A3942E07356C26B0" X-Spam-Score: 28.0 (++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de ----126A3942E07356C26B0 Content-Type: text/html; charset="iso-2DC6-E" Content-Transfer-Encoding: quoted-printable g[1-5 ----126A3942E07356C26B0-- From bidulock@openss7.org Mon Feb 14 09:01:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04638 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 09:01:48 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0h8F-0002lP-4A for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 09:23:23 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2005 06:10:58 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1EE0dq8005977; Mon, 14 Feb 2005 06:00:40 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1EE017U027291 for sctp-impl-filtered; Mon, 14 Feb 2005 06:00:03 -0800 (PST) Message-Id: <200502141400.j1EE017U027291@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108389601-27283-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: Anatoly Khusid <anatoly.khusid@ulticom.com> From: "Brian F. G. Bidulock" <bidulock@openss7.org> Cc: sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Mon, 14 Feb 2005 06:54:14 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 This is a multi-part message in MIME format... ------------=_1108389601-27283-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly, The socket option is protocol independent, but reuse of local addresses is not supported by all protocols. (e.g. under SCCP or X.25, a local address describes a complete connection unlike TCP or SCTP where it merely names a socket.) On Linux: ADDR = Some valid address to bind fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); bind(fd1, ADDR) fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); bind(fd2, ADDR) <=== Fails EADDRINUSE ADDR = Some valid address to bind fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) bind(fd1, ADDR) fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) bind(fd2, ADDR) <=== Succeeds For OpenSS7 SCTP (and LKSCTP I suppose): ADDR = Some valid address to bind fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); bind(fd1, ADDR) fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); bind(fd2, ADDR) <=== Fails EADDRINUSE ADDR = Some valid address to bind fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) bind(fd1, ADDR) fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) bind(fd2, ADDR) <=== Succeeds Which makes perfect sense and is consistent with POSIX. You will find the following true for Linux as well: ADDR = Some valid address to bind fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR); bind(fd1, ADDR); listen(fd1); fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR); bind(fd2, ADDR); <=== Fails EADDRINUSE Which makes less sense... I think this should actually succeed. Not having such a mechanism will make peer-to-peer protocols like M2PA quite difficult to implement in user space, and will go quite against the POSIX sockets model. --brian On Mon, 14 Feb 2005, Anatoly Khusid wrote: > Brian, > > First you say that: > >SO_REUSEADDR is described by POSIX and is protocol independent. > > But then you quote POSIX, which says: > > "if this is supported by the protocol." > > So how can it be protocol independent? I agree with Randall that > SO_REUSEADDR does not make sense for SCTP. > > Anatoly > > Sent: Friday, February 11, 2005 6:48 PM > To: Anatoly Khusid > Cc: sctp-impl@external.cisco.com > Subject: Re: SO_REUSEADDR setsockopt() and SCTP > > > Anatoly, > > POSIX: > > SO_REUSEADDR > Specifies that the rules used in validating addresses supplied to > bind() > should allow reuse of local addresses, if this is supported by the > protocol. > This option takes an int value. This is a boolean option. > > SO_REUSEADDR is necessary to bind to a protocol address that is already > listening or connected (or in the case of TCP in timed wait as well). > > The former two are perfectly applicable to SCTP. > > --brian > > On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > > > > >SO_REUSEADDR is described by POSIX and is protocol independent. > > > > It works different on Linux SLES9 vs. Solaris when using SCTP sockets. > > I provided an example which illustrates the differences. > > This web site only explains how SO_REUSEADDR work with TCP. > > Is TCP TIME_WAIT equivalent to SCTP_SHUTDOWN_PENDING ? > > > > > > >You can use setsockopt() to set the SO_REUSEADDR socket option, which > > explicitly > > >allows a process to bind to a port which remains in TIME_WAIT (it still > > only > > >allows a single process to be bound to that port). This is the both the > > simplest > > >and the most effective option for reducing the "address already in use" > > error. > > > > http://hea-www.harvard.edu/~fine/Tech/addrinuse.html > > > > -----Original Message----- > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > Sent: Friday, February 11, 2005 5:04 PM > > To: Anatoly Khusid > > Cc: sctp-impl@external.cisco.com > > Subject: Re: SO_REUSEADDR setsockopt() and SCTP > > > > > > Anatoly, > > > > SO_REUSEADDR is described by POSIX and is protocol independent. > > > > --brian > > > > On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > > > > This question deals more with "SCTP Sockets API" draft. I have not seen > > any > > > explanation in this document regarding the usage of SO_REUSEADDR on SCTP > > > sockets. > > > The following code fails on Solaris 10: > > > > > > > > > ADDR = Some valid address to bind > > > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > > > bind(fd1, ADDR) > > > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > > > bind(fd2, ADDR) <=== Fails with errno="Address in use" > > > > > > > > > However, the above code works fine on Linux SLES9. Does it mean that > > Linux > > > has a bug, or this is something implementation dependent? > > > What is the right behavior for SO_REUSEADDR on SCTP sockets? > > > Do you think this should be explained/documented in "SCTP Sockets API"? > > > > > > Thanks, > > > > > > Anatoly Khusid > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > ¦ Therefore all progress depends on the ¦ > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108389601-27283-0-- From bidulock@openss7.org Mon Feb 14 09:14:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06173 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 09:14:26 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0hKS-0003At-EJ for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 09:36:01 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2005 06:14:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1EEDLYO004549; Mon, 14 Feb 2005 06:13:24 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1EEDB7U027487 for sctp-impl-filtered; Mon, 14 Feb 2005 06:13:13 -0800 (PST) Message-Id: <200502141413.j1EEDB7U027487@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108390391-27484-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: Anatoly Khusid <anatoly.khusid@ulticom.com> From: "Brian F. G. Bidulock" <bidulock@openss7.org> Cc: sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Mon, 14 Feb 2005 07:07:30 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 This is a multi-part message in MIME format... ------------=_1108390391-27484-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly, See also UNIX'98 XTI/TLI IP option T_IP_REUSEADDR (where it came from). T_IP_REUSEADDR Many TCP implementations do not allow the user to bind more than one transport endpoint to addresses with identical port numbers. If T_IP_REUSEADDR is set to T_YES this restriction is relaxed in the sense that it is now allowed to bind a transport endpoint to an address with a port number and an underspecified internet address ("wild card" address) and further endpoints to addresses with the same port number and (mutually exclusive) fully specified internet addresses. That is more like: int val=1; ADDR1 = IN_ADDRANY, port 32 ADDR2 = 192.168.0.1, port 32 fd1=socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(val)); bind(fd1, &ADDR1, sizeof(ADDR1)) fd2=socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(val)); bind(fd2, &ADDR2, sizeof(ADDR2)) <=== Succeeds fd1=socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); bind(fd1, &ADDR1, sizeof(ADDR1)) fd2=socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); bind(fd2, &ADDR2, sizeof(ADDR2)) <=== Fails EADDRINUSE Technically, following this older rule, the Solaris behavior may be correct. Check the above with a wildcard and specific address on the same port number on Solaris and see if it exhibits the above behavior. It should, Solaris being originally SVR4.2 based can be expected to follow the UNIX'98 behavior. --brian On Mon, 14 Feb 2005, Brian F. G. Bidulock wrote: > Anatoly, > > The socket option is protocol independent, but reuse of local > addresses is not supported by all protocols. (e.g. under SCCP > or X.25, a local address describes a complete connection unlike > TCP or SCTP where it merely names a socket.) > > On Linux: > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); > bind(fd1, ADDR) > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); > bind(fd2, ADDR) <=== Fails EADDRINUSE > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > bind(fd1, ADDR) > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > bind(fd2, ADDR) <=== Succeeds > > For OpenSS7 SCTP (and LKSCTP I suppose): > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > bind(fd1, ADDR) > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > bind(fd2, ADDR) <=== Fails EADDRINUSE > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > bind(fd1, ADDR) > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > bind(fd2, ADDR) <=== Succeeds > > Which makes perfect sense and is consistent with POSIX. > > You will find the following true for Linux as well: > > ADDR = Some valid address to bind > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR); > bind(fd1, ADDR); > listen(fd1); > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR); > bind(fd2, ADDR); <=== Fails EADDRINUSE > > Which makes less sense... I think this should actually succeed. > > Not having such a mechanism will make peer-to-peer protocols > like M2PA quite difficult to implement in user space, and will > go quite against the POSIX sockets model. > > --brian > > On Mon, 14 Feb 2005, Anatoly Khusid wrote: > > > Brian, > > > > First you say that: > > >SO_REUSEADDR is described by POSIX and is protocol independent. > > > > But then you quote POSIX, which says: > > > > "if this is supported by the protocol." > > > > So how can it be protocol independent? I agree with Randall that > > SO_REUSEADDR does not make sense for SCTP. > > > > Anatoly > > > > Sent: Friday, February 11, 2005 6:48 PM > > To: Anatoly Khusid > > Cc: sctp-impl@external.cisco.com > > Subject: Re: SO_REUSEADDR setsockopt() and SCTP > > > > > > Anatoly, > > > > POSIX: > > > > SO_REUSEADDR > > Specifies that the rules used in validating addresses supplied to > > bind() > > should allow reuse of local addresses, if this is supported by the > > protocol. > > This option takes an int value. This is a boolean option. > > > > SO_REUSEADDR is necessary to bind to a protocol address that is already > > listening or connected (or in the case of TCP in timed wait as well). > > > > The former two are perfectly applicable to SCTP. > > > > --brian > > > > On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > > > > > > > >SO_REUSEADDR is described by POSIX and is protocol independent. > > > > > > It works different on Linux SLES9 vs. Solaris when using SCTP sockets. > > > I provided an example which illustrates the differences. > > > This web site only explains how SO_REUSEADDR work with TCP. > > > Is TCP TIME_WAIT equivalent to SCTP_SHUTDOWN_PENDING ? > > > > > > > > > >You can use setsockopt() to set the SO_REUSEADDR socket option, which > > > explicitly > > > >allows a process to bind to a port which remains in TIME_WAIT (it still > > > only > > > >allows a single process to be bound to that port). This is the both the > > > simplest > > > >and the most effective option for reducing the "address already in use" > > > error. > > > > > > http://hea-www.harvard.edu/~fine/Tech/addrinuse.html > > > > > > -----Original Message----- > > > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > > > Sent: Friday, February 11, 2005 5:04 PM > > > To: Anatoly Khusid > > > Cc: sctp-impl@external.cisco.com > > > Subject: Re: SO_REUSEADDR setsockopt() and SCTP > > > > > > > > > Anatoly, > > > > > > SO_REUSEADDR is described by POSIX and is protocol independent. > > > > > > --brian > > > > > > On Fri, 11 Feb 2005, Anatoly Khusid wrote: > > > > > > > This question deals more with "SCTP Sockets API" draft. I have not seen > > > any > > > > explanation in this document regarding the usage of SO_REUSEADDR on SCTP > > > > sockets. > > > > The following code fails on Solaris 10: > > > > > > > > > > > > ADDR = Some valid address to bind > > > > fd1 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > > > setsockopt(fd1, SOL_SOCKET, SO_REUSEADDR) > > > > bind(fd1, ADDR) > > > > fd2 = socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP); > > > > setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR) > > > > bind(fd2, ADDR) <=== Fails with errno="Address in use" > > > > > > > > > > > > However, the above code works fine on Linux SLES9. Does it mean that > > > Linux > > > > has a bug, or this is something implementation dependent? > > > > What is the right behavior for SO_REUSEADDR on SCTP sockets? > > > > Do you think this should be explained/documented in "SCTP Sockets API"? > > > > > > > > Thanks, > > > > > > > > Anatoly Khusid > > > > > > -- > > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > > ¦ Therefore all progress depends on the ¦ > > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > > > -- > > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > > ¦ Therefore all progress depends on the ¦ > > ¦ unreasonable man. -- George Bernard Shaw ¦ > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108390391-27484-0-- From bidulock@openss7.org Mon Feb 14 09:37:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08511 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 09:37:41 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0hgx-0003nE-P5 for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 09:59:17 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2005 06:46:51 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1EEaouC012035; Mon, 14 Feb 2005 06:36:50 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1EEae7U027852 for sctp-impl-filtered; Mon, 14 Feb 2005 06:36:42 -0800 (PST) Message-Id: <200502141436.j1EEae7U027852@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108391800-27850-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SO_REUSEADDR setsockopt() and SCTP List-Id: sctp-impl To: Anatoly Khusid <anatoly.khusid@ulticom.com> From: "Brian F. G. Bidulock" <bidulock@openss7.org> Cc: sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Mon, 14 Feb 2005 07:30:54 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab This is a multi-part message in MIME format... ------------=_1108391800-27850-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Anatoly, See also, all the references in the index under SO_REUSEADDR and SO_REUSEPORT in Stevens' TCP/IP Illustrated Volume 1. --brian -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108391800-27850-0-- From lehmann@ulticom.com Mon Feb 14 11:30:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19206 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 11:30:26 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jS7-0006F4-2C for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 11:52:03 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2005 08:30:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,199,1102320000"; d="scan'208"; a="161376178:sNHT19918584" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1EGSnwN005532; Mon, 14 Feb 2005 08:28:50 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1EGSI7U029535 for sctp-impl-filtered; Mon, 14 Feb 2005 08:28:20 -0800 (PST) Message-Id: <200502141628.j1EGSI7U029535@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108398497-29532-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: sctp-impl@external.cisco.com From: David Lehmann <lehmann@ulticom.com> X-Nails-Approved: lehmann@ulticom.com Date: Mon, 14 Feb 2005 11:05:32 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format... ------------=_1108398497-29532-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Janardhan Iyengar wrote: > >>>> Switching over to an alternate on an FR may give you really good >>>> failover, >>>> but will likely hurt performance when there's no failure (the common >>>> case). Optimizing for the common case makes sense. >>> >>> >>> Actually, if a failure occurs, you will not be able to fast rtx because >>> the ack clock will be lost. So switching to an alternate on an FR won't >>> even improve failover time. >> >> >> >> Yeah, good point. In fact, turning that reasoning around: when an FR >> does occur, since an ack clock exists, the ack clock demonstrates that >> there is no failure! >> >> To clarify, an FR occurs only when there are acks coming back; meaning >> data is getting through and so are acks. Therefore, failure couldn't have >> happened if an FR happens! > > > Well, we tested it with a real failure. To be honest, I have not looked > at that code in a long time. So maybe my follow-up comment was wrong. > I have to look into it. OK. As a clarification... FR only causes faster retransmission, but should not cause the error count to increase nor the RTO to be adjusted... Correct? -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108398497-29532-0-- From iyengar@mail.eecis.udel.edu Mon Feb 14 11:47:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20543 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 11:47:00 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0ji8-0006aj-4M for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 12:08:37 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2005 08:46:39 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1EGkBYO025807; Mon, 14 Feb 2005 08:46:12 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1EGjq7U029793 for sctp-impl-filtered; Mon, 14 Feb 2005 08:45:54 -0800 (PST) Message-Id: <200502141645.j1EGjq7U029793@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108399552-29791-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: David Lehmann <lehmann@ulticom.com> From: Janardhan Iyengar <iyengar@mail.eecis.udel.edu> Cc: sctp-impl@external.cisco.com X-Nails-Approved: iyengar@mail.eecis.udel.edu Date: Mon, 14 Feb 2005 11:33:20 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 This is a multi-part message in MIME format... ------------=_1108399552-29791-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary Hi David, > > Well, we tested it with a real failure. To be honest, I have not looked > > at that code in a long time. So maybe my follow-up comment was wrong. > > I have to look into it. > > OK. As a clarification... FR only causes faster retransmission, but should > not cause the error count to increase nor the RTO to be adjusted... > Correct? I think that is correct. Only an RTO increases the error count. regards, jana --------------------------------------------------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab -- CIS -- University Of Delaware --------------------------------------------------------------- ------------=_1108399552-29791-0-- From rrs@cisco.com Mon Feb 14 15:02:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09391 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 15:02:29 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0mlJ-0002sd-Ue for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 15:24:07 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2005 13:14:43 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,84,1107734400"; d="scan'208"; a="226019417:sNHT43338084" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1EK1Pq8019997; Mon, 14 Feb 2005 12:01:25 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1EK0m7U002822 for sctp-impl-filtered; Mon, 14 Feb 2005 12:00:50 -0800 (PST) Message-Id: <200502142000.j1EK0m7U002822@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108411248-2819-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: Janardhan Iyengar <iyengar@mail.eecis.udel.edu> From: Randall Stewart <rrs@cisco.com> Cc: David Lehmann <lehmann@ulticom.com>, sctp-impl@external.cisco.com X-Nails-Approved: rrs@cisco.com Date: Mon, 14 Feb 2005 14:57:45 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format... ------------=_1108411248-2819-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Janardhan Iyengar wrote: > Hi David, > > >>>Well, we tested it with a real failure. To be honest, I have not looked >>>at that code in a long time. So maybe my follow-up comment was wrong. >>>I have to look into it. >> >>OK. As a clarification... FR only causes faster retransmission, but should >>not cause the error count to increase nor the RTO to be adjusted... >>Correct? > > > I think that is correct. Only an RTO increases the error count. Or a missed heartbeat.. But FR's do not effect the error count or RTO R > > regards, > jana > > --------------------------------------------------------------- > Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar > Protocol Engineering Lab -- CIS -- University Of Delaware > --------------------------------------------------------------- > -- Randall Stewart ITD 803-345-0369 <or> 815-342-5222 ------------=_1108411248-2819-0-- From bidulock@openss7.org Mon Feb 14 16:05:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18382 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 16:05:53 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0nkg-00050p-Sz for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 16:27:32 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2005 13:15:06 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1EL4uuC003367; Mon, 14 Feb 2005 13:04:57 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1EL4i7U003789 for sctp-impl-filtered; Mon, 14 Feb 2005 13:04:46 -0800 (PST) Message-Id: <200502142104.j1EL4i7U003789@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108415084-3787-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: Randall Stewart <rrs@cisco.com> From: "Brian F. G. Bidulock" <bidulock@openss7.org> Cc: Janardhan Iyengar <iyengar@mail.eecis.udel.edu>, David Lehmann <lehmann@ulticom.com>, sctp-impl@external.cisco.com X-Nails-Approved: bidulock@openss7.org Date: Mon, 14 Feb 2005 13:58:56 -0700 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is a multi-part message in MIME format... ------------=_1108415084-3787-0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: binary Randall, But FR does affect cwnd, so if one is doing CMT considering cwnd then the traffic will be weighted towards the other destinations. --brian On Mon, 14 Feb 2005, Randall Stewart wrote: > Janardhan Iyengar wrote: > > Hi David, > > > > > >>>Well, we tested it with a real failure. To be honest, I have not looked > >>>at that code in a long time. So maybe my follow-up comment was wrong. > >>>I have to look into it. > >> > >>OK. As a clarification... FR only causes faster retransmission, but should > >>not cause the error count to increase nor the RTO to be adjusted... > >>Correct? > > > > > > I think that is correct. Only an RTO increases the error count. > Or a missed heartbeat.. > > But FR's do not effect the error count or RTO > > R > > > > regards, > > jana > > > > --------------------------------------------------------------- > > Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar > > Protocol Engineering Lab -- CIS -- University Of Delaware > > --------------------------------------------------------------- > > > > > -- > Randall Stewart > ITD > 803-345-0369 <or> 815-342-5222 -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ ------------=_1108415084-3787-0-- From lehmann@ulticom.com Mon Feb 14 16:19:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19712 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 16:19:39 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0ny0-0005KT-Lo for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 16:41:18 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2005 13:19:20 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1ELIRwN019115; Mon, 14 Feb 2005 13:18:28 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1ELIF7U003993 for sctp-impl-filtered; Mon, 14 Feb 2005 13:18:17 -0800 (PST) Message-Id: <200502142118.j1ELIF7U003993@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108415895-3991-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: sctp-impl@external.cisco.com From: David Lehmann <lehmann@ulticom.com> X-Nails-Approved: lehmann@ulticom.com Date: Mon, 14 Feb 2005 15:54:30 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 This is a multi-part message in MIME format... ------------=_1108415895-3991-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: >> I think that is correct. Only an RTO increases the error count. > > Or a missed heartbeat.. > > But FR's do not effect the error count or RTO Thanks. I don't think that is clear in the spec, especially since that data chunk could be acting as a HB on the primary path. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108415895-3991-0-- From lehmann@ulticom.com Mon Feb 14 16:24:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20296 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 16:24:36 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0o2o-0005Sb-Bb for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 16:46:15 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2005 13:24:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1ELNiwN021631; Mon, 14 Feb 2005 13:23:45 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1ELNc7U004079 for sctp-impl-filtered; Mon, 14 Feb 2005 13:23:40 -0800 (PST) Message-Id: <200502142123.j1ELNc7U004079@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108416217-4077-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: SCTP API section 7.1.13 List-Id: sctp-impl To: SCTP Implementors <sctp-impl@external.cisco.com> From: David Lehmann <lehmann@ulticom.com> X-Nails-Approved: lehmann@ulticom.com Date: Mon, 14 Feb 2005 16:00:52 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 This is a multi-part message in MIME format... ------------=_1108416217-4077-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hello, How does the user set the spp_pathmaxrxt without changing the hbinterval? Typically, when the user does not want to change the value of a parameter, it is set to zero. In this case, setting hbinterval to zero has quite a different behavior. Setting it to UINT32_MAX will not change the parameter, but has the side effect of sending a HB immediately. I just want to change pathmaxrxt. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108416217-4077-0-- From bickhart@cis.udel.edu Mon Feb 14 17:59:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29081 for <sctp-impl-archive@ietf.org>; Mon, 14 Feb 2005 17:59:13 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0pWO-0007hO-HN for sctp-impl-archive@ietf.org; Mon, 14 Feb 2005 18:20:53 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 14 Feb 2005 15:10:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107763200"; d="scan'208"; a="614368758:sNHT35612220" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1EMwIuC004601; Mon, 14 Feb 2005 14:58:18 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1EMw17U005528 for sctp-impl-filtered; Mon, 14 Feb 2005 14:58:03 -0800 (PST) Message-Id: <200502142258.j1EMw17U005528@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108421881-5526-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP API section 7.1.13 List-Id: sctp-impl To: David Lehmann <lehmann@ulticom.com> From: Ryan W Bickhart <bickhart@cis.udel.edu> Cc: SCTP Implementors <sctp-impl@external.cisco.com> X-Nails-Approved: bickhart@cis.udel.edu Date: Mon, 14 Feb 2005 17:48:58 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 This is a multi-part message in MIME format... ------------=_1108421881-5526-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary I believe what you would do is first get all the current peer address parameter values which are returned in the sctp_paddrparams struct, change the fields that you want to new values, and then do a set, passing the struct back to SCTP. Anything you didn't modify would remain what it was before. Maybe there is a more direct way but that would definitely work. Ryan On Mon, 2005-02-14 at 16:00 -0500, David Lehmann wrote: > Hello, > > How does the user set the spp_pathmaxrxt without changing > the hbinterval? Typically, when the user does not want to > change the value of a parameter, it is set to zero. > In this case, setting hbinterval to zero has quite a different > behavior. > > Setting it to UINT32_MAX will not change the parameter, but > has the side effect of sending a HB immediately. > I just want to change pathmaxrxt. > ------------=_1108421881-5526-0-- From lehmann@ulticom.com Tue Feb 15 09:51:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06623 for <sctp-impl-archive@ietf.org>; Tue, 15 Feb 2005 09:51:13 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14No-0006Yk-7e for sctp-impl-archive@ietf.org; Tue, 15 Feb 2005 10:13:01 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 15 Feb 2005 07:02:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107763200"; d="scan'208"; a="614542062:sNHT34721508" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1FEnjYO015328; Tue, 15 Feb 2005 06:49:45 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1FEmo7U020132 for sctp-impl-filtered; Tue, 15 Feb 2005 06:48:52 -0800 (PST) Message-Id: <200502151448.j1FEmo7U020132@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108478930-20130-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP API section 7.1.13 List-Id: sctp-impl To: SCTP Implementors <sctp-impl@external.cisco.com> From: David Lehmann <lehmann@ulticom.com> X-Nails-Approved: lehmann@ulticom.com Date: Tue, 15 Feb 2005 09:25:53 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 This is a multi-part message in MIME format... ------------=_1108478930-20130-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Ryan W Bickhart wrote: > I believe what you would do is first get all the current peer address > parameter values which are returned in the sctp_paddrparams struct, > change the fields that you want to new values, and then do a set, > passing the struct back to SCTP. Anything you didn't modify would remain > what it was before. Maybe there is a more direct way but that would > definitely work. How do you "get all the current peer address parameter values" without setting it? The draft says that you "should" use sctp_opt_info which 'sets' and 'gets'. Does this mean that you can use getsockopt() as well? If so, I did not see that statement in the draft. Even if this is the case, it seems that this API is inconsistent with the other structures where zero means "don't change". Also, it is very inconvenient to get a value just so we can then set it to the same value. IMHO, zero should mean "don't change". UINT32_MAX could mean disable heartbeats. (Or ~49 days, which is affectively disabled.) How about adding a boolean parameter "spp_send_hb"? zero would mean don't send a HB; nonzero would mean send it. That would leave spp_hbinterval to behave like the other parameters. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108478930-20130-0-- From bickhart@cis.udel.edu Tue Feb 15 11:12:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26951 for <sctp-impl-archive@ietf.org>; Tue, 15 Feb 2005 11:12:38 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15ed-0003Yb-5U for sctp-impl-archive@ietf.org; Tue, 15 Feb 2005 11:34:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Feb 2005 08:23:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107763200"; d="scan'208"; a="614572368:sNHT29630980" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1FGBUq8009736; Tue, 15 Feb 2005 08:11:31 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1FGB37U021453 for sctp-impl-filtered; Tue, 15 Feb 2005 08:11:05 -0800 (PST) Message-Id: <200502151611.j1FGB37U021453@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108483863-21451-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: RE: SCTP API section 7.1.13 List-Id: sctp-impl To: "'David Lehmann'" <lehmann@ulticom.com> From: "Ryan W Bickhart" <bickhart@cis.udel.edu> Cc: "'SCTP Implementors'" <sctp-impl@external.cisco.com> X-Nails-Approved: bickhart@cis.udel.edu Date: Tue, 15 Feb 2005 11:05:18 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format... ------------=_1108483863-21451-0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: binary -----Original Message----- From: David Lehmann [mailto:lehmann@ulticom.com] Sent: Tuesday, February 15, 2005 9:26 AM To: SCTP Implementors Subject: Re: SCTP API section 7.1.13 > How do you "get all the current peer address parameter values" without > setting it? The draft says that you "should" use sctp_opt_info which > 'sets' and 'gets'. Does this mean that you can use getsockopt() as well? > If so, I did not see that statement in the draft. According to UNP (third ed) page 278, sctp_opt_info is a more portable replacement for getsockopt. It says that some OS implementations may not support in-out variables with getsockopt, which SCTP needs in some cases. So you could think of sctp_opt_info as a glorified getsockopt that always works. On FreeBSD, for example, you can use getsockopt directly, but this is discouraged for portability reasons. So you might do: sctp_opt_info(...) /* get the settings */ /*modify what you want */ setsockopt(...) /* save the changes */ > Even if this is the case, it seems that this API is > inconsistent with the other structures where zero means > "don't change". Also, it is very inconvenient to get a value just > so we can then set it to the same value. I agree on both counts. > IMHO, zero should mean "don't change". UINT32_MAX could mean > disable heartbeats. (Or ~49 days, which is affectively > disabled.) How about adding a boolean parameter "spp_send_hb"? > zero would mean don't send a HB; nonzero would mean send it. > That would leave spp_hbinterval to behave like the other parameters. Even with the boolean, I think we would still have the same type of consistency problem, just with a different parameter. How would you turn off heartbeats by setting spp_send_hb to zero if zero means do not change the current value? :) Maybe the first suggestion might work better...any other ideas? Ryan ------------=_1108483863-21451-0-- From beheld.Swain@hotmail.com Tue Feb 15 12:01:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11025; Tue, 15 Feb 2005 12:01:38 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D16Q2-00082u-Vo; Tue, 15 Feb 2005 12:23:28 -0500 Received: from host114-223.pool81121.interbusiness.it ([81.121.223.114]) by mx2.foretec.com with smtp (Exim 4.24) id 1D164l-0001fw-GW; Tue, 15 Feb 2005 12:01:28 -0500 Received: from agave6penthouseprivilege (58.29.175.91) by mail6.81.121.223.114 (waterhousebenzene TYL 1.2.499) id 27EG05AR14850OE23 for saad-request@ietf.org; Tue, 15 Feb 2005 11:52:37 -0500 X-MIME-Autoconverted: Yes Disclose-Recipients: No Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed X-No-Archive: Yes Reply-To: "Mack Flood" <beheld.Swain@hotmail.com> From: "Mack Flood" <beheld.Swain@hotmail.com> To: saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org, rserpool@ietf.org, saad@ietf.org, rmonmib-admin@ietf.org, rpsec-admin@ietf.org, rohc-request@ietf.org, rohc-admin@ietf.org, rserpool-admin@ietf.org, rmonmib@ietf.org, rmt-request@ietf.org, routing-discussion@ietf.org, rpsec@ietf.org, saad-admin@ietf.org Subject: the original online source for market research Date: Tue, 15 Feb 2005 20:00:37 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--986950958951224" Message-Id: <E1D164l-0001fw-GW@mx2.foretec.com> X-Spam-Score: 21.5 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----986950958951224 Content-Type: text/plain; charset="iso-1700-7" Content-Transfer-Encoding: quoted-printable ***GEEC*****GEEC*****GEEC*****GEEC*****GEEC*** Global Environmental Energy Corp. (OTC-BB: GEEC) Shares Outstanding : 35 million Approx. Float : 9 million 30 Day Target : $6.25 6 Month Price Projection : $15.00 Recent News and Major Share-Price Driving Milestones: GEEC just announced a $10 Billion, 5-year joint venture with several companies operated by the Chinese Government. GEEC uses their Biosphere Process System to convert various types of waste into clean, "green" electricity at 5 to 10 mega-watts per hour. GEEC Chairman, former Prime Minister of Ireland Dr. Albert Reynolds, has secured a $2 Billion line of credit for GEEC and opened doors in over a dozen countries through political contacts at the highest level. Global Environmental Energy is CBS Marketwatch.com's #1 Best Performer in the DJ Diversified Industrials Index in the last 2 months. This Dow Jones Index also contains 3M, GE, and Honeywell. Conservative estimates value the company at One Billion Dollars Future Milestones: 1. GEEC had a $100 Million backlog of sales orders for the Biosphere before the China joint-venture with 26 completed Biospheres in operation. The backlog is now into the Billions with complete financing to be provided by China and 1,300 Biospheres to be deployed throughout the country. 2. GEEC's present assets of $35 Million will conservatively jump into the $300 Million range, a 10-times increase. 3. GEEC is in advanced stages of agreement on at least 6 major international projects which could add $50 Million to the bottom-line or $1.42 per share. 4. P/E on average for this Industry Group is 20 to 1 putting GEEC in the $13 dollar range without any future business expansion. 5. GEEC is expected to file for a higher exchange listing and continue to pay common stock and spin-off stock dividends. Worldwide Market Potential $15 to $25 Billion over next 5 years with no other known company that can match their technology, leadership, or explosive sales growth. Up until now GEEC has been one of Wall Street's best kept secrets, yet now it seems the cat is coming out of the bag and the release of this new Investor Awareness Campaign should be excellent timing in regards to some new PR's forthcoming which will Rocket GEEC. This power-play has nowhere to go but up, according to most insiders, and there's still a bit of time to get in before the boom. DISCLOSURE: The information and opinions in this feature profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past-results is not an indicator of future-results. This report is a paid profile and is for information purposes only and should not be used as the basis for any investment decision. Ten thousand dollars has been paid for the preparation of this profile and for continuing coverage of the featured company. We are not an investment advisor and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains forward-look-ing statements and is subject to significant risks and uncertainties. There are no shares held and there will be no participation in the trading of shares of any profiled company. ----986950958951224-- From lehmann@ulticom.com Tue Feb 15 12:39:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21826 for <sctp-impl-archive@ietf.org>; Tue, 15 Feb 2005 12:39:13 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D170N-00036C-TM for sctp-impl-archive@ietf.org; Tue, 15 Feb 2005 13:01:03 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 15 Feb 2005 09:41:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,86,1107763200"; d="scan'208"; a="161611071:sNHT68519880" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1FHcKq8010185; Tue, 15 Feb 2005 09:38:20 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1FHbx7U022892 for sctp-impl-filtered; Tue, 15 Feb 2005 09:38:01 -0800 (PST) Message-Id: <200502151738.j1FHbx7U022892@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108489079-22890-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP API section 7.1.13 List-Id: sctp-impl To: "'SCTP Implementors'" <sctp-impl@external.cisco.com> From: David Lehmann <lehmann@ulticom.com> X-Nails-Approved: lehmann@ulticom.com Date: Tue, 15 Feb 2005 12:14:08 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db This is a multi-part message in MIME format... ------------=_1108489079-22890-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Ryan W Bickhart wrote: >>How do you "get all the current peer address parameter values" without >>setting it? The draft says that you "should" use sctp_opt_info which >>'sets' and 'gets'. Does this mean that you can use getsockopt() as well? >>If so, I did not see that statement in the draft. > > > According to UNP (third ed) page 278, sctp_opt_info is a more portable > replacement for getsockopt. It says that some OS implementations may not Who is defining sctp_opt_info? UNP or SCTP API I-D? If it is the SCTP API I-D, then usage need to be defined clearly in the I-D. > support in-out variables with getsockopt, which SCTP needs in some cases. > So you could think of sctp_opt_info as a glorified getsockopt that always > works. On FreeBSD, for example, you can use getsockopt directly, but this > is discouraged for portability reasons. I don't necessarily agree with these statements, but I won't belabor the point. > So you might do: > sctp_opt_info(...) /* get the settings */ My understanding is that sctp_opt_info will _set_ the values. How do you get the values before setting them? > /*modify what you want */ > setsockopt(...) /* save the changes */ > > >>Even if this is the case, it seems that this API is >>inconsistent with the other structures where zero means >>"don't change". Also, it is very inconvenient to get a value just >>so we can then set it to the same value. > > I agree on both counts. Progress! :-) >>IMHO, zero should mean "don't change". UINT32_MAX could mean >>disable heartbeats. (Or ~49 days, which is affectively >>disabled.) How about adding a boolean parameter "spp_send_hb"? >>zero would mean don't send a HB; nonzero would mean send it. >>That would leave spp_hbinterval to behave like the other parameters. > > > Even with the boolean, I think we would still have the same type of > consistency problem, just with a different parameter. How would you turn > off heartbeats by setting spp_send_hb to zero if zero means do not change > the current value? :) Maybe the first suggestion might work better...any > other ideas? I was suggesting this: struct sctp_paddrparams { sctp_assoc_t spp_assoc_id; struct sockaddr_storage spp_address; uint32_t spp_hbinterval; uint16_t spp_pathmaxrxt; uint8_t spp_send_hb; }; If spp_hbinterval == 0, do not change the HB interval. If spp_hbinterval != 0, set the HB interval to the given number of milliseconds. Setting it to UINT32_MAX would disable the HBs. (My point above is that if the SCTP implementation did not make a special case for UINT32_MAX, the interval would be more than 49 days, which effectively disables it.) If spp_pathmaxrxt == 0, do not change the path max retrans. If spp_pathmaxrxt != 0, set the path max retrans to that value. If spp_send_hb == 0, do not send a HB. If spp_send_hb != 0, send a HB. (spp_hbinterval should not cause the immediate sending of a HB.) Better yet, leave the sctp_paddrparams as it was and create a new function to send a HB: int sctp_send_heartbeat( int sd, sctp_assoc_t id, const struct sockaddr *addr); -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108489079-22890-0-- From mariam.nelson@virgilio.it Tue Feb 15 13:03:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00510 for <sctp-impl-archive@ietf.org>; Tue, 15 Feb 2005 13:03:10 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17NV-0005qj-Gx for sctp-impl-archive@ietf.org; Tue, 15 Feb 2005 13:24:56 -0500 Received: from [81.199.125.4] (helo=mrson1102.com) by mx2.foretec.com with smtp (Exim 4.24) id 1D172I-0003H6-OB for sctp-impl-archive@ietf.org; Tue, 15 Feb 2005 13:03:01 -0500 From: "Mrs Mariam Nelson" <mariam.nelson@virgilio.it> Reply-To: mariam.nelson@virgilio.it To: sctp-impl-archive@ietf.org Date: Tue, 15 Feb 2005 18:04:57 +0000 Subject: From Yours Humble Sister Mariam X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <E1D172I-0003H6-OB@mx2.foretec.com> X-Spam-Score: 11.4 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable From mrs Mariam Nelson Dearest in christ. My name is Mrs Mariam Nelson a nationality of Kuwait. I am married to la= te Mr. James Nelson who worked with Kuwait embassy in Ivory Coast for ni= ne years before he died in the year Octorber 2003. We were married for t= wenty years with a child. He died after a the illness that lasted for long four days. Before his death we were= both born again Christians. When my late husband was alive we deposited= the sum of $12Million (twelve Million U.S. Dollars) with one of good ba= nks here in Cote d'Ivoire . Presently, this money is still with the bank. Recently my Doctor told me= that I would not last for the next three months due to my cancer proble= m. Though what disturbs me most is my stroke. Having known my condition = I decided to donate this fund to church or better still a Christian individual that will utilize this money th= e way I am going to instruct here in. I want a person or church that will use this fund to churches, orphanag= es, research centres and widows propagating the word of God and to ensur= e that the house of God is maintained. The Bible made us to understand t= hat blessed is the hand that giveth. I took this decision because I have a child that will inherit this money = but my son can not carryout this work only because i and my late husban= d decide to use some of the money to work for God and live some for our = son to have a better live. our son is just 17years old now and been grow up in africa, he have low manterity = and my husband=B4s relatives are not Christians and I don=B4t want my fa= mily hard earned money to be misused by unbelievers. I don=B4t want a si= tuation where this money will be used in an ungodly manner. Hence the reason for taking this bold decision. I am not afraid of death hence I know where I am going to. I know that I= am going to be in the bosom of the Lord. Exodus 14 VS 14 says that the = lord will fight my case and I shall hold my peace. I want your telephone= communication in this regard because of my health and due to the presence of my family relatives around me al= ways .call me or my son his name is George, with this our Telephone numb= er is +22505268694, Immediately you recievd this message. I don=B4t want= any of my husband family relatives to recieve this money. With God all things are possible. As soon as I receive your reply I shall give you the contact of the Fina= nce/bank. I will also issue you a letter of authority that will empower = you as the new beneficiary of this fund. I want you and the church to al= ways pray for me because the lord is my shepherd. My happiness is that I live a life of a worthy Christian. Whoever that wants to serve the Lord must serve him in spirit and truth.= Please always be prayerful all through your life. Any delay in your rep= ly will give me room in sourcing for a church or Christian individual fo= r this same purpose. Please assure me that you will act accordingly as I stated here. Expecting to hearing from you on this private mailbox. Remain blessed in the name of the Lord. Mrs. Mariam Nelson. From rrs@cisco.com Tue Feb 15 15:36:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09421 for <sctp-impl-archive@ietf.org>; Tue, 15 Feb 2005 15:36:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19mG-0000io-AI for sctp-impl-archive@ietf.org; Tue, 15 Feb 2005 15:58:36 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 15 Feb 2005 12:36:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1FKZOwN001221; Tue, 15 Feb 2005 12:35:27 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1FKYx7U025576 for sctp-impl-filtered; Tue, 15 Feb 2005 12:35:01 -0800 (PST) Message-Id: <200502152035.j1FKYx7U025576@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108499699-25574-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP API section 7.1.13 List-Id: sctp-impl To: David Lehmann <lehmann@ulticom.com> From: Randall Stewart <rrs@cisco.com> Cc: "'SCTP Implementors'" <sctp-impl@external.cisco.com> X-Nails-Approved: rrs@cisco.com Date: Tue, 15 Feb 2005 15:31:50 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 This is a multi-part message in MIME format... ------------=_1108499699-25574-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Ryan W Bickhart wrote: > >>> How do you "get all the current peer address parameter values" without >>> setting it? The draft says that you "should" use sctp_opt_info which >>> 'sets' and 'gets'. Does this mean that you can use getsockopt() as well? >>> If so, I did not see that statement in the draft. >> >> >> >> According to UNP (third ed) page 278, sctp_opt_info is a more portable >> replacement for getsockopt. It says that some OS implementations may not > > > Who is defining sctp_opt_info? UNP or SCTP API I-D? > If it is the SCTP API I-D, then usage need to be defined clearly in the > I-D. > >> support in-out variables with getsockopt, which SCTP needs in some cases. >> So you could think of sctp_opt_info as a glorified getsockopt that always >> works. On FreeBSD, for example, you can use getsockopt directly, but >> this >> is discouraged for portability reasons. > > > I don't necessarily agree with these statements, but I won't belabor the > point. > But that IS the whole point of the sctp_opt_info.. i.e. a replacement for getsockopt that allows in-out parameters... I can say that with authority since I was there when all of us authors debated the need for it.. and this was the ONLY reason to create it... The text currently says: **************************************************************** <t> For some IP stacks getsockopt() is read-only, so a new interface will be needed when information must be passed both in to and out of the SCTP stack. The syntax for sctp_opt_info() is, </t> <figure> <artwork> int sctp_opt_info(int sd, sctp_assoc_t id, int opt, void *arg, socklen_t *size); </artwork> </figure> <t> For one-to-many style sockets, id specifies the association to query. For one-to-one style sockets, id is ignored. </t> <t> opt specifies which SCTP socket option to get. It can any socket option currently supported that requests information (either read/write options or read only) such as: </t> ******************************************************* You may be being confusred by that last line in ()'s What that is eluding to is the "classification" of the socket options.. i.e. the document classify's all options as read-only, or read-write options... This is NOT saying anything about sctp_opt_info being used to set an option.. And I think that first bit clearly states this is as Ryan implied.. due to some O/S's not allowing in/out in a getsockopt(). >> So you might do: >> sctp_opt_info(...) /* get the settings */ > > > My understanding is that sctp_opt_info will _set_ the values. > How do you get the values before setting them? No.. its used for read only .. but with an in parameter. > >> /*modify what you want */ >> setsockopt(...) /* save the changes */ >> >> >>> Even if this is the case, it seems that this API is >>> inconsistent with the other structures where zero means >>> "don't change". Also, it is very inconvenient to get a value just >>> so we can then set it to the same value. >> >> >> I agree on both counts. > > > Progress! :-) > >>> IMHO, zero should mean "don't change". UINT32_MAX could mean >>> disable heartbeats. (Or ~49 days, which is affectively >>> disabled.) How about adding a boolean parameter "spp_send_hb"? >>> zero would mean don't send a HB; nonzero would mean send it. >>> That would leave spp_hbinterval to behave like the other parameters. >> >> >> >> Even with the boolean, I think we would still have the same type of >> consistency problem, just with a different parameter. How would you turn >> off heartbeats by setting spp_send_hb to zero if zero means do not change >> the current value? :) Maybe the first suggestion might work better...any >> other ideas? > > > I was suggesting this: > struct sctp_paddrparams { > sctp_assoc_t spp_assoc_id; > struct sockaddr_storage spp_address; > uint32_t spp_hbinterval; > uint16_t spp_pathmaxrxt; > uint8_t spp_send_hb; > }; > > If spp_hbinterval == 0, do not change the HB interval. > If spp_hbinterval != 0, set the HB interval to the given number > of milliseconds. Setting it to UINT32_MAX would disable > the HBs. (My point above is that if the SCTP implementation did not > make a special case for UINT32_MAX, the interval would be > more than 49 days, which effectively disables it.) > > If spp_pathmaxrxt == 0, do not change the path max retrans. > If spp_pathmaxrxt != 0, set the path max retrans to that value. > > If spp_send_hb == 0, do not send a HB. > If spp_send_hb != 0, send a HB. (spp_hbinterval should not > cause the immediate sending of a HB.) > > Better yet, leave the sctp_paddrparams as it was and create > a new function to send a HB: > > int sctp_send_heartbeat( > int sd, sctp_assoc_t id, const struct sockaddr *addr); > > I can live with either approach... but I think the heart of this problem is that you are assuming that sctp_opt_info() is a write option.. it is NOT meant to change any values. That definetly needs to be clearified in the next pass. R -- Randall Stewart ITD 803-345-0369 <or> 815-342-5222 ------------=_1108499699-25574-0-- From lehmann@ulticom.com Tue Feb 15 17:14:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18823 for <sctp-impl-archive@ietf.org>; Tue, 15 Feb 2005 17:14:46 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1BJ8-0003LO-Ho for sctp-impl-archive@ietf.org; Tue, 15 Feb 2005 17:36:39 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2005 14:24:13 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1FMDhq8002868; Tue, 15 Feb 2005 14:13:43 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1FMDK7U027190 for sctp-impl-filtered; Tue, 15 Feb 2005 14:13:22 -0800 (PST) Message-Id: <200502152213.j1FMDK7U027190@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108505599-27188-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP API section 7.1.13 List-Id: sctp-impl To: "'SCTP Implementors'" <sctp-impl@external.cisco.com> From: David Lehmann <lehmann@ulticom.com> X-Nails-Approved: lehmann@ulticom.com Date: Tue, 15 Feb 2005 16:49:32 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 This is a multi-part message in MIME format... ------------=_1108505599-27188-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: >> I don't necessarily agree with these statements, but I won't belabor the >> point. >> > > But that IS the whole point of the sctp_opt_info.. i.e. a replacement > for getsockopt that allows in-out parameters... OOOhhhh... The light bulb just turned on! I remember this issue when speaking to one of the authors of RFC 3542. In section 11.4, it states "there is no way to pass the destination via getsockopt()", even though the given struct ip6_mtuinfo has a spot for the destination. Thinking out loud... Maybe there should be a generic sock_opt_info(). int sock_opt_info(int s, int level, int optname, void *optval, int *optlen); The association id can be put in each structure so it could be used in sock_opt_info(). Actually, the association id is in each structure. Why is the association id needed on sctp_opt_info()? > I can say that with authority since I was there when all of > us authors debated the need for it.. and this was the ONLY reason > to create it... > The text currently says: > **************************************************************** > <t> > For some IP stacks getsockopt() is read-only, so a new > interface will be needed when information must be passed both in to > and out of the SCTP stack. The syntax for sctp_opt_info() is, > </t> > <figure> > <artwork> > int sctp_opt_info(int sd, > sctp_assoc_t id, > int opt, > void *arg, > socklen_t *size); > </artwork> > </figure> > <t> > For one-to-many style sockets, id specifies the association to > query. For > one-to-one style sockets, id is ignored. > </t> > <t> > opt specifies which SCTP socket option to get. It can I think you are missing a "get" after the "can". > any socket option currently supported that requests information > (either read/write options or read only) such as: > </t> > ******************************************************* > > > You may be being confusred by that last line in ()'s > > What that is eluding to is the "classification" of the socket > options.. i.e. the document classify's all options as read-only, > or read-write options... This is NOT saying anything about > sctp_opt_info being used to set an option.. > > And I think that first bit clearly states this is as Ryan > implied.. due to some O/S's not allowing in/out in a > getsockopt(). Got it. Maybe a statement is needed to explicitly state what you just wrote: "Sctp_opt_info() is a replacement for getsockopt() only and will not set any options associated with the specified socket. Setsockopt() must be used to set these options." > ... >> I was suggesting this: >> struct sctp_paddrparams { >> sctp_assoc_t spp_assoc_id; >> struct sockaddr_storage spp_address; >> uint32_t spp_hbinterval; >> uint16_t spp_pathmaxrxt; >> uint8_t spp_send_hb; >> }; >> >> If spp_hbinterval == 0, do not change the HB interval. >> If spp_hbinterval != 0, set the HB interval to the given number >> of milliseconds. Setting it to UINT32_MAX would disable >> the HBs. (My point above is that if the SCTP implementation did not >> make a special case for UINT32_MAX, the interval would be >> more than 49 days, which effectively disables it.) >> >> If spp_pathmaxrxt == 0, do not change the path max retrans. >> If spp_pathmaxrxt != 0, set the path max retrans to that value. >> >> If spp_send_hb == 0, do not send a HB. >> If spp_send_hb != 0, send a HB. (spp_hbinterval should not >> cause the immediate sending of a HB.) >> >> Better yet, leave the sctp_paddrparams as it was and create >> a new function to send a HB: >> >> int sctp_send_heartbeat( >> int sd, sctp_assoc_t id, const struct sockaddr *addr); >> >> > > I can live with either approach... but I think the heart of > this problem is that you are assuming that sctp_opt_info() is > a write option.. it is NOT meant to change any values. Yep, I did misunderstand the functionality of sctp_opt_info. Thanks for belaboring the point even though I didn't want to. :-) Nonetheless, I would like to see the authors discuss the issue of making 'spp_hbinterval == 0' do nothing on a setsockopt(). > That definetly needs to be clearified in the next pass. Agreed. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108505599-27188-0-- From wo16281628@163.net Tue Feb 15 22:36:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09715 for <sctp-impl-archive@ietf.org>; Tue, 15 Feb 2005 22:36:03 -0500 (EST) Message-Id: <200502160336.WAA09715@ietf.org> Received: from [218.17.69.44] (helo=163.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1GJy-0004SE-Ut for sctp-impl-archive@ietf.org; Tue, 15 Feb 2005 22:57:58 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= <wo16281628@163.net> Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Wed, 16 Feb 2005 11:35:35 +0800 X-Priority: 2 X-Mailer: FoxMail 4.0 beta 2 [cn] X-Spam-Score: 5.9 (+++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>ÎÞ±êÌâÎĵµ
 
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076 »ò 0755-88363633
       QQ£º 282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From rrs@cisco.com Wed Feb 16 08:03:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05622 for ; Wed, 16 Feb 2005 08:03:50 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1PBd-0003BT-NZ for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 08:25:50 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 Feb 2005 06:14:44 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,88,1107734400"; d="scan'208"; a="226154482:sNHT35139264" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1GD14uC011929; Wed, 16 Feb 2005 05:01:04 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1GD0c7U012207 for sctp-impl-filtered; Wed, 16 Feb 2005 05:00:40 -0800 (PST) Message-Id: <200502161300.j1GD0c7U012207@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108558838-12204-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP API section 7.1.13 List-Id: sctp-impl To: David Lehmann From: Randall Stewart Cc: "'SCTP Implementors'" X-Nails-Approved: rrs@cisco.com Date: Wed, 16 Feb 2005 07:57:13 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd This is a multi-part message in MIME format... ------------=_1108558838-12204-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Randall Stewart wrote: > >>> I don't necessarily agree with these statements, but I won't belabor the >>> point. >>> >> >> But that IS the whole point of the sctp_opt_info.. i.e. a replacement >> for getsockopt that allows in-out parameters... > > > OOOhhhh... The light bulb just turned on! > > I remember this issue when speaking to one of the authors of RFC 3542. > In section 11.4, it states "there is no way to pass the destination via > getsockopt()", even though the given struct ip6_mtuinfo has a spot for > the destination. > > Thinking out loud... > Maybe there should be a generic sock_opt_info(). That maybe.. or getsockopt() needs to be re-defined to require it to allow in-out parameters.. its that way on most BSD's but I don't think so on most other O/S's :-D > > int sock_opt_info(int s, int level, int optname, void *optval, int > *optlen); > > The association id can be put in each structure so it could be used > in sock_opt_info(). Actually, the association id is in each structure. > Why is the association id needed on sctp_opt_info()? > Well, in the case of the 1-to-N model, you need to figure out which association id is being requested information on... >> I can say that with authority since I was there when all of >> us authors debated the need for it.. and this was the ONLY reason >> to create it... > > > >> The text currently says: >> **************************************************************** >> >> For some IP stacks getsockopt() is read-only, so a new >> interface will be needed when information must be passed both in to >> and out of the SCTP stack. The syntax for sctp_opt_info() is, >> >>
>> >> int sctp_opt_info(int sd, >> sctp_assoc_t id, >> int opt, >> void *arg, >> socklen_t *size); >> >>
>> >> For one-to-many style sockets, id specifies the association to >> query. For >> one-to-one style sockets, id is ignored. >> >> >> opt specifies which SCTP socket option to get. It can > > > I think you are missing a "get" after the "can". > >> any socket option currently supported that requests information >> (either read/write options or read only) such as: >> >> ******************************************************* >> >> >> You may be being confusred by that last line in ()'s >> >> What that is eluding to is the "classification" of the socket >> options.. i.e. the document classify's all options as read-only, >> or read-write options... This is NOT saying anything about >> sctp_opt_info being used to set an option.. >> >> And I think that first bit clearly states this is as Ryan >> implied.. due to some O/S's not allowing in/out in a >> getsockopt(). > > > Got it. Maybe a statement is needed to explicitly state > what you just wrote: "Sctp_opt_info() is a replacement > for getsockopt() only and will not set any options associated > with the specified socket. Setsockopt() must be used to > set these options." > I have fixed the missing "get" (I noticed that to when I cut and pasted into the email :-0) And put in most of the wording above verbatim.. with one minor change.. it will read: For some IP stacks getsockopt() is read-only, so a new interface will be needed when information must be passed both in to and out of the SCTP stack. The syntax for sctp_opt_info() is, The sctp_opt_info() call is a replacement for getsockopt() only and will not set any options associated with the specified socket. A setsockopt() must be used to set any writeable option. That hopefully will cover it :-D >> ... >> >>> I was suggesting this: >>> struct sctp_paddrparams { >>> sctp_assoc_t spp_assoc_id; >>> struct sockaddr_storage spp_address; >>> uint32_t spp_hbinterval; >>> uint16_t spp_pathmaxrxt; >>> uint8_t spp_send_hb; >>> }; >>> >>> If spp_hbinterval == 0, do not change the HB interval. >>> If spp_hbinterval != 0, set the HB interval to the given number >>> of milliseconds. Setting it to UINT32_MAX would disable >>> the HBs. (My point above is that if the SCTP implementation did not >>> make a special case for UINT32_MAX, the interval would be >>> more than 49 days, which effectively disables it.) >>> >>> If spp_pathmaxrxt == 0, do not change the path max retrans. >>> If spp_pathmaxrxt != 0, set the path max retrans to that value. >>> >>> If spp_send_hb == 0, do not send a HB. >>> If spp_send_hb != 0, send a HB. (spp_hbinterval should not >>> cause the immediate sending of a HB.) >>> >>> Better yet, leave the sctp_paddrparams as it was and create >>> a new function to send a HB: >>> >>> int sctp_send_heartbeat( >>> int sd, sctp_assoc_t id, const struct sockaddr *addr); >>> >>> >> >> I can live with either approach... but I think the heart of >> this problem is that you are assuming that sctp_opt_info() is >> a write option.. it is NOT meant to change any values. > > > Yep, I did misunderstand the functionality of sctp_opt_info. > Thanks for belaboring the point even though I didn't want to. :-) > > Nonetheless, I would like to see the authors discuss the > issue of making 'spp_hbinterval == 0' do nothing on a > setsockopt(). Maybe we can have an authors and interested folks pow-wow at the IETF.. R >> That definetly needs to be clearified in the next pass. > > > Agreed. > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108558838-12204-0-- From support@paypal.com Wed Feb 16 08:06:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06178 for ; Wed, 16 Feb 2005 08:06:56 -0500 (EST) Received: from [216.117.177.39] (helo=216.117.177.39) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1PEe-0003MD-CY for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 08:28:56 -0500 Received: from 248.154.100.168 by ; Wed, 16 Feb 2005 16:03:51 +0300 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Wed, 16 Feb 2005 15:00:51 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2654417177546344" X-Webmail-Time: Wed, 16 Feb 2005 08:59:51 -0400 X-Spam-Score: 12.3 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----2654417177546344 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----2654417177546344-- From lehmann@ulticom.com Wed Feb 16 08:43:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09084 for ; Wed, 16 Feb 2005 08:43:26 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Pnw-0004Dq-02 for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 09:05:26 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 16 Feb 2005 05:43:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1GDgFwN003507; Wed, 16 Feb 2005 05:42:16 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1GDg07U012935 for sctp-impl-filtered; Wed, 16 Feb 2005 05:42:02 -0800 (PST) Message-Id: <200502161342.j1GDg07U012935@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108561320-12927-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: SCTP API section 7.1.13 List-Id: sctp-impl To: "'SCTP Implementors'" From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Wed, 16 Feb 2005 08:18:07 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format... ------------=_1108561320-12927-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Randall Stewart wrote: > That maybe.. or getsockopt() needs to be re-defined to require > it to allow in-out parameters.. its that way on most > BSD's but I don't think so on most other O/S's :-D Agreed. >> int sock_opt_info(int s, int level, int optname, void *optval, int >> *optlen); >> >> The association id can be put in each structure so it could be used >> in sock_opt_info(). Actually, the association id is in each structure. >> Why is the association id needed on sctp_opt_info()? >> > > > Well, in the case of the 1-to-N model, you need to figure > out which association id is being requested information > on... Isn't the association id in all of the structures used by sctp_opt_info()? > And put in most of the wording above verbatim.. with one > minor change.. it will read: > > > For some IP stacks getsockopt() is read-only, so a new > interface will be needed when information must be passed both in to > and out of the SCTP stack. The syntax for sctp_opt_info() is, > > > The sctp_opt_info() call is a replacement for getsockopt() only > and will not set any options associated with the specified socket. > A setsockopt() must be used to set any writeable option. > > > That hopefully will cover it :-D Yep, looks good. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108561320-12927-0-- From service@paypal.com Wed Feb 16 08:48:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09536 for ; Wed, 16 Feb 2005 08:48:56 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1PtI-0004Lg-FT for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 09:10:56 -0500 Received: from [216.117.177.39] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D1PY1-0005Qa-Sb for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 08:48:58 -0500 Received: from 18zks.4n6l9.org ([190.116.167.241]) by 65.246.255.50 with ESMTP id <506706-29125>; Wed, 16 Feb 2005 10:39:50 -0300 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Wed, 16 Feb 05 10:39:50 GMT X-Mailer: Microsoft Outlook, Build 10.0.2627 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="C.6.735C_1" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 23.6 (+++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --C.6.735C_1 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--C.6.735C_1-- From lehmann@ulticom.com Wed Feb 16 09:38:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14663 for ; Wed, 16 Feb 2005 09:38:25 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1QfB-0005gb-7x for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 10:00:26 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2005 06:49:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,89,1107763200"; d="scan'208"; a="614953313:sNHT672693184" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GEVtq8022578; Wed, 16 Feb 2005 06:31:56 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1GEVa7U013794 for sctp-impl-filtered; Wed, 16 Feb 2005 06:31:38 -0800 (PST) Message-Id: <200502161431.j1GEVa7U013794@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108564296-13786-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: sack delay parameter List-Id: sctp-impl To: SCTP Implementors From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Wed, 16 Feb 2005 09:07:52 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 This is a multi-part message in MIME format... ------------=_1108564296-13786-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hello, In RFC2960, section 6.2, the sack delay is specified as 200ms and can be configured up to 500ms. Can we add a sack delay parameter to the API, maybe in struct sctp_assocparams? -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108564296-13786-0-- From Michael.Tuexen@micmac.franken.de Wed Feb 16 10:32:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24621 for ; Wed, 16 Feb 2005 10:32:33 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1RVb-00082x-J9 for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 10:54:35 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 16 Feb 2005 07:32:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1GFVSwN013906; Wed, 16 Feb 2005 07:31:29 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1GFVA7U014823 for sctp-impl-filtered; Wed, 16 Feb 2005 07:31:12 -0800 (PST) Message-Id: <200502161531.j1GFVA7U014823@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108567870-14821-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sack delay parameter List-Id: sctp-impl To: David Lehmann From: Michael Tuexen Cc: SCTP Implementors X-Nails-Approved: Michael.Tuexen@micmac.franken.de Date: Wed, 16 Feb 2005 15:51:13 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f This is a multi-part message in MIME format... ------------=_1108567870-14821-0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David, I agree with you. On a BSD system you can configure only via sysctl and on LKSCTP there is no way of configuring currently. A value of 0 should disable delaying the SACK. The other open point (from my perspective) is to be able to set the path MTU and therefore disabling path MTU discovery. Best regards Michael PS: Randy, should we add this before Monday? On Feb 16, 2005, at 15:07 Uhr, David Lehmann wrote: > Hello, > > In RFC2960, section 6.2, the sack delay is specified as 200ms > and can be configured up to 500ms. Can we add a sack delay > parameter to the API, maybe in struct sctp_assocparams? > > -- > > David Lehmann Ulticom, Inc. > AOL/Yahoo IM: davidULCM 1020 Briggs Road > 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108567870-14821-0-- From lehmann@ulticom.com Wed Feb 16 12:36:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01323 for ; Wed, 16 Feb 2005 12:36:05 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1TR8-0002z1-N9 for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 12:58:09 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2005 09:47:16 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,90,1107763200"; d="scan'208"; a="615017395:sNHT40752290" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1GHZ6uC006131; Wed, 16 Feb 2005 09:35:06 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1GHYR7U016900 for sctp-impl-filtered; Wed, 16 Feb 2005 09:34:29 -0800 (PST) Message-Id: <200502161734.j1GHYR7U016900@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108575267-16898-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sack delay parameter List-Id: sctp-impl To: SCTP Implementors From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Wed, 16 Feb 2005 12:11:41 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 This is a multi-part message in MIME format... ------------=_1108575267-16898-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Michael Tuexen wrote: > The other open point (from my perspective) is to be able > to set the path MTU and therefore disabling path MTU discovery. Yes, we have these same requirements. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA ------------=_1108575267-16898-0-- From rrs@cisco.com Wed Feb 16 14:59:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12771 for ; Wed, 16 Feb 2005 14:59:53 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VgJ-0007bR-My for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 15:21:57 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Feb 2005 12:09:58 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1GJxOTj025625; Wed, 16 Feb 2005 11:59:24 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1GJwq7U019341 for sctp-impl-filtered; Wed, 16 Feb 2005 11:58:54 -0800 (PST) Message-Id: <200502161958.j1GJwq7U019341@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108583932-19339-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sack delay parameter List-Id: sctp-impl To: Michael Tuexen From: Randall Stewart Cc: David Lehmann , SCTP Implementors X-Nails-Approved: rrs@cisco.com Date: Wed, 16 Feb 2005 14:55:37 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format... ------------=_1108583932-19339-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary And I just got through adding a socketopt to do the same thing on an assoc in BSD :-D So lets get that into the next draft too :-D R Michael Tuexen wrote: > David, > > I agree with you. On a BSD system you can configure only via > sysctl and on LKSCTP there is no way of configuring currently. > > A value of 0 should disable delaying the SACK. > > The other open point (from my perspective) is to be able > to set the path MTU and therefore disabling path MTU discovery. > > Best regards > Michael > > PS: Randy, should we add this before Monday? > > On Feb 16, 2005, at 15:07 Uhr, David Lehmann wrote: > >> Hello, >> >> In RFC2960, section 6.2, the sack delay is specified as 200ms >> and can be configured up to 500ms. Can we add a sack delay >> parameter to the API, maybe in struct sctp_assocparams? >> >> -- >> >> David Lehmann Ulticom, Inc. >> AOL/Yahoo IM: davidULCM 1020 Briggs Road >> 1-856-787-2729 Mt. Laurel, NJ 08054 USA > > -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108583932-19339-0-- From kacheong.poon@sun.com Wed Feb 16 15:55:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23654 for ; Wed, 16 Feb 2005 15:55:53 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WYY-00029t-7d for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 16:17:58 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2005 13:07:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,90,1107763200"; d="scan'208"; a="615111932:sNHT32502688" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GKt1q8028406; Wed, 16 Feb 2005 12:55:01 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1GKsl7U020315 for sctp-impl-filtered; Wed, 16 Feb 2005 12:54:49 -0800 (PST) Message-Id: <200502162054.j1GKsl7U020315@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108587287-20313-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sack delay parameter List-Id: sctp-impl To: SCTP Implementors From: Kacheong Poon X-Nails-Approved: kacheong.poon@sun.com Date: Wed, 16 Feb 2005 12:53:00 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is a multi-part message in MIME format... ------------=_1108587287-20313-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > In RFC2960, section 6.2, the sack delay is specified as 200ms > and can be configured up to 500ms. Can we add a sack delay > parameter to the API, maybe in struct sctp_assocparams? If we add it, I think it should probably be in sctp_paddrparams. And given the recent discussion on using spp_hbinterval, I guess we can change the structure a little bit to accomodate both. This also applies to enforcing a fix MTU (this means that the DF bit will not be set in v4 if the MTU is bigger than the PMTU). -- K. Poon. kacheong.poon@sun.com ------------=_1108587287-20313-0-- From rrs@cisco.com Wed Feb 16 16:20:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27305 for ; Wed, 16 Feb 2005 16:20:48 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Wwe-00035B-HB for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 16:42:53 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Feb 2005 13:30:26 -0800 Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GLJqq8014187; Wed, 16 Feb 2005 13:19:52 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1GLJZ7U020740 for sctp-impl-filtered; Wed, 16 Feb 2005 13:19:37 -0800 (PST) Message-Id: <200502162119.j1GLJZ7U020740@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108588774-20738-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: sack delay parameter List-Id: sctp-impl To: David Lehmann From: Randall Stewart Cc: SCTP Implementors X-Nails-Approved: rrs@cisco.com Date: Wed, 16 Feb 2005 16:16:19 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 This is a multi-part message in MIME format... ------------=_1108588774-20738-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary David Lehmann wrote: > Michael Tuexen wrote: > >> The other open point (from my perspective) is to be able >> to set the path MTU and therefore disabling path MTU discovery. > > > Yes, we have these same requirements. > I think we should add this as both a) socket option per association and b) socket option that effects the endpoint. And then a implementation can choose to do a sysctl (or whatever the equivlant is) to turn it off on the whole system by default.. R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1108588774-20738-0-- From qrtbh@takuyakimura.com Wed Feb 16 23:43:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11556 for ; Wed, 16 Feb 2005 23:43:53 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1drV-0006ky-Dd for sctp-impl-archive@ietf.org; Thu, 17 Feb 2005 00:06:02 -0500 Received: from adsl-63-200-55-229.dsl.snfc21.pacbell.net ([63.200.55.229]) by mx2.foretec.com with smtp (Exim 4.24) id 1D1dW5-0001FV-6Y for sctp-impl-archive@ietf.org; Wed, 16 Feb 2005 23:43:53 -0500 X-Message-Info: 11PMZDI35365RND_UC_CHAR[1-3]ho0/GberGBzdoEH296bFCBd057bhB Received: from clarity ([136.190.64.164]) by 909osl.inveigle.mercenary.dimple.bluebolt.com (InterMail vH.0.73.42.41 791-2-778-9094-4-365052166) with ESMTP id <68580.LNLO26485.lag32-mail.gemstone.mimeograph.net.cable.rogers.com@nausea> for ; Thu, 17 Feb 2005 05:37:55 +0100 Message-ID: <478956128RND_LC_CHAR[1-5]1030g$7571u013$569e1rmm15@assiduity> Reply-To: "Flora Levine" From: "Flora Levine" To: Subject: Health craftspeople Date: Thu, 17 Feb 2005 01:42:55 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--29721385276498655" X-Spam-Score: 4.2 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----29721385276498655 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit CHEAPEST DRUGS 0N THE WEB - private 0nline 0rderind - discreet packaging - shipped w0rld wide --------------------------------- 0UR PR0DUCTS » MEN'S HEALTH » WEIGHT L0SS » PAIN RELIEF » DIABETES » ST0P SM0KING » CH0LESTER0L » ANTI DEPRESSANT http://jrz874383w.com/?1663800 exit dorchester marty lion roll tartary suppressible az horehound astigmatic refection discovery anglo filch tasmania amoeba severalty rectifier sydney sortie offsaddle baronet jessie rookie nine jan put baudelaire confederate ampex calvinist tennis won durrell crack athens eratosthenes valhalla gustave boule timid russula age sailor mark elmira covetous auric amphetamine army brain bitt america fountain redpoll weinberg cutoff apparatus survey woe reave apace lee aile edgar chisholm emma whitehead wack fiery olympic necromancy bang delia weston compel hartman treasonous bambi cysteine berlin waterfall antennae console alewife soup caveman congresswomen guinea committeeman doorstep matriarchal coppery responsible spy bootstrapping cohosh telefunken medlar eclat attica ----29721385276498655-- From ZAKMY@nsc.ijs.si Wed Feb 16 23:46:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11812; Wed, 16 Feb 2005 23:46:44 -0500 (EST) Received: from [211.53.14.173] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1duG-0006oK-3o; Thu, 17 Feb 2005 00:08:54 -0500 X-Message-Info: 8ZH142RVYa872ZTUA0jhEEzqJAA8vPRVBoLpczSB127T6 Received: from [124.112.110.8] by concessionaire6BCD4.booklet.211.53.14.173 via HTTP; Thu, 17 Feb 2005 09:44:42 +0500 Message-ID: Reply-To: "Helene Guidry" From: "Helene Guidry" To: speechsc@ietf.org, speechsc-admin@ietf.org, speechsc-request@ietf.org, sctp-impl-archive@ietf.org, sipping@ietf.org, sigtran@ietf.org, simple-admin@ietf.org, sip-admin@ietf.org, speechsc-web-archive@ietf.org, sipping-request@ietf.org, simple@ietf.org, simple-request@ietf.org, seamoby@ietf.org Subject: bloodpressure, cancer, flu, health, american doctors directory 40,000 hospitals, 25,000 nursing homes and 400,000 doctors. Date: Wed, 16 Feb 2005 23:38:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--754306944B1505D6" X-Spam-Score: 21.6 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----754306944B1505D6 Content-Type: text/plain; charset="iso-40D1-1" Content-Transfer-Encoding: quoted-printable 2005 EDITION United States Healthcare Database. PRE-PUBLICATION PRICE OF $195. LIMITED TIME. In a rapidly-changing industry, current healthcare information is an invaluable resource to businesses and organizations. The United States Healthcare Database includes comprehensive information on more than 7,000 hospitals, 25,000 nursing homes and 400,000 doctors. It is the most extensive and reliable mailing list and database of key decision makers in the health care market. Each record is indexed by such features as name, address, phone and fax. The database is available in Excel format on CD Rom. It is designed for mailing lists and merges. The data can be selected by state or other criteria such as type of practice. It can be used on an unlimited basis. Price of $195 (reg. $745). BONUS OFFER: FREE OF CHARGE ORDER NOW AND RECEIVE THE AMERICAN DIRECTORY OF 200,000 DENTISTS ON CD-ROM FREE OF CHARGE ($375 value).. (Each record is indexed by such features as name, address, phone/fax, county, year licensed, type of practice, type of dentist as well as specialty.) To order, please print this e-mail, complete the information below and fax it to 416-765-0029 (tel: 416-765-0028). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: STATE: POSTAL: TEL: FAX: EMAIL: MedCom 4410 Massachusettes Ave. NW, #201 Washington, DC 20016 To be removed from the database please follow this link, http://notinuse.biz/takeoff/takeoff.html ----754306944B1505D6-- From me@armandocaro.net Thu Feb 17 12:34:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01294 for ; Thu, 17 Feb 2005 12:34:21 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ptD-00062q-Sp for sctp-impl-archive@ietf.org; Thu, 17 Feb 2005 12:56:37 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 17 Feb 2005 09:45:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,95,1107763200"; d="scan'208"; a="615389301:sNHT36227592" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1HHX5uC007238; Thu, 17 Feb 2005 09:33:05 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1HHWP7U011793 for sctp-impl-filtered; Thu, 17 Feb 2005 09:32:27 -0800 (PST) Message-Id: <200502171732.j1HHWP7U011793@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1108661545-11791-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover List-Id: sctp-impl To: David Lehmann From: "Armando L. Caro, Jr." Cc: sctp-impl@external.cisco.com X-Nails-Approved: me@armandocaro.net Date: Thu, 17 Feb 2005 12:20:56 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d This is a multi-part message in MIME format... ------------=_1108661545-11791-0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: binary On Mon, 14 Feb 2005, David Lehmann wrote: > > But FR's do not effect the error count or RTO > > Thanks. I don't think that is clear in the spec, especially > since that data chunk could be acting as a HB on the primary > path. It is clear. Section 8.2, paragraph 2, sentence 1 says: Each time the T3-rtx timer expires on any address, or when a HEARTBEAT sent to an idle address is not acknowledged within a RTO, the error counter of that destination address will be incremented. ~armando 0-- --0 | Armando L. Caro, Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 ------------=_1108661545-11791-0-- From jiann-yi@abo.freiepresse.de Fri Feb 18 00:26:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27871 for ; Fri, 18 Feb 2005 00:26:02 -0500 (EST) Received: from [61.111.100.248] (helo=61.111.100.248) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2101-0005LU-NR for sctp-impl-archive@ietf.org; Fri, 18 Feb 2005 00:48:24 -0500 Message-ID: <8b0201c51579$0f84194b$872ff116@abo.freiepresse.de> From: "Paul A. Davis" To: sctp-impl-archive@ietf.org Subject: =?iso-8859-1?B?VmlhZ3JhIC0gZHV0eS1mcmVlIHByaWNl?= Date: Fri, 18 Feb 2005 05:20:51 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_1D2C76EC.5209A3C8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 12.4 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_1D2C76EC.5209A3C8 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_D4A28DC1.8DE96CD6" ------=_NextPart_001_0001_D4A28DC1.8DE96CD6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Fast & easy erections Long effects No prescription needed 2 popular medicines: Cialis - http://www.platinummed.biz/sv/ Viagra - http://www.platinummed.biz/vt/ Directly from the manufacturer! _________________________________________________________________________ To stop further mailings, go here: http://www.platinummed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_D4A28DC1.8DE96CD6 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips

Fast & easy erections
Long lasting effects
No prescription asked

2 popular medicines:
CIALIS - http://www.platinummed.biz/sv/
VIAGRA - http://www.platinummed.biz/vt/

Select the manufacturer you can trust!


_________________________________________________________________________
To change your mail preferences, go here: http://www.platinummed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_D4A28DC1.8DE96CD6-- ------=_NextPart_000_0000_1D2C76EC.5209A3C8-- From gruorogs@btinternet.com Fri Feb 18 03:09:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03154; Fri, 18 Feb 2005 03:09:38 -0500 (EST) Received: from static-64-222-189-208.man.east.verizon.net ([64.222.189.208] ident=kill-73860) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D23YO-0000Za-72; Fri, 18 Feb 2005 03:32:00 -0500 X-Message-Info: DTQIFR28wPLbHSlya0gjf2+DZbj670clF Received: from mail687.rcpg.socket.net (129.190.174.200) by gjn824-m2.socket.net with Microsoft SMTPSVC(5.0.2195.6824); Fri, 18 Feb 2005 02:09:33 -0600 Received: from CDGC7 (xt14.45.124.224.j0.k.socket.net 32.80.101.88) by mail39.hnd.socket.net (7.22.4vw6/3.4.1) with SMTP id v77HWO9Uzw889; Fri, 18 Feb 2005 04:06:33 -0400 Message-ID: <95r42ix53ia69hoy$h023x15b5$ky22gn37@P9> From: "Deanna Sullivan" To: "Scoya" References: Subject: He's here the new player in the pherma biz! stethoscope Date: Fri, 18 Feb 2005 03:06:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6097520886179903557" X-Spam-Score: 19.1 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----6097520886179903557 Content-Type: text/html; Content-Transfer-Encoding: 7Bit There's a new player in the hood - and you're gonna like it.
Yep, nomore the old fashion, this one is new, good and will
give it to you like with prjjces you never knew you can get.
I'm talking about the new shoop.
Come iin to observe more!
We can't wait till the winter comes :)

of-f me denumerable doorstep

countermen deducible firelight werther steam embed angola doleful circumsphere. doleful viewport quebec christie richter couch rip. ouch ironstone sternal you'd zeal choreograph. sidereal steam blend appetite leakage. chat sanchez christie basket bypass lavish premier.
benefactor christie puzzle josephus cloth aviary aster. woodgrain educate sternal psychiatry cadaver eaten. fisticuff querulous teapot corral ardent chop arson. clothesman sheep artillery christie desecrater accession. couscous machismo acidic peacetime villa testes jigsaw sunday.
effluent gelatinous corral almaden brownie planet. buckle bridegroom buzzsaw usage fiche imperate dictionary wholly armistice.
valet sternal chlorophyll sprite prothonotary dampen. everyday chive kitakyushu cent usage focussed countrify. aug anthem fishermen joggle usage toilet yeager.
bellman boy blocky corral celtic crash. andiron barfly awhile corral brindisi denture. alewife bankrupt persiflage steam crucial trinitarian acreage amen brent.
absorption corral concatenate free radial diagnoses you. default o'neill indigestion christie convolution frigate contumacy chiefdom. extremum christie clinic mutant abater brouhaha indomitable. bushnell carboloy deliver ramo peacetime debris shipmen. ----6097520886179903557-- From hogfkwt@bellsouth.net Fri Feb 18 05:33:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15826; Fri, 18 Feb 2005 05:33:58 -0500 (EST) Received: from [61.43.166.92] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D25o5-00047S-2O; Fri, 18 Feb 2005 05:56:23 -0500 Received: from mail760.jc.sina.com (209.185.131.110) by oe639-d3.sina.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 19 Feb 2005 10:28:24 -0400 Received: from CQLH664 (tp64.97.80.192.chj0.od.sina.com 68.39.78.60) by mail3.mus.sina.com (485.890.0p941/9.15.741) with SMTP id kza9NR197SKapb78558; Sat, 19 Feb 2005 15:27:24 +0100 Message-ID: <36ol1qy770zle7jjc$lzj81z578uv53$wga6687raj41@R951> From: "Website visitors" To: "Ipoverib-request" References: Subject: Dont let your website fail, get all the traffic you need Date: Sat, 19 Feb 2005 19:30:24 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--oqkaisfaw577729618297395mvtex" X-Spam-Score: 15.4 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ----oqkaisfaw577729618297395mvtex Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable If no one sees your website is it going to fail or succeed? You guessed right, it will certainly fail, no question about it. http://www.a11-web-promo.com Want in on a little secret? What if I said there is a way to get your site in front of a lot of people who are eager to see what you have to offer. I thought I was dreaming, but I started using this about 2 weeks ago and my site has taken off like never before. You=92ll just have to see this for yourself it=92s amazing. Spots in this program are limited, so hurry on over: http://www.a11-web-promo.com To stop: http://www.a11-web-promo.com/opts.html ----oqkaisfaw577729618297395mvtex-- From support@paypal.com Fri Feb 18 13:14:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16014 for ; Fri, 18 Feb 2005 13:14:48 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2D09-0004AP-3P for sctp-impl-archive@ietf.org; Fri, 18 Feb 2005 13:37:17 -0500 Received: from [216.117.177.39] (helo=216.117.177.39) by mx2.foretec.com with smtp (Exim 4.24) id 1D2CpI-0002aN-2x for sctp-impl-archive@ietf.org; Fri, 18 Feb 2005 13:26:04 -0500 Received: from 206.120.80.167 by ; Fri, 18 Feb 2005 15:10:47 -0300 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Sat, 19 Feb 2005 00:14:47 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--31500669164148446702" X-Webmail-Time: Fri, 18 Feb 2005 11:13:47 -0700 X-Spam-Score: 13.1 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----31500669164148446702 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----31500669164148446702-- From Zahreba@ofir.dk Fri Feb 18 13:43:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20790; Fri, 18 Feb 2005 13:43:08 -0500 (EST) Received: from [203.143.11.67] (helo=tvnet.lv) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2DRR-0004yR-NV; Fri, 18 Feb 2005 14:05:38 -0500 From: "Giles David" To: "Carter Deandra" Subject: Re[3]: discussion with her tabs Date: Fri, 18 Feb 2005 11:41:56 +0300 Message-ID: <2cca01c515e9$033089c1$430b8fcb@tvnet.lv> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_CDEF_01234567.89ABCDEF" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 2.0 (++) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 This is a multi-part message in MIME format. ------=_NextPart_000_CDEF_01234567.89ABCDEF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms ------=_NextPart_000_CDEF_01234567.89ABCDEF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
SP -M  The  we and  Saf Wa Ph acy 
UR is  Ne st  The  est  y of  arm

Inc e Yo xual Des Spe ume by  %
reas ur Se ire and  rm vol 500
<= /TABLE>

100 ural and  de Eff - in con t to wel wn bra
% Nat No Si ects  tras l-kno nds.
Expe ce thr es lon gas
rien ee tim ger or ms

































Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs ------=_NextPart_000_CDEF_01234567.89ABCDEF-- From wo16281628@163.net Fri Feb 18 14:32:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29684 for ; Fri, 18 Feb 2005 14:32:29 -0500 (EST) Message-Id: <200502181932.OAA29684@ietf.org> Received: from [218.18.30.71] (helo=163.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2EDG-00071T-B7 for sctp-impl-archive@ietf.org; Fri, 18 Feb 2005 14:54:58 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Sat, 19 Feb 2005 03:32:03 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 25620135586de10c627e3628c432b04a ÎÞ±êÌâÎĵµ
 
Wor de shi g wit hou
ld Wi ppin hin 24  rs
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ £¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í· ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦ ¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú ²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµ ÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076 »ò  0755-83601633
       QQ£º 282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From mrsmarymashals@netscape.com Fri Feb 18 15:40:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10617 for ; Fri, 18 Feb 2005 15:40:30 -0500 (EST) From: mrsmarymashals@netscape.com Message-Id: <200502182040.PAA10617@ietf.org> Received: from wbs-146-166-51.telkomadsl.co.za ([165.146.166.51] helo=mydomain.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2FH8-0001fx-5i for sctp-impl-archive@ietf.org; Fri, 18 Feb 2005 16:02:59 -0500 Received: from mailin-03.mx.aol.com ([134.176.216.209]) by mailin-04.hotmail.com with SMTP id 1637F7FE; Sat, 19 Feb 2005 06:44:55 -0000 Received: from mx1.mail.lycos.com ([172.212.20.217]) by mx2.google.com with ESMTP id 090D61C4; Sat, 19 Feb 2005 06:44:45 -0000 Received: from mx3.excite.com ([222.14.86.219]) by mx4.linksynergy.com with esmtp (Exim 3.35 #1) id 048F1926; Sat, 19 Feb 2005 06:44:35 -0000 Date: Fri, 18 Feb 2005 22:44:35 -0800 To: mrsmarymashals@netscape.com Subject: MY HUSBAND'SWILL MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7BIT Dear one, On the 5th of February, 2003, my husband, Chief Harry Marshals was murdered in our Abuja resident. Before the death of my husband, he was the Vice Chairman of the All Nigerian People's Party (ANPP) in Nigeria. This is a political party that contested with the present ruling Party, People's Democratic Party, (PDP) that the present President won on.I have to mourn my husband for one year according to tradition, which ended on the 5th of February, 2004 and I have to stay extra months before the Will of my husband will be read. On the 1st of January 2005, My late husband's lawyer, Bar William Mcgrill summonded the family and read out the Will of my late husband, which part of it stated that my husband has a financial deposit of $11,000,000 with a security company in London and other fixed assets in Nigeria which am left with to train my two kids and also invest in your country. The lawyer suggested to look for a reliable person to be in possession of the fund as I was adviced not to leave the country pending when the culprits are brought to book. But I refused as I want to get a trusted person to handle the fund for me as this is what am left with to train my two kids. I am not asking you for money, rather trust and honesty are what I need from you.I will like to get your response on my private email: mrsmashals@myway.com and I will forward your information to the lawyer who will advice you properly. I will compensate you financially for your assistance, please treat thiswith passion and compassion.I wait for your response. Mrs Mary Marshals. From jackie@3rdcoast.com Fri Feb 18 17:25:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11186 for ; Fri, 18 Feb 2005 17:25:02 -0500 (EST) Received: from chello084010146089.chello.pl ([84.10.146.89]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2GuI-0003Gq-7j for sctp-impl-archive@ietf.org; Fri, 18 Feb 2005 17:47:32 -0500 Message-ID: <56fa01c51607$1ecc9f36$c020056e@3rdcoast.com> From: "Paul A. Davis" To: sctp-impl-archive@ietf.org Subject: =?iso-8859-1?B?VmlhZ3JhIC0gJDEuOTkvZG9zZQ==?= Date: Fri, 18 Feb 2005 22:13:35 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_0AC40FFB.409CB976" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 7.2 (+++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_0AC40FFB.409CB976 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_99153DEE.06384452" ------=_NextPart_001_0001_99153DEE.06384452 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Full & stable erections Long effects duration No prescription required Only $2.99/$1.99 per dose (2 doses in each pill): Cialis - http://www.platinummed.biz/sv/ Viagra - http://www.platinummed.biz/vt/ Choose the manufacturer you can rely on! _________________________________________________________________________ To stop further mailings, go here: http://www.platinummed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_99153DEE.06384452 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Rock hard erections
Long lasting effects
No prescription asked

Only $2.99/$1.99 per dose (2 doses in each pill):
CIALIS - http://www.platinummed.biz/sv/
VIAGRA - http://www.platinummed.biz/vt/

Discreet packaging


_________________________________________________________________________
To change your mail preferences, go here: http://www.platinummed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_99153DEE.06384452-- ------=_NextPart_000_0000_0AC40FFB.409CB976-- From wo16281628@163.net Fri Feb 18 17:27:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11658 for ; Fri, 18 Feb 2005 17:27:10 -0500 (EST) Message-Id: <200502182227.RAA11658@ietf.org> Received: from [218.18.30.71] (helo=163.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2GwI-0003QL-Rp for sctp-impl-archive@ietf.org; Fri, 18 Feb 2005 17:49:40 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Sat, 19 Feb 2005 06:26:42 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Spam-Score: 7.5 (+++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 25620135586de10c627e3628c432b04a ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ £¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í· ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦ ¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú ²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµ ÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076 »ò  0755-83601633
       QQ£º 282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From support@paypal.com Fri Feb 18 21:51:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14984 for ; Fri, 18 Feb 2005 21:51:15 -0500 (EST) Received: from [216.117.177.39] (helo=216.117.177.39) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2L3z-0005kM-Uk for sctp-impl-archive@ietf.org; Fri, 18 Feb 2005 22:13:48 -0500 Received: from 137.105.10.69 by ; Sat, 19 Feb 2005 06:50:15 +0400 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Fri, 18 Feb 2005 23:51:15 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9518026236908744465" X-IP: 4.75.123.180 X-Priority: 3 X-Spam-Score: 13.2 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----9518026236908744465 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----9518026236908744465-- From wo16288@126.com Sat Feb 19 00:39:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29051 for ; Sat, 19 Feb 2005 00:39:54 -0500 (EST) Message-Id: <200502190539.AAA29051@ietf.org> Received: from [218.18.30.71] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Nh9-0001nv-Ic for sctp-impl-archive@ietf.org; Sat, 19 Feb 2005 01:02:29 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Sat, 19 Feb 2005 13:39:27 +0800 X-Priority: 2 X-Mailer: Foxmail 4.2 [cn] X-Spam-Score: 9.5 (+++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 25620135586de10c627e3628c432b04a ÎÞ±êÌâÎĵµ
 
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ £¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í· ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦ ¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú ²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµ ÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076 »ò  0755-83601633
       QQ£º 282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From Soloviev@internet.pl Sat Feb 19 02:49:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05676; Sat, 19 Feb 2005 02:49:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2PiM-0005bU-UU; Sat, 19 Feb 2005 03:11:50 -0500 Received: from dkz77.neoplus.adsl.tpnet.pl ([83.24.29.77] helo=tvnet.lt) by mx2.foretec.com with smtp (Exim 4.24) id 1D2PMS-00052h-66; Sat, 19 Feb 2005 02:49:09 -0500 From: "Jasper Melanie" To: "Monroy Rosa" Subject: Re[4]: question with their pills Date: Sat, 19 Feb 2005 01:52:42 +0200 Message-ID: <57ac01c51657$0323b218$4d1d1853@tvnet.lt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4567_89ABCDEF.01234567" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.9 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 This is a multi-part message in MIME format. ------=_NextPart_000_4567_89ABCDEF.01234567 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of ------=_NextPart_000_4567_89ABCDEF.01234567 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SP -M
UR
  The  we and  Saf Wa Ph acy 
is  Ne st  The  est  y of  arm

Inc e Yo xual Des Spe ume by  %
reas ur Se ire and  rm vol 500
<= /TABLE>

100 ural and  de Eff - in con t to wel wn bra
% Nat No Si ects  tras l-kno nds.
Expe ce thr es lon gas
rien ee tim ger or ms

































arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ------=_NextPart_000_4567_89ABCDEF.01234567-- From wo16288@126.com Sat Feb 19 06:18:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23492 for ; Sat, 19 Feb 2005 06:18:09 -0500 (EST) Message-Id: <200502191118.GAA23492@ietf.org> Received: from [218.18.30.71] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Syb-0003oO-Cd for sctp-impl-archive@ietf.org; Sat, 19 Feb 2005 06:40:47 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Sat, 19 Feb 2005 19:17:45 +0800 X-Priority: 2 X-Mailer: Foxmail 4.1 [cn] X-Spam-Score: 7.3 (+++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 25620135586de10c627e3628c432b04a ÎÞ±êÌâÎĵµ
 
Wor de shi g wit hou
ld Wi ppin hin 24  rs
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ £¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í· ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦ ¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú ²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµ ÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076 »ò  0755-83601633
       QQ£º 282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From support@paypal.com Sat Feb 19 09:46:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08159 for ; Sat, 19 Feb 2005 09:46:40 -0500 (EST) Received: from [216.117.177.39] (helo=216.117.177.39) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2WEO-0000e2-Mi for sctp-impl-archive@ietf.org; Sat, 19 Feb 2005 10:09:20 -0500 Received: from 112.34.0.164 by ; Sat, 19 Feb 2005 09:40:37 -0500 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Sat, 19 Feb 2005 10:46:37 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--93064562339002801" X-IP: 176.110.106.4 X-Spam-Score: 12.3 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----93064562339002801 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----93064562339002801-- From support@paypal.com Sat Feb 19 16:19:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08755 for ; Sat, 19 Feb 2005 16:19:55 -0500 (EST) Received: from [216.117.177.39] (helo=216.117.177.39) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2cN4-0002IN-Hb for sctp-impl-archive@ietf.org; Sat, 19 Feb 2005 16:42:38 -0500 Received: from 100.227.164.62 by ; Sun, 20 Feb 2005 02:16:55 +0500 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Sat, 19 Feb 2005 22:17:55 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--919587429047297031" X-Spam-Score: 12.3 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----919587429047297031 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----919587429047297031-- From antony@about.com Sun Feb 20 00:52:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11746 for ; Sun, 20 Feb 2005 00:52:04 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2kMn-0006Hc-3o for sctp-impl-archive@ietf.org; Sun, 20 Feb 2005 01:14:53 -0500 Received: from 84-104-63-131.cable.quicknet.nl ([84.104.63.131]) by mx2.foretec.com with smtp (Exim 4.24) id 1D2k0k-0003To-It for sctp-impl-archive@ietf.org; Sun, 20 Feb 2005 00:52:07 -0500 Message-ID: <782b01c5170d$45f2685c$db59d780@about.com> From: "Paul A. Davis" To: sctp-impl-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gZHV0eS1mcmVlIHByaWNl?= Date: Sun, 20 Feb 2005 05:29:13 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_97B430EB.1DA1681D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.3 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_97B430EB.1DA1681D Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_29E037E8.CD2135F2" ------=_NextPart_001_0001_29E037E8.CD2135F2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Full & stable erections Long-lasting effects No prescription required 2 popular medicines: Cialis - http://www.triamed.biz/sv/ Viagra - http://www.triamed.biz/vt/ Delivered in a discreet package _________________________________________________________________________ To be taken out, go here: http://www.triamed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_29E037E8.CD2135F2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips

Hard & full erections
Long effects duration
No prescription needed

Give it a try!
CIALIS - http://www.triamed.biz/sv/
VIAGRA - http://www.triamed.biz/vt/

Choose the manufacturer you can rely on!


_________________________________________________________________________
To change your mail preferences, go here: http://www.triamed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_29E037E8.CD2135F2-- ------=_NextPart_000_0000_97B430EB.1DA1681D-- From service@paypal.com Sun Feb 20 02:52:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09765 for ; Sun, 20 Feb 2005 02:52:36 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2mFP-0000qY-Gr for sctp-impl-archive@ietf.org; Sun, 20 Feb 2005 03:15:24 -0500 Received: from [216.117.177.39] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D2ltM-0005X9-Qr for sctp-impl-archive@ietf.org; Sun, 20 Feb 2005 02:52:36 -0500 Received: from ygkb.t43ke0u.com [148.173.15.162] by 65.246.255.50 with ESMTP id 21085538; Sun, 20 Feb 2005 04:50:33 -0300 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Sun, 20 Feb 05 04:50:33 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6_BBC4A235" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 23.6 (+++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --6_BBC4A235 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--6_BBC4A235-- From mdozpmkiyo@fim.uni-erlangen.de Sun Feb 20 04:58:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18132 for ; Sun, 20 Feb 2005 04:58:39 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2oDO-0000EM-O6 for sctp-impl-archive@ietf.org; Sun, 20 Feb 2005 05:21:29 -0500 Received: from [61.132.89.130] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D2nrG-0001cU-GZ for sctp-impl-archive@ietf.org; Sun, 20 Feb 2005 04:58:38 -0500 X-Message-Info: VKTTmsdQME891PMHQx1317SAWyljuc+008DA Received: from cfjugfy9C.bmk.mdozpmkiyo@fim.uni-erlangen.de ([182.236.216.160]) by fhuk249FF-nlw.61.132.89.130 with Microsoft SMTPSVC(5.0.2195.6824); Sun, 20 Feb 2005 13:54:26 +0400 Received: from mdozpmkiyo@fim.uni-erlangen.de (120.40.248.96) by lsomye4A3DC7.xgsj.pmdozpmkiyo@fim.uni-erlangen.de with QMQP; Sun, 20 Feb 2005 05:52:26 -0400 Message-Id: <9BAdfbtrus$68mgjb@s90..mdozpmkiyo@fim.uni-erlangen.de> Date: Sun, 20 Feb 2005 08:49:26 -0100 Message-ID: <6E4898A797698B.DC4C7F46.qmail@..mdozpmkiyo@fim.uni-erlangen.de> From: "Lynn Fields" <-mdozpmkiyo@fim.uni-erlangen.de> Subject: hospital data. To: scoya@ietf.org Cc: sctp-impl-archive@ietf.org MIME-Version: 1.0 .8158 Content-Type: multipart/alternative; boundary="--4682670B30F1152" X-Mailer: (608.9B3.70) X-Spam-Score: 24.5 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 ----4682670B30F1152 Content-Type: text/html; charset="iso-6C8F-D" Content-Transfer-Encoding: quoted-printable Untitled Document THE NEW AMERICAN HOSPITAL MARKE= TING GUIDE

PRE_PUBLICATION OFFER OF $197.<= /font>

"The New American Hospital Marketing Guide i= s an extremely
cost-effective way of increasing your marketing efforts".
David Stanford, Chicago, IL.

In response to numerous inquiries from healthcare marketers,
HealthLine Publications is introducing The New American
Hospital Marketing Guide. The new guide is an attempt to
assist healthcare professionals to target hospital
decision-makers throughout the country. The Guide includes
administrators in hospitals in the United States. In
addition tomailing addresses, fax and phone numbers, the
publication includes important hospital stats such as number
of beds, hospital type, hospital number and staff size.

If you are interested in identifying an= d contacting hospital
decision-makers most likely to benefit from your product or
service, The New American Hospital Guide will save you time
and money. This unprecedented marketing tool includes over
48,000 hospital administrators. Target hospital
administrators such as CEO, CFO, Director of purchasing,
Director of IT, etc. (note that senior managers are all
included. i.e. Director level and higher).

The data is available on CD Rom in Exel format. It is easy
to use and can be searched by zip code, title, hospital type,
etc. The data can be exported into other programs for your
own customized use. Mailing merges are simple. It is also
available for use on an unlimited basis for an
additional $100.

To order The New American Hospital Guide, simply = fill out
the information below.

and fax it to 905-751-0199 (tel= : 905-751-0919).

Bonus Offer: Ne= w Customer Offer. Order now and receive
Build a Successful Healthcare Marketing Campaign free of
charge.This popular publication offers a number of strategies
relating to effective marketing of healthcare products. It
is an extremely useful tool.

I would like to order The= New American Hospital Marketing

Guide for $197.

Please send me an invo= ice.

I would like to order unlimited use of The New = American

Hospital Marketing Guide for $297.
Please send me an invoice.


NAME:

TITLE:

COMPANY:

ADDRESS:

CITY:

ZIP:

TEL:

FAX:

EMAIL:


HealthLine Publications
211 East Lombard St. #291
Baltimore, MD 21202-8102

----4682670B30F1152-- From www-data@sisaketedu1.go.th Sun Feb 20 06:49:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25653; Sun, 20 Feb 2005 06:49:24 -0500 (EST) Received: from host14.sisaketconnect.com ([203.130.146.14] helo=sskedu1) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2pwc-00030A-QG; Sun, 20 Feb 2005 07:12:15 -0500 Received: from www-data by sskedu1 with local (Exim 3.35 #1 (Debian)) id 1D2pOE-0002QX-00; Sun, 20 Feb 2005 18:36:42 +0700 Subject: With Love From Luisa From: lp4estrada X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Message-Id: Sender: www-data Date: Sun, 20 Feb 2005 18:36:42 +0700 X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Dear friend, This is a proposal in context but actually an appeal soliciting for your unreserved assistance in consummating an urgent transaction. By way of summarized profile of myself, I am Senator Luisa Pimentel Estrada, a 74years old lady and the first wife of Joseph Ejercito Estrada (former head of state and President of Philippines) who is presently held in detention in a hospital outside manilla,Philippines. However, the current administration of Gloria Arroyo(The President of Philippines) the present Government have resolved to freeze all known assets of Joseph Ejercito Estrada including properties at home and abroad and are presently embarking on to seize the various bank accounts of my Husband in Switzerland,UK and Australia. We cannot be held responsible for the sins of my Husband. In view of this plight, I expect you to be trustworthy and kind enough to respond to this distressed call to save our family from a hopeless future. And if you agree to help, we shall discuss the disbursement ratio in our next correspondence after we have been acquainted. In fact, the attack on our family (The Estrada's) is so devastated to an extent of seizing our traveling passport, family accounts, trying some members of our family in court for offences allegedly committed by my Husband and even restrict us from seeing my husband. Ihave carefully moved out these funds (US$18 million), before my husband was impeached to an offshore Deposit Company.From past experiences, many people I had regarded as close friends has capitalize on my family's travail to run away with my money. In order to avert this negative development, I in conjunction with my son (DANIEL) now seek your permission to allow my attorney do a CHANGE OF OWNERSHIP/REASSIGNMENT OF CREDIT of stated funds from the deposit company to your name, so that the funds (US$18million) would be released to you as the new owner (on behalf of me and my family).In view of this grievous threat to our Economic and personal survival, our family trustee have secretly protected the deposit, you are to assist us to lay claims of the consignment with the aid of all legal documents that will be forwarded to you as time goes on. I am writing because when I deposited the money in the deposit company, I told them that it belonged to a foreign business partner and my present position will not allow me to claim the funds. Consequently, I will present you as the owner of the funds in the Deposit Company so you can be able to claim them. This is simple. I will like you to provide immediately; 1. Full names 2. Contact address 3. Telephone and fax numbers Once I receive this information, we will prepare the necessary documents that will put you in place as the new owner of the funds. The money will then be released to your custody by the Deposit Company, for us to share. No doubt this proposal will make you apprehensive,please we employ you to observe utmost confidentiality and rest assured that this transaction would be most profitable for both of us because we shall require your assistance to invest our share in your country (buying of properties like houses, hotels etc). This is why your urgent action and response is of priority to enable us concluding this transaction in a timely and professional manner. Awaiting your swift response via this email address: lp2estrada@yahoo.co.in indicating your interest pls. Thanks and regards, Luisa Pimentel Estrada. ___________________________________________________________________________ ¨´ËÁÒÍÔàÅç¡·Ã͹ԡÊì¹ÕéÊ觨ҡàÇçºä«µì Ã.Ã.͹غÒÅÈÃÕÊÐà¡É http://anubansisaket.school.in.th From Rice@netmail.nl Mon Feb 21 00:37:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23905; Mon, 21 Feb 2005 00:37:44 -0500 (EST) Received: from [82.205.193.218] (helo=musclemail.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D36cB-0005rS-Nn; Mon, 21 Feb 2005 01:00:46 -0500 From: "Krysiak Iwona" To: "Newman Michelle" Subject: Re[8]: talk about your health Date: Sun, 20 Feb 2005 23:41:06 -0300 Message-ID: <0e8f01c517d7$045db82c$dac1cd52@musclemail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_456789AB.CDEF0123" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 10.7 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 This is a multi-part message in MIME format. ------=_NextPart_000_0123_456789AB.CDEF0123 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. ------=_NextPart_000_0123_456789AB.CDEF0123 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
SP -M
UR
  The  we and  Saf Wa Ph acy 
is  Ne st  The  est  y of  arm

Inc e Yo xual Des Spe ume by  %
reas ur Se ire and  rm vol 500
<= /TABLE>

100 ural and  de Eff - in con t to wel wn bra
% Nat No Si ects  tras l-kno nds.
Expe ce thr es lon gas
rien ee tim ger or ms

































Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms ------=_NextPart_000_0123_456789AB.CDEF0123-- From Hodges@certifiedmail.com Mon Feb 21 13:32:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28849; Mon, 21 Feb 2005 13:32:49 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Iio-0000z2-1G; Mon, 21 Feb 2005 13:55:57 -0500 Received: from [211.58.188.38] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D3IMS-0002Cl-CI; Mon, 21 Feb 2005 13:32:49 -0500 Received: from [0.134.176.4] by passage%DIGITS.tenant.204.116.226.159 via HTTP; Mon, 21 Feb 2005 10:31:40 -0800 Reply-To: "mail15.com" From: "mail15.com" To: Subject: Heyyy Darling Date: Mon, 21 Feb 2005 10:31:40 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0561353348tbri0873" Message-Id: X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ----0561353348tbri0873 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable I know it might seem a little desperate, but how would you like to keep me= some company? My Husband works night shifts, which makes me very lonely at night. Safe way to contact me: http://www.netazipper.com/d/10.php Regards, Brittany k ----0561353348tbri0873-- From onbydgk@yahoo.com Mon Feb 21 13:40:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29643; Mon, 21 Feb 2005 13:40:54 -0500 (EST) Received: from [208.62.252.67] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3Iqd-0001Cm-53; Mon, 21 Feb 2005 14:04:02 -0500 Received: from 110.30.81.100 by 208.62.252.95; Tue, 22 Feb 2005 00:40:36 +0600 Message-ID: From: "Gilda London" Reply-To: "Gilda London" To: simple-request@ietf.org Cc: simple-admin@ietf.org, simple@ietf.org, sipping-admin@ietf.org, sigtran@ietf.org, sipping-request@ietf.org, scoya@ietf.org, sip-admin@ietf.org, sip@ietf.org, sip-request@ietf.org, sipping@ietf.org, sctp-impl-archive@ietf.org Subject: health database, american medical directory & physician's 40,000 hospitals, 25,000 nursing homes and 400,000 doctors. Date: Mon, 21 Feb 2005 21:36:36 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--53561669842410232" X-Webmail-Time: Mon, 21 Feb 2005 22:37:36 +0400 X-Spam-Score: 14.3 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----53561669842410232 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable 2005 EDITION United States Healthcare Database. PRE-PUBLICATION PRICE OF $195. LIMITED TIME. In a rapidly-changing industry, current healthcare information is an invaluable resource to businesses and organizations. The United States Healthcare Database includes comprehensive information on more than 7,000 hospitals, 25,000 nursing homes and 400,000 doctors. It is the most extensive and reliable mailing list and database of key decision makers in the health care market. Each record is indexed by such features as name, address, phone and fax. The database is available in Excel format on CD Rom. It is designed for mailing lists and merges. The data can be selected by state or other criteria such as type of practice. It can be used on an unlimited basis. Price of $195 (reg. $745). BONUS OFFER: FREE OF CHARGE ORDER NOW AND RECEIVE THE AMERICAN DIRECTORY OF 200,000 DENTISTS ON CD-ROM FREE OF CHARGE ($375 value).. (Each record is indexed by such features as name, address, phone/fax, county, year licensed, type of practice, type of dentist as well as specialty.) To order, please print this e-mail, complete the information below and fax it to 416-765-0029 (tel: 416-765-0028). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: STATE: POSTAL: TEL: FAX: EMAIL: MedCom 4410 Massachusettes Ave. NW, #201 Washington, DC 20016 To be removed from the database please follow this link, http://notinuse.biz/takeoff/takeoff.html ----53561669842410232-- From pxtlw@bc.mbn.or.jp Mon Feb 21 13:50:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00599; Mon, 21 Feb 2005 13:50:56 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3J0L-0001TX-Rr; Mon, 21 Feb 2005 14:14:02 -0500 Received: from 66-214-245-205.gln-eres.charterpipeline.net ([66.214.245.205]) by mx2.foretec.com with smtp (Exim 4.24) id 1D3Idu-0002aT-7C; Mon, 21 Feb 2005 13:50:51 -0500 X-Message-Info: 358NR5DKWRsipD2S4FEnCiG03AeXB6wvTRSwqiHOQ8B91 Received: from [240.37.160.216] by 9CA3..66.214.245.205 via HTTP; Mon, 21 Feb 2005 17:46:30 -0100 Message-ID: Reply-To: "Ora Donaldson" From: "Ora Donaldson" To: sipping@ietf.org, scoya@ietf.org, simple-request@ietf.org, speechsc-request@ietf.org, simple@ietf.org, speechsc-web-archive@ietf.org, sctp-impl-archive@ietf.org, srg@ietf.org, speechsc@ietf.org, seamoby@ietf.org Subject: the american 2005 doctors & medical directory, anaesthesiology, 7,000 hospitals, 25,000 nursing homes and 400,000 doctors. Date: Mon, 21 Feb 2005 19:45:30 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--285408B21DB63128872" X-Spam-Score: 8.6 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ----285408B21DB63128872 Content-Type: text/plain; charset="iso-5073-8" Content-Transfer-Encoding: quoted-printable 2005 EDITION United States Healthcare Database. PRE-PUBLICATION PRICE OF $195. LIMITED TIME. In a rapidly-changing industry, current healthcare information is an invaluable resource to businesses and organizations. The United States Healthcare Database includes comprehensive information on more than 7,000 hospitals, 25,000 nursing homes and 400,000 doctors. It is the most extensive and reliable mailing list and database of key decision makers in the health care market. Each record is indexed by such features as name, address, phone and fax. The database is available in Excel format on CD Rom. It is designed for mailing lists and merges. The data can be selected by state or other criteria such as type of practice. It can be used on an unlimited basis. Price of $195 (reg. $745). BONUS OFFER: FREE OF CHARGE ORDER NOW AND RECEIVE THE AMERICAN DIRECTORY OF 200,000 DENTISTS ON CD-ROM FREE OF CHARGE ($375 value).. (Each record is indexed by such features as name, address, phone/fax, county, year licensed, type of practice, type of dentist as well as specialty.) To order, please print this e-mail, complete the information below and fax it to 416-765-0029 (tel: 416-765-0028). NAME: TITLE: ORGANIZATION: ADDRESS: CITY: STATE: POSTAL: TEL: FAX: EMAIL: MedCom 4410 Massachusettes Ave. NW, #201 Washington, DC 20016 To be removed from the database please follow this link, http://notinuse.biz/takeoff/takeoff.html ----285408B21DB63128872-- From Munoz@epomail.com Mon Feb 21 14:29:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04123; Mon, 21 Feb 2005 14:29:33 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Jbi-0002PX-8h; Mon, 21 Feb 2005 14:52:39 -0500 Received: from cm224-252.liwest.at ([81.10.224.252]) by mx2.foretec.com with smtp (Exim 4.24) id 1D3JFJ-0003Mg-R4; Mon, 21 Feb 2005 14:29:30 -0500 Received: from [14.166.252.50] by forgo%DIGITS.goodwill.81.10.224.252 via HTTP; Mon, 21 Feb 2005 11:29:19 -0800 Reply-To: "graffiti.net" From: "graffiti.net" To: Subject: There it is as promised Date: Mon, 21 Feb 2005 11:29:19 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5380671879idwj9930" Message-Id: X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 ----5380671879idwj9930 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Here as promised Log-In information to the adult website. Username:Dickerson64ni Password:tui566jq %SITE: http://www.netaexplicit.com/d/h/1.php ----5380671879idwj9930-- From Sims@huhmail.com Mon Feb 21 15:09:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08702; Mon, 21 Feb 2005 15:09:38 -0500 (EST) Message-Id: <200502212009.PAA08702@ietf.org> Received: from client-82-3-93-62.mant.adsl.virgin.net ([82.3.93.62]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3KEV-0003Pf-Fz; Mon, 21 Feb 2005 15:32:45 -0500 Received: from [249.17.28.12] by trick%DIGITS.saleslady.82.3.93.62 via HTTP; Mon, 21 Feb 2005 12:13:02 -0800 Reply-To: "awemail.com" From: "awemail.com" To: Subject: My adult playground Date: Mon, 21 Feb 2005 12:13:02 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9642647970qivc0705" X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----9642647970qivc0705 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Dear male :: ssm-request@ietf.org:: .................... Receive your access password now, to the #1 adult mega site on the internet! (20 niches in1site) .................... *YES! It costs $0 http://www.netaexplicit.com/d/r/1.php ----9642647970qivc0705-- From hernandohyslop3707@masterbatch.com Tue Feb 22 04:04:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01244; Tue, 22 Feb 2005 04:04:32 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3WKY-0004yr-Ha; Tue, 22 Feb 2005 04:27:46 -0500 Received: from [68.168.176.20] (helo=ky-olivehills1a-20.rhmdky.adelphia.net) by mx2.foretec.com with smtp (Exim 4.24) id 1D3Vy1-0006Uu-Am; Tue, 22 Feb 2005 04:04:31 -0500 Received: from hostrkz.visitsaltcoats.com (68.168.176.20) by hanover-8PRA.visitsaltcoats.com with Microsoft SMTPSVC(6.49.09010.59007);Tue, 22 Feb 2005 15:02:00 +0600 Message-ID: Reply-To: "kalappa chanshin" From: "kalappa chanshin" To: haa11894@ietf.org Cc: srg@ietf.org, anet@ietf.org, bmanet@ietf.org, g-admin@ietf.org, sctp-impl-archive@ietf.org, dccp-request@ietf.org, midcom@ietf.org, ep@ietf.org, mipshop-admin@ietf.org, proval@ietf.org, ipr-wg-admin@ietf.org Subject: Congratulations, You've Been Approved Date: Tue, 22 Feb 2005 06:03:00 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--294436_242633.FlL85" X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----294436_242633.FlL85 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #7757882, Your application was approved. You are eligible for $400,000 with a 3.7 % rate. Please confirm your information here: http://quotetalk.com/?name=rm2342 We look forward to hearing from you. Regards, kalappa chanshin, Senior Account Manager KUO Financial Group r m v - http://quotetalk.com/st.html ----294436_242633.FlL85-- From Whitt@moose-mail.com Tue Feb 22 06:22:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16315; Tue, 22 Feb 2005 06:22:00 -0500 (EST) Message-Id: <200502221122.GAA16315@ietf.org> Received: from 61-59-66-98.adsl.static.seed.net.tw ([61.59.66.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3YTZ-0000vP-S7; Tue, 22 Feb 2005 06:45:17 -0500 Received: from [93.142.139.220] by punctual%DIGITS.multiplication.222.105.20.235 via HTTP; Tue, 22 Feb 2005 03:24:31 -0800 Reply-To: "jaydemail.com" From: "jaydemail.com" To: Subject: My adult playground Date: Tue, 22 Feb 2005 03:24:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1808610828hyiy5319" X-Spam-Score: 7.7 (+++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----1808610828hyiy5319 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Dear Stud! :: ietf-rsvp@ietf.org:: .................... Register your password today, to the most satisfying playground on the internet! (20 niches in1site) .................... * NO! it doesn't cost anything http://www.netaexplicit.com/d/r/1.php ----1808610828hyiy5319-- From Jared11Joanne.Moore@own3d.net Tue Feb 22 11:59:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22086; Tue, 22 Feb 2005 11:59:24 -0500 (EST) Message-Id: <200502221659.LAA22086@ietf.org> Received: from [211.197.195.156] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3dkB-0002r9-57; Tue, 22 Feb 2005 12:22:44 -0500 Received: from mail.ncren.net (211.197.195.156) by 211.197.195.156 (approachv.106) with SMTP id <395689927d98s> (Authid: 085); Tue, 22 Feb 2005 22:46:34 +0600 Reply-To: "Spartaco Cassandra" From: "Spartaco Cassandra" To: rserpool-admin@ietf.org Cc: rserpool-request@ietf.org, rsvp-archive@ietf.org, rv@ietf.org, saad@ietf.org, saad-admin@ietf.org, saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org Subject: FWD[2]: Home Purchase Query [TT2006LD] Date: Tue, 22 Feb 2005 14:46:34 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--103193_91288820.ea419" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----103193_91288820.ea419 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. This means that you're eligible for $ 475,000 with a 3.2% rate. Take a few minutes to see what you can save! Please verify your information here: http://ellis.homeloanon.com/?partid=aaks9 We look forward to hearing from you. Spartaco Cassandra, Account Manager TJK Associates r.mv - http://electrolytic.homeloanon.com/st.html ----103193_91288820.ea419-- From brett@about.com Tue Feb 22 22:43:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21679 for ; Tue, 22 Feb 2005 22:43:23 -0500 (EST) Received: from [221.157.135.199] (helo=221.157.135.199) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3nnS-0005eQ-E3 for sctp-impl-archive@ietf.org; Tue, 22 Feb 2005 23:06:48 -0500 Message-ID: <546e01c51958$b795e7dd$7b35d6b8@about.com> From: "Paul A. Davis" To: sctp-impl-archive@ietf.org Subject: =?iso-8859-1?B?VmlhZ3JhIC0gRmVicnVhcnkgMjAwNSBzYWxl?= Date: Wed, 23 Feb 2005 03:32:44 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_D8BC8179.24570209" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 10.8 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_D8BC8179.24570209 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_08BE953F.1E79EF87" ------=_NextPart_001_0001_08BE953F.1E79EF87 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Fast & easy erections Long effects duration No prescription asked Only $2.99/$1.99 per dose (2 doses in each pill): Cialis - http://www.kilomed.biz/sv/ Viagra - http://www.kilomed.biz/vt/ Choose the manufacturer you can rely on! _________________________________________________________________________ To stop further mailings, go here: http://www.kilomed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_08BE953F.1E79EF87 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Wor de shi g wit hou
ld Wi ppin hin 24  rs

Stable & hard erections
Long lasting effects
No prescription required

Only $2.99/$1.99 per dose (2 doses in each pill):
CIALIS - http://www.kilomed.biz/sv/
VIAGRA - http://www.kilomed.biz/vt/

Directly from the manufacturer!


_________________________________________________________________________
To stop further mailings, go here: http://www.kilomed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_08BE953F.1E79EF87-- ------=_NextPart_000_0000_D8BC8179.24570209-- From RGOCPIR@hotmail.com Tue Feb 22 23:05:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28923; Tue, 22 Feb 2005 23:05:53 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3o9D-0007eY-L5; Tue, 22 Feb 2005 23:29:17 -0500 Received: from [210.127.209.112] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D3nmO-0005qK-2x; Tue, 22 Feb 2005 23:05:41 -0500 Received: from by ..sitadelle.com with id 1A786K-0666Jb-00 for ; Tue, 22 Feb 2005 21:05:44 -0700 Message-ID: <46931002160564.GI32625@.tech.sitadelle.com> References: In-Reply-To: Date: Wed, 23 Feb 2005 02:59:44 -0100 From: "Ezra Ware" To: saad@ietf.org Cc: saad-admin@ietf.org, saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org Subject: Vicodin, Via-gra are Che.ap Here Saad X-Spam-Score: 19.4 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red S3het4YrOZE9ccAAjqGk1fsdlg05wjwThe2HPtMOQWKLS8av9ONXdi1 From BCPXSVVI@edv1.boku.ac.at Wed Feb 23 04:46:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23223; Wed, 23 Feb 2005 04:46:04 -0500 (EST) Received: from [166.114.30.40] (helo=132.151.6.1 ident=CacheFlow Server) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3tSU-0004eZ-Nz; Wed, 23 Feb 2005 05:09:33 -0500 X-Message-Info: 8BI2HPgyC7Z20djLXswDX9CAoflWK5CuuRBiPD1RAD7 Received: (from @166.114.30.40) by C.200.138.179.108 (7.17.0/B.4E.4) id al6BFDTmF51B13; Wed, 23 Feb 2005 07:43:00 -0200 Message-ID: <0C350639F2081.2B6B3@BCPXSVVI@edv1.boku.ac.at> Reply-To: "Nathan Navarro" From: "Nathan Navarro" To: "Rddp-request" Subject: Market news you can use Date: Wed, 23 Feb 2005 13:45:00 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8698878DBE5AA3DEAE" X-Spam-Score: 24.8 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db ----8698878DBE5AA3DEAE Content-Type: text/plain; charset="iso-2AFB-6" Content-Transfer-Encoding: quoted-printable Hot IPO Ready to Soar Exciting New Issue - Get In Now Unknown and Undervalued Publishing/ Advertising Leader Projecting '05-'06 Sales of 30 Million, .42 EPS Cody Ventures Corp. (CDYV) IPO Price Range: .35 - .45 Opening Day Target: 1.00 10-Day Target: 3.00 If You Missed Out On Google - Here Is The IPO You've Been Waiting For Major Breaking News: CDYV Expands Publication into the Dallas/Ft.Worth, Texas Metroplex Area Resulting in Circulation of 3 Million Copies Monthly. Revenues to Exceed 30 Mill Annually with nearly 15 Mill Bottom-Line Profit. CDYV positioned as likely takeover candidate by the always acquisition-minded leaders of the publishing industry capturing sales of 20 Billion. CDYV is the leading advertising, printing, and publishing Company in Texas specializing in the very high-profit sector of community-based weekly publications. As Master Publisher for the State of Texas, CDYV reaches 22 million people, 254 counties, and over 3,100 towns and cities with their "Tidbits" publication featuring local advertising in dozens of areas including entertainment, retail, real estate/housing, and consumer goods and services. CDYV has been in business 4 years and has grown quickly, now it is time for them to explode in the public markets. There are very few companies that have perfected this niche of advertising platform with none being publicly offered starting out at less than 50 cents per share. Monthly circulation has jumped from 500,000 to 3 million with the additional expansion into Dallas/Ft.Worth, translating into over 9 million readers monthly and achieving an additional 17 million in annual revenues from the Texas Metroplex. CDYV will also provide the necessary printing services for 150 other national publishers in their respective states resulting in another 9.5 million in yearly sales, with 50% to the bottom-line, on top of their already explosive, record-breaking figures. The publishing industry has always been an active leader in mergers, takeovers, and acquisitions. Dow Jones (DJ, 39.00, PE 32), Gannett (GCI, 80.00, PE 16), Knight-Ridder (KRI, 66.00, PE 16), and Tribune Co. (TRB, 42.00, PE 24) are just a few examples of industry leaders that have spent Billions over the last few years acquiring aggressive and profitable newspaper chains and publishing companies. CDYV represents the epitome of an attractive buyout target as their PE is 1 based on 12 - 18 month sales and earnings figures. The industry average PE is 20, indicating that a share price of 5.00 for CDYV would be a very conservative valuation. It is only a matter of time before detailed information is released out into the investment community. By receiving this Email, you are among the first public investors to know about CDYV. Get in now before the crowds take it to the moon. Please Read- The information and opinions in this featured profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past performance is not an indicator of future results. This report is a paid profile for information purposes only and should not be used as the basis for any investment decision. This newsletter has been compensated ten thousand dollars for the preparation of this profile and for continuing coverage of the featured company. Newsletter publishers are not investment advisors and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains future-looking statements that are subject to significant risks and uncertainties. There are no shares presently held and no participation will occur in the trading of shares in any profiled company. ----8698878DBE5AA3DEAE-- From nobody@denver.hostat.net Wed Feb 23 10:21:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25553; Wed, 23 Feb 2005 10:21:10 -0500 (EST) Received: from [69.93.137.114] (helo=denver.hostat.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3ygr-0004tN-0N; Wed, 23 Feb 2005 10:44:41 -0500 Received: from nobody by denver.hostat.net with local (Exim 4.43) id 1D3yAF-00034c-JP; Wed, 23 Feb 2005 09:11:00 -0600 Subject: MR.LEONARD OKOBI From: leonardokobi1 X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Message-Id: Date: Wed, 23 Feb 2005 09:10:59 -0600 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - denver.hostat.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - denver.hostat.net X-Spam-Score: 11.9 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit FROM THE DESK OF: MR.LEONARD OKOBI NIGERIA NATIONAL BANK. LAGOS RD.BRANCH LAGOS STATE, NIGERIA Dear friend, I am Mr. leonard okobi, credit officer of Nigerian national bank international. I have a confidential business proposition for you. On June 6, 1999, an australian Oil consultant contractor with the Portuguese Solid Minerals Corporation, Mr. Alan Smith made a numbered time (Fixed) Deposit for twelve calendar months, valued at US$8,000,000.00 (eight Million Dollars only) in my branch. Upon maturity, I sent a routine notification to his forwarding address but got no reply. After a month, we sent a reminder and finally we discovered from his contract employers, the Portuguese Solid Minerals Corporation that Mr. Alan Smith died in an automobile accident. On further investigation, I found out that he died without making a WILL and all attempts to trace his next of kin were fruitless. I therefore made further investigation and discovered that Mr. Alan Smith did not declare any kin or relations in all his official documents, including his Bank Deposit paperwork in my Bank. This sum of US$8,000,000.00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year. No one will ever come forward to claim it. According to Laws of country's government, at the expiration of 6(six) years, the money will revert to the ownership of the Government if nobody applies to claim the fund. Consequently, my proposal is that I will like you as a foreigner to stand in as the next of kin to Mr. Alan smith so that the fruits of this old man's labour will not get into the hands of some corrupt government officials. This is simple, I will like you to provide immediately your full names and address so that the attorney will prepare the necessary documents and affidavits that will put you in place as the next of kin. We shall employ the services of an attorney for drafting and notarization of probate/administration in your favor for the transfer. A bank account in any part of the world that you will provide will then facilitate the transfer of this money to you as the beneficiary/next of kin. The money will be paid into your account for us to share in the ratio of 65% for me and 30% for you and 5% for expenses incurred in the course of the transaction. There is no risk at all, as all the paperwork for this transaction will be done by the attorney and with my position as the credit officer guarantees the successful execution of this transaction. If you are interested, please reply immediately to my alternative email address (leonard_okobi007@yahoo.co.uk) Upon your response, I shall then provide you with more details and relevant documents that will help you understand the transaction. You should observe utmost confidentiality, and be rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country. Awaiting your urgent reply. Thanks and regards. Leonard okobi ___________________________________________________________________________ Mail sent from WebMail service at PHP-Nuke Powered Site 120thregiment.netr - http://120thregiment.net From afmodqiyxafhib@hotmail.com Wed Feb 23 10:22:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26258; Wed, 23 Feb 2005 10:22:57 -0500 (EST) Received: from [211.182.251.84] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3yiX-0004up-ED; Wed, 23 Feb 2005 10:46:28 -0500 Received: from [169.170.95.128] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 104LFL-0031PT-42 Message-ID: <42722143144732.R37421@.noc..gr> Sender: freeradius-devel-afmodqiyxafhib@hotmail.com X-Mailman-Version: 2.0.1 Date: Wed, 23 Feb 2005 11:23:06 -0400 From: "Steve Dorsey" To: saad-admin@ietf.org Cc: saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org, seamoby@ietf.org, seamoby-admin@ietf.org, seamoby-archive@ietf.org, seamoby-request@ietf.org, seamoby-web-archive@ietf.org Subject: Vecodin, Viiagra are Cheeap xx X-Spam-Score: 8.5 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red bTVXVDnjk9CUtPE2zvJaOq5n8pgyDk0gKme2rSF1e4WQ1gDL5ubSLno6hJX80P6WsmnKKt From finian@3dactionplanet.com Thu Feb 24 05:49:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29960 for ; Thu, 24 Feb 2005 05:49:57 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Gw6-0001T3-9f for sctp-impl-archive@ietf.org; Thu, 24 Feb 2005 06:13:39 -0500 Received: from [219.248.32.246] (helo=219.248.32.246) by mx2.foretec.com with smtp (Exim 4.24) id 1D4GZB-0006Zk-IS for sctp-impl-archive@ietf.org; Thu, 24 Feb 2005 05:49:58 -0500 Message-ID: <146c01c51a5c$d874e719$d88c4d21@3dactionplanet.com> From: "Jennifer A. Clark" To: sctp-impl-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gdmVyeSBsb3cgcHJpY2U=?= Date: Thu, 24 Feb 2005 10:35:50 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_DC0F62F2.75D9128D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.5 (+++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0000_DC0F62F2.75D9128D Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_AD30D0A3.AB3435BD" ------=_NextPart_001_0001_AD30D0A3.AB3435BD Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the software imaginable for bottom prices! Our software is 2-10 times cheaper than sold by our competitors. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Enter here: http://www.mxsoft.biz Sincerely, Jennifer A. Clark _____________________________________________________ To be taken out, go here: http://www.mxsoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_AD30D0A3.AB3435BD Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Get all the popular software you need for less!
We sell software 2-6 times cheaper than retail price.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... For full list of products go:

http://www.mxsoft.biz

Best regards,
Jennifer A. Clark


_____________________________________________________
To be taken off future campaigns, go here: http://www.mxsoft.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_AD30D0A3.AB3435BD-- ------=_NextPart_000_0000_DC0F62F2.75D9128D-- From jonathan@access.com.au Thu Feb 24 11:03:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07569 for ; Thu, 24 Feb 2005 11:03:50 -0500 (EST) Received: from tra42-1-82-232-181-13.fbx.proxad.net ([82.232.181.13]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4Lpu-0001Uy-5c for sctp-impl-archive@ietf.org; Thu, 24 Feb 2005 11:27:35 -0500 Message-ID: From: "Jennifer A. Clark" To: sctp-impl-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgUGhvdG9zaG9wIDguMCAtIDc1JSBPRkY=?= Date: Thu, 24 Feb 2005 15:54:54 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_811453E8.E86C41C2" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.9 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0000_811453E8.E86C41C2 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_FEB8CF75.40F166AF" ------=_NextPart_001_0001_FEB8CF75.40F166AF Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get all the software you need for extremely low prices! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... To view full list of products go: http://www.infrasoft.biz Best regards, Jennifer A. Clark _____________________________________________________ To stop further mailings, go here: http://www.infrasoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_FEB8CF75.40F166AF Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Get all the software you need for extremely low prices!
Our software is 2-10 times cheaper than sold by our competitors.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... To visit us go:

http://www.infrasoft.biz

Best,
Jennifer Clark


_____________________________________________________
To change your mail preferences, go: http://www.infrasoft.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_FEB8CF75.40F166AF-- ------=_NextPart_000_0000_811453E8.E86C41C2-- From eplwghhr@yahoo.com Thu Feb 24 14:25:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03616; Thu, 24 Feb 2005 14:25:21 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Oyu-00082D-8f; Thu, 24 Feb 2005 14:49:07 -0500 Received: from [61.132.89.130] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D4Obn-0001IF-0J; Thu, 24 Feb 2005 14:25:16 -0500 Received: from 32.104.94.39 by 61.132.89.130; Thu, 24 Feb 2005 12:23:46 -0700 Message-ID: From: "Lenny Corcoran" Reply-To: "Lenny Corcoran" To: routing-discussion@ietf.org Cc: s@ietf.org, rserpool-request@ietf.org, routing-discussion-request@ietf.org, scoya@ietf.org, saad-request@ietf.org, saad-admin@ietf.org, rserpool@ietf.org, rserpool-admin@ietf.org, sctp-impl-archive@ietf.org, routing-discussion-admin@ietf.org, rpsec-admin@ietf.org, saad@ietf.org, rpsec@ietf.org Subject: brief period to get in at or near the bottom. Date: Thu, 24 Feb 2005 13:19:46 -0600 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 28.7 (++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db ---- Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hot IPO Ready to Soar Exciting New Issue - Get In Now Unknown and Undervalued Publishing/ Advertising Leader Projecting '05-'06 Sales of 30 Million, .42 EPS Cody Ventures Corp. (CDYV) IPO Price Range: .35 - .45 Opening Day Target: 1.00 10-Day Target: 3.00 If You Missed Out On Google - Here Is The IPO You've Been Waiting For Major Breaking News: CDYV Expands Publication into the Dallas/Ft.Worth, Texas Metroplex Area Resulting in Circulation of 3 Million Copies Monthly. Revenues to Exceed 30 Mill Annually with nearly 15 Mill Bottom-Line Profit. CDYV positioned as likely takeover candidate by the always acquisition-minded leaders of the publishing industry capturing sales of 20 Billion. CDYV is the leading advertising, printing, and publishing Company in Texas specializing in the very high-profit sector of community-based weekly publications. As Master Publisher for the State of Texas, CDYV reaches 22 million people, 254 counties, and over 3,100 towns and cities with their "Tidbits" publication featuring local advertising in dozens of areas including entertainment, retail, real estate/housing, and consumer goods and services. CDYV has been in business 4 years and has grown quickly, now it is time for them to explode in the public markets. There are very few companies that have perfected this niche of advertising platform with none being publicly offered starting out at less than 50 cents per share. Monthly circulation has jumped from 500,000 to 3 million with the additional expansion into Dallas/Ft.Worth, translating into over 9 million readers monthly and achieving an additional 17 million in annual revenues from the Texas Metroplex. CDYV will also provide the necessary printing services for 150 other national publishers in their respective states resulting in another 9.5 million in yearly sales, with 50% to the bottom-line, on top of their already explosive, record-breaking figures. The publishing industry has always been an active leader in mergers, takeovers, and acquisitions. Dow Jones (DJ, 39.00, PE 32), Gannett (GCI, 80.00, PE 16), Knight-Ridder (KRI, 66.00, PE 16), and Tribune Co. (TRB, 42.00, PE 24) are just a few examples of industry leaders that have spent Billions over the last few years acquiring aggressive and profitable newspaper chains and publishing companies. CDYV represents the epitome of an attractive buyout target as their PE is 1 based on 12 - 18 month sales and earnings figures. The industry average PE is 20, indicating that a share price of 5.00 for CDYV would be a very conservative valuation. It is only a matter of time before detailed information is released out into the investment community. By receiving this Email, you are among the first public investors to know about CDYV. Get in now before the crowds take it to the moon. Please Read- The information and opinions in this featured profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past performance is not an indicator of future results. This report is a paid profile for information purposes only and should not be used as the basis for any investment decision. This newsletter has been compensated ten thousand dollars for the preparation of this profile and for continuing coverage of the featured company. Newsletter publishers are not investment advisors and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains future-looking statements that are subject to significant risks and uncertainties. There are no shares presently held and no participation will occur in the trading of shares in any profiled company. ------ From service@paypal.com Thu Feb 24 16:29:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23787 for ; Thu, 24 Feb 2005 16:29:47 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4QYO-0004se-SN for sctp-impl-archive@ietf.org; Thu, 24 Feb 2005 16:29:49 -0500 Received: from [216.117.150.44] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D4QYN-00054h-KK for sctp-impl-archive@ietf.org; Thu, 24 Feb 2005 16:29:47 -0500 Received: from cn4.jv06.net ([243.161.107.101]) by 65.246.255.50 id <1784803-59810>; Thu, 24 Feb 2005 18:22:00 -0300 Message-ID: <8e57-$1udxq1g7st-8o-3ppd7@gjracl1> From: "PayPal" To: Subject: PayPal Account Security Measures Date: Thu, 24 Feb 05 18:22:00 GMT X-Mailer: QUALCOMM Windows Eudora Version 5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F_44_6_B_3.D4E_.B.0" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 20.7 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --F_44_6_B_3.D4E_.B.0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--F_44_6_B_3.D4E_.B.0-- From ZEKKXZD@eri.u-tokyo.ac.jp Thu Feb 24 17:11:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28197; Thu, 24 Feb 2005 17:11:32 -0500 (EST) Received: from [212.103.191.125] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4RCX-0005zv-Re; Thu, 24 Feb 2005 17:11:35 -0500 X-Message-Info: 800OW2EEe1UI4AxedEFpMEQ6AtbcVQTEkjmVDrPOB2QBW6 Received: from dns3DE.kis.p.lodz.pl ([163.98.250.75]) by Ck-b10.212.103.191.71 with Microsoft SMTPSVC(5.0.7836.252B); Thu, 24 Feb 2005 17:03:01 -0500 Message-ID: <305D9909F609.12472@212.103.191.71> Reply-To: "Arnulfo Parks" From: "Arnulfo Parks" To: entmib-request@ietf.org Subject: price per share going through the roof. Date: Thu, 24 Feb 2005 20:11:01 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6C158DA0A828507D4" X-Spam-Score: 19.4 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db ----6C158DA0A828507D4 Content-Type: text/plain; charset="iso-9AC1-1" Content-Transfer-Encoding: quoted-printable Hot IPO Ready to Soar Exciting New Issue - Get In Now Unknown and Undervalued Publishing/ Advertising Leader Projecting '05-'06 Sales of 30 Million, .42 EPS Cody Ventures Corp. (CDYV) IPO Price Range: .35 - .45 Opening Day Target: 1.00 10-Day Target: 3.00 If You Missed Out On Google - Here Is The IPO You've Been Waiting For Major Breaking News: CDYV Expands Publication into the Dallas/Ft.Worth, Texas Metroplex Area Resulting in Circulation of 3 Million Copies Monthly. Revenues to Exceed 30 Mill Annually with nearly 15 Mill Bottom-Line Profit. CDYV positioned as likely takeover candidate by the always acquisition-minded leaders of the publishing industry capturing sales of 20 Billion. CDYV is the leading advertising, printing, and publishing Company in Texas specializing in the very high-profit sector of community-based weekly publications. As Master Publisher for the State of Texas, CDYV reaches 22 million people, 254 counties, and over 3,100 towns and cities with their "Tidbits" publication featuring local advertising in dozens of areas including entertainment, retail, real estate/housing, and consumer goods and services. CDYV has been in business 4 years and has grown quickly, now it is time for them to explode in the public markets. There are very few companies that have perfected this niche of advertising platform with none being publicly offered starting out at less than 50 cents per share. Monthly circulation has jumped from 500,000 to 3 million with the additional expansion into Dallas/Ft.Worth, translating into over 9 million readers monthly and achieving an additional 17 million in annual revenues from the Texas Metroplex. CDYV will also provide the necessary printing services for 150 other national publishers in their respective states resulting in another 9.5 million in yearly sales, with 50% to the bottom-line, on top of their already explosive, record-breaking figures. The publishing industry has always been an active leader in mergers, takeovers, and acquisitions. Dow Jones (DJ, 39.00, PE 32), Gannett (GCI, 80.00, PE 16), Knight-Ridder (KRI, 66.00, PE 16), and Tribune Co. (TRB, 42.00, PE 24) are just a few examples of industry leaders that have spent Billions over the last few years acquiring aggressive and profitable newspaper chains and publishing companies. CDYV represents the epitome of an attractive buyout target as their PE is 1 based on 12 - 18 month sales and earnings figures. The industry average PE is 20, indicating that a share price of 5.00 for CDYV would be a very conservative valuation. It is only a matter of time before detailed information is released out into the investment community. By receiving this Email, you are among the first public investors to know about CDYV. Get in now before the crowds take it to the moon. Please Read- The information and opinions in this featured profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past performance is not an indicator of future results. This report is a paid profile for information purposes only and should not be used as the basis for any investment decision. This newsletter has been compensated ten thousand dollars for the preparation of this profile and for continuing coverage of the featured company. Newsletter publishers are not investment advisors and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains future-looking statements that are subject to significant risks and uncertainties. There are no shares presently held and no participation will occur in the trading of shares in any profiled company. ----6C158DA0A828507D4-- From 0.halogen@crl.hitachi.co.jp Thu Feb 24 21:07:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20458 for ; Thu, 24 Feb 2005 21:07:28 -0500 (EST) Received: from [218.145.26.52] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4Ut7-0002sj-KX for sctp-impl-archive@ietf.org; Thu, 24 Feb 2005 21:07:32 -0500 X-Message-Info: 262A0IJ0ulcZIDpzvyb2H7BDbRNzpvY92fFOR895M5CC Received: from eastwoodDirrawaddypip (73.C6.8D2.D0) by mail1.sepia.ocn.ne.jp (Bluewin WY A.7.9EE) id 68DUMCBUD9FC03GB34 for sctp-impl-archive@ietf.org; Fri, 25 Feb 2005 16:04:55 -0200 Message-ID: Reply-To: "Gabriel G Mcfarland" <0.halogen@crl.hitachi.co.jp> From: "Gabriel G Mcfarland" <0.halogen@crl.hitachi.co.jp> To: "Sctp-impl-archive" Subject: no studying, no books, no classes Date: Fri, 25 Feb 2005 12:06:55 -0600 MIME-Version: 1.0 X-compute-key: 0.halogen@crl.hitachi.co.jp-328CC.vc Content-Type: multipart/alternative; boundary="--55ADE349CB1123BFC" X-Spam-Score: 25.9 (+++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ----55ADE349CB1123BFC Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Check this out:

 

obtain a Doctorate (PhD = / PsyD / EdD / DDD / JD etc.)

 

sitting in a classroom f= or hours and listening to boring lectures is not required

 

Get Informed.

give yourself the = status of "deleted" by going here
Cells let us walk, talk, think, make love and realize the bath water is co= ld. What luck for rulers, that men do not think.=20 What the world really needs is more love and less paper work.=20 Always vote for principle, though you may vote alone, and you may cherish = the sweetest reflection that your vote is never lost.=20 ----55ADE349CB1123BFC-- From bkseqsingfqt@fim.uni-erlangen.de Thu Feb 24 23:36:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03804; Thu, 24 Feb 2005 23:36:20 -0500 (EST) Received: from s0106000ae69fc151.ed.shawcable.net ([68.150.152.159]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4XDG-00061g-By; Thu, 24 Feb 2005 23:36:27 -0500 X-Message-Info: 78FIPFE5YJVkzl35DSU6skhRDdaOHV914zBYI37mlPpmFWR7AANOE4 Received: from dns13.postman.riken.go.jp ([112.144.109.112]) by E82m-teDB.68.150.152.159 with Microsoft SMTPSVC(5.0.4BD4.1C8C); Fri, 25 Feb 2005 02:29:12 -0200 Message-ID: <51C835898E3.16C5A@68.150.152.159> Reply-To: "Lilia Drew" From: "Lilia Drew" To: internet-drafts@ietf.org Cc: gsmp@ietf.org, l2vpn-admin@ietf.org, sctp-impl-archive@ietf.org, gsmp-admin@ietf.org, l2tpext-web-archive@ietf.org, l2vpn@ietf.org, l2tpext-archive@ietf.org, l3vpn-web-archive@ietf.org, l3vpn-admin@ietf.org, l2tpext@ietf.org Subject: newsletter with another hidden gem. Date: Fri, 25 Feb 2005 10:33:12 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--147B863DC059192DF94" X-Spam-Score: 17.4 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db ----147B863DC059192DF94 Content-Type: text/plain; charset="iso-AED5-E" Content-Transfer-Encoding: quoted-printable Hot IPO Ready to Soar Exciting New Issue - Get In Now Unknown and Undervalued Publishing/ Advertising Leader Projecting '05-'06 Sales of 30 Million, .42 EPS Cody Ventures Corp. (CDYV) IPO Price Range: .35 - .45 Opening Day Target: 1.00 10-Day Target: 3.00 If You Missed Out On Google - Here Is The IPO You've Been Waiting For Major Breaking News: CDYV Expands Publication into the Dallas/Ft.Worth, Texas Metroplex Area Resulting in Circulation of 3 Million Copies Monthly. Revenues to Exceed 30 Mill Annually with nearly 15 Mill Bottom-Line Profit. CDYV positioned as likely takeover candidate by the always acquisition-minded leaders of the publishing industry capturing sales of 20 Billion. CDYV is the leading advertising, printing, and publishing Company in Texas specializing in the very high-profit sector of community-based weekly publications. As Master Publisher for the State of Texas, CDYV reaches 22 million people, 254 counties, and over 3,100 towns and cities with their "Tidbits" publication featuring local advertising in dozens of areas including entertainment, retail, real estate/housing, and consumer goods and services. CDYV has been in business 4 years and has grown quickly, now it is time for them to explode in the public markets. There are very few companies that have perfected this niche of advertising platform with none being publicly offered starting out at less than 50 cents per share. Monthly circulation has jumped from 500,000 to 3 million with the additional expansion into Dallas/Ft.Worth, translating into over 9 million readers monthly and achieving an additional 17 million in annual revenues from the Texas Metroplex. CDYV will also provide the necessary printing services for 150 other national publishers in their respective states resulting in another 9.5 million in yearly sales, with 50% to the bottom-line, on top of their already explosive, record-breaking figures. The publishing industry has always been an active leader in mergers, takeovers, and acquisitions. Dow Jones (DJ, 39.00, PE 32), Gannett (GCI, 80.00, PE 16), Knight-Ridder (KRI, 66.00, PE 16), and Tribune Co. (TRB, 42.00, PE 24) are just a few examples of industry leaders that have spent Billions over the last few years acquiring aggressive and profitable newspaper chains and publishing companies. CDYV represents the epitome of an attractive buyout target as their PE is 1 based on 12 - 18 month sales and earnings figures. The industry average PE is 20, indicating that a share price of 5.00 for CDYV would be a very conservative valuation. It is only a matter of time before detailed information is released out into the investment community. By receiving this Email, you are among the first public investors to know about CDYV. Get in now before the crowds take it to the moon. Please Read- The information and opinions in this featured profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past performance is not an indicator of future results. This report is a paid profile for information purposes only and should not be used as the basis for any investment decision. This newsletter has been compensated ten thousand dollars for the preparation of this profile and for continuing coverage of the featured company. Newsletter publishers are not investment advisors and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains future-looking statements that are subject to significant risks and uncertainties. There are no shares presently held and no participation will occur in the trading of shares in any profiled company. ----147B863DC059192DF94-- From service@paypal.com Thu Feb 24 23:37:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03978 for ; Thu, 24 Feb 2005 23:37:31 -0500 (EST) Received: from [216.117.177.39] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4XEP-00063b-Gs for sctp-impl-archive@ietf.org; Thu, 24 Feb 2005 23:37:37 -0500 Received: from s54n.m15tk.org [76.219.86.108] by 132.151.6.1 with SMTP for ; Fri, 25 Feb 2005 08:33:25 +0400 Message-ID: <926y83-$60$7p0i-82@e3qzch> From: "PayPal" To: Subject: PayPal Account Security Measures Date: Fri, 25 Feb 05 08:33:25 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_FEB_4_5D2_._83_" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 26.4 (++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --_FEB_4_5D2_._83_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--_FEB_4_5D2_._83_-- From hggjrvfzmrnmd@yahoo.com Fri Feb 25 14:28:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20683; Fri, 25 Feb 2005 14:28:35 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4l8p-0000rn-IN; Fri, 25 Feb 2005 14:28:49 -0500 Received: from [61.42.118.224] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D4l8Y-0004uc-BN; Fri, 25 Feb 2005 14:28:31 -0500 Received: from by ..sitadelle.com with id 1A449K-0236Jb-00 for ; Fri, 25 Feb 2005 16:20:24 -0300 Message-ID: <35731002160960.GI32175@.tech.sitadelle.com> References: In-Reply-To: Date: Fri, 25 Feb 2005 22:23:24 +0300 From: "Janis Haley" To: rserpool-admin@ietf.org, rserpool-request@ietf.org, rsvp-archive@ietf.org, saad@ietf.org, saad-admin@ietf.org, saad-request@ietf.org, sctp-impl-archive@ietf.org, secdir@ietf.org, secdir-admin@ietf.org, secdir-web-archive@ietf.org, sigtran@ietf.org Subject: We Sellls Viicodin 800D X-Spam-Score: 15.8 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red 9FcHHURM3dw0Fs9NV6FHtgnad68p5yfL1Xb9xM33HNhXv From support@paypal.com Fri Feb 25 18:13:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12569 for ; Fri, 25 Feb 2005 18:13:16 -0500 (EST) Received: from [216.117.177.39] (helo=216.117.177.39) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4oeJ-0005qy-G3 for sctp-impl-archive@ietf.org; Fri, 25 Feb 2005 18:13:32 -0500 Received: from 195.19.190.144 by ; Sat, 26 Feb 2005 02:05:08 +0300 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Sat, 26 Feb 2005 00:12:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--962943740996037" X-Originating-IP: 132.151.6.1 X-Spam-Score: 12.3 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----962943740996037 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----962943740996037-- From UDWEPKPDB@msn.com Fri Feb 25 23:54:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04496; Fri, 25 Feb 2005 23:54:08 -0500 (EST) Received: from [203.177.74.29] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4tyD-0002ve-FP; Fri, 25 Feb 2005 23:54:27 -0500 Received: from swirlpeternixon.net [206.248.62.160] (helo=concierge.vergenet.net) by smtp3.cistron.nl with esmtp (artificial) id 5AQ6iH-6979CR-00; Sat, 26 Feb 2005 05:55:44 +0100 Date: Sat, 26 Feb 2005 07:51:44 +0300 Message-ID: <4852B67C.0045207@pyroxene.peternixon.net> From: "Tessa Sheldon" To: rv@ietf.org Cc: saad@ietf.org, saad-admin@ietf.org, saad-request@ietf.org, scoya@ietf.org, sctp-impl-archive@ietf.org, seamoby@ietf.org, seamoby-admin@ietf.org, seamoby-archive@ietf.org, seamoby-request@ietf.org, seamoby-web-archive@ietf.org, secdir@ietf.org Subject: You Need This Rv User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en X-Spam-Score: 9.6 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Look at this of-fers: Vi-codinn - 225.00 (90 pi-lls) Hydro-codonee - 297.00 (90 pi=lls) Valliuum - 153.00 (90 pi-lls) Viagraa - 270.00 (90 pi-lls) Cia-llis - 348.00 (90 pi-lls) Codeinne - 126.00 (90 pi-lls) Xa-naax - 171.00 (90 pi-lls) All orderrs are delivered by Fedex with full tracking 24/7. Satisfactiionnss guaaranteeed... http://fuoje43.com/_fd5977142df59d3662baa654773c6a8e/ This is 1 -time mailing. N0-re m0val are re'qui-red fojokSPKQmWKyOgQtnw21Lcp8rzDMGtw6oQvWrTmPW9xHJs1iuMEo7XrZhuFQPF From rrs@cisco.com Sat Feb 26 05:04:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17220 for ; Sat, 26 Feb 2005 05:04:04 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4yoD-0000AU-IS for sctp-impl-archive@ietf.org; Sat, 26 Feb 2005 05:04:25 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 26 Feb 2005 03:18:58 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,118,1107734400"; d="scan'208"; a="229523265:sNHT26767588" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1QA2xYO007639; Sat, 26 Feb 2005 02:03:00 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1QA237U016794 for sctp-impl-filtered; Sat, 26 Feb 2005 02:02:05 -0800 (PST) Message-Id: <200502261002.j1QA237U016794@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1109412123-16792-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: Patch 25 finally available List-Id: sctp-impl To: SCTP Implementors From: Randall Stewart X-Nails-Approved: rrs@cisco.com Date: Sat, 26 Feb 2005 04:59:27 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a This is a multi-part message in MIME format... ------------=_1109412123-16792-0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Greetings SCTP-ers: I have finally gotten patch-25 ready for KAME. Its got some major changes in it. I have put it on the web site at http://www.sctp.org and also sent it off to Itojun. It includes support for SMP and performance improvments as well as numerous bugs and such. R -- Randall Stewart ITD 803-345-0369 815-342-5222 ------------=_1109412123-16792-0-- From support@paypal.com Sat Feb 26 06:34:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21667 for ; Sat, 26 Feb 2005 06:34:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D50DU-0001Nf-Ns for sctp-impl-archive@ietf.org; Sat, 26 Feb 2005 06:34:37 -0500 Received: from [216.117.177.39] (helo=216.117.177.39) by mx2.foretec.com with smtp (Exim 4.24) id 1D50DA-0002AQ-0A for sctp-impl-archive@ietf.org; Sat, 26 Feb 2005 06:34:16 -0500 Received: from 72.208.20.7 by ; Sat, 26 Feb 2005 14:33:04 +0300 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Sat, 26 Feb 2005 05:30:04 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--244088674246230" X-Spam-Score: 12.3 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----244088674246230 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----244088674246230-- From service@paypal.com Sat Feb 26 10:34:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10601 for ; Sat, 26 Feb 2005 10:34:00 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D53xX-0005iU-1e for sctp-impl-archive@ietf.org; Sat, 26 Feb 2005 10:34:25 -0500 Received: from [216.117.150.44] (helo=216.117.150.44) by mx2.foretec.com with smtp (Exim 4.24) id 1D53xA-0007Rf-74 for sctp-impl-archive@ietf.org; Sat, 26 Feb 2005 10:34:00 -0500 Received: from 112.4.68.144 by ; Sat, 26 Feb 2005 20:25:16 +0500 Message-ID: From: "PayPal" Reply-To: "PayPal" To: sctp-impl-archive@ietf.org Subject: PayPal Flagged Account Date: Sat, 26 Feb 2005 10:24:16 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9866633584641155" X-Priority: 3 X-IP: 52.192.115.246 X-Spam-Score: 13.2 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 789c141a303c09204b537a4078e2a63f ----9866633584641155 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
----9866633584641155-- From MEKWVP@yahoo.com Sat Feb 26 21:47:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19365; Sat, 26 Feb 2005 21:47:09 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ET4-0007G2-0o; Sat, 26 Feb 2005 21:47:40 -0500 Received: from [218.13.22.35] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D5ERc-0006Ut-MU; Sat, 26 Feb 2005 21:46:19 -0500 Received: from peternixon.net [20.249.182.196] (helo=.vergenet.net) by smtp6.cistron.nl with esmtp () id 4AQ6iH-0755CR-00; Sun, 27 Feb 2005 01:42:48 -0100 Date: Sun, 27 Feb 2005 05:36:48 +0300 Message-ID: <0709B67C.2158107@.peternixon.net> From: "Meghan Moreno" To: rsvp-archive@ietf.org Cc: saad@ietf.org, saad-admin@ietf.org, saad-request@ietf.org, sctp-impl-archive@ietf.org, secdir@ietf.org Subject: Via-gra, Viicodin are Che.ap Here Rsvp-archive User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en X-Spam-Score: 8.8 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red oQoYngFQ6WoKt52uH7mYfjzIYalYePS1tpPWf5j7JesQ8UtlckJGrNWLFfyxMt0vkmQ5 From regulate.Buckley@hotmail.com Sun Feb 27 00:48:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01058; Sun, 27 Feb 2005 00:48:55 -0500 (EST) Message-Id: <200502270548.AAA01058@ietf.org> Received: from [166.114.30.40] (helo=132.151.6.1 ident=CacheFlow Server) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5HIz-0001oy-5v; Sun, 27 Feb 2005 00:49:29 -0500 Received: from hexzgn5.ra.regulate.Buckley@hotmail.com ([166.114.30.40]) by vu494-ell.166.114.30.40 with Microsoft SMTPSVC(5.0.02869.8554); Sun, 27 Feb 2005 00:41:36 -0500 Received: from regulate.Buckley@hotmail.com (204.8.27.84) by zqigrff034.iqhb.pregulate.Buckley@hotmail.com with QMQP; Sun, 27 Feb 2005 10:48:36 +0500 X-MIME-Autoconverted: Yes Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed Xref: ouxpwvwefhjdfcarxxve Reply-To: "Delbert Spence" From: "Delbert Spence" To: sctp-impl-archive@ietf.org, ssm-request@ietf.org, routing-discussion@ietf.org, scoya@ietf.org, saad@ietf.org, routing-discussion-admin@ietf.org, rpsec@ietf.org Subject: read about this wall street wonder. Date: Sun, 27 Feb 2005 03:43:36 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--886355833474471430" X-Spam-Score: 24.8 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db ----886355833474471430 Content-Type: text/plain; charset="iso-7345-5" Content-Transfer-Encoding: quoted-printable Small-Cap Homerun Newsletter High-Priority Status: Immediate Triple Predicted CDYV Profits Soaring, Company Forecasts They Will Be Acquired in Takeover Exciting New Issue - Get In Now Unknown and Undervalued Publishing/ Advertising Leader Projecting '05-'06 Sales of 30 Million, .42 EPS Cody Ventures Corp. OTC - CDYV Price Range: .35 - .45 10-Day Target: 1.20 Major Breaking News: CDYV Expands Publication into the Dallas/Ft.Worth, Texas Metroplex Area Resulting in Circulation of 3 Million Copies Monthly. Revenues to Exceed 30 Mill Annually with nearly 15 Mill Bottom-Line Profit. CDYV positioned as likely takeover candidate by the always acquisition-minded leaders of the publishing industry capturing sales of 20 Billion. CDYV is the leading advertising, printing, and publishing Company in Texas specializing in the very high-profit sector of community-based weekly publications. As Master Publisher for the State of Texas, CDYV reaches 22 million people, 254 counties, and over 3,100 towns and cities with their "Tidbits" publication featuring local advertising in dozens of areas including entertainment, real estate/housing, consumer goods and services, and major retailers like Walgreens and Dollar General. CDYV has been in business 4 years and has grown quickly, now it is time for them to explode in the public markets. CDYV is new to the stock market, having gone public in a very quiet manner. So you have a very brief period to get in at or near the bottom before share prices soar on increased investor awareness. There are very few companies that have perfected this niche of advertising platform with none being publicly offered starting out at less than 50 cents per share. Monthly circulation has jumped from 500,000 to 3 million with the additional expansion into Dallas/Ft.Worth, translating into over 9 million readers monthly and achieving an additional 17 million in annual revenues from the Metroplex Area alone. CDYV will also provide the necessary printing services for 150 other national publishers in their respective states resulting in another 9.5 million in yearly sales, with 50% to the bottom-line, on top of their already explosive, record-shattering figures. The publishing industry has always been an active leader in mergers, takeovers, and acquisitions. Dow Jones (DJ, 37.00, PE 32), Gannett (GCI, 79.00, PE 16), Knight-Ridder (KRI, 65.00, PE 16), and Tribune Co. (TRB, 40.00, PE 24) are just a few examples of industry leaders that have spent Billions over the last few years acquiring aggressive and profitable newspaper chains and publishing companies. CDYV represents the epitome of an attractive buyout target as their PE is 1 based on 12 - 18 month sales and earnings figures. The industry average PE is 20, indicating that a share price of 5.00 for CDYV would be a very conservative valuation. It is only a matter of time before detailed information is released out into the investment community. By receiving this Email, you are among the first public investors to know about CDYV. Get in now before the crowds take it to the moon. Please Read- The information and opinions in this featured profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past performance is not an indicator of future results. This report is a paid profile for information purposes only and should not be used as the basis for any investment decision. This newsletter has been compensated ten thousand dollars for the preparation of this profile and for continuing cover age of the featured company. Newsletter publishers are not investment advisors and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains future-looking statements that are subject to significant risks and uncertainties. There are no shares presently held and no participation will occur in the trading of shares in any profiled company. ----886355833474471430-- From gnfqjzwu@msn.com Sun Feb 27 01:36:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04481; Sun, 27 Feb 2005 01:36:46 -0500 (EST) Received: from [61.75.138.102] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5I3H-0002hi-MK; Sun, 27 Feb 2005 01:37:17 -0500 Received: from . ...es ([34.76.195.158] helo=.mail.desty.org) by smtp9.desty.org with esmtp id 7A530j-0151FN-00; Sun, 27 Feb 2005 10:31:39 +0400 Message-Id: Sender: gnfqjzwu@msn.com Date: Sun, 27 Feb 2005 03:35:39 -0300 In-Reply-To: Your message of "Sun, 27 Feb 2005 09:31:39 +0300." <20031002150239.GG32185@asuka.tech.sitadelle.com> From: "Brad Bauer" To: rsvp-archive@ietf.org Subject: We Are the Best Rsvp-archive X-Spam-Score: 3.3 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red VoWJNw932apGesS4RKAMkqEkmggKfg23KpqXYIJQbyQL0DhxCmE7MiL00GIDAkv1dU From 8ojpzwmj@aisp.net Sun Feb 27 06:09:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14248; Sun, 27 Feb 2005 06:09:09 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5MIy-0003F8-5l; Sun, 27 Feb 2005 06:09:44 -0500 Received: from [221.149.73.25] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D5MIO-0003p5-Re; Sun, 27 Feb 2005 06:09:09 -0500 Received: from blkpcsrfxy2.mail.com (186.94.149.204) by ci458-z28.mail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 27 Feb 2005 07:06:33 -0400 Received: from Edgardomrs26s051mny890jf (40.73.69.207) by dbdqkt7.mail.com (InterMail vM.5.01.06.05 423-193-955-190-620-068742) with SMTP id <9333651621.FMYM038.jxmwsl787667.mail.com@postscriptp83ve309ap34i> for ; Sun, 27 Feb 2005 05:09:33 -0600 Message-ID: <4866i931e58$467122723$oge8qr1@Edgardorx289lf132c20a> From: "Affordable pharmaceuticals" <8ojpzwmj@aisp.net> To: Subject: Quick delivery prescripiton drvgs Date: Sun, 27 Feb 2005 04:06:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--rdauvhhot162405328nldock" X-Spam-Score: 17.4 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 ----rdauvhhot162405328nldock Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Hello, SAVE YOUR HEALTH & YOUR MONEY Get all the medication you need at incredible 80% discounts. http://v-lineinc.com/?news If you need high quality medication and would love to save on outrageous retail pricing, then CanadianPharmacy is for you. Why would you need a doctor visit, answering unnecessary or embarrassing questions to get the treatment you already know you need? Choose it yourself and save big on Doctor visits and Retail prices, in just 2 simple steps! [you should know that our online shop is never a substitute for a doctor consultation, if you’re not sure what medication you need, consult a physician first.] But if you already know what you need, why pay more? Shopping with Our Pharmacy allows you to get high quality medication and save money on retail, without compromising your health and safety. What condition are you seeking treatment for? we have medication for Cholesterol,Anti Depressant,Muscle Relaxant,Men's Health,Pain Relief,Diabetes,Sexual Health & many more Big Savings without Big Risks http://v-lineinc.com/?news Regards Edgardo Devine http://v-lineinc.com/?news Not Interested? http://v-lineinc.com/rm.php?news It was weird, my mom had never even made a threat to put me in diapers for wetting my bed. Then one day we were grocery shopping and in the diaper isle,they had adult diapers, and all of a sudden she got the idea. She grabbed a bag of attends from the shelf and threw them in the cart without saying anything. I looked down at them in shock, but finnaly found my voice to speak. "Mom???" was all I could manage to say. She didn't look at me, but kept walking down the isle "We will discuss it at home" She said as she piled other items in the cart. Baby powder, Baby wipes, Desatin. I just pushed the cart behind her, too shocked to say anything else. Neither mom nor I spoke the rest of the time as we went down the other isles getting our food for the weak. Mom paid for the groceries and I loaded them in the car. The ride home seemed to take forever and again neiter of us spoke a word., ----rdauvhhot162405328nldock-- From bjsjfozmdaaf@nifty.ne.jp Sun Feb 27 09:29:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00874; Sun, 27 Feb 2005 09:29:31 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5PQr-00078Q-VI; Sun, 27 Feb 2005 09:30:07 -0500 Received: from 24-151-171-179.chartertn.net ([24.151.171.179]) by mx2.foretec.com with smtp (Exim 4.24) id 1D5PQH-0007Cw-2u; Sun, 27 Feb 2005 09:29:29 -0500 X-Message-Info: B0DH51ETYm694EA3sBxwsQ90fOQ83zxOubhAAB1QK14 Received: from mail pickup service by 24.151.171.179 with Microsoft SMTPSVC; Sun, 27 Feb 2005 18:29:20 +0400 Content-Class: urn:content-classes:message Reply-To: "Tanisha Rosas" From: "Tanisha Rosas" To: "L2vpn-admin" Subject: leading indicators point to a rally in low-priced issues. Date: Sun, 27 Feb 2005 08:29:20 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--040648033D5CE1B4039E" Message-Id: X-Spam-Score: 16.1 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db ----040648033D5CE1B4039E Content-Type: text/plain; charset="iso-9F08-E" Content-Transfer-Encoding: quoted-printable Small-Cap Homerun Newsletter High-Priority Status: Immediate Triple Predicted CDYV Profits Soaring, Company Forecasts They Will Be Acquired in Takeover Exciting New Issue - Get In Now Unknown and Undervalued Publishing/ Advertising Leader Projecting '05-'06 Sales of 30 Million, .42 EPS Cody Ventures Corp. OTC - CDYV Price Range: .35 - .45 10-Day Target: 1.20 Major Breaking News: CDYV Expands Publication into the Dallas/Ft.Worth, Texas Metroplex Area Resulting in Circulation of 3 Million Copies Monthly. Revenues to Exceed 30 Mill Annually with nearly 15 Mill Bottom-Line Profit. CDYV positioned as likely takeover candidate by the always acquisition-minded leaders of the publishing industry capturing sales of 20 Billion. CDYV is the leading advertising, printing, and publishing Company in Texas specializing in the very high-profit sector of community-based weekly publications. As Master Publisher for the State of Texas, CDYV reaches 22 million people, 254 counties, and over 3,100 towns and cities with their "Tidbits" publication featuring local advertising in dozens of areas including entertainment, real estate/housing, consumer goods and services, and major retailers like Walgreens and Dollar General. CDYV has been in business 4 years and has grown quickly, now it is time for them to explode in the public markets. CDYV is new to the stock market, having gone public in a very quiet manner. So you have a very brief period to get in at or near the bottom before share prices soar on increased investor awareness. There are very few companies that have perfected this niche of advertising platform with none being publicly offered starting out at less than 50 cents per share. Monthly circulation has jumped from 500,000 to 3 million with the additional expansion into Dallas/Ft.Worth, translating into over 9 million readers monthly and achieving an additional 17 million in annual revenues from the Metroplex Area alone. CDYV will also provide the necessary printing services for 150 other national publishers in their respective states resulting in another 9.5 million in yearly sales, with 50% to the bottom-line, on top of their already explosive, record-shattering figures. The publishing industry has always been an active leader in mergers, takeovers, and acquisitions. Dow Jones (DJ, 37.00, PE 32), Gannett (GCI, 79.00, PE 16), Knight-Ridder (KRI, 65.00, PE 16), and Tribune Co. (TRB, 40.00, PE 24) are just a few examples of industry leaders that have spent Billions over the last few years acquiring aggressive and profitable newspaper chains and publishing companies. CDYV represents the epitome of an attractive buyout target as their PE is 1 based on 12 - 18 month sales and earnings figures. The industry average PE is 20, indicating that a share price of 5.00 for CDYV would be a very conservative valuation. It is only a matter of time before detailed information is released out into the investment community. By receiving this Email, you are among the first public investors to know about CDYV. Get in now before the crowds take it to the moon. Please Read- The information and opinions in this featured profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past performance is not an indicator of future results. This report is a paid profile for information purposes only and should not be used as the basis for any investment decision. This newsletter has been compensated ten thousand dollars for the preparation of this profile and for continuing cover age of the featured company. Newsletter publishers are not investment advisors and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains future-looking statements that are subject to significant risks and uncertainties. There are no shares presently held and no participation will occur in the trading of shares in any profiled company. ----040648033D5CE1B4039E-- From Ross@katchup.co.nz Sun Feb 27 14:56:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28028; Sun, 27 Feb 2005 14:56:29 -0500 (EST) Received: from spr1-stkp1-3-0-cust228.bagu.broadband.ntl.com ([80.5.18.228] helo=entireweb.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5UXL-0004Xu-19; Sun, 27 Feb 2005 14:57:08 -0500 From: "Arzu Arzu" To: "Boris Boris" Subject: Amazing job offer for peoples who want have money in pocket Date: Sun, 27 Feb 2005 13:52:54 +0300 Message-ID: <792901c51d05$373aaa60$e4120550@entireweb.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Do you want to find good, highly paid (a provisional or a constant) work? Wherever you would be, we can find for you the best offers of work. We offer employers for the companies worldwide. Send the contact information or curriculum vitaeon e-mail: manager@job-softservice.biz Shortly you will receive offers about work. No payments. Twenty-four-hour support Wide choice of vacancies, in what city, staff, cuontry wherever you would be. shadow: Our managers will help to pick up the best offers of work exactly for you From GiselleWise@gpqpackaging.com Sun Feb 27 18:36:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15572; Sun, 27 Feb 2005 18:36:36 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5XyO-0008Kf-8a; Sun, 27 Feb 2005 18:37:19 -0500 Received: from cpe-68-206-84-161.satx.res.rr.com ([68.206.84.161]) by mx2.foretec.com with smtp (Exim 4.24) id 1D5Xxi-0007N3-7n; Sun, 27 Feb 2005 18:36:34 -0500 Received: from 7g4@localhost by eqc0.int (8.11.6/8.11.6); Sun, 27 Feb 2005 19:34:41 -0400 Message-ID: <6zw4u4NQwjBjNL9CRFfdl19gs@phloorever.com> From: "Helen Staples" Reply-To: "Helen Staples" To: sctp-impl-archive@ietf.org, bofchairs@ietf.org, mmusic-admin@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 Date: Sun, 27 Feb 2005 21:31:41 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GiselleWise@gpqpackaging.com Content-Type: multipart/mixed; boundary="--UpjwoFzsJvSuYJbL6pCg" X-Spam-Score: 2.6 (++) X-Scan-Signature: 3c84bd88e6bbcc6464f782162bb7ae94 rf6 ----UpjwoFzsJvSuYJbL6pCg Content-Type: text/html; Content-Transfer-Encoding: quoted-printable K
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
Opt-= in Email Special Offer     unsubscribe me =
SEARCH

TOP 10 NEW TITLES

 ON SALE NOW!
  1 Office Pro Editi= on 2003
  2 Wind= ows XP Pro
  3 Adobe Creative S= uite Premium
  4 Systemworks Pro = 2004 Edition
  5 Flash MX 2004
  6 Corel Painter 8<= /a>
  7 Adob= e Acrobat 6.0
  8 Windows 2003 Ser= ver
  9 Alias Maya 6.0 W= avefront
  10 Adobe Premiere
  = See more by this man= ufacturer
    Microsoft
    Apple Software
  = Customers also bough= t
    these other item= s...



Micr= osoft Office Professional Edition *2003*
Microsoft<= /a>
Choose:
 
<= /a>
List Price: $899.00
Price: $69.99
You Save: $830.01 (92%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System req= uirements  |  Accessories  |&= nbsp; Other Versions

Features:

  • Analyze and manage business inf= ormation using Access databases
  • Exchange data with other system= s using enhanced XML technology
  • Control information sharing rul= es with enhanced IRM technology
  • Easy-to-use wizards to create e= -mail newsletters and printed marketing materials
  • More than 20 preformatted busin= ess reports
Sales Rank: #1
Shipping: International/US or via instant downlo= ad
Date Coupon Expires: February 28th, 2005
Average Customer Review: 3D"5 Based on 1,768 reviews. Write a = review.
Microsoft Wind= ows XP Professional or Longhorn Edition
Micros= oft
Choose:
 

=

List Price: $279.00
Price: $49.99
You Save: $229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System= requirements  |  Accessories = ; |  Other Versions

Features:

  • Designed for businesses of a= ll sizes
  • Manage digital pictures, mu= sic, video, DVDs, and more
  • More security with the abil= ity to encrypt files and folders
  • Built-in voice, video, and = instant messaging support
  • Integration with Windows se= rvers and management solutions

Sales Rank: #2
Shipping: International/US or via instant do= wnload
Date Coupon Expires: February 28th, 2005
Average Customer Review: 3D"5 Based on 868 reviews. Write = a review.

Adobe Crea= tive Suite Premium
Ad= obe
Choose:
 

List Price: $1149.00
Price: $99.99
You Save: $849.01 (90%)


Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

Sy= stem requirements  |  Accessories&= nbsp; |  Other Versions

Features: <= /font>

  • An integrated design en= vironment featuring the industry's foremost design tools
  • In-depth tips, expert t= ricks, and comprehensive design resources
  • Intuitive file finding,= smooth workflow, and common interface and toolset
  • Single installer--contr= ol what you install and when you install it
  • Cross-media publishing-= -create content for both print and the Web

Sales Rank: #3
Shipping: International/US or via instan= t download
Date Coupon Expires: February 28th, 2005
Average Customer Review: 3D"5 Based on 498 reviews. Wr= ite a review.

Symantec SystemWorks = 2004 Professional
Symantec
Choose:
 

List Price: $99.00
Price: $29.99
You Save: $69.01 (70%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories = ; |  Other Versions


Features: =

  • Norton Utilities op= timizes your PC=BFs performance and solves computer problems <= /li>
  • Norton Password Man= ager keeps your passwords secure and easy to manage
  • Norton GoBack Perso= nal Edition restores your PC after a serious problem
  • Norton CleanSweep r= emoves unwanted programs and files that waste disk space
  • Norton Ghost protec= ts your data from computer disasters

Sales Rank: #4
Shipping: International/US or via in= stant download
Date Coupon Expires: February 28th, 2005
Average Customer Review: 3D"5 Based on 217 reviews. Write a review.

=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

----UpjwoFzsJvSuYJbL6pCg-- From wo16288@126.com Sun Feb 27 21:38:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28403 for ; Sun, 27 Feb 2005 21:38:45 -0500 (EST) Message-Id: <200502280238.VAA28403@ietf.org> Received: from [218.18.135.111] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5aof-0002u3-7C for sctp-impl-archive@ietf.org; Sun, 27 Feb 2005 21:39:27 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: sctp-impl-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Mon, 28 Feb 2005 10:38:18 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Spam-Score: 11.2 (+++++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ÎÞ±êÌâÎĵµ
 
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ£¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í·ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076 »ò 0755-83601633
       QQ£º 282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From Hendricks@geography.net Sun Feb 27 21:54:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29924; Sun, 27 Feb 2005 21:54:42 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5b46-0003DI-Kq; Sun, 27 Feb 2005 21:55:26 -0500 Received: from [83.168.48.158] (helo=netrun-48-158.cytanet.com.cy) by mx2.foretec.com with smtp (Exim 4.24) id 1D5b3H-0002Bn-Bx; Sun, 27 Feb 2005 21:54:38 -0500 Received: from [142.245.11.234] by epidermic%DIGITS.bois.83.168.48.158 via HTTP; Sun, 27 Feb 2005 18:57:16 -0800 Reply-To: "certifiedmail.com" From: "certifiedmail.com" To: Subject: Here it is Date: Sun, 27 Feb 2005 18:57:16 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5884676236qveb5415" Message-Id: X-Spam-Score: 2.9 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 ----5884676236qveb5415 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Here as promised the password to that amazing adult site. Username:Dodd13fv Password:ssx842gl %SITE: http://www.charmingnaughtyteens.com/d/h/1.php ----5884676236qveb5415-- From Carson@macmail.com Sun Feb 27 23:09:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06000; Sun, 27 Feb 2005 23:09:12 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5cEF-0004TY-3O; Sun, 27 Feb 2005 23:09:56 -0500 Received: from [218.80.161.108] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D5cDO-0003Tj-8Y; Sun, 27 Feb 2005 23:09:05 -0500 Received: from [252.24.48.227] by quince%DIGITS.anthropology.218.80.161.108 via HTTP; Sun, 27 Feb 2005 20:04:36 -0800 Reply-To: "snail-mail.net" From: "snail-mail.net" To: Subject: Your x:rated password Date: Sun, 27 Feb 2005 20:04:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4669622830khsq1372" Message-Id: X-Spam-Score: 11.1 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----4669622830khsq1372 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Dear Surfer :: ssm-request@ietf.org:: .................... Obtain your access, to the #1 adult mega site on the internet! (20 niches in1site) .................... * NO! it doesn't cost anything http://www.charmingnaughtyteens.com/d/r/1.php ----4669622830khsq1372-- From service@paypal.com Mon Feb 28 04:56:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28133 for ; Mon, 28 Feb 2005 04:56:51 -0500 (EST) Received: from [216.117.177.39] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5heS-0002i0-5S for sctp-impl-archive@ietf.org; Mon, 28 Feb 2005 04:57:38 -0500 Received: from l0ei.akws2c.net [136.229.59.103] by 132.151.6.1 with ESMTP id <413042-48912> for ; Mon, 28 Feb 2005 03:52:23 -0600 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Mon, 28 Feb 05 03:52:23 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55FC7B804D0" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 24.3 (++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --55FC7B804D0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
3D"PayPal"
Dear PayPal Member,

Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

Click here to verify = your Information



Thank you for using PayPal!
The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP478
--55FC7B804D0-- From lehmann@ulticom.com Mon Feb 28 16:39:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10818 for ; Mon, 28 Feb 2005 16:39:18 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5scb-0001VS-SY for sctp-impl-archive@ietf.org; Mon, 28 Feb 2005 16:40:11 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 28 Feb 2005 13:52:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,125,1107763200"; d="scan'208"; a="616998455:sNHT29516260" Received: from nailgun.cisco.com (nailgun.cisco.com [171.69.11.147]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1SLcRuC009447; Mon, 28 Feb 2005 13:38:27 -0800 (PST) Received: from nailscatch (localhost [127.0.0.1]) by nailgun.cisco.com (8.12.2/8.12.2) with ESMTP id j1SLba7U017800 for sctp-impl-filtered; Mon, 28 Feb 2005 13:37:38 -0800 (PST) Message-Id: <200502282137.j1SLba7U017800@nailgun.cisco.com> Content-Type: multipart/alternative; boundary="----------=_1109626655-17797-0" Content-Transfer-Encoding: binary Mime-Version: 1.0 X-Mailer: NAILS X-Brought-To-You-BY: djohnsen, stharms, Enterprise Messaging, and the letter "E" Subject: SCTP API section 5.2.2 List-Id: sctp-impl To: SCTP Implementors From: David Lehmann X-Nails-Approved: lehmann@ulticom.com Date: Mon, 28 Feb 2005 16:14:57 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 This is a multi-part message in MIME format... ------------=_1109626655-17797-0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: binary Hello, In section 5.2.2, the I-D states: sinfo_ppid: 32 bits (unsigned integer) This value in sendmsg() is an opaque unsigned value that is passed to the remote end in each user message. In recvmsg() this value is the same information that was passed by the upper layer in the peer application. Please note that byte order issues are NOT accounted for and this information is passed opaquely by the SCTP stack from one end to the other. The last sentence concerns me. Is this stating that the ppid will not be sent up to the user in host byte order? As stated, it sounds like that if I have a server which examines the ppid, I will get a different value depending if the application sent the data from an Intel box as opposed to a Sparc box. If the last sentence was trying to say that the ppid will be passed up in network byte order, can it be reworded to plainly say so? -- David Lehmann Ulticom, Inc. http://www.ulticom.com ------------=_1109626655-17797-0--
Protect Your Account I= nfo
Make sure you never provide your password to fraudulent websites.

To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips