- NZNOG - lists.nznog.org

[nznog-owner@list.waikato.ac.nz: Re: DNS lookup false positives with: com.co.nz > 208.73.212.12 > information.com]
by Richard Haakma 29 Oct '07

29 Oct '07

On Tue, Oct 30, 2007 at 09:43:32AM +1300, Paul Adshead wrote: > Are any others being affected by the fools who have registered "com.co.nz"? > > It's been setup as a 'catch all' search engine, for the 'append parent DNS > suffix' queries. So a lookup on "abcd.com" that should fail, comes back > successful from "abcd.com.co.nz"... :-( I add a line search . in /etc/resolv.conf in my mail servers to fix this sort of stuff. All email addresses should be fully qualified. Regards, RH.

1 0

DNS lookup false positives with: com.co.nz > 208.73.212.12 > information.com
by Paul Adshead 29 Oct '07

29 Oct '07

Are any others being affected by the fools who have registered "com.co.nz"? It's been setup as a 'catch all' search engine, for the 'append parent DNS suffix' queries. So a lookup on "abcd.com" that should fail, comes back successful from "abcd.com.co.nz"... :-(

4 3

114/8 and 115/8 allocated to APNIC
by Leo Vegoda 28 Oct '07

28 Oct '07

Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in October 2007: 144/8 and 115/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space Please update your filters as appropriate. Regards, Leo vegoda Manager, Number Resources - IANA

1 1

NZRR Route Registry Update
by NZRR Database Notifications 28 Oct '07

28 Oct '07

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 210.54.56.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ricky.tipper(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070928 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 210.54.56.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.95.250.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ricky.tipper(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071029 source: NZRR ------------------------------------------------------------

1 0

Youtube in NZ?
by Joel van Velden 25 Oct '07

25 Oct '07

Does anyone know anything about todays launch of a New Zealand portal on Youtube and in particular talk of a local youtube server? -Joel

3 2

[Fwd: Academic Study - Telephone Interview]
by Gerard Creamer 23 Oct '07

23 Oct '07

The following came into the info (at) nznog email address. Usually such things make their way to the recycle bin (it used to be the deleted, but we've gone PC /and/ green). This one looked like it might be of interest to someone and possibly even on topic for the list, so if it is something of interest to you please contact the person directly. If I'm wrong please flame me without regard for my feelings (as feeling are definitely off topic :^) Regards, Gerard -------- Original Message -------- Subject: Academic Study - Telephone Interview Date: Wed, 24 Oct 2007 14:54:33 +1300 From: Juan Gan <ganju908 (at) student.otago.ac.nz> To: info (at) nznog.org Hi, My name is Juan-Jim Gan and I am a student at the University of Otago. I am currently conducting a study on the Telecommunication Policymaking in New Zealand ─ specifically dealing with issues of the LLU (Local Loop Unbundling). While conducting my research, I stumbled upon NZNOG - an online community of network operators, predominantly in the Internet and Online Services area. This study could benefit from getting feedback from people within this community (people who are either directly or indirectly related to the LLU). I would like to ask for your permission to talk to someone from this community [via a short telephone interview] with regards to their view on the LLU. The participant could be anyone with an interest in the LLU. Information gathered from this interview could be very valuable for my study on the LLU. I would really appreciate it if you [or anyone from the community] agree to participate in this study. Participation in this study is entirely voluntary and you may choose not to participate or to withdraw your consent to be in the study, for any reason, at any time. Materials gathered from this interview will not be published. If you are interested in taking part in this study, please contact me via e-mail to arrange a suitable time to conduct the interview. My supervisor, Dr. Michael Bourk will be supervising this study. If you have any questions, please do not hesitate to contact either myself or Dr Bourk. Dr Bourk could be contacted on 03 ? 479 5751 or via email at Michael.bourk (at) otago.ac.nz. Your involvement in this study would be greatly appreciated. Thank you, Juan-Jim Gan -- Netspace Services Limited http://www.netspace.net.nz Phone +64 4 917 8098 Mobile +64 21 246 2266 Level One, 220 Thorndon Quay, Thorndon PO Box 12-082, Thorndon, Wellington 6004, New Zealand

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Oct '07

23 Oct '07

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 116.90.129.0/24^24-29, 116.90.131.0/24^24-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071003 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071024 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Oct '07

23 Oct '07

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 116.90.129.0/24^24-29, 116.90.131.0/24^24-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071003 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071024 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Re Yahoo and Spam...
by jwkckid1＠ix.netcom.com 22 Oct '07

22 Oct '07

Lenz and all, I am sorry you take the view you do regarding my suggestion. Very unfortunate. None the less, with the amount of spam Yahoo.com and Yahoo.de sems to allow is a huge waste of bandwidth which effects directly the stability of the Internet not to mention irritates unsuspecting users. Hence in part my suggestion. Unless there is a bonified threat of some sort, expecting mass spammers like Yahoo and AOL to curtail their network traffic accordingly, will never occur. However our members routienly block all AOL traffic/Email and all Yahoo.de traffic/Email currently, and have for some time. I suspect they will continue to do so for the forseeable future. -----Original Message----- >From: lengsc(a)coretech.co.nz >Sent: Oct 22, 2007 4:39 PM >To: nznog(a)list.waikato.ac.nz >Subject: Re: [nznog] Re Yahoo and Spam... > >hi, > >i see IMHO no use in spamming ICANN for things that that far away from >their responsibilities like this issue. drop the server in blacklists, >try to raise awarenes for the problem at the companies (spam the board >of yahoo/aol) or do something alike. ICANN has nothing to do with >mailservers and ICANN can not take down any address because they >manage the root not the respective second level domains.yahoo.com is >registered via markmonitor but i am pretty shure that they will not >take down the domain as well. >the approach you suggest is a bit kindergarden like and shows very >little knowledge of the different responsibilities in the internet. > >greets >lenz > >Quoting jwkckid1(a)ix.netcom.com: > >> Mark, >> >> Yahoo and AOL are famous for not addressing Spam or >> any abuse complaints. I have in the recent past suggested >> to ICANN that these sites be taken down unless or until >> they actually address abuse concerns in a direct and meaningful >> way and not with "Canned Email responses". Of course >> ICANN has refused to address this situation with Yahoo or >> AOL as well as Google, simply because of the presence in >> which these Domain names represent, which is IMHO besides >> the point. So I would suggest that every time you get >> one of the "Canned Email responses" you direct it to >> the ICANN bod or vint Cerf at the Email addresses I >> CC'ed this response to, until a ligitimate solution is >> effected. >> >> -----Original Message----- >>> From: Mark Foster <blakjak(a)blakjak.net> >>> Sent: Oct 19, 2007 6:49 PM >>> To: nznog(a)list.waikato.ac.nz >>> Subject: [nznog] Re Yahoo and Spam... >>> >>> Learned NZNOGrs, >>> >>> Some advice, please. >>> >>> Recently an email address that comes to me was sent some Unsolicited >>> Commercial Email from (apparently) a UK based outfit that sells (print) >>> magazine subscriptions. >>> >>> The headers contain this: >>> >>> Received: from smtp107.biz.mail.re2.yahoo.com >>> (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) >>> by mx.blakjak.net (Postfix) with SMTP id 8C508500D4 >>> for <dest(a)address>; Tue, 16 Oct 2007 12:02:52 +1300 (NZDT) >>> >>> They contain additional Received: headers which would imply that Yahoo >>> themselves received the message via SMTP from an AOL IP address that >>> Traceroute implies is likely in the UK as well. >>> >>> So I took a full-headers copy of the message and forwarded the complaint >>> to the relevant abuse contacts for both Yahoo and AOL. >>> >>> AOL, i've heard nothing (unsuprising). Yahoo, I had a response within 2-3 >>> days which basically absolved them of responsibility, as follows: >>> >>> --8<-- >>> >>> Thank you for writing to Yahoo! Mail. >>> >>> I understand your frustration in receiving unsolicited email. While we >>> investigate all reported violations against the Yahoo! Terms of Service >>> (TOS), in this particular case the message you received was not sent >>> through the Yahoo! Mail system. >>> >>> Yahoo! has no control over activities outside its service, and therefore >>> we cannot take action. You may try contacting the sender's email >>> provider, by identifying the sender's domain and contacting the >>> administrator of that domain. The sender's provider should be in a >>> better position to take appropriate action against the sender's account. >>> >>> The email message itself does contain some information relating to the >>> sender's identity. Yahoo! includes the originating Internet Protocol >>> (IP) address in the full Internet headers of all messages sent through >>> Yahoo! Mail, so that we will have information regarding the origin of >>> messages sent through our system. The originating IP address should be >>> located in the very last "Received" line of the full Internet headers >>> and corresponds to the sender's Internet Service Provider (ISP). >>> >>> Please see the following URL for more assistance: >>> >>> http://help.yahoo.com/help/us/mail/spam/spam-05.html >>> >>> Once you have identified the IP address, you can conduct an IP lookup to >>> determine which ISP provides this person with Internet access. One such >>> lookup tool you may want to try is: >>> >>> http://www.arin.net/whois/ >>> >>> You can then attempt to contact that ISP to report any abuse activities >>> occurring within their service. >>> >>> Please let us know if you still need assistance so I may assist you >>> further. >>> >>> Your patience during this process is greatly appreciated. >>> >>> Thank you again for contacting Yahoo! Mail. >>> >>> Regards, >>> >>> --8<-- >>> >>> I responded back indicating my understanding as being: >>> >>> - That my MTA received it from Yahoo, thus they relayed it... >>> - That headers below the line where my MTA actually is involved, are often >>> untrustworthy... >>> >>> I got a very-slightly-reworded version of exactly the same canned response >>> back. >>> >>> >>> So despite the fact that the sender is very clearly using Yahoo for SMTP >>> (which, one would hope, would establish the sender as a Yahoo! Mail >>> customer), they're pleading ignorance and/or innocence. >>> >>> Any other players had similar dealings with Yahoo (or other free mail >>> providers) ? At what point can the provider realistically abdicate from >>> responsibility when it comes to spam? >>> >>> And the obvious question: Is it fair to expect more from them? Or am I >>> resigned to accept either periodic junk relayed by Yahoo because they >>> can't be held responsible for what individual customers do? (And because >>> in this example, the collateral damage of blackholing them is probably >>> unacceptable? >>> >>> Cheers >>> Mark. >>> >> ======= >> >> 'Regards, >> Jeffrey A. Williams >> Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) >> "Obedience of the law is the greatest freedom" - >> Abraham Lincoln >> >> "Credit should go with the performance of duty and not with what is very >> often the accident of glory" - Theodore Roosevelt >> >> "If the probability be called P; the injury, L; and the burden, B; liability >> depends upon whether B is less than L multiplied by >> P: i.e., whether B is less than PL." >> United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] >> =============================================================== >> Updated 1/26/04 >> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of >> Information Network Eng. INEG. INC. >> ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com >> ======= 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

4 3

Re: [nznog] Re Yahoo and Spam...
by jwkckid1＠ix.netcom.com 22 Oct '07

22 Oct '07

Mark, Yahoo and AOL are famous for not addressing Spam or any abuse complaints. I have in the recent past suggested to ICANN that these sites be taken down unless or until they actually address abuse concerns in a direct and meaningful way and not with "Canned Email responses". Of course ICANN has refused to address this situation with Yahoo or AOL as well as Google, simply because of the presence in which these Domain names represent, which is IMHO besides the point. So I would suggest that every time you get one of the "Canned Email responses" you direct it to the ICANN bod or vint Cerf at the Email addresses I CC'ed this response to, until a ligitimate solution is effected. -----Original Message----- >From: Mark Foster <blakjak(a)blakjak.net> >Sent: Oct 19, 2007 6:49 PM >To: nznog(a)list.waikato.ac.nz >Subject: [nznog] Re Yahoo and Spam... > >Learned NZNOGrs, > >Some advice, please. > >Recently an email address that comes to me was sent some Unsolicited >Commercial Email from (apparently) a UK based outfit that sells (print) >magazine subscriptions. > >The headers contain this: > >Received: from smtp107.biz.mail.re2.yahoo.com >(smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) > by mx.blakjak.net (Postfix) with SMTP id 8C508500D4 > for <dest(a)address>; Tue, 16 Oct 2007 12:02:52 +1300 (NZDT) > >They contain additional Received: headers which would imply that Yahoo >themselves received the message via SMTP from an AOL IP address that >Traceroute implies is likely in the UK as well. > >So I took a full-headers copy of the message and forwarded the complaint >to the relevant abuse contacts for both Yahoo and AOL. > >AOL, i've heard nothing (unsuprising). Yahoo, I had a response within 2-3 >days which basically absolved them of responsibility, as follows: > >--8<-- > >Thank you for writing to Yahoo! Mail. > >I understand your frustration in receiving unsolicited email. While we >investigate all reported violations against the Yahoo! Terms of Service >(TOS), in this particular case the message you received was not sent >through the Yahoo! Mail system. > >Yahoo! has no control over activities outside its service, and therefore >we cannot take action. You may try contacting the sender's email >provider, by identifying the sender's domain and contacting the >administrator of that domain. The sender's provider should be in a >better position to take appropriate action against the sender's account. > >The email message itself does contain some information relating to the >sender's identity. Yahoo! includes the originating Internet Protocol >(IP) address in the full Internet headers of all messages sent through >Yahoo! Mail, so that we will have information regarding the origin of >messages sent through our system. The originating IP address should be >located in the very last "Received" line of the full Internet headers >and corresponds to the sender's Internet Service Provider (ISP). > >Please see the following URL for more assistance: > > http://help.yahoo.com/help/us/mail/spam/spam-05.html > >Once you have identified the IP address, you can conduct an IP lookup to >determine which ISP provides this person with Internet access. One such >lookup tool you may want to try is: > > http://www.arin.net/whois/ > >You can then attempt to contact that ISP to report any abuse activities >occurring within their service. > >Please let us know if you still need assistance so I may assist you >further. > >Your patience during this process is greatly appreciated. > >Thank you again for contacting Yahoo! Mail. > >Regards, > >--8<-- > >I responded back indicating my understanding as being: > >- That my MTA received it from Yahoo, thus they relayed it... >- That headers below the line where my MTA actually is involved, are often >untrustworthy... > >I got a very-slightly-reworded version of exactly the same canned response >back. > > >So despite the fact that the sender is very clearly using Yahoo for SMTP >(which, one would hope, would establish the sender as a Yahoo! Mail >customer), they're pleading ignorance and/or innocence. > >Any other players had similar dealings with Yahoo (or other free mail >providers) ? At what point can the provider realistically abdicate from >responsibility when it comes to spam? > >And the obvious question: Is it fair to expect more from them? Or am I >resigned to accept either periodic junk relayed by Yahoo because they >can't be held responsible for what individual customers do? (And because >in this example, the collateral damage of blackholing them is probably >unacceptable? > >Cheers >Mark. > ======= 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

2 1