Re: NTP security
On one of my multihomed machines together with authentication I tend to use something like: restrict default ignore restrict ntpserver1 nomodify restrict ntpserver2 nomodify restrict ntpserver3 nomodify restrict network1 mask netmask1 notrust nomodify restrict network2 mask netmask2 notrust nomodify restrict network3 mask netmask3 restrict 127.0.0.1 Basically this synchronizes time using the 3 server sources and then via a broadcast server config it advertises the time to network1, network2, and network3. network3 however is the only network which administrative requests may be honored from, or localhost. See the other popular thread right now for locking down your interfaces on a ip forwarding machine. g Combined with a packet filter this should offer pretty good protection, though it will be somthing you have to watch as your server addresses can change with little warning. On the subject of securing NTP, has anyone gotten the autokey stuff to work the version of ntpd in stable? -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Mon, Mar 12, 2001 at 11:11:40PM +, Jim Breton wrote: Again, I'm not disagreeing with you. rp_filter and source checking has nothing to do with the issue though. The question posed was about packet destinations, and you keep referring to source checks. Arggghh! Sorry, you're right. I was pretty sure that linux checked the dest of packets before accepting them, so I guess my brain decided to read it wrong and think you were talking about what I expected you to be a talking about :( I decided to check this out, partly since I owe you one for being an idiot and not listening to what you told me twice! llama is 10.0.0.1, MAC 00:00:92:96:51:C0. bigfoot is 10.0.0.4, MAC 00:05:02:D4:B7:0A. On bigfoot, I used arp -s to point a nonexistant IP to the same MAC address as llama, a linux machine running 2.2.18. bigfoot:~# arp Address HWtype HWaddress Flags Mask Iface 10.0.0.10ether 00:00:92:96:51:C0 CM eth0 llamaether 00:00:92:96:51:C0 C eth0 bigfoot:~# nc 10.0.0.10 25 (UNKNOWN) [10.0.0.10] 25 (smtp) : No route to host before attempting the connection, I did: llama:~# tcpdump -p -e -n -i eth1 port ! ssh tcpdump: listening on eth1 22:03:23.249795 0:5:2:d4:b7:a 0:0:92:96:51:c0 0800 74: 10.0.0.4.3641 10.0.0.10.25: S 1026521176:1026521176(0) win 5840 mss 1460,sackOK,timestamp 59103824 0,nop,wscale 0 (DF) 22:03:23.250230 0:0:92:96:51:c0 0:5:2:d4:b7:a 0800 102: 10.0.0.1 10.0.0.4: icmp: redirect 10.0.0.10 to host 10.0.0.10 [tos 0xc0] 22:03:23.250502 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.10 tell 10.0.0.1 22:03:24.243578 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.10 tell 10.0.0.1 22:03:25.243324 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.10 tell 10.0.0.1 22:03:26.243237 0:0:92:96:51:c0 0:5:2:d4:b7:a 0800 102: 10.0.0.1 10.0.0.4: icmp: host 10.0.0.10 unreachable [tos 0xc0] Notice that with the interface not in promiscuous mode (-p), tcpdump still received the SYN packet, but the kernel didn't start a connection. exim is listening on *:25, (i.e. INADDR_ANY, not the interface addresses). nc 10.0.0.1 25 connects to exim normally. It's not so easy to check what happens if you send a packet with a destination in 127.0.0.0/8, but I'd be surprised if it was accepted. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Firewalling
Hi All Have created a file which contains all my ipchains rules and I would like it to start when the machine loads. Not sure where the best place is for this. I used to use rc.local on RH but was told that this is a bush job and very sloppy as for debian, well used to use the network file on slink. Any suggestions or assistance would be appreciated :) Thanks Craig
Re: Firewalling
On Tue, Mar 13, 2001 at 09:15:20AM +0200, Craig wrote: Hi All Have created a file which contains all my ipchains rules and I would like it to start when the machine loads. Not sure where the best place is for this. I used to use rc.local on RH but was told that this is a bush job and very sloppy as for debian, well used to use the network file on slink. Any suggestions or assistance would be appreciated :) Thanks Craig look in /etc/rc?.d is a number or letter. Find the spot where your interfaces are enabled and choose that spot. then use update-rc.d to insert the symlinks for you. You should make your script only do something useful when $1 = "start" Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firewalling
Hi Wade, I'm fairly sure that this is "debian-illegal" way to do it, but I created a "firewall" script in /etc/init.d, and then the correct symlinks to that script from the RC directories. The files are: -rwxr-xr-x387 Nov 7 22:43 init.d/firewall* lrwxrwxrwx 18 Oct 7 23:36 rc2.d/S21firewall - ../init.d/firewall* lrwxrwxrwx 18 Oct 7 23:36 rc6.d/K21firewall - ../init.d/firewall* ...yes - you are right its "debian-illegal" :-) the proper way is add the script to /etc/init.d/ and then: update-rc.d SCRIPTNAME defaults then it adds the script to all /etc/rc*.d/ in the right way with S* for starting and K* for shutting down. for further information have a look at the manpage. just a hint for the future :-) regards joris -- Joris Mocka, Leiter Abt. IuK SBF Gruppe Tel: +49 211 20 99 51 31 Steinhof 51 Fax: +49 211 20 99 51 88 D-40699 Erkrath http://www.sbf.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
potato camediaplay security problem
Is this important enough to backport to potato? If so, should I do that myself, or should the security team? Thanks. The potato version of camediaplay, camediaplay980118-1 Still Camera Digital Interface installs its binary suid 'uucp': -r-sr-xr-x1 uucp bin 17132 Feb 18 1998 /usr/bin/camediaplay and has this runtime option: -Nxxx Specify the output filename, in sprintf() format. Default is: pic%05d.jpg. (Be careful about escaping shell meta characters!) I've recently adopted, updated, and uploaded to unstable camediaplay20010211-2 Still Camera Digital Interface which isn't suid (I instead suggest that users be added to the 'dialout' group) -rwxr-xr-x1 root root20860 Mar 7 23:06 /usr/bin/camediaplay and in which the upstream author has removed the -N option for security reasons. In case I shouldn't upload it myself, the following patch to the camediaplay 20010211-2 rules file allows it to compile and build on current potato, and the resulting package works for me: --- debian-work/camediaplay/debian/rulesWed Mar 7 22:23:39 2001 +++ /home/david/camediaplay-20010211/debian/rules Mon Mar 12 00:03:07 2001 @@ -6,7 +6,7 @@ #export DH_VERBOSE=1 # This is the debhelper compatibility version to use. -export DH_COMPAT=3 +export DH_COMPAT=2 build: build-stamp @@ -63,7 +63,7 @@ # dh_installmime # dh_installinit # dh_installcron - dh_installman src/camediaplay.1 + dh_installmanpages src/camediaplay.man # dh_installinfo # dh_undocumented dh_installchangelogs
Re: Is it possible to chroot scp?
[EMAIL PROTECTED] wrote: Hello. I have been setting up a webserver that users need to acess remotely. The problem is that I don't like the way that ftp sends passwords plaintext. I am currently useing proftpd, as I also require the ability to chroot users into thier own directories. Now, essentialy what I need is to have windoze users login w. some sort of point click client, be able to drag stuff too from the server, and not be able to mess with, or even know about, other peoples' files. (I have to assume that they cannot use DOS, let alone do an scp from it) I have found a few, such as ixplorer and winSCP, however, again, they allow one to specify a directory above thier home. I have heard that the commercial ssh version offers the ability to chroot, but I would rather stay with OpenSSH if I can. Does anyone have any suggestions, short of doing a chmod a-r * -R from / ? A PAM module is apparently a work-in-progress to perform chroot() at the PAM level. Email Bruce Campbell [EMAIL PROTECTED] and ask about its status. Regards, Alex.
[ot] our hero (was: Is it possible to chroot scp?)
On Mon, Mar 12, 2001 at 12:03:51AM -0800, Alexander Hvostov wrote: [snip] A PAM module is apparently a work-in-progress to perform chroot() at the PAM level. Email Bruce Campbell [EMAIL PROTECTED] and ask about its status. interesting -- I wasn't aware Mr Campbell was about to protect us from the Evil Dead once more. sorry...couldn't resist :) Jörgen
Re: Is it possible to chroot scp?
Hi, On Sun, 11 Mar 2001 [EMAIL PROTECTED] wrote: I have been setting up a webserver that users need to acess remotely. The problem is that I don't like the way that ftp sends passwords plaintext. I am currently useing proftpd, as I also require the ability to chroot users into thier own directories. Now, essentialy what I need is to have windoze users login w. some sort of point click client, be able to drag stuff too from the server, and not be able to mess with, or even know about, other peoples' files. (I have to assume that they cannot use DOS, let alone do an scp from it) I have found a few, such as ixplorer and winSCP, however, again, they allow one to specify a directory above thier home. I have heard that the commercial ssh version offers the ability to chroot, but I would rather stay with OpenSSH if I can. Does anyone have any suggestions, short of doing a chmod a-r * -R from / ? Have you considered https POSTs with write permissions only for users' home directory? Its fairly easy to setup with apache, uses encryption (SSL) and allows fine-grained access control. Plus, even Netscape composer supports such uploads directly... Regards, Siggi
Re: Kernel 2.2.15 hole ?
There were some other security holes in the kernel which was corrected in 2.2.19pre9 or somewhere around that pre-release concerning the signed/unsigned usage of some int variables. I think this is a sufficient reason for upgrading. Regards, Robert Varga On Mon, 5 Mar 2001, David Wright wrote: Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): On Mon, Mar 05, 2001 at 03:31:07AM -0900, Ethan Benson wrote: On Thu, Mar 01, 2001 at 03:34:21AM +, Stephen Walton wrote: Has anyone seen the announcement about a root exploit in the 2.2.15 and earlier kernel versions as posted yes ages ago. Does this apply to the debian kernels? depends what debian kernel, i think some of them had backported patches, but really there is no reason to be running anything that old. upgrade to 2.2.18. I purposely have a policy of not upgrading software (including the kernel) unless there is a good reason to do so, either with new functionality that is required, or for security reasons. I have no objections to upgrading in this instance, but I was more concerned that a search on Debians archives did not show this as a security issue. Perhaps it's at http://www.uk.debian.org/security/2000/2612 ? i.e. 2.2.15-3 is patched. Cheers, -- Email: [EMAIL PROTECTED] Tel: +44 1908 653 739 Fax: +44 1908 655 151 Snail: David Wright, Earth Science Dept., Milton Keynes, England, MK7 6AA Disclaimer: These addresses are only for reaching me, and do not signify official stationery. Views expressed here are either my own or plagiarised. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Sat, Mar 10, 2001 at 05:20:26PM +, Jim Breton wrote: On Sat, Mar 10, 2001 at 10:22:48AM -0600, Ted Cabeen wrote: if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr)) goto martian_destination; This is part of the routing check for incoming packets. It should take care of the problem being discussed. :) (I haven't tested this section of the code, but it should prevent that kind of attack, I think) It should yes, however see the recent thread on Bugtraq about this issue. Also since log_martians is not enabled by default (unless your distro does so, and afaict potato at least does not) you will never hear a word about these packets. Logging them would be nice. Even with log_martians enabled, it doesn't tell you anything about the packet other than src, dst, and iface. Further, I'm not sure the martian code would stop a packet from landing on an internal interface other than loopback (again see the Bugtraq discussion) which is why we should (and do) filter the destination addresses of incoming packets as well as the source addresses. Doesn't rp_filter do this, or am I missing something? It should make the kernel drop packets coming in on interfaces they shouldn't be, e.g. 10.0.0.0 packets coming from an interface to 192.168.1.0. (It will break asymmetric routing setups, where packets do come in on a different interface from the one replies will be sent on, so you have to do it manually with ipchains for that case. Otherwise, you don't even need to compile ipchains into the kernel for rp_filter to work.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: NTP security
On Sat, Mar 10, 2001 at 11:28:50PM -0600, Bryan Andersen wrote: Jamie Heilman wrote: I noticed that /etc/services has a tcp entry for ntp. Is there any way (short of changing the code) to coax ntp to use tcp instead of udp ? No, UDP is intrinsic to how NTP works. Actually it isn't. A bi-directional link is usually needed, but it seams the latest version also supports connecting to a multicast network for broadcasting the current time or for receiving it. In this case there is an unknown amount of network lag between the transmitter and receiver. For most computers this isn't a problem as it's unlikely the lag will be over 500 ms. Most computers only need 1 second accuracy if that even. That still uses UDP. Broadcast or multicast UDP, but still UDP. NTP is different from DNS and other stuff in that it is a real-time protocol. Running it over TCP would be trememdously stupid, because you'd have to try to figure out whether you were seeing a retransmitted segment or not, etc. In NTP, the information is carried by the arrival time of the packet, as well as the data in it. Using TCP hides retransmissions from the application, and deprives the application of timing information necessary for NTP to operate. (You could try to work around it by looking at the RTT, and rejecting too-high RTTs, but nobody would want to write that since UDP is exactly what is needed for NTP (assuming it has to run over an IP network. Other networks could do even better for time synchronization by providing (near) constant latency if asked, or something.)) So, in summary, you would have to do a whole lot more than just change SOCK_DGRAM to SOCK_STREAM in the code. You would have to write and tweak some code to work around TCP's retransmission algorithm, since retransmitted packets are useless to you because of the unknown extra delay. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
RE: NTP security
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, March 10, 2001 9:29 PM Subject: Re: NTP security [...] See Ultra-Link, http://www.ulio.com/ for a low cost battery powerable atomic clock radio receiver. It has a 3V inverted TTL RS-232 link that runs at 2400 or 9600 baud. Power draw is +3.5V to 15V at 600uA. Last I knew the ntp daemon knew how to talk to this guy. It's available as a board set or in cases with proper RS-232 signal levels, power supply, etc. I thought that ntpdate was what you wanted to use in this instance.
Re: 127.0.0.0/8 addresses from the network
On Mon, Mar 12, 2001 at 06:36:25PM +, Jim Breton wrote: On Mon, Mar 12, 2001 at 02:31:57PM -0400, Peter Cordes wrote: Doesn't rp_filter do this, or am I missing something? It should make the kernel drop packets coming in on interfaces they shouldn't be, e.g. 10.0.0.0 packets coming from an interface to 192.168.1.0. It does do what you describe; however the original question is about evil packet _destinations_ and not evil packet _sources._ No, I just checked linux/Documentation/filesystems/proc.txt, and it points out that this is a source check. Destination is always checked, since it is incorrect not to do so, not just a security risk. rp_filter filters out some packets that are allowed by the protocols, but are obviously bogus in a normal network. - rp_filter - Integer value determines if a source validation should be made. 1 means yes, 0 means no. Disabled by default, but local/broadcast address spoofing is always on. If you set this to 1 on a router that is the only connection for a network to the net, it will prevent spoofing attacks against your internal networks (external addresses can still be spoofed), without the need for additional firewall rules. - -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: 127.0.0.0/8 addresses from the network
On Mon, Mar 12, 2001 at 06:58:07PM -0400, Peter Cordes wrote: On Mon, Mar 12, 2001 at 06:36:25PM +, Jim Breton wrote: It does do what you describe; however the original question is about evil packet _destinations_ and not evil packet _sources._ No, I just checked linux/Documentation/filesystems/proc.txt, and it points out that this is a source check. Destination is always checked, since it is incorrect not to do so, not just a security risk. rp_filter filters out some packets that are allowed by the protocols, but are obviously bogus in a normal network. Again, I'm not disagreeing with you. rp_filter and source checking has nothing to do with the issue though. The question posed was about packet destinations, and you keep referring to source checks. Read the original post again. Also read my post where I mentioned that more verbose logging of such a packet may be useful; the kernel's martian logging is not very verbose. Try it and you will see what I mean. Fwiw whether the firewall framework in 2.2 will even pick it up in the input chain is beyond me, you would have to try it. 2.4 won't, you have to do it in the mangle table as far as I can tell (works for me there, but not in the filter table). Thanks.
Re: NTP security
At 10:32 -0600 3/10/2001, Piotr Tarnowski wrote: Hi, I've installed NTP daemon on my firewall (with sync to external machine) and on all internal machines (with sync to my firewall). I found that this had opend port 123/udp on my firewall, so now everybody from the net can use my machine as a server. I have nothing against this as long as this is secure. Is it ? If not can I limit allowed clients somehow ? (I noticed that DENY on ipchains to others than my reference external server limits ntptrace usage). Best regards, Piotr Tarnowski As detailed here: http://www.eecis.udel.edu/~ntp/ntp_spool/html/accopt.htm Some access control is supposed to be built into NTP, but I never got it to work correctly (could be my fault, i dunno.) As soon as I activiated it, nptd stopped updating from any time server. Here's what I had in my ntp.conf file: # don't trust anyone else's clock, or allow config changes # restrict default notrust nomodify # trust timeservers for time, but don't allow config changes # note masks don't have to be the same network mask that the # specified ip uses. using a mask of 255.255.255.255 applies # a rule to that specific ip. A shorter mask applies # the rule to more computers. When a packet arrives the rule # with the most matching bits in the mask is used # restrict time.server.1.ip mask 255.255.255.255 # restrict time.server.2.ip mask 255.255.255.255 # restrict time.server.3.ip mask 255.255.255.255 So instead I locked down access on the external interface to just the time servers I use. In my firewall script I put: TIME_SERVERS=time.server.1.ip time.server.2.ip time.server.3.ip time.server.4.ip for TIMESERVER in $TIME_SERVERS do echo Allowing client access to time server $TIMESERVER ... ipchains -A output -i $EXTERNAL_INTERFACE -p udp \ -s $IPADDR $UNPRIVPORTS \ -d $TIMESERVER 123 -j ACCEPT ipchains -A input -i $EXTERNAL_INTERFACE -p udp \ -s $TIMESERVER 123 \ -d $IPADDR $UNPRIVPORTS -j ACCEPT # these seem to allow a local time server running # on port 123 to sync with another time server on port # 123 ipchains -A output -i $EXTERNAL_INTERFACE -p udp \ -s $IPADDR 123 \ -d $TIMESERVER 123 -j ACCEPT ipchains -A input -i $EXTERNAL_INTERFACE -p udp \ -s $TIMESERVER 123 \ -d $IPADDR 123 -j ACCEPT done Not super secure as it does nothing against spoofing (guess that's really only possible with a digitally signed time server signature), but it sufficed for me. Kevin
Re: NTP security
On one of my multihomed machines together with authentication I tend to use something like: restrict default ignore restrict ntpserver1 nomodify restrict ntpserver2 nomodify restrict ntpserver3 nomodify restrict network1 mask netmask1 notrust nomodify restrict network2 mask netmask2 notrust nomodify restrict network3 mask netmask3 restrict 127.0.0.1 Basically this synchronizes time using the 3 server sources and then via a broadcast server config it advertises the time to network1, network2, and network3. network3 however is the only network which administrative requests may be honored from, or localhost. See the other popular thread right now for locking down your interfaces on a ip forwarding machine. g Combined with a packet filter this should offer pretty good protection, though it will be somthing you have to watch as your server addresses can change with little warning. On the subject of securing NTP, has anyone gotten the autokey stuff to work the version of ntpd in stable? -- Jamie Heilman http://audible.transient.net/~jamie/ ...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity... -Rimmer
Re: 127.0.0.0/8 addresses from the network
On Mon, Mar 12, 2001 at 11:11:40PM +, Jim Breton wrote: Again, I'm not disagreeing with you. rp_filter and source checking has nothing to do with the issue though. The question posed was about packet destinations, and you keep referring to source checks. Arggghh! Sorry, you're right. I was pretty sure that linux checked the dest of packets before accepting them, so I guess my brain decided to read it wrong and think you were talking about what I expected you to be a talking about :( I decided to check this out, partly since I owe you one for being an idiot and not listening to what you told me twice! llama is 10.0.0.1, MAC 00:00:92:96:51:C0. bigfoot is 10.0.0.4, MAC 00:05:02:D4:B7:0A. On bigfoot, I used arp -s to point a nonexistant IP to the same MAC address as llama, a linux machine running 2.2.18. bigfoot:~# arp Address HWtype HWaddress Flags Mask Iface 10.0.0.10ether 00:00:92:96:51:C0 CM eth0 llamaether 00:00:92:96:51:C0 C eth0 bigfoot:~# nc 10.0.0.10 25 (UNKNOWN) [10.0.0.10] 25 (smtp) : No route to host before attempting the connection, I did: llama:~# tcpdump -p -e -n -i eth1 port ! ssh tcpdump: listening on eth1 22:03:23.249795 0:5:2:d4:b7:a 0:0:92:96:51:c0 0800 74: 10.0.0.4.3641 10.0.0.10.25: S 1026521176:1026521176(0) win 5840 mss 1460,sackOK,timestamp 59103824 0,nop,wscale 0 (DF) 22:03:23.250230 0:0:92:96:51:c0 0:5:2:d4:b7:a 0800 102: 10.0.0.1 10.0.0.4: icmp: redirect 10.0.0.10 to host 10.0.0.10 [tos 0xc0] 22:03:23.250502 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.10 tell 10.0.0.1 22:03:24.243578 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.10 tell 10.0.0.1 22:03:25.243324 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 10.0.0.10 tell 10.0.0.1 22:03:26.243237 0:0:92:96:51:c0 0:5:2:d4:b7:a 0800 102: 10.0.0.1 10.0.0.4: icmp: host 10.0.0.10 unreachable [tos 0xc0] Notice that with the interface not in promiscuous mode (-p), tcpdump still received the SYN packet, but the kernel didn't start a connection. exim is listening on *:25, (i.e. INADDR_ANY, not the interface addresses). nc 10.0.0.1 25 connects to exim normally. It's not so easy to check what happens if you send a packet with a destination in 127.0.0.0/8, but I'd be surprised if it was accepted. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
