Re: SPEWS?
[ On Thursday, June 20, 2002 at 15:48:41 (-0700), John Payne wrote: ] Subject: Re: SPEWS? On Thu, Jun 20, 2002 at 04:38:02PM -0400, Geo. wrote: I am a postmaster for a state wide ISP and we maintain our own blacklist along with usage of one other public blacklist, the spamcop blacklist. Why spamcop and not spews? My question is why a dnsbl that the *maintainer* of which says should not be used for production mail systems? That's how you know bl.spamcop.net is a good and useful list! The maintainer(s) wouldn't use such a disclaimer if it wasn't. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: attention network operators who are listed in blacklists! your problem is with the blockers, not the blacklist managers! (was: SPEWS?)
[ On Friday, June 21, 2002 at 14:48:36 (+0100), Peter Galbavy wrote: ] Subject: Re: SPEWS? But then there are the whacko's like SpamCop who just ignore every mail you send them anyway. Why would anyone even bother to try to contact SpamCop about a listing in the first place!?!?!?!? SpamCop merely lists known sources of spam. So long as spam comes from some source, it'll likely be listed by SpamCop. They very VERY clearly state their mode of operation and they clearly tell those who are listed that they can only ever be de-listed by stopping the spam (and waiting for some delay). SpamCop really is just an impartial listing of spam sources. Its content is defined by its users, not by its operator -- it really is as impartial as it can possibly be. If its operator were to selectively de-list some of the people who asked then the result would be that the list would not be impartial any more. If you want someone using the DNS-BL at bl.spamcop.net who's blocking or filtering mail from you then you have to go directly to that person doing the blocking and ask them to whitelist your server(s). The same thing essentially goes for SPEWS or any other blacklist too. If you're operating a mail server that's listed in some blacklist, or providing connectivity for some customer who's IP#s are so listed, and you/they are being blocked by some mailer/firewall to which you/they are trying to connect to, then you should contact the administrators of the mailer/firewall doing the blocking. They're the ones in control here, not the blacklist operators! If you're spending all your time contacting blacklist users then maybe you should think about why so many of your good neighbours are using those blacklists, and why your mailer/network is getting listed in various blacklists. The very last thing you should do is try to contact any blacklist operator and try to gget them to remove the entry for your server(s) or network(s). If there's no de-list my server or re-check my server button on the main web site for a given blacklist then there's probably no mechanism, formal or otherwise, for getting de-listed (and there doesn't need to be). Your issue is with those using the blacklist to block your server(s) or network(s), not with the blacklist operator. Remember if you and/or your customers (or you on behalf of your customers) wish to connect to some remote network in order to deliver e-mail there or whatever, then the onus is on you to figure out why connection attempts might be being blocked and to negotiate to get the remote operator to lift their ban, not to moan and whine about why some shared blacklist manager might have listed your network and why they won't remove you or why they ignore you. Now that we've sorted out the operational procedures for dealing with these issues can we please stop all this silly whining? Thanks! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: SPEWS?
[ On Thursday, June 20, 2002 at 17:01:20 (-0400), David Charlap wrote: ] Subject: Re: SPEWS? Dan Hollis wrote: Its my box, my hardware, my property. No one has an inherent right to force speech on an unwilling recipient. If you're installing a blacklist on a mail server you keep at home for yourself, then yes. If you're running an ISP with thousands of customers, then you also have to deal with how you're impacting them. Sure, it may still be your equipment, but that won't matter if you tick off your paying customers and they decide to cancel their accounts and go to your competitors. You, or at least I, really don't want paying customers who demand to receive e-mail from known spam sources and open relays. They cost far to much in support to be worthwhile keeping -- I'd much sooner keep the good customers and get the support-heavy ones to go suck on some competitor's pipe! On the other hand a clever business person might want to set up two mailers for their customers -- one normal spam-free one; and another for those customers who want all their e-mail regardless of where it comes from. Maybe we can write up an RFC/BCP to define a standardized name like iwantspam for the second one, and mailboxes could always exist for every user on both servers and the users could choose to read from either or both, and the expiry policy and quotas could be set a bit lower on iwantspam one. :-) That way everyone who was getting bounces because they were using a spam-infested ISP would know to try sending to their friends a the standard iwantspam subdomain (and they could phone their friends to let them know legit e-mail was being sent there too! :-). In any case the onus is still on the sender to correct the problem, and after all they are paying the offending ISP for service too -- if they're not getting service because the offending ISP would rather have spammers than grandmas as customers then the best thing is for everyone to block the offending ISP's netblocks so that both grandma and the spammers will get the message that their service provider is no longer worth using. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Viri capture...
[ On Tuesday, June 18, 2002 at 18:30:33 (+0100), Stephen J. Wilcox wrote: ] Subject: Re: Viri capture... Are you suggesting us as end users should reprogram every OS and Email client rather than run a virus checker? Alternatives are not rare, difficult to use, or more limited in any significaant way. Even patches are not lacking, though in this case patching over such fundamental design flaws has proven time and time again to be fallible. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: ATTBI refuses to do reverse DNS?
[ On Tuesday, June 18, 2002 at 17:47:10 (-0400), Daniel Senie wrote: ] Subject: Re: ATTBI refuses to do reverse DNS? While I believe people SHOULD be providing INADDR service, the people hurt by refusing connections are rarely the ones who have any influence. On the contrary! The people who are supposedly hurt here are those who ultimately have the most influence. In the end they can vote with their wallets even if they can't edit the appropriate zone files directly. (And the whole idea behind DNS trust really revolves around having two different parties agree on the mapping, not in simply allowing the user to edit their own reverse DNS!) Just as Network Address Translation is not a security solution, neither is checking INADDR. I don't think anyone has said that DNS consistency is a security solution. You keep confusing these concepts I think. It's only one tiny part of the picture. Fully consistent DNS only increases the level of trust you can have in the hostnames used. Since hostnames are supposed to be more stable than IP addresses, you _want_ to have more trust in the hostnames, but with current protocols you cannot unless there is full consistency between forward and reverse lookups. Now if you check INADDR over Secure DNS, you might start having some level of information to trust. We can only hope, but I'll believe it when I see it. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: ATTBI refuses to do reverse DNS?
[ On Tuesday, June 18, 2002 at 16:54:54 (-0500), Stephen Sprunk wrote: ] Subject: Re: ATTBI refuses to do reverse DNS? So, if you ran Amazon.com, you wouldn't accept money from customers of clueless ISPs? Luckily Amazon.com and sites like it, and more importantly their customers, have the assurance of credit card banks to back up their transactions -- they don't really need any of this pesky Internet security B.S. to secure their transactions. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Bogon list
[ On Friday, June 7, 2002 at 10:26:53 (+0100), Stephen J. Wilcox wrote: ] Subject: Re: Bogon list RFC1918 does not break path-mtu, filtering it does tho.. So, in other words inappropriate use of RFC 1918 does not break Path MTU Discovery! You can't still have your cake and have eaten it too. One way or another RFC 1918 addresses must not be let past the enterprise boundaries. Lazy and/or ignorant people don't always meet all the requirements of RFC 1918, but it's only their lack of compliance that _may_ allow Path-MTU-discovery to continue working for their networks for _some_ people _some_ of the time. However any enterprise also using RFC 1918, but using it correctly (or customers of such an enterprise), and thus who are also carefully protecting their use from interference by outside parties, will be filtering inbound packets with source addresses in the RFC 1918 assigned networks, and so as a result they _will_ experience Path-MTU-discovery failure (i.e. at any time it's necessary it literally cannot work) when attempting to contact (and sometimes be contacted by, depending on the application protocol in use) any host on or behind the lazy and/or ignorant operator's network(s). (and no, I'm not sorry if I've yet again offended anyone who might be mis-using RFC 1918 addresses for public nodes -- you should all know better by now! How many _years_ has it been?) 2) Not believe in filtering RFC1918 sourced traffic at enterprise boundaries (of which an exchange would be a boundary) What for? You'll find many more much more mailicious packets coming from legit routable address space. If you have any IP address level trust relationsips on your internal LANs then you _MUST_ (if you want those trust relationships to be valid) filter all foreign packets with source addresses appearing to be part of your internal LANs. For p2p you can use unnumbered.. it wont work on exchanges but i agree they shouldnt be rfc1918. On this we can agree! :-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Bogon list
[ On Friday, June 7, 2002 at 15:28:56 (-0400), Stephen Griffin wrote: ] Subject: Re: Bogon list I agree, however, most folks want to see the topology, some just choose to violate RFC1918 in order to do it. Sometimes even I stoop so low! :-) # bloody rogers routers use these nets for interfaces, # thus we need to allow them for our own traceroutes to work # pass in quick proto icmp from 10.0.0.0/8 to 65.48.34.145 group 250 pass in quick proto icmp from 10.0.0.0/8 to 204.92.254.0/24 group 250 pass in quick proto icmp from 192.168.0.0/16 to 65.48.34.145 group 250 pass in quick proto icmp from 192.168.0.0/16 to 204.92.254.0/24 group 250 grrr -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: OT: Re: Bogon list
[ On Wednesday, June 5, 2002 at 23:22:38 (-0400), [EMAIL PROTECTED] wrote: ] Subject: Re: OT: Re: Bogon list 3) Remember that for procmail to nuke the second copy, the second copy has to arrive - I'm personally just a bit miffed at somebody who sent me 2 copies of a large file. Yes, procmail nuked the second one - *after* I'd pulled several hundred K over a modem. Indeed. That was my original point. I don't want to _receive_ two copies of any messages, especially not those that are also forwarded via any mailing list. I do what I can to ensure things work the way I desire for replies to my posts, and I'm surprised more people don't do what I do as well. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: packet sniffers and protocol decoders used by isps
[ On Tuesday, June 4, 2002 at 09:52:20 (+0200), Daniska Tomas wrote: ] Subject: packet sniffers and protocol decoders used by isps i'd like to make an idea of which sniffers and (the more important part) decoders are included in the arsenal of engineering tools used by network engineers at various isp sizes tcpdump and ethereal !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN Please DO NOT EVER send HTML, rich text, or otherwise stylized e-mail, especially not to me or to any public mailing list. Not all mail readers will recognize such formats. HTML in particular is a potential security threat and many firewalls filter it entirely -- especially since CERT and Microsoft recently anounced a very major flaw in the HTML rendering engine used in all Microsoft products. Please send all your messages as plain text only. Thanks! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Bogon list
[[ What's with the huge CC list everyone? Aren't we all subscribers? Do y'all enjoy getting multiple copies of replies? I don't! ;-) ]] [ On Tuesday, June 4, 2002 at 18:33:23 (-0700), Sean M. Doran wrote: ] Subject: Re: Bogon list | Why treat exchange subnets differently to any other bit of backbone | infrastructure? Oh, I wholeheartedly agree. I would love them all to use RFC 1918 addresses, because it is VERY VERY VERY rare that anything outside the scope in which the 1918 local use addresses are unique actually has to communicate with backbone infrastructure of any type. has to and can in this context are two very different things. If everyone filtered source and destination bogons A.S.A.P.P. In short, ping traceroute are about the only interaction anyone will ever have with a router that is not under their control, excepting error messages (which is the usual way at least traceroute works), and it is NOT WORTH THE ADDRESS CONSUMPTION just to facilitate this. I'm not so sure I agree (traceroute can be fun), _BUT_, if such routers were to always use only one unique-to-themselves canonical routable address in all valid error messages that they generate then there wouldn't be such a problem. Providers would at the same time enjoy the benefits of hiding all the niggling interface details while not borking tools that the little guys a the edge have used to point the finger from time immemorial Regrettably, IP sux in the confusing of where and what, so the only way to know who sent you the error ICMP datagram except by the source address. Indeed, but IIRC there's nothing which says a router has to emit error replies using the source address of the interface the undeliverable packet arrived on, is there? If a given router uses a single unique-to-itself canonical globally routable source address for all ICMP error replies it generates then the output of the likes of traceroute and even ping will still be meaningful and useful. No important information is lost, at least not from the point of view of everyone _without_ a login on the router in question at least (and if you can login to the router then I should hope you can figure out what interface the undeliverable packets are arriving on without any external help!). Isn't there even an IOS command to make it so, or am I dreaming visions of some as-yet unimplemented BSD-based router feature again? -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Is this list working?
[ On Thursday, May 30, 2002 at 13:05:18 (-0500), John Palmer wrote: ] Subject: Is this list working? Posted a message several times and it never made it out Is the list broken? In the past there have been low-level networking issues somewhere out there that were causing problems with the Merit mailers sending messages to my mailer. TCP traces at this end only showed the connection hanging, as if there were a PMTUd problem (though there's no such problem at my end any more). Eventually it got so bad I was only receiving about 1% of the postings and the MLM eventually unsubscribed me for too many bounces. Lately though it's been running OK for me, and I've not seen any stuck SMTP connections from Merit on my mail server. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Routers vs. PC's for routing - was list problems?
[ On Friday, May 24, 2002 at 04:50:27 (-), Joseph T. Klein wrote: ] Subject: Re: Routers vs. PC's for routing - was list problems? Didn't National Semiconductor have a spec sheet for write only memory back in the late 70s or early 80s? I think they developed it for the NSA. Not long ago I finished reading one of Stephen R. Donaldson's The Gap series (the second -- I don't know if I'll bother with more of them) where secure write-only core is said to be the foundation for interstellar security. Basically it's for keeping an unbreakable and unmodifiable record of all ship functions and communications. Only authorised police have keys to read it, but it supposed to be physically unalterable once written. Of course it turns out what's written to it is not quite so indelible as most people are lead to believe :-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: portscans (was Re: Arbor Networks DoS defense product)
[ On Sunday, May 19, 2002 at 16:30:48 (-0700), Dan Hollis wrote: ] Subject: Re: portscans (was Re: Arbor Networks DoS defense product) On Sun, 19 May 2002, Greg A. Woods wrote: Such technology is very dangerous if automated. And if its not? If it's not an automated system then it's only as dangerous as the person(s) controlling it, plus whatever propensity they have for making unintended errors that would not be made by a properly tested automatic system -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: portscans (was Re: Arbor Networks DoS defense product)
[ On Sunday, May 19, 2002 at 03:16:28 (-0700), Dan Hollis wrote: ] Subject: Re: portscans (was Re: Arbor Networks DoS defense product) On 18 May 2002, Scott Gifford wrote: Before choosing an onling bank, I portscanned the networks of the banks I was considering. It was the only way I could find to get a rough assessment of their network security, which was important to me as a customer for obvious reasons. So for your offline banks, do you also go to the local branches at night and jiggle all the locks to make sure their doors and windows are locked? That analogy is fundamentaly flawed. For one the Interent is never locked after hours -- there is no after hours, it's always open! There are also no sign posts at every router on the Internet. The only sign-posts are the responses you get from trying a given door -- either it opens or it doesn't. Unless you actually try to go somewhere in TCP/IP-land you won't know whether or not you can get there. A good firewall makes it appear for all intents and purposes that there's no door handle to wiggle in the first place. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: portscans (was Re: Arbor Networks DoS defense product)
[ On Sunday, May 19, 2002 at 11:22:08 (-0400), Ralph Doncaster wrote: ] Subject: Re: Re[4]: portscans (was Re: Arbor Networks DoS defense product) I think that's pretty stupid. If I had my network admin investigate every portscan, my staff costs would go up 10x and I'd quickly go bankrupt. Indeed -- and we can only hope. I know a few companies who actually do that, and sometimes their policies about how they do it are so broken they refuse to acknowledge the difference between the likes of a squid cache server just doing its job and a compromised Windoze box scanning for web servers. :-) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: Re[8]: portscans (was Re: Arbor Networks DoS defense product)
[ On Sunday, May 19, 2002 at 14:14:18 (-0400), Allan Liska wrote: ] Subject: Re[8]: portscans (was Re: Arbor Networks DoS defense product) However, if the same network is continuously portscanning your network that network should be stopped. Unless you're also a tier-1 kind of provider you don't usually get to control the AUP for other networks unrelated to your own. How do you propose to resolve a fundamental conflict between your own users need to access the content on a network that also happens to be regularly scanning your network? Unless real damage is done you probably don't even have any recourse under the law, even if you do happen to be in the same jurisdiction (and heaven help us should any such recourse ever become possible in the free world!). Unless you expect to be vulnerable to attack and thus really need to have a record of past scans in case they can be used in evidence; or maybe unless you're doing research into scanning activities; even keeping long-term logs of all scans becomes more of a burden than it's worth. You will be scanned. Resistance is futile! I.e. get over it! ;-) (Actually, that's not as bad of an analogy -- look at how active scans are handled in science fiction, such as in Star Trek. Sometimes they're treated as hostile, sometimes not. Scans aren't just used to target weapons -- they're also used to detect life signs on rescue missions! Certainly unless the captain is scared witless he or she has never held back on doing an active scan when information is needed, and when he or she is scared of detection a variety of stealth scans are often still attempted.) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: portscans (was Re: Arbor Networks DoS defense product)
[ On Sunday, May 19, 2002 at 17:45:36 (-0400), Benjamin P. Grubin wrote: ] Subject: RE: Re[8]: portscans (was Re: Arbor Networks DoS defense product) If you separate the pointless argument about the hostility of portscans and the viability of a distributed landmine system, this may turn out to be a useful discussion in the end. I mean--we all know portscans are hardly the ideal trigger anyhow. On top of the potential ambiguity of their intention, they are also difficult to reliably detect. The distributed landmine tied to subscription blackhole ala RBL may very well have significant positive attributes that are being drowned out due to the portscan debate. Obviously the vast majority in the spam world think RBL and/or ORBS have merit, despite the vocal complaints. Why not discuss viable alternative trigger methods instead of whining about portscans? Well, there is still the issue of discovering the intent of a scan, regardless of how many landmines have to be triggered before a blackhole listing is put in place. Such technology is very dangerous if automated. Anyone with sufficient intelligence to find enough of the landmine systems could probably also figure out how to trigger them in such a way as to DoS any random host or network at will (assuming enough networks to matter used the listing service in real time). Unless there's also a sure-fire automated way of quickly revoking such a black list entry, as well as a free white-listing service, the consequences are far too dire to earn my support. On the other hand SMTP open relay blackholes are easy to prove and usually easy enough to fix and get de-listed from. Even the Spamcop realtime DNS list bl.spamcop.net is pretty hard to trick, and of course it's not really widely enough used that getting listed there is all that disruptive (apparently, since listed sites keep sending spam with no apparent degradation in their throughput). -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: portscans (was Re: Arbor Networks DoS defense product)
[ On Saturday, May 18, 2002 at 16:03:11 (-0700), Scott Francis wrote: ] Subject: Re: portscans (was Re: Arbor Networks DoS defense product) And why, pray tell, would some unknown and unaffiliated person be scanning my network to gather information or run recon if they were not planning on attacking? I'm not saying that you're not right, I'm just saying that so far I have heard no valid non-attack reasons for portscans (other than those run by network admins against their own networks). I scan networks and hosts very regularly for legitimate diagnostic purposes as well as occasionally for curiosity's sake. I've never attacked any host or network that I was not directly responsible for. If you don't want the public portions of your network mapped then you should withdraw them from public view. BTW, please be one heck of a lot more careful with your replies. My original reply to you was not copied to the list and I did not give you permission to post a response quoting my words back to the list. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
Re: portscans (was Re: Arbor Networks DoS defense product)
[ On Saturday, May 18, 2002 at 20:15:10 (-0700), Scott Francis wrote: ] Subject: Re: portscans (was Re: Arbor Networks DoS defense product) Apologies; my finger was a bit too quick on the 'g'. As this message came to the list, I will assume it is safe to cc the list on my reply. Sorry about that last. Apology accepted, but I strongly recommend you learn to use some more reliable mail reader software -- something that doesn't accidentally invent reply addresses! There was no hint that my message to you was in any way associated with the NANOG list -- it was delivered directly to you and CC'd only to the person you were responding to. Some outside influence had to have associated it with having been a reply to a list posting and connected your desire to reply with inclusion of the list submission address. According to your reply's headers you're using Mutt-1.3.25i, and according to the Mutt manual 'g' is the group-reply command. I don't find any hint in the description of that command to indicate that it will magically associate a given message with a list, especially one that was not received from the list. Even the 'list-reply' command should not be able to associate a private reply with the list address. If Mutt really does magically associate private replies with list addresses by some mysterious mechanism then it's even more broken than I suspected. -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
