June 2004 - Test - lists.nanog.org

RE: Unplugging spamming PCs
by Larry Pingree 24 Jun '04

24 Jun '04

But if you telnet from an IP that is not registered, you would be denied. Thus at least eliminating many of the erroneous email servers out there on the DSL, dial-up and other broadband connections, this has been tried in the open with such things as MABS RBL, etc by blocking common spamming IP's and mail servers. But since it is not mandatory, it falls apart too easily. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: Joe Hamelin [mailto:nethead@gmail.com] Sent: Wednesday, June 23, 2004 5:26 PM To: Larry Pingree Cc: nanog(a)nanog.org Subject: Re: Unplugging spamming PCs On Wed, 23 Jun 2004 16:40:23 -0700, Larry Pingree <lpingree(a)juniper.net> wrote: > I agree with you it's a hard problem to solve. But unless there is > mandatory cooperation within mail server software (which can be > monitored) to interface with a registry of acceptable/registered sites, > then this model could work. I can telnet to a mailserver and send mail to that host without much thought. What good will a registry do? What will solve spam is getting some of these virus writers to actually write some code that will trash disks of poorly patched (if a at all) hosts. Let Darwin take over. -Joe

1 0

RE: Homeland Security now wants to restrict outage notifications
by Larry Pingree 24 Jun '04

24 Jun '04

I agree, there are much more important things to protect than this information. It would be almost impossible to manage, and even more unlikely to ever have a positive effect. Besides, if someone with ill intentions has the abilities to act so quickly on such short notice, then we have much greater failures of our intelligence system that would need to be addressed. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Scott McGrath Sent: Thursday, June 24, 2004 11:06 AM To: nanog(a)merit.edu Subject: RE: Homeland Security now wants to restrict outage notifications I did read the article and having worked for gov't agencies twice in my career a proposal like the one floated by DHS is just the camel's nose. I should hope the carriers oppose this. Now a call comes into our ops center "I cant reach my experiment at Stanford". Ops looks up the outages Oh yeah there's a fiber cut affecting service we will let you know when it's fixed. They check it's fixed they call the customer telling them to try it now. Under the proposed regime "We know its dead do not know why or when it will be fixed because it' classified information" This makes for absolutely wonderful customer service and it protects public safety how?. Scott C. McGrath On Thu, 24 Jun 2004, Tad Grosvenor wrote: > Did you read the article? The DHS is urging that the FCC drop the proposal > to require outage reporting for "significant outages." This isn't the DHS > saying that outage notifications should be muted. The article also > mentions: "Telecom companies are generally against the proposed new > reporting requirements, arguing that the industry's voluntary efforts are > sufficient." > > -Tad > > > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Scott McGrath > Sent: Thursday, June 24, 2004 12:58 PM > To: nanog(a)merit.edu > Subject: Homeland Security now wants to restrict outage notifications > > > > See > > http://www.theregister.co.uk/2004/06/24/network_outages/ > > for the gory details. The Sean Gorman debacle was just the beginning > this country is becoming more like the Soviet Union under Stalin every > passing day in its xenophobic paranoia all we need now is a new version of > the NKVD to enforce the homeland security directives. > > Scott C. McGrath > >

1 0

MTU discovery
by Edward B. Dreger 24 Jun '04

24 Jun '04

Is it just me, or are more sites breaking pmtud these days? It's getting tempting to hack up ietf-pmtud-method support even before it becomes standard... Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked.

3 2

RE: .ORG DNS Problem?
by Mike Damm 24 Jun '04

24 Jun '04

<rant> A reminder to folks giving status reports on anycasted DNS deployments, don't forget to mention which node you are querying. For the F root (and other BIND implementations): dig +norec @f.root-servers.net hostname.bind chaos txt For UltraDNS: dig +norec @tld1.ultradns.net whoareyou.ultradns.net in a </rant> I'm seeing no problems with tld1.ultradns.net (udns2pxpa.ultradns.net) or tld2.ultradns.net (udns2eqsj.ultradns.net) -Mike -----Original Message----- From: Alexander Bochmann [mailto:ab@lists.gxis.de] Sent: Thursday, June 24, 2004 7:49 AM To: nanog(a)nanog.org Subject: Re: .ORG DNS Problem? Hi, ...on Thu, Jun 24, 2004 at 11:18:26AM -0400, Adam Kujawski wrote: > Anybody else having problems resolving .ORG domains via TLD1.ULTRADNS.NET > (204.74.112.1) and TLD2.ULTRADNS.NET. (204.74.113.1). I'm seeing slow > respones, or no responses. Same here, until a few minutes ago. Didn't work (connection timed out) from various places in Europe, while I had no problems when coming from a host in the US. Alex. -- AB54-RIPE

2 1

.ORG DNS Problem?
by Adam Kujawski 24 Jun '04

24 Jun '04

Anybody else having problems resolving .ORG domains via TLD1.ULTRADNS.NET (204.74.112.1) and TLD2.ULTRADNS.NET. (204.74.113.1). I'm seeing slow respones, or no responses. Traceroutes look fine: % tcptraceroute 204.74.112.1 53 Selected device fxp0, address 64.246.100.1, port 55786 for outgoing packets Tracing the path to 204.74.112.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 9.403 ms 7.361 ms 9.148 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.801 ms 8.061 ms 9.917 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.748 ms 8.341 ms 9.612 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 10.001 ms 9.172 ms 8.762 ms 5 ge-4-3-0.r00.chcgil06.us.bb.verio.net (206.223.119.12) 9.646 ms 8.960 ms 9.502 ms 6 ge-0-3-0.r02.chcgil06.us.bb.verio.net (129.250.2.121) 9.323 ms 9.071 ms 9.039 ms 7 ge-1-1.a00.chcgil07.us.ra.verio.net (129.250.25.136) 9.848 ms 9.306 ms 9.003 ms 8 fa-2-1.a00.chcgil07.us.ce.verio.net (128.242.186.134) 9.679 ms 9.697 ms 9.684 ms 9 tld1.ultradns.net (204.74.112.1) [open] 10.296 ms 10.625 ms 9.537 ms -AND - % tcptraceroute 204.74.113.1 53 Selected device fxp0, address 64.246.100.1, port 55792 for outgoing packets Tracing the path to 204.74.113.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 5.402 ms 7.282 ms 9.738 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.973 ms 7.958 ms 9.909 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.800 ms 10.295 ms 8.835 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 8.878 ms 8.786 ms 9.187 ms 5 fe9-2.IR1.Chicago2-IL.us.xo.net (206.111.2.149) 9.512 ms 8.964 ms 8.869 ms 6 p5-0-0.RAR2.Chicago-IL.us.xo.net (65.106.6.137) 9.580 ms 9.214 ms 9.120 ms 7 p4-1-0.MAR2.Chicago-IL.us.xo.net (65.106.6.154) 9.512 ms 10.285 ms 9.594 ms 8 p15-0.CHR1.Chicago-IL.us.xo.net (207.88.84.14) 10.126 ms 9.517 ms 9.472 ms 9 10.11.102.1 (10.11.102.1) 10.990 ms 9.808 ms 10.182 ms 10 tld2.ultradns.net (204.74.113.1) [open] 9.933 ms 10.124 ms 9.778 ms Source IP for the traceroutes is 64.246.100.1. Dig's don't get very far: % dig nanog.org +trace ; <<>> DiG 9.2.2-P3 <<>> nanog.org +trace ;; global options: printcmd . 300086 IN NS C.ROOT-SERVERS.NET. . 300086 IN NS D.ROOT-SERVERS.NET. . 300086 IN NS E.ROOT-SERVERS.NET. . 300086 IN NS F.ROOT-SERVERS.NET. . 300086 IN NS G.ROOT-SERVERS.NET. . 300086 IN NS H.ROOT-SERVERS.NET. . 300086 IN NS I.ROOT-SERVERS.NET. . 300086 IN NS J.ROOT-SERVERS.NET. . 300086 IN NS K.ROOT-SERVERS.NET. . 300086 IN NS L.ROOT-SERVERS.NET. . 300086 IN NS M.ROOT-SERVERS.NET. . 300086 IN NS A.ROOT-SERVERS.NET. . 300086 IN NS B.ROOT-SERVERS.NET. ;; Received 388 bytes from 64.246.100.1#53(64.246.100.1) in 10 ms org. 172800 IN NS TLD1.ULTRADNS.NET. org. 172800 IN NS TLD2.ULTRADNS.NET. ;; Received 109 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 9 ms ;; connection timed out; no servers could be reached -Adam

2 2

RE: .ORG DNS Problem?
by Cody Lerum 24 Jun '04

24 Jun '04

Seeing it also.. Resolving intermittently, but timeouts abound. -C -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Adam Kujawski Sent: Thursday, June 24, 2004 9:18 AM To: nanog(a)nanog.org Subject: .ORG DNS Problem? Anybody else having problems resolving .ORG domains via TLD1.ULTRADNS.NET (204.74.112.1) and TLD2.ULTRADNS.NET. (204.74.113.1). I'm seeing slow respones, or no responses. Traceroutes look fine: % tcptraceroute 204.74.112.1 53 Selected device fxp0, address 64.246.100.1, port 55786 for outgoing packets Tracing the path to 204.74.112.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 9.403 ms 7.361 ms 9.148 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.801 ms 8.061 ms 9.917 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.748 ms 8.341 ms 9.612 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 10.001 ms 9.172 ms 8.762 ms 5 ge-4-3-0.r00.chcgil06.us.bb.verio.net (206.223.119.12) 9.646 ms 8.960 ms 9.502 ms 6 ge-0-3-0.r02.chcgil06.us.bb.verio.net (129.250.2.121) 9.323 ms 9.071 ms 9.039 ms 7 ge-1-1.a00.chcgil07.us.ra.verio.net (129.250.25.136) 9.848 ms 9.306 ms 9.003 ms 8 fa-2-1.a00.chcgil07.us.ce.verio.net (128.242.186.134) 9.679 ms 9.697 ms 9.684 ms 9 tld1.ultradns.net (204.74.112.1) [open] 10.296 ms 10.625 ms 9.537 ms -AND - % tcptraceroute 204.74.113.1 53 Selected device fxp0, address 64.246.100.1, port 55792 for outgoing packets Tracing the path to 204.74.113.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 5.402 ms 7.282 ms 9.738 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.973 ms 7.958 ms 9.909 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.800 ms 10.295 ms 8.835 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 8.878 ms 8.786 ms 9.187 ms 5 fe9-2.IR1.Chicago2-IL.us.xo.net (206.111.2.149) 9.512 ms 8.964 ms 8.869 ms 6 p5-0-0.RAR2.Chicago-IL.us.xo.net (65.106.6.137) 9.580 ms 9.214 ms 9.120 ms 7 p4-1-0.MAR2.Chicago-IL.us.xo.net (65.106.6.154) 9.512 ms 10.285 ms 9.594 ms 8 p15-0.CHR1.Chicago-IL.us.xo.net (207.88.84.14) 10.126 ms 9.517 ms 9.472 ms 9 10.11.102.1 (10.11.102.1) 10.990 ms 9.808 ms 10.182 ms 10 tld2.ultradns.net (204.74.113.1) [open] 9.933 ms 10.124 ms 9.778 ms Source IP for the traceroutes is 64.246.100.1. Dig's don't get very far: % dig nanog.org +trace ; <<>> DiG 9.2.2-P3 <<>> nanog.org +trace ;; global options: printcmd . 300086 IN NS C.ROOT-SERVERS.NET. . 300086 IN NS D.ROOT-SERVERS.NET. . 300086 IN NS E.ROOT-SERVERS.NET. . 300086 IN NS F.ROOT-SERVERS.NET. . 300086 IN NS G.ROOT-SERVERS.NET. . 300086 IN NS H.ROOT-SERVERS.NET. . 300086 IN NS I.ROOT-SERVERS.NET. . 300086 IN NS J.ROOT-SERVERS.NET. . 300086 IN NS K.ROOT-SERVERS.NET. . 300086 IN NS L.ROOT-SERVERS.NET. . 300086 IN NS M.ROOT-SERVERS.NET. . 300086 IN NS A.ROOT-SERVERS.NET. . 300086 IN NS B.ROOT-SERVERS.NET. ;; Received 388 bytes from 64.246.100.1#53(64.246.100.1) in 10 ms org. 172800 IN NS TLD1.ULTRADNS.NET. org. 172800 IN NS TLD2.ULTRADNS.NET. ;; Received 109 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 9 ms ;; connection timed out; no servers could be reached -Adam

1 0

Re: Unplugging spamming PCs
by Michael.Dillon＠radianz.com 24 Jun '04

24 Jun '04

> That sentence is A joke 15000 subscribers affected A joke? Doing hard time is no joke. > http://www.reuters.com/newsArticle.jhtml; > jsessionid=IPQ4NZVA4P24ACRBAELCFEY?type=technologyNews&storyID=5504916 Maybe I read the Russian wrong here http://www.echel.ru/news/?page=2&id=3421#3421 but it seemed to me like he was sentenced to two years with the possibility of early release after one year. Nevertheless, when you read the details of what he actually did, this is a real wakeup call for anyone in Russia who sends spam. The police take it as seriously as releasing viruses or worms. Wouldn't we all like to see our courts treat spammers this way? Write a few lines of PERL to pump out SPAM and go to jail. --Michael Dillon

1 0

Re: Can a customer take IP's with them?
by Howard C. Berkowitz 24 Jun '04

24 Jun '04

>does your contract with your customers state that the space >is non-portable, that they can't take it with them and that >they WILL have to renumber ?? If so then they are asking >the court to change the contract you and they entered, which >i doubt would happen. > >the legal risk here is if the court gets it in their head >that IP's are like phone numbers and that they (numbers) >should be portable...... > >Judge: "So what exactly is an IP address" > >Plantif: "Judge, an IP address is a unique number that is >assigned to each computer on my clients network. It unique >like a phone number, and like each person in the company has >a unique phone number, they must have a unique IP address" > >Judge: "So basicly its like a phone number for computers." > >Plantif: "Yes" This would absolutely have to be challenged on cross-examination. Were I the attorney, especially if the plaintiff had mentioned telephone number portability, I would ask the plaintiff to explain what additional work had to be done to the POTS network to implement portability. Should the plaintiff start mumbling, I'd impugn his credibility, and then ask a bunch of hard questions about SS7 (including the TCAP mechanism for portable number translation), how IP routing works, how IP routing has no authoritative mechanism for global translation, etc. I'd interrogate the customer about DNS and why they weren't able to solve their portability requirement with it. I'd look for detailed familiarity with RFC 2071 and 2072. I wouldn't expect the customer to be able to answer many of these. As the defendant, I would expect to bring in my own expert witness who is very good at explaining these differences, and how the telephone and IP routing environments are different. > >also how much space are we talking about here ?? a /19 >or a /27 ? or ??? If its smaller than a /20, Hell >let them announce it, most places won't take the route >and their connectivity will be dorked. > >You might also advise ARIN that this customer has IP space >that is not being used and that it should be reclaimed >as they didn't renumber from your space. > > >john brown > >On Wed, Jun 23, 2004 at 01:16:48AM -0400, Alex Rubenstein wrote: >> >> >> >> (also sent to nanog) >> >> >> >> Should a customer be allowed to force a carrier to allow them to announce >> non-portable IP space as they see fit to any other carriers of their >> choosing when they are no longer buying service from the original carrier >> [that the space is assigned to]? >> >> According to ARIN regulations, the space does not "belong" to us but we >> have the right to assign or revoke the space to our customers as we see >> fit. In addition ARIN regulations specifically prohibit us from transferring >> or selling the IP space to another customer (even if we want to). >> >> NAC has a customer who is leaving NAC. As part of normal procedure (and >> also because the space provided to us by ARIN is non portable), the >> customer has been informed that the IP space used by the customer will not >> be available to be used by the customer subsequent to them leaving us. >> >> It should be mentioned that the following facts exist, and cannot be >> disputed: >> >> a) customer has obtained space directly from ARIN over a year ago, but has >> chosen not to renumber from space allocated from us. This was solely their >> choice, and we did not restrict this in any way. >> >> b) customer is exercising the right not to renew the business agreement, >> and is leaving NAC voluntarily. >> >> Thus, they are attempting to file for and obtain a temporary restraining >> order (TRO), and ask for the following: >> >> >> -- start -- >> >> "NAC shall permit CUSTOMER to continue utilization through any >> carrier or carriers of CUSTOMER's choice of any IP addresses that were >> utilized by, through or on behalf of CUSTOMER under the current agreement >> during the term thereof (the "Prior CUSTOMER Addresses") and shall not >> interfere in any way with the use of the Prior CUSTOMER Addresses, > > including, but not limited to: >> >> (i) by reassignment of IP address space to any customer; >> aggregation and/or BGP announcement modifications >> >> (ii) by directly or indirectly causing the occurrence of >> superseding or conflicting BGP Global Routing Table entries; filters >> and/or access lists, and/or >> >> (iii) by directly or indirectly causing reduced prioritization of >> access to and/or from the Prior CUSTOMER Addresses. >> >> NAC shall provide CUSTOMER with a LOA within 7 days of CUSTOMERS's written >> request for sale, >> >> NAC shall permit announcement of the Prior CUSTOMER Address to ANY >> carrier, IP transit, or IP peering network." >> >> -- end -- >> >> >> In other words, customer is asking a court to rule whether or not IP space >> should be portable, when an industry-supported organization (ARIN) has >> made policy that the space is in fact not portable. It can be further >> argued that the court could impose a TRO that would potentially negatively >> affect the operation of my network. >> >> NAC does not want to be forced to rely on a customer's ability to properly >> make complex routing updates that if done improperly could disrupt >>the entire >> NAC network. We believe there is a great danger to NAC that their routing >> mistakes could take down some or all of our network infrastructure. >> >> Another VERY important issue to bring up: If customer is granted the legal >> right to continue to use IP space that is registered to NAC by ARIN, NAC >> runs into the very serious problem of being liable for all of the Spam >> that could be generated by the customer and all of the RBLs that the >> carrier may be added to [that of course will effect all of NAC's >> customers] with no ability to revoke the IP space to protect itself. This >> has to potential to effect the NAC network in a catastrophic manner. >> >> I'd love any comments from anyone. >> _______________________________________________ >> "Eat sushi frequently". - Avi >> inet(a)inet-access.net is the human contact address. >> list(a)inet-access.net is the list posting address. >> See below URL for subscribe/unsubscribe and list options: >> http://inet-access.net/mailman/listinfo/list >_______________________________________________ >"Eat sushi frequently". - Avi >inet(a)inet-access.net is the human contact address. >list(a)inet-access.net is the list posting address. >See below URL for subscribe/unsubscribe and list options: >http://inet-access.net/mailman/listinfo/list _______________________________________________ "Eat sushi frequently". - Avi inet(a)inet-access.net is the human contact address. list(a)inet-access.net is the list posting address. See below URL for subscribe/unsubscribe and list options: http://inet-access.net/mailman/listinfo/list

2 2

RE: Unplugging spamming PCs
by Larry Pingree 24 Jun '04

24 Jun '04

Mail servers should be registered just like domains and shutdown by a registrar if they are misusing their registered services. This really needs to be handled by a multi-lateral legal solution, industry will not fix it alone. LP Best Regards, Larry Larry Pingree Partner Engineering Juniper Networks, Inc. 408-543-2190 "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree Juniper Networks Logo -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Petri Helenius Sent: Wednesday, June 23, 2004 1:15 PM To: Sam Hayes Merritt, III Cc: nanog(a)merit.edu Subject: Re: Unplugging spamming PCs Sam Hayes Merritt, III wrote: > >Proactive would be blocking port 25 except to comcast.net's mail servers, >at least on retail users without static IPs, and then opening it up if >the customer cannot work around it by using comcast's mail server to send >out. Thats what responsible ISPs have done. > > No, that would be punishing before the crime happened. Responsible would be to punish swiftly after the fact, but not before. Pete

5 4

Suggestion: identify and thread trouble tickets
by Colm MacCarthaigh 24 Jun '04

24 Jun '04

Many network operators have Trouble Ticket systems (as per RFC1297) which send mails notifying customers, peers and other interested parties of network problems, events and so on. Many of these mails cross my desk, so I thought it might be useful to make two small suggestions to trivially increase the functionality of these mails ... use the mail headers cleverly. Firstly, a lot of us receive a lot of tickets and to ease the workload we filter them into seperate mailboxes. To assist this process, rather than making us all use unreliable filters based on a sender address or a particular format to the subject, consider including a custom X-header, here at HEAnet we use: X-HEAnet-TicketID: [ticket id] X-HEAnet-Ticket-Distribution: [public|noc|personal ..] But only one is really neccessary (though I guess it depends on how easy you want to make subfiltering), and it should be committed to. No matter what you do to your trouble ticketing system the X header should remain. This would avoid the situation of breaking filtering on people when you change whatever unique subtlety they happen to be relying upon. Now secondly, after you've made it easy for people to distuingish your tickets from those of others, consider making it easy for people to distinguish your tickets from each other. For 1 year now, HEAnet have been issueing tickets with Message-ID's generated by our ticketing system, for example: To: noc@wherever From: Colm MacCarthaigh <colm.maccarthaigh@wherever> Subject: HEA-NOC/20040519-11 [OPEN] IPv6 packet loss on backbone X-HEAnet-TicketID: 20040519-11 X-HEAnet-Ticket-Distribution: public Message-ID: <20040519-11-1(a)cyclops.heanet.ie> And then subsequent updates to the ticket have headers such as: To: noc@wherever From: Colm MacCarthaigh <colm.maccarthaigh@wherever> Subject: HEA-NOC/20040519-11 [UPDATE] IPv6 packet loss on backbone X-HEAnet-TicketID: 20040519-11 X-HEAnet-Ticket-Distribution: public In-Reply-To: <20040519-11-1(a)cyclops.heanet.ie> References: <20040519-11-1(a)cyclops.heanet.ie> Message-ID: <20040519-11-2(a)cyclops.heanet.ie> I'm sure everyone can predict that the next mail would look like: To: noc@wherever From: Colm MacCarthaigh <colm.maccarthaigh@wherever> Subject: HEA-NOC/20040519-11 [UPDATE] IPv6 packet loss on backbone X-HEAnet-TicketID: 20040519-11 X-HEAnet-Ticket-Distribution: public In-Reply-To: <20040519-11-2(a)cyclops.heanet.ie> References: <20040519-11-2(a)cyclops.heanet.ie> Message-ID: <20040519-11-3(a)cyclops.heanet.ie> This simple feature has the effect of enabling mails concerning the same ticket to be threaded/grouped (and whatever gmail is calling it these days) in the users mail client, if their mail-client supports threaded viewing. We all know what it looks like :). If a user wants to see them chronologically instead, just turning the threaded viewing off is enough. We've had no reports of problems and many people have found it useful, and personally I find TT mails substantially more manageable in this form. If tickets are logged to a HTML archive, threaded mails can help there also by allowing a nice way to see all ticket updates relevant to a single issue. I would imagine that all ticketing systems already have a unique number per ticket (the ticket id) and incrementing a counter for each update/close is not hard, so it's a simple enough feature to add (though making sure the message ID's are in fact unique is critical). It's probably not a new idea, and it has almost certainly been implemented before but none of the trouble tickets I get implement it. So, my humble suggestion is to consider adding it in the next rewrite of your ticketing system, or requesting it as a feature from your TT system vendor. There may be problems we have not encountered in operation or I have not considered, if so - comments welcome. -- Colm

1 0