RE: what is *.da.uu.net?
TNT usually refers to the equipment, I believe it is a large-scale access hardware made by Ascend. The TNT line is for carriers and takes in multiple T1 or PRI lines. I'm not sure if those .da.uu.net or exclusively dial-up addresses, you might end up blocking their co-lo customers or someone like that whom you might want to be able to receive mail from. Maybe try forwarding the spam to [EMAIL PROTECTED] and see if they actually do something about it. They usually don't but it doesn't hurt to try... Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 10, 2000 9:27 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: what is *.da.uu.net? What kind of service is *.tnt.city.state.da.uu.net, or for example 1Cust147.tnt7.fort-lauderdale.fl.da.uu.net? SPAM from these addresses is not being blocked by DULS. traceroute suggests to me an above.net colo at uu.net? (my guess) We're running the collected SPAMPATCH patches. Does it make sense to block *.da.uu.net in badmailpatterns or might there better way of doing it with tcpserver? Frankly, depending on what tnt is I'm tempted to block all da.uu.net. The addresses along the path change with each instance; only the source address seems consistent. Can anyone tell me what this is and suggest the best approach to stopping this sort of SPAM? Thanks, cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Content management, electronic commerce, internet integration, Debian linux >From [EMAIL PROTECTED] Sun Dec 10 15:43:17 2000 Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: (qmail 1322 invoked from network); 10 Dec 2000 15:43:16 - Received: from gray.maine.com (204.176.0.13) by sooshi.maine.com with SMTP; 10 Dec 2000 15:43:16 - Received: (qmail 26767 invoked by alias); 10 Dec 2000 15:42:35 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 26749 invoked from network); 10 Dec 2000 15:42:33 - Received: from co-location.ibtoday.iasiaworks.ne.kr (HELO ns.asiatrans.com) ([EMAIL PROTECTED]) by gray.maine.com with SMTP; 10 Dec 2000 15:42:33 - Received: from mail1.joymail.com (1Cust147.tnt7.fort-lauderdale.fl.da.uu.net [63.25.243.147]) by ns.asiatrans.com (8.9.3/8.9.3) with SMTP id AAA15685 for <[EMAIL PROTECTED]>; Mon, 11 Dec 2000 00:40:45 +0900 Message-ID: <> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Bcc: Subject: RE: Your Christmas Present. Date: Sun, 10 Dec 2000 10:20:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Status: RO Content-Length: 509 Lines: 19 and: >From [EMAIL PROTECTED] Sun Dec 10 15:43:20 2000 Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: (qmail 1334 invoked from network); 10 Dec 2000 15:43:19 - Received: from gray.maine.com (204.176.0.13) by sooshi.maine.com with SMTP; 10 Dec 2000 15:43:19 - Received: (qmail 26799 invoked by uid 501); 10 Dec 2000 15:42:38 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 26787 invoked from network); 10 Dec 2000 15:42:37 - Received: from unknown (HELO mail.megatrans.co.kr) ([EMAIL PROTECTED]) by gray.maine.com with SMTP; 10 Dec 2000 15:42:37 - Received: from mail1.joymail.com (1Cust147.tnt7.fort-lauderdale.fl.da.uu.net [63.25.243.147]) by mail.megatrans.co.kr (8.9.3/8.9.3) with SMTP id AAA17694 for <[EMAIL PROTECTED]>; Mon, 11 Dec 2000 00:43:18 +0900 Message-ID: <> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Bcc: Subject: RE: Your Christmas Present. Date: Sun, 10 Dec 2000 10:20:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Status: RO Content-Length: 547 Lines: 19 You have seen it on TV! Hard Copy, Howard Stern, Extra, Inside Edition, Etc... You have heard about it from friends! Now go and see for yourself! Click http://1082394634/hardcore_celeb/index.html The site they don't want you to see. The site that they want shut down, but the first amendment protects us! Click http://1082394634/hardcore_celeb/index.html If link does not work, cut and paste in your browsers window. remove [EMAIL PROTECTED] ll 91317
what is *.da.uu.net?
What kind of service is *.tnt.city.state.da.uu.net, or for example 1Cust147.tnt7.fort-lauderdale.fl.da.uu.net? SPAM from these addresses is not being blocked by DULS. traceroute suggests to me an above.net colo at uu.net? (my guess) We're running the collected SPAMPATCH patches. Does it make sense to block *.da.uu.net in badmailpatterns or might there better way of doing it with tcpserver? Frankly, depending on what tnt is I'm tempted to block all da.uu.net. The addresses along the path change with each instance; only the source address seems consistent. Can anyone tell me what this is and suggest the best approach to stopping this sort of SPAM? Thanks, cfm -- Christopher F. Miller, Publisher [EMAIL PROTECTED] MaineStreet Communications, Inc 208 Portland Road, Gray, ME 04039 1.207.657.5078 http://www.maine.com/ Content management, electronic commerce, internet integration, Debian linux >From [EMAIL PROTECTED] Sun Dec 10 15:43:17 2000 Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: (qmail 1322 invoked from network); 10 Dec 2000 15:43:16 - Received: from gray.maine.com (204.176.0.13) by sooshi.maine.com with SMTP; 10 Dec 2000 15:43:16 - Received: (qmail 26767 invoked by alias); 10 Dec 2000 15:42:35 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 26749 invoked from network); 10 Dec 2000 15:42:33 - Received: from co-location.ibtoday.iasiaworks.ne.kr (HELO ns.asiatrans.com) ([EMAIL PROTECTED]) by gray.maine.com with SMTP; 10 Dec 2000 15:42:33 - Received: from mail1.joymail.com (1Cust147.tnt7.fort-lauderdale.fl.da.uu.net [63.25.243.147]) by ns.asiatrans.com (8.9.3/8.9.3) with SMTP id AAA15685 for <[EMAIL PROTECTED]>; Mon, 11 Dec 2000 00:40:45 +0900 Message-ID: <> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Bcc: Subject: RE: Your Christmas Present. Date: Sun, 10 Dec 2000 10:20:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Status: RO Content-Length: 509 Lines: 19 and: >From [EMAIL PROTECTED] Sun Dec 10 15:43:20 2000 Return-Path: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] Received: (qmail 1334 invoked from network); 10 Dec 2000 15:43:19 - Received: from gray.maine.com (204.176.0.13) by sooshi.maine.com with SMTP; 10 Dec 2000 15:43:19 - Received: (qmail 26799 invoked by uid 501); 10 Dec 2000 15:42:38 - Delivered-To: [EMAIL PROTECTED] Received: (qmail 26787 invoked from network); 10 Dec 2000 15:42:37 - Received: from unknown (HELO mail.megatrans.co.kr) ([EMAIL PROTECTED]) by gray.maine.com with SMTP; 10 Dec 2000 15:42:37 - Received: from mail1.joymail.com (1Cust147.tnt7.fort-lauderdale.fl.da.uu.net [63.25.243.147]) by mail.megatrans.co.kr (8.9.3/8.9.3) with SMTP id AAA17694 for <[EMAIL PROTECTED]>; Mon, 11 Dec 2000 00:43:18 +0900 Message-ID: <> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Bcc: Subject: RE: Your Christmas Present. Date: Sun, 10 Dec 2000 10:20:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Status: RO Content-Length: 547 Lines: 19 You have seen it on TV! Hard Copy, Howard Stern, Extra, Inside Edition, Etc... You have heard about it from friends! Now go and see for yourself! Click http://1082394634/hardcore_celeb/index.html The site they don't want you to see. The site that they want shut down, but the first amendment protects us! Click http://1082394634/hardcore_celeb/index.html If link does not work, cut and paste in your browsers window. remove [EMAIL PROTECTED] ll 91317
Re: A local mail server in sync with a .com
Devrim, > I have been looking for a solution for our mail server > problem on net and after reading lots of sendmail and > qmail documents I am totally confused :) Top tip: Sendmail bad. qmail good (particularly on this list... ;-) > My requirements are : > > 1. We have a domain name on net www.machsim.com, the > hosting company provides pop boxes but no SMTP > service. We need the linux box to send the messages. Straight qmail on this box - accept any SMTP message from your local IPs and let qmail sort out what to do with them using the DNS - you mention squid below, so it looks like this box can already do DNS lookups. > 2. We have a linux server at the company. It runs > squid etc. We want to use this PC for as an internet > and intranet mail server so that when > [EMAIL PROTECTED] sends a mail to > [EMAIL PROTECTED], message will never need to go > outside and stay in the intranet. Any mail that is > written to some other domain shall be sent via > internet. Have machsim.com in control/locals - and accounts for all your users on the Linux box to deliver to. > 3. We want the linux server to send the messages in > the queue and get mails stored in the server outside ( > machsim.com ) which is hosted by a hosting company in > US. Erm, you mean the "pop boxes" you mention in item 1.?? Checkout fetchmail, and Dan's serialmail package (on cr.yp.to website). > Before going in to technical configuration issues, I > feel that I need to understand the big picture. I > would appreciate any suggestions on a model and a > configuration as well as other ideas. I hope that helps. Your options will vary according to what addtional functionality you have available from your hosting company - such as ETRN. cheers, Andrew.
Re: Does qmail really delay a bounce for this long?
On Mon, Dec 11, 2000 at 11:11:51AM +1100, Rod... Whitworth wrote: > On Sun, 10 Dec 2000 18:03:57 -0500, Alex Pennace wrote: > > >This isn't qmail, it's ezmlm. ezmlm waits a week after the first > >bounce to send a warning note by default. > > Sad! I'd have to fix that if I ran it, but thanks for the info. > What happens with plain qmail in a similar circumstance? I suppose I'll find out if >I keep reading? Plain qmail bounces back shortly after it encounters a permanent failure. PGP signature
Re: Does qmail really delay a bounce for this long?
On Sun, 10 Dec 2000 18:03:57 -0500, Alex Pennace wrote: >This isn't qmail, it's ezmlm. ezmlm waits a week after the first >bounce to send a warning note by default. Sad! I'd have to fix that if I ran it, but thanks for the info. What happens with plain qmail in a similar circumstance? I suppose I'll find out if I keep reading? Thanx again.
Re: Does qmail really delay a bounce for this long?
On Mon, Dec 11, 2000 at 09:54:11AM +1100, Rod... Whitworth wrote: > I have been lurking here for quite a while learning > whilst I spend the evenings reading various qmail docs > so > that when I do get my new box configured and running > qmail I hopefully won't need to ask anything. > > BUT I did get a message today from the list daemon that > said: [snip ezmlm warning message] > I looked at the logs on the server here and found that > there had been one attempt to get this message through > and that it said that the connection was broken (i.e. no > QUIT was received) and the time was a week before the > bounce date. > > So the question is - Does qmail by default leave a > person trying to send mail waiting for a week before > they > get any notification that an attempt has failed? Even if > the return code suggests a permanent failure? This isn't qmail, it's ezmlm. ezmlm waits a week after the first bounce to send a warning note by default. PGP signature
Does qmail really delay a bounce for this long?
I have been lurking here for quite a while learning whilst I spend the evenings reading various qmail docs so that when I do get my new box configured and running qmail I hopefully won't need to ask anything. BUT I did get a message today from the list daemon that said: snip == Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. Messages to you seem to have been bouncing. I've attached a copy of the first bounce message I received. If this message bounces too, I will send you a probe. If the probe bounces, I will remove your address from the mailing list, without further notice. I've kept a list of which messages bounced from your address. Copies of these messages may be in the archive. To get message 12345 from the archive, send an empty note to [EMAIL PROTECTED] Here are the message numbers: 58201 --- Below this line is a copy of the bounce message I received. Return-Path: <> Received: (qmail 15605 invoked for bounce); 29 Nov 2000 03:06:15 - Date: 29 Nov 2000 03:06:15 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at muncher.math.uic.edu. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: 139.130.242.11 failed after I sent the message. Remote host said: 552 Requested mail action aborted: storage allocation or incoming size limit exceeded === end snip I looked at the logs on the server here and found that there had been one attempt to get this message through and that it said that the connection was broken (i.e. no QUIT was received) and the time was a week before the bounce date. So the question is - Does qmail by default leave a person trying to send mail waiting for a week before they get any notification that an attempt has failed? Even if the return code suggests a permanent failure? This seems more than a little derelict even if it was due to a typo in an address and very harsh when there is nothing wrong with the message. Is there a way to change this behaviour? BTW the server concerned had no limits set for the mailbox and had 667MB of free space at the time (and now) so I am pursuing that issue elsewhere. TIA In the beginning was The Word and The Word was Content-type: text/plain The Word of Rod.
Re: IPCHAINS and Qmail
Am Sonntag, 10. Dezember 2000 09:39 schrieb Timothy Legant: > On Sun, Dec 10, 2000 at 01:31:54AM -0700, Sean Reifschneider wrote: > > On Sun, Dec 10, 2000 at 02:51:24AM -0500, Steve Manes wrote: > > >Dec 10 01:02:49 meg kernel: Packet log: output REJECT eth0 PROTO=6 > > > 166.84.147. 124:3687 206.26.89.202:25 L=1064 S=0x00 I=46413 F=0x > > > T=64 (#37) Dec 10 01:02:55 meg kernel: Packet log: output REJECT eth0 > > > PROTO=6 166.84.147. 124:4396 204.242.84.1:25 L=60 S=0x00 I=46421 > > > F=0x T=64 SYN (#37) > > > > > >Any idea what's causing this? > > > > ipchains is blocking incoming connections to port 25/tcp. You know, the > > e-mail port. > > Er, it looks like exactly the opposite. ipchains is blocking _outgoing_ > connections _to_ port 25 on other machines. Steve's IP is > 166.84.147.124. > > I don't use ipchains and don't know how to fix this. Hopefully someone > can tell you how to open up the ports qmail needs for output. ipchains -I input -s 166.84.147.124 --dport 25 -p tcp -j ACCEPT ipchains -I forward -s 166.84.147.124 --dport 25 -p tcp -j ACCEPT ipchains -I output -s 166.84.147.124 --dport 25 -p tcp -j ACCEPT Tge original poster should a) understand what's going on before running a firewall b) learn to use the correct list. This is a question fore the ipchains mailing list. > -thl -- Henning Brauer | BS Web Services Hostmaster BSWS| Roedingsmarkt 14 [EMAIL PROTECTED] | 20459 Hamburg www.bsws.de| Germany
Re: IPCHAINS and Qmail
On Sun, Dec 10, 2000 at 10:31:24AM -0500, Steve Manes wrote: >I know what port 25 is and, no, it's not blocking incoming connections. It >seems to be blocking outgoing connections. But if you look at the script >you'll see that port 25 is open both ways: Ahh, I didn't notice the output rule. I don't tend to use output rules. ># SMTP server (25) ># >ipchains -A input -i $EXTERNAL_INTERFACE -p tcp \ > --source-port $UNPRIVPORTS \ > -d $IPADDR 25 -j ACCEPT > >ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \ > -s $IPADDR 25 \ > --destination-port $UNPRIVPORTS -j ACCEPT This rule includes "! -y", which means "match all rules *EXCEPT* those with the SYN bit set". But, this is only for responses *FROM* your SMTP port. The log lines you posted indicate it's connecting to a remote SMTP port when it gets blocked, which isn't covered above. There should be a section for "outbound connections", which is what's getting blocked. >In fact, the script doesn't firewall any outbound traffic in eth0, only >input. That's why this is weird. The error log throws occasional mentions >about "SYN" (above) so I wonder if it's a problem with that. What's the default policy on the output interface? Deny? If the script doesn't mention outbound connections, that would be the problem... Sean -- I never thought I'd live in a country where physical violence would be used to disenfranchise voters. Have you heard about Bush supporters rioting? Sean Reifschneider, Inimitably Superfluous <[EMAIL PROTECTED]> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
RE: all mail forwarding and catching all bounces
Thank you all for this advice, and it did seem a good idea, until I somehow brought my server to his knees (good thing it is after work hours) just by recompiling and running "make setup check" - I was unable to start qmail with the "alert: cannot start: unable to read controls" messages in the log. Well now I am past it. I now have all messages duplicated to the log alias, but there is a problem... |grep -qv MAILER-DAEMON && exit 99 - this does not catch anything at all ... |grep -q MAILER-DAEMON && exit 99 - this one causes the message to log to be deferred. |grep -q MAILER-DAEMON || exit 99 - this works, but cause a loop in the system because every message forwarded to a user specified after this line (me of course) eventually goes again through qmail-queue and gets replicated to the log alias again. Any suggestions (and if you could please tell me where can I read how that line functions - I am not familiar with this command form.) Thank you. Alex Incredimail Admin. -Original Message- From: Peter Green [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 10, 2000 7:53 PM To: [EMAIL PROTECTED] Cc: Charles Cazabon Subject: Re: all mail forwarding and catching all bounces * Charles Cazabon <[EMAIL PROTECTED]> [001210 10:19]: > > 1. Is it possible to copy every bounce message generated to any user to > > another user (in this case - me : i want to know when my users do not > > succeede sending, or someone from the outside is sending mail to a wrong > > address in my domain) > > A bounce message is just another message to qmail. What you could do is use > the QUEUE_EXTRA feature to send copies of all mail to an alias (msglog is > a common choice). Then have a file ~alias/.qmail which does something like: > > |grep -q MAILER-DAEMON && exit 99 Shouldn't this use ``||'' instead of ``&&''? If he wants to see only the bounces... Also, it might be a good idea to use the mess822 package to only grep for MAILER-DAEMON in the headers, where it makes sense. /pg -- Peter Green : Gospel Communications Network, SysAdmin : [EMAIL PROTECTED] --- For mad scientists who keep brains in jars, here's a tip: why not add a slice of lemon to each jar, for freshness? (Jack Handey)
Re: big-concurrency.patch
On 09/12/00 at 3:21 PM Federico Edelman Anaya wrote: >A few days ago .. I post on the list many question about >big-concurrency.patch ... > >I was reading other list about Qmail and I get this solution about the >problem with the FD .. > >The solution was: > >echo "65536" > /proc/sys/fs/inode-max >echo "16384" > /proc/sys/fs/file-max > >So.. you need to do this every system reboot, I don't know how to make >this persistent.. anybody have idea or know how to make this persistent? Under Liux 2.2.x, the way to make this persistent is to use the sysctl facility. add: fs.file-max = 16384 fs.inode-max = 65536 to the sysctl.conf file in /etc, and it will be loaded up evey time you boot the machine. Martin Volesky - [EMAIL PROTECTED] CTO - Deijlabs Corporation 1221 Mackay, Suite 200 Montreal, Quebec, Canada H3G 2H5 Tel.: 514.399.9930 Fax.: 514.399.1117
Re: all mail forwarding and catching all bounces
Peter Green <[EMAIL PROTECTED]> wrote: > > |grep -q MAILER-DAEMON && exit 99 > > Shouldn't this use ``||'' instead of ``&&''? If he wants to see only the > bounces... Actually, I meant to type 'grep -qv', but changing either would work. > Also, it might be a good idea to use the mess822 package to only grep for > MAILER-DAEMON in the headers, where it makes sense. An excellent suggestion. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: IPCHAINS and Qmail
On Sun, 10 Dec 2000, Peter Green wrote: > Most likely, you have a rule in the output chain that has a higher > precendence that is blocking the outgoing traffic. By adding a rule like: Or a 'default' REJECT rule is catching it because the ACCEPT higher up is too specific. > /sbin/ipchains -I output 1 -j ACCEPT -i $EXTERNAL_INTERFACE -p tcp -s > $IPADDR -d 0/0 25 > (Note that port 25 is the *destination* port also, NOT the source port.) > Also, you might check the output chain to ensure that a block is actually > there: > /sbin/ipchains -L output -n | grep " 25" A better method is to get the rule number from the log fragments posted (#37), do a 'ipchains -L output' and look at that rule number. > See what that turns up. Finally, you might check with the firewall software > author or support list, since it would seem that that is where the problem > apparently lies. True, this is entirely an ipchains problem, not a qmail one. --Colin. Colin Palmer -- [EMAIL PROTECTED] -- http://raccoon.osoal.org.nz/ Systems Engineer -- [One Short Of A Llama] http://web.osoal.org.nz/
Re: IPCHAINS and Qmail
On Sun, 10 Dec 2000, David Dyer-Bennet wrote: > > # SMTP server (25) > > # > > ipchains -A input -i $EXTERNAL_INTERFACE -p tcp \ > > --source-port $UNPRIVPORTS \ > > -d $IPADDR 25 -j ACCEPT > > > > ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \ > > -s $IPADDR 25 \ > > --destination-port $UNPRIVPORTS -j ACCEPT > > The ! -y means it's not open to *initiating* any outbound > connections, doesn't it? I'm not an ipchains expert, but I run it > with some simple rules, and I double-checked the docs just now. Yes, and it's supposed to be there. (the rule says 'only allow traffic from port 25 on my machine to an unpriviledged port on someone else's machine if it's part of a connection that's already been established') > Also, this particular pair of rules doesn't allow a connection from > port 25 here to port 25 elsewhere, or vice versa. Actually the rules needed were for connections from the local machine to port 25 on a remote one since the above two rules only covered incoming mail. > Does qmail do that, > or are the outbound connects always from non-priv ports? And do > *other* people do that, or are the inbound connects always from > non-priv ports? All the Unix MTAs I've encountered do (and the log fragments posted showed the connection qmail was attempting originating from one). On my own server, I'd be tempted to leave out $UNPRIVPORTS (thus allowing all possible ports implicitly) just in case though. --Colin Colin Palmer -- [EMAIL PROTECTED] -- http://raccoon.osoal.org.nz/ Systems Engineer -- [One Short Of A Llama] http://web.osoal.org.nz/
Re: IPCHAINS and Qmail
On Sun, 10 Dec 2000, Steve Manes wrote: > I know what port 25 is and, no, it's not blocking incoming connections. It > seems to be blocking outgoing connections. But if you look at the script > you'll see that port 25 is open both ways: > > # SMTP server (25) > # > ipchains -A input -i $EXTERNAL_INTERFACE -p tcp \ > --source-port $UNPRIVPORTS \ > -d $IPADDR 25 -j ACCEPT > > ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \ > -s $IPADDR 25 \ > --destination-port $UNPRIVPORTS -j ACCEPT Actually, no, it's not open both ways. All those two rules do is allow traffic back and forth between an external smtp client and your smtp server. To allow traffic between qmail acting as a smtp client on your machine and a remote smtp server, you also need this: # SMTP client (unpriv->25) # ipchains -A input -i $EXTERNAL_INTERFACE -p tcp \ --source-port 25 \ -d $IPADDR $UNPRIVPORTS -j ACCEPT ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \ -s $IPADDR $UNPRIVPORTS \ --destination-port 25 -j ACCEPT (note that both these two rules and the above ones will fall over if you meet a SMTP server that binds to a port <1024 for outgoing mail (Exchange maybe?)) > In fact, the script doesn't firewall any outbound traffic in eth0, only > input. That's why this is weird. The error log throws occasional mentions > about "SYN" (above) so I wonder if it's a problem with that. Yes it does. The actual rule on your firewall that is rejecting SMTP traffic is this one: ipchains -A output -i $EXTERNAL_INTERFACE -j REJECT -l > Admittedly, it's huge but I didn't create it by hand. Nevertheless it's a > very thorough script and well commented, and similarly-generated firewall > scripts work very well on my other machines. It's only Qmail that seems to > be having a problem with it. I'd be surprised if that worked on any mail server. It was at least easy to read and find the problem --Colin. Colin Palmer -- [EMAIL PROTECTED] -- http://raccoon.osoal.org.nz/ Systems Engineer -- [One Short Of A Llama] http://web.osoal.org.nz/
Re: How to get Mail delivery in form cgi´s work
On Fri, Dec 08, 2000 at 06:16:47PM +, Mark Delany wrote: > On Fri, Dec 08, 2000 at 10:09:17AM -0800, Jon Rust wrote: > > On Fri, Dec 08, 2000 at 11:47:32AM -0600, Bruno Wolff III wrote: > > > > > > And did the address you were sending to have any characters needing > > > quoting in it? > > > > > > You going into mutt and use the 'm' command to mail a message. > > > Use the following for the To address: > > > "jpr"@vcnet.com > > > > > > You should get a bounce on a qmail system. If you were using sendmail > > > you wouldn't. > > > > No offense intended, but I'm not sure I care really. I just don't see > > why you'd present the address as "something"@domain.com. Is there a > > What if the "something" has spaces in it? "John Doe"@example.com is a > legit address. iIf you want to have fun with Outlook Express users, put this in your signature: "[EMAIL PROTECTED] Doe"@example.com I don't know if that's a legal address, but its mere presence in an e-mail message will cause Outlook Express to freeze and eventually consume all of your memory. Merely pasting the above text into a blank e-mail message in Outlook Express will have the same effect. Chris
Re: IPCHAINS and Qmail
* Steve Manes <[EMAIL PROTECTED]> [001210 12:06]: > At 08:47 AM 12/10/00 -0800, Phil Oester wrote: > >Your output rule for port 25 is definitely the problem. Contrary to your > >belief, it is filtering outbound traffic on eth0. Personally, I don't think > >that's such a good idea - my firewall allows everything outbound, and only > >filters inbound. Try changing your SMTP output rule to this: > > > >/sbin/ipchains -A output -j ACCEPT -i $EXTERNAL_INTERFACE -p tcp -s $IPADDR > >25 -d 0.0.0.0/0 > > Thanks for the help. I tried it but unfortunately it's still > blocking. Here's the /var/log/messages. It looks like the same error. I > also tried removing the "! -y" in the original IPCHAINS arguments and that > didn't help either. Most likely, you have a rule in the output chain that has a higher precendence that is blocking the outgoing traffic. By adding a rule like: /sbin/ipchains -I output 1 -j ACCEPT -i $EXTERNAL_INTERFACE -p tcp -s $IPADDR -d 0/0 25 (Note that port 25 is the *destination* port also, NOT the source port.) Also, you might check the output chain to ensure that a block is actually there: /sbin/ipchains -L output -n | grep " 25" See what that turns up. Finally, you might check with the firewall software author or support list, since it would seem that that is where the problem apparently lies. /pg -- Peter Green : Gospel Communications Network, SysAdmin : [EMAIL PROTECTED] --- If I ever opened a trampoline store, I don't think I'd call it Tramp-Land, because you might think it was a store for tramps, which is not the impression we are trying to convey with our store. On the other hand, we would not prohibit tramps from browsing, or testing the trampolines, unless a tramp's gyrations seemed to be getting out of control. (Jack Handey)
Re: all mail forwarding and catching all bounces
* Charles Cazabon <[EMAIL PROTECTED]> [001210 10:19]: > > 1. Is it possible to copy every bounce message generated to any user to > > another user (in this case - me : i want to know when my users do not > > succeede sending, or someone from the outside is sending mail to a wrong > > address in my domain) > > A bounce message is just another message to qmail. What you could do is use > the QUEUE_EXTRA feature to send copies of all mail to an alias (msglog is > a common choice). Then have a file ~alias/.qmail which does something like: > > |grep -q MAILER-DAEMON && exit 99 Shouldn't this use ``||'' instead of ``&&''? If he wants to see only the bounces... Also, it might be a good idea to use the mess822 package to only grep for MAILER-DAEMON in the headers, where it makes sense. /pg -- Peter Green : Gospel Communications Network, SysAdmin : [EMAIL PROTECTED] --- For mad scientists who keep brains in jars, here's a tip: why not add a slice of lemon to each jar, for freshness? (Jack Handey)
RE: IPCHAINS and Qmail
Your output rule for port 25 is definitely the problem. Contrary to your belief, it is filtering outbound traffic on eth0. Personally, I don't think that's such a good idea - my firewall allows everything outbound, and only filters inbound. Try changing your SMTP output rule to this: /sbin/ipchains -A output -j ACCEPT -i $EXTERNAL_INTERFACE -p tcp -s $IPADDR 25 -d 0.0.0.0/0 -Phil -Original Message- From: Steve Manes [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 10, 2000 7:31 AM To: Sean Reifschneider Cc: [EMAIL PROTECTED] Subject: Re: IPCHAINS and Qmail At 01:31 AM 12/10/00 -0700, Sean Reifschneider wrote: >On Sun, Dec 10, 2000 at 02:51:24AM -0500, Steve Manes wrote: > >Dec 10 01:02:49 meg kernel: Packet log: output REJECT eth0 PROTO=6 > 166.84.147. > >124:3687 206.26.89.202:25 L=1064 S=0x00 I=46413 F=0x T=64 (#37) > >Dec 10 01:02:55 meg kernel: Packet log: output REJECT eth0 PROTO=6 > 166.84.147. > >124:4396 204.242.84.1:25 L=60 S=0x00 I=46421 F=0x T=64 SYN (#37) > > > >Any idea what's causing this? > >ipchains is blocking incoming connections to port 25/tcp. You know, the >e-mail port. I know what port 25 is and, no, it's not blocking incoming connections. It seems to be blocking outgoing connections. But if you look at the script you'll see that port 25 is open both ways: # SMTP server (25) # ipchains -A input -i $EXTERNAL_INTERFACE -p tcp \ --source-port $UNPRIVPORTS \ -d $IPADDR 25 -j ACCEPT ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \ -s $IPADDR 25 \ --destination-port $UNPRIVPORTS -j ACCEPT In fact, the script doesn't firewall any outbound traffic in eth0, only input. That's why this is weird. The error log throws occasional mentions about "SYN" (above) so I wonder if it's a problem with that. > >The problematic firewall script is rather large (25k) so I've posted it on > >my web server at http://www.magpie.com/work/rc.firewall.html > >Yikes! 25KB?!? I have a hard time imagining it being a tenth the size >of that. Admittedly, it's huge but I didn't create it by hand. Nevertheless it's a very thorough script and well commented, and similarly-generated firewall scripts work very well on my other machines. It's only Qmail that seems to be having a problem with it. ---[ http://www.magpie.com ]---=o&>o--- Steve Manes Brooklyn, N'Yawk
RE: IPCHAINS and Qmail
At 08:47 AM 12/10/00 -0800, Phil Oester wrote: >Your output rule for port 25 is definitely the problem. Contrary to your >belief, it is filtering outbound traffic on eth0. Personally, I don't think >that's such a good idea - my firewall allows everything outbound, and only >filters inbound. Try changing your SMTP output rule to this: > >/sbin/ipchains -A output -j ACCEPT -i $EXTERNAL_INTERFACE -p tcp -s $IPADDR >25 -d 0.0.0.0/0 Thanks for the help. I tried it but unfortunately it's still blocking. Here's the /var/log/messages. It looks like the same error. I also tried removing the "! -y" in the original IPCHAINS arguments and that didn't help either. Dec 10 10:54:26 meg kernel: Packet log: output REJECT eth0 PROTO=6 166.84.147.124:1384 166.84.0.213:25 L=60 S=0x00 I=39172 F=0x T=64 SYN (#37) Dec 10 10:54:26 meg kernel: Packet log: output REJECT eth0 PROTO=6 166.84.147.124:1385 166.84.0.212:25 L=60 S=0x00 I=39174 F=0x T=64 SYN (#37) Dec 10 10:54:26 meg kernel: Packet log: output REJECT eth0 PROTO=6 166.84.147.124:1386 166.84.0.167:25 L=60 S=0x00 I=39176 F=0x T=64 SYN (#37) Dec 10 10:55:05 meg kernel: Packet log: output REJECT eth0 PROTO=6 166.84.147.124:1388 207.46.181.94:25 L=60 S=0x00 I=39197 F=0x T=64 SYN (#37) ---[ http://www.magpie.com ]---=o&>o--- Steve Manes Brooklyn, N'Yawk
Re: Newbie questions relating to multiple servers
Roger Arnold <[EMAIL PROTECTED]> writes on 11 December 2000 at 02:05:41 +1100 > Roger Arnold wrote: > > Sorry if these are stupid questions or is already covered in a how-to, > if it is perhaps someone can point me to it please. > > I need to know is how to setup qmail to work with multiple servers with > a mix of IP and Name based virtual domains on 2 or more servers i.e.: > > Server 1, is a nameserver as well as hosting some IP based virtual > domains, it is also the gateway between the www and the local LAN where > the other servers are. > > Server 2, is also a nameserver as well as hosting name based virtual > domains > > Server 3 just hosts name based virtual domains > > Qmail is installed on each and all servers (with the intention of adding > vpopmail & SqWebMail). > > What I need to know is how to setup Qmail (and vpopmail) on each server > to handle the virtual domains on that server and pass the mail forward > and back through Server 1 ? Is this *outgoing* mail you're talking about? The way to do that is to use control/smtproutes on each of the three servers to send *everything* remote to the gateway server. If you really want to make one system that mission-critical. Oops, on *two* of the servers; the third server actually *is* the gateway so it has to be allowed to actually send the mail out. > Do I simply set the MX of the domain to the server that the virtual > domain is on and setup qmail on each server as though it was the only > server on the network ? if so how should I configure each server? For the inbound mail to come in direct to the right server the simple way, you need an MX pointing to the system you want the mail to end up on, and you need to allow direct connects from outside to that system. If you want to run all inbound email through your gateway instead, you need to have all the MX records pointing at the gateway, and then use either control/smtproutes (qmail control file) or else split DNS (internal systems see different DNS answers than external systems) to cause incoming mail to go from the gateway to the intended server. -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: IPCHAINS and Qmail
Steve Manes <[EMAIL PROTECTED]> writes on 10 December 2000 at 10:31:24 -0500 > At 01:31 AM 12/10/00 -0700, Sean Reifschneider wrote: > >On Sun, Dec 10, 2000 at 02:51:24AM -0500, Steve Manes wrote: > > >Dec 10 01:02:49 meg kernel: Packet log: output REJECT eth0 PROTO=6 > > 166.84.147. > > >124:3687 206.26.89.202:25 L=1064 S=0x00 I=46413 F=0x T=64 (#37) > > >Dec 10 01:02:55 meg kernel: Packet log: output REJECT eth0 PROTO=6 > > 166.84.147. > > >124:4396 204.242.84.1:25 L=60 S=0x00 I=46421 F=0x T=64 SYN (#37) > > > > > >Any idea what's causing this? > > > >ipchains is blocking incoming connections to port 25/tcp. You know, the > >e-mail port. > > I know what port 25 is and, no, it's not blocking incoming connections. It > seems to be blocking outgoing connections. But if you look at the script > you'll see that port 25 is open both ways: > > # SMTP server (25) > # > ipchains -A input -i $EXTERNAL_INTERFACE -p tcp \ > --source-port $UNPRIVPORTS \ > -d $IPADDR 25 -j ACCEPT > > ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \ > -s $IPADDR 25 \ > --destination-port $UNPRIVPORTS -j ACCEPT The ! -y means it's not open to *initiating* any outbound connections, doesn't it? I'm not an ipchains expert, but I run it with some simple rules, and I double-checked the docs just now. Also, this particular pair of rules doesn't allow a connection from port 25 here to port 25 elsewhere, or vice versa. Does qmail do that, or are the outbound connects always from non-priv ports? And do *other* people do that, or are the inbound connects always from non-priv ports? -- David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED] SF: http://www.dd-b.net/dd-b/ Minicon: http://www.mnstf.org/minicon/ Photos: http://dd-b.lighthunters.net/
Re: IPCHAINS and Qmail
At 01:31 AM 12/10/00 -0700, Sean Reifschneider wrote: >On Sun, Dec 10, 2000 at 02:51:24AM -0500, Steve Manes wrote: > >Dec 10 01:02:49 meg kernel: Packet log: output REJECT eth0 PROTO=6 > 166.84.147. > >124:3687 206.26.89.202:25 L=1064 S=0x00 I=46413 F=0x T=64 (#37) > >Dec 10 01:02:55 meg kernel: Packet log: output REJECT eth0 PROTO=6 > 166.84.147. > >124:4396 204.242.84.1:25 L=60 S=0x00 I=46421 F=0x T=64 SYN (#37) > > > >Any idea what's causing this? > >ipchains is blocking incoming connections to port 25/tcp. You know, the >e-mail port. I know what port 25 is and, no, it's not blocking incoming connections. It seems to be blocking outgoing connections. But if you look at the script you'll see that port 25 is open both ways: # SMTP server (25) # ipchains -A input -i $EXTERNAL_INTERFACE -p tcp \ --source-port $UNPRIVPORTS \ -d $IPADDR 25 -j ACCEPT ipchains -A output -i $EXTERNAL_INTERFACE -p tcp ! -y \ -s $IPADDR 25 \ --destination-port $UNPRIVPORTS -j ACCEPT In fact, the script doesn't firewall any outbound traffic in eth0, only input. That's why this is weird. The error log throws occasional mentions about "SYN" (above) so I wonder if it's a problem with that. > >The problematic firewall script is rather large (25k) so I've posted it on > >my web server at http://www.magpie.com/work/rc.firewall.html > >Yikes! 25KB?!? I have a hard time imagining it being a tenth the size >of that. Admittedly, it's huge but I didn't create it by hand. Nevertheless it's a very thorough script and well commented, and similarly-generated firewall scripts work very well on my other machines. It's only Qmail that seems to be having a problem with it. ---[ http://www.magpie.com ]---=o&>o--- Steve Manes Brooklyn, N'Yawk
Re: all mail forwarding and catching all bounces
Alex Kramarov <[EMAIL PROTECTED]> wrote: > > I am new to this list, but i am a diligent reader, and after reading all > documentation on q-mail i couldn't find two things i need a lot , after I > successfully installed a qmail server and put it instead of my old exchange, > which was giving me a lot of trouble before ... This is quite possibly the best "newbie" message to the list I've seen in months. Thank you for doing your research. > 1. Is it possible to copy every bounce message generated to any user to > another user (in this case - me : i want to know when my users do not > succeede sending, or someone from the outside is sending mail to a wrong > address in my domain) A bounce message is just another message to qmail. What you could do is use the QUEUE_EXTRA feature to send copies of all mail to an alias (msglog is a common choice). Then have a file ~alias/.qmail which does something like: |grep -q MAILER-DAEMON && exit 99 &you@yourdomain This should forward copies of qmail bounces to you. You could make the grep term a little more flexible to catch bounces from other MTAs. > 2. Is it possible to forward all mail (except the local mail, as listed in > control/local) to another host - and I am not talking of smtproutes, which > takes place after the original e-mail has been parsed and copies of it has > been generated to every domain it's destined to go. I want to forward all > non-local mail to the server of my provider, so that if someone sends a 2MB > mail to 50 recipients, which unfortunately my users do sometimes, that will > not take my 128 bit line till the rest of the day sending 50 copies of the > mail (and instead, of course, forward 1 mail to my provider's server, so he > would have to send these 50 copies). Once a message hits qmail-queue, it will be sent once for each recipient. An alternative would be to have a wrapper around qmail-queue which determines if the message is to a local or remote address; if its local, it calls qmail-queue; otherwise it sends it directly to your ISP's smarthost (using nullmailer perhaps?). Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Newbie questions relating to multiple servers
Roger Arnold wrote: Sorry if these are stupid questions or is already covered in a how-to, if it is perhaps someone can point me to it please. I need to know is how to setup qmail to work with multiple servers with a mix of IP and Name based virtual domains on 2 or more servers i.e.: Server 1, is a nameserver as well as hosting some IP based virtual domains, it is also the gateway between the www and the local LAN where the other servers are. Server 2, is also a nameserver as well as hosting name based virtual domains Server 3 just hosts name based virtual domains Qmail is installed on each and all servers (with the intention of adding vpopmail & SqWebMail). What I need to know is how to setup Qmail (and vpopmail) on each server to handle the virtual domains on that server and pass the mail forward and back through Server 1 ? Do I simply set the MX of the domain to the server that the virtual domain is on and setup qmail on each server as though it was the only server on the network ? if so how should I configure each server? Thanks in advance for any and all help Roger
A local mail server in sync with a .com
Hi, I have been looking for a solution for our mail server problem on net and after reading lots of sendmail and qmail documents I am totally confused :) My requirements are : 1. We have a domain name on net www.machsim.com, the hosting company provides pop boxes but no SMTP service. We need the linux box to send the messages. 2. We have a linux server at the company. It runs squid etc. We want to use this PC for as an internet and intranet mail server so that when [EMAIL PROTECTED] sends a mail to [EMAIL PROTECTED], message will never need to go outside and stay in the intranet. Any mail that is written to some other domain shall be sent via internet. 3. We want the linux server to send the messages in the queue and get mails stored in the server outside ( machsim.com ) which is hosted by a hosting company in US. Before going in to technical configuration issues, I feel that I need to understand the big picture. I would appreciate any suggestions on a model and a configuration as well as other ideas. Thanks. A lot. Devrim Erdem __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
qmail Digest 10 Dec 2000 11:00:01 -0000 Issue 1209
qmail Digest 10 Dec 2000 11:00:01 - Issue 1209 Topics (messages 53802 through 53809): Re: ezmlm response 53802 by: Charles Cazabon big-concurrency.patch 53803 by: Federico Edelman Anaya 53804 by: Charles Cazabon 53805 by: Sean Reifschneider all mail forwarding and catching all bounces 53806 by: Alex Kramarov IPCHAINS and Qmail 53807 by: Steve Manes 53808 by: Sean Reifschneider 53809 by: Timothy Legant Administrivia: To unsubscribe from the digest, e-mail: [EMAIL PROTECTED] To subscribe to the digest, e-mail: [EMAIL PROTECTED] To bug my human owner, e-mail: [EMAIL PROTECTED] To post to the list, e-mail: [EMAIL PROTECTED] -- Liberty <[EMAIL PROTECTED]> wrote: >My site's host uses Qmail for the mail list, but > does not provide assistance for the advanced features. >How can I set up masquerading so when I send mail > to my email list no one can obtain the address of the > list? >Recently my list was spammed because of it's > visibility in the "To" address box when I send > messages out to it. Is your mailing list an ezmlm list, or just a .qmail file with a bunch of forward directives in it? If it's ezmlm (which means this question should be asked on the ezmlm list instead of the qmail list), you can fix this by making the list moderated, so you can approve all messages, or make it a read-only list, so only you can send messages at all. You could also configure it to only accept submissions from list members. If it's just a .qmail file, have the first line be a pipe to a script, which checks either the originating IP address or the envelope sender (less secure). The script should exit 0 if the message is to be delivered to the rest of the list, or 99 to drop it on the floor. `man qmail-command` for more details. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. --- A few days ago .. I post on the list many question about big-concurrency.patch ... I was reading other list about Qmail and I get this solution about the problem with the FD .. This is the log whit error: Report of Qmailanalog: - Errors of FD?: 24 6.36 /bin/sh: /usr/bin/ezmlm-return: Too many open files in system/ 16 28.13 /bin/sh: /usr/bin/ezmlm-weed: Too many open files in system/ 92 27.81 /bin/sh: error in loading shared libraries: libc.so.6: cannot open shared object file: Error 23/ 59 41.43 /bin/sh: error in loading shared libraries: libdl.so.2: cannot open shared object file: Error 23/ 48 63.30 /bin/sh: error in loading shared libraries: libncurses.so.5: cannot open shared object file: Error 23/ 58 18.57 /usr/bin/ezmlm-return: error in loading shared libraries: libc.so.6: cannot open shared object file: Error 23/ 106 37.99 /usr/bin/ezmlm-return: error in loading shared libraries: libcrypt.so.1: cannot open shared object file: Error 23/ 4 1.46 /usr/bin/ezmlm-return: error in loading shared libraries: libm.so.6: cannot open shared object file: Error 23/ - Other error: 851 3182.23 Connected to 200.41.50.10 but connection died. (#4.4.2)/ 1 60.03 Connected to 200.41.50.7 but connection died. (#4.4.2)/ 316 12453.57 Connected to 200.41.50.9 but connection died. (#4.4.2)/ 1 0.20 Sorry, I couldn't find any host by that name. (#4.1.2)/ 30.74 bin/qmail-local: error in loading shared libraries: libc.so.6: cannot open shared object file: Error 23/ The solution was: echo "65536" > /proc/sys/fs/inode-max echo "16384" > /proc/sys/fs/file-max So.. you need to do this every system reboot, I don't know how to make this persistent.. anybody have idea or know how to make this persistent? Thanks :) Federico Edelman Anaya <[EMAIL PROTECTED]> wrote: > > The solution was: > > echo "65536" > /proc/sys/fs/inode-max > echo "16384" > /proc/sys/fs/file-max > > So.. you need to do this every system reboot, I don't know how to make > this persistent.. anybody have idea or know how to make this persistent? This is really more of a Unix/Linux question than anything else. However, try adding those two lines to the end of /etc/rc.d/rc.local or your system's equivalent. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. --- On Sat, Dec 09, 2000 at 12:31:16PM -0600, Charles Cazabon wrote: >> echo "65536" > /
Re: IPCHAINS and Qmail
On Sun, Dec 10, 2000 at 02:51:24AM -0500, Steve Manes wrote: >Dec 10 01:02:49 meg kernel: Packet log: output REJECT eth0 PROTO=6 166.84.147. >124:3687 206.26.89.202:25 L=1064 S=0x00 I=46413 F=0x T=64 (#37) >Dec 10 01:02:55 meg kernel: Packet log: output REJECT eth0 PROTO=6 166.84.147. >124:4396 204.242.84.1:25 L=60 S=0x00 I=46421 F=0x T=64 SYN (#37) > >Any idea what's causing this? ipchains is blocking incoming connections to port 25/tcp. You know, the e-mail port. >The problematic firewall script is rather large (25k) so I've posted it on >my web server at http://www.magpie.com/work/rc.firewall.html Yikes! 25KB?!? I have a hard time imagining it being a tenth the size of that. Allow incoming 25 and 113 TCP, maybe 110 and 143, allow outgoing connections, and allow DNS. Probably also want SSH... A dozen rules? Sean -- I never thought I'd live in a country where physical violence would be used to disenfranchise voters. Have you heard about Bush supporters rioting? Sean Reifschneider, Inimitably Superfluous <[EMAIL PROTECTED]> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
Re: IPCHAINS and Qmail
On Sun, Dec 10, 2000 at 01:31:54AM -0700, Sean Reifschneider wrote: > On Sun, Dec 10, 2000 at 02:51:24AM -0500, Steve Manes wrote: > >Dec 10 01:02:49 meg kernel: Packet log: output REJECT eth0 PROTO=6 166.84.147. > >124:3687 206.26.89.202:25 L=1064 S=0x00 I=46413 F=0x T=64 (#37) > >Dec 10 01:02:55 meg kernel: Packet log: output REJECT eth0 PROTO=6 166.84.147. > >124:4396 204.242.84.1:25 L=60 S=0x00 I=46421 F=0x T=64 SYN (#37) > > > >Any idea what's causing this? > > ipchains is blocking incoming connections to port 25/tcp. You know, the > e-mail port. Er, it looks like exactly the opposite. ipchains is blocking _outgoing_ connections _to_ port 25 on other machines. Steve's IP is 166.84.147.124. I don't use ipchains and don't know how to fix this. Hopefully someone can tell you how to open up the ports qmail needs for output. -thl
