From owner-freebsd-hackers Fri Sep 22 10:30:41 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA11003 for hackers-outgoing; Fri, 22 Sep 1995 10:30:41 -0700 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA10998 for ; Fri, 22 Sep 1995 10:30:39 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id KAA08820 for ; Fri, 22 Sep 1995 10:26:18 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id NAA05628 for ; Fri, 22 Sep 1995 13:48:11 +0100 To: freebsd-hackers@FreeBSD.ORG Subject: iijppp Date: Fri, 22 Sep 1995 13:48:09 +0100 Message-ID: <5626.811774089@palmer.demon.co.uk> From: Gary Palmer Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Hi I've got a setup which works for me, but it has it's problems. The cause: I filter which packets are used to dial out (the `dfilter'). One of the ports I ignore is the smtp port, so that when I send mail, it'll get queued rather than running up my phone bill. Then I can dial in when I've replied to my entire inbox and unbatch the mails. (I also filter DNS so that sendmail can't force a dial out that way either). Problem: sendmail doesn't know that it's packets are going to /dev/null. This lead to a problem yesterday in that sendmail timed out its attempts to contact the advertised MX hosts for a site, but I have a `fallback' MX defined, mainly 'cos the net doesn't seem reliable enough nowadays (at least when being accessed through my ISP) for me to just use advertised MX's. So, the mail went merrily off to my ISP's mail host for queueing and delivery. 17 hours later it appears at it's destination. Considering that the mail had time sensitive info in it, I was not best pleased. Suggestion: would it be a good idea to make IIJPPP return ``ICMP net unreachable'' or something when it receives packets which are ignored as a result of the dfilter, and the connection isn't up or in the process of coming up. It just seems daft to let things time out when we have the technology to handle this in a better fashion... Comments? Gary