qmail Digest 3 Sep 1999 10:00:01 -0000 Issue 748
Topics (messages 29729 through 29806):
qmail and forwarding
29729 by: Van Liedekerke Franky <[EMAIL PROTECTED]>
Any ideas?
29730 by: Matthew Harrell <[EMAIL PROTECTED]>
29731 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
29734 by: Matthew Harrell <[EMAIL PROTECTED]>
29735 by: Dave Sill <[EMAIL PROTECTED]>
29736 by: Dave Sill <[EMAIL PROTECTED]>
29737 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
29739 by: Matthew Harrell <[EMAIL PROTECTED]>
29741 by: Matthew Harrell <[EMAIL PROTECTED]>
29742 by: Matthew Harrell <[EMAIL PROTECTED]>
29744 by: Dave Sill <[EMAIL PROTECTED]>
29746 by: Matthew Harrell <[EMAIL PROTECTED]>
29748 by: Dirk Harms-Merbitz <[EMAIL PROTECTED]>
29750 by: Matthew Harrell <[EMAIL PROTECTED]>
29751 by: Dave Sill <[EMAIL PROTECTED]>
29753 by: James Raftery <[EMAIL PROTECTED]>
29754 by: Greg Owen <[EMAIL PROTECTED]>
29755 by: James Raftery <[EMAIL PROTECTED]>
29756 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
29757 by: Matthew Harrell <[EMAIL PROTECTED]>
29758 by: Bruce Guenter <[EMAIL PROTECTED]>
29759 by: Matthew Harrell <[EMAIL PROTECTED]>
29778 by: "Aaron L. Meehan" <[EMAIL PROTECTED]>
29784 by: Matthew Harrell <[EMAIL PROTECTED]>
29788 by: "Scott D. Yelich" <[EMAIL PROTECTED]>
trouble injecting bounce message
29732 by: "D. Carlos Knowlton" <[EMAIL PROTECTED]>
Mail.com blacklisting
29733 by: Nicolas MONNET <[EMAIL PROTECTED]>
29738 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
29740 by: "David Dyer-Bennet" <[EMAIL PROTECTED]>
29745 by: "Fred Lindberg" <[EMAIL PROTECTED]>
AUTOTURN questions
29743 by: "Filippos Slavik" <[EMAIL PROTECTED]>
virtual domain users can't get msgs from maillists
29747 by: egor <[EMAIL PROTECTED]>
29749 by: Sam <[EMAIL PROTECTED]>
29752 by: Nicolas MONNET <[EMAIL PROTECTED]>
Alpha Base
29760 by: "Kulish, Chris (Des Moines)" <[EMAIL PROTECTED]>
29762 by: "Timothy L. Mayo" <[EMAIL PROTECTED]>
29764 by: Stan Horwitz <[EMAIL PROTECTED]>
29765 by: Dave Sill <[EMAIL PROTECTED]>
29766 by: Fabrice Scemama <[EMAIL PROTECTED]>
daemontools 0.6x
29761 by: Tim Hunter <[EMAIL PROTECTED]>
29763 by: "Timothy L. Mayo" <[EMAIL PROTECTED]>
29767 by: Tim Hunter <[EMAIL PROTECTED]>
29768 by: Dave Sill <[EMAIL PROTECTED]>
Alias Manipulation by CGI Script
29769 by: Kai MacTane <[EMAIL PROTECTED]>
29771 by: "Timothy L. Mayo" <[EMAIL PROTECTED]>
29775 by: Peter Gradwell <[EMAIL PROTECTED]>
Lobby mail.com
29770 by: "Nathan J. Mehl" <[EMAIL PROTECTED]>
29772 by: Justin Bell <[EMAIL PROTECTED]>
29773 by: "Daniluk, Cris" <[EMAIL PROTECTED]>
29774 by: "David Dyer-Bennet" <[EMAIL PROTECTED]>
29776 by: "David Harris" <[EMAIL PROTECTED]>
29777 by: Justin Bell <[EMAIL PROTECTED]>
29779 by: "Nathan J. Mehl" <[EMAIL PROTECTED]>
29780 by: "Nathan J. Mehl" <[EMAIL PROTECTED]>
29783 by: "Nathan J. Mehl" <[EMAIL PROTECTED]>
29785 by: Sam <[EMAIL PROTECTED]>
29787 by: Ben Kosse <[EMAIL PROTECTED]>
29789 by: "James J. Lippard" <[EMAIL PROTECTED]>
29790 by: Ben Kosse <[EMAIL PROTECTED]>
29791 by: Sam <[EMAIL PROTECTED]>
29792 by: "James J. Lippard" <[EMAIL PROTECTED]>
29793 by: "Nathan J. Mehl" <[EMAIL PROTECTED]>
29796 by: "Cris Daniluk" <[EMAIL PROTECTED]>
29799 by: "Adam D . McKenna" <[EMAIL PROTECTED]>
29800 by: [EMAIL PROTECTED]
29801 by: "Cris Daniluk" <[EMAIL PROTECTED]>
29802 by: "Adam D . McKenna" <[EMAIL PROTECTED]>
29803 by: Fabrice Scemama <[EMAIL PROTECTED]>
29804 by: "Einar Bordewich" <[EMAIL PROTECTED]>
Problems with qpop and Solaris
29781 by: [EMAIL PROTECTED]
qmail and statistics
29782 by: "Bill Johnson" <[EMAIL PROTECTED]>
qmail SMTP delivery hangs while manual SMTp telnet works fine
29786 by: Emmanuel Mogenet <[EMAIL PROTECTED]>
.qmail-ext deliver to recepient and another maildir
29794 by: Steve Vertigan <[EMAIL PROTECTED]>
SMTP Authentication
29795 by: [EMAIL PROTECTED]
could not start qmail
29797 by: [EMAIL PROTECTED] (Tong YU)
Block Email From Server
29798 by: "Cesar A. Iriarte" <[EMAIL PROTECTED]>
29805 by: Anand Buddhdev <[EMAIL PROTECTED]>
29806 by: Tomasz Papszun <[EMAIL PROTECTED]>
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Hi all, I have 2 servers (A and B) here, and mails are being forwarded from A to B in the following way: when a mail arrives to A, it gets processed first and then (in a .qmail file) it is decided this mail should be forwarded to B. Now a forward mail first gets back in the queue from A, which does then the actual delivery to B. So one mail gets stored on A two times before arriving to B. Is it possible to eliminate this second store on A, using for example qmtpd or something? Franky
Okay, I'm trying to pull even more out of my qmail box. It's a dual P2 450 with 256 MB of RAM and the following qmail configuration: qmail with fsync's removed concurrencyremote set to 120 big-todo patch installed using cyclog and not syslog I'm getting what appears to be around 60K messages per hour and I'm wondering what I can do to get a higher throughput. Any ideas are welcome. I'm using a Perl script talking directly to qmail-queue to pump the messages in (each of which is slightly unique) and I know that's not the limiter because I have to slow the script down to avoid filling the queue up (100K+ messages). Here's some output from qmailanalog: Completed messages: 196952 Recipients for completed messages: 196956 Total delivery attempts for completed messages: 197869 Average delivery attempts per completed message: 1.00466 Bytes in completed messages: 1152135331 Bytes weighted by success: 1140658136 Average message qtime (s): 12.2331 Total delivery attempts: 202944 success: 195605 failure: 2398 deferral: 4941 Total ddelay (s): 2338545.236874 Average ddelay per success (s): 11.955447 Total xdelay (s): 806842.48747 Average xdelay per delivery attempt (s): 3.975690 Time span (days): 0.198014 Average concurrency: 47.1606 I'll send along vmstat entries if anyone thinks it would help. Any ideas? I've got multiple boxes here with the same hardware configuration just slated for this project but if I'm not able to get the rate much higher I'm probably going to have to consider this whole effort a failure. thanks -- Matthew Harrell Behind every great computer sits Bit Twiddlers, Inc. a skinny little geek. [EMAIL PROTECTED]
Your problem is not QMail, it's disk. We've been configuring an array of servers to allow us to send approximately 1000 messages per second from a span of 4 servers, each running 4 separate qmail queues on 4 separate disks. My first recommendation is to turn up the concurrencyremote. The majority of the time in *most* SMTP transactions is establishing the connection and then closing it at the finish. You can bypass QMail's limit of 255 by making a small code modification, but do this carefully--you may need to turn up your operating system's max procs. I'd build a RAID configuration with a large disk cache. Of all the various things we've done, the raid cache made the most significant performance increase. High speed 10k rpm drives (shameless plug for Seagate's Cheetah...) allow for fast queue retrieval and the cache allows for fast queue filling. I would put those fsyncs back in. No fsyncs is evil :) But I'm sure you already knew that part. Now this may or may not be an issue, but generating the messages on the same server you send from may slow you down. We are able to fill a queue via qmail-smtpd at about 300 messages or so per second to any one qmail but via qmail-inject it's only around 400--not that significant of an increase. With that in mind, it doesn't seem like its worth wasting processor cycles to save that extra time. In fact if you send via qmtp it would probably be even closer to 400 per second. Also, what's wrong with a 100k+ queue? The majority of your messages are not deferalls, they succeed. That tells me that your messages are getting through the first time the queue picks them up and processes them. A lot of messages should only slow you down if they continually fail. If 50% fail, it is only sending half as many messages per second as it could. Fill the queue so qmail doesn't have to worry about doing it while you're sending.. I would fill it as fast as I can so qmail doesn't have to worry about doing 2 things at once. Then again, I'm wrong sometimes too. :) Try things out and see what gives you the best results. Many factors influence mail delivery speed. I haven't even gotten into the minor idiosyncrasies such as network controller (PCI vs ISA actually does make a difference when you're doing high performance mail delivery... little things that seem negligible most times often aren't when you go orders of magnitude higher and volume), or even the type of bandwidth you have to send out on. For us, 16 messages per second filled a T1 with ~20k messages. Keep in mind that every little thing goes a long way. Cris Daniluk MicroStrategy > -----Original Message----- > From: Matthew Harrell [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 02, 1999 1:05 PM > To: Qmail List > Subject: Any ideas? > > > > Okay, I'm trying to pull even more out of my qmail box. It's > a dual P2 450 > with 256 MB of RAM and the following qmail configuration: > > qmail with fsync's removed > concurrencyremote set to 120 > big-todo patch installed > using cyclog and not syslog > > I'm getting what appears to be around 60K messages per hour > and I'm wondering > what I can do to get a higher throughput. Any ideas are > welcome. I'm using > a Perl script talking directly to qmail-queue to pump the > messages in (each > of which is slightly unique) and I know that's not the > limiter because I have > to slow the script down to avoid filling the queue up (100K+ > messages). Here's > some output from qmailanalog: > > Completed messages: 196952 > Recipients for completed messages: 196956 > Total delivery attempts for completed messages: 197869 > Average delivery attempts per completed message: 1.00466 > Bytes in completed messages: 1152135331 > Bytes weighted by success: 1140658136 > Average message qtime (s): 12.2331 > > Total delivery attempts: 202944 > success: 195605 > failure: 2398 > deferral: 4941 > Total ddelay (s): 2338545.236874 > Average ddelay per success (s): 11.955447 > Total xdelay (s): 806842.48747 > Average xdelay per delivery attempt (s): 3.975690 > Time span (days): 0.198014 > Average concurrency: 47.1606 > > I'll send along vmstat entries if anyone thinks it would > help. Any ideas? > I've got multiple boxes here with the same hardware > configuration just slated > for this project but if I'm not able to get the rate much > higher I'm probably > going to have to consider this whole effort a failure. > > thanks > > -- > Matthew Harrell Behind every great > computer sits > Bit Twiddlers, Inc. a skinny little geek. > [EMAIL PROTECTED] >
: Your problem is not QMail, it's disk. We've been configuring an array of : servers to allow us to send approximately 1000 messages per second from a : span of 4 servers, each running 4 separate qmail queues on 4 separate disks. Actually, one of my next thoughts was to try multiple instantiations of qmail on the same machine. I'm getting in a series of Compaqs with four drives each on them and I thought this might be a good utilization of all that disk space if it made sense. I wasn't sure how much of a difference multiple instantiations might make on the same machine but I was going to give it a try. You have four queues - do those machines have four processors or less? : My first recommendation is to turn up the concurrencyremote. The majority of : the time in *most* SMTP transactions is establishing the connection and then : closing it at the finish. You can bypass QMail's limit of 255 by making a : small code modification, but do this carefully--you may need to turn up your : operating system's max procs. Agreed. I thought the limit was 120 but I was going to go digging into the code today to find out where it's listed. How do I turn up the number of concurrent processes under Linux? : I'd build a RAID configuration with a large disk cache. Of all the various : things we've done, the raid cache made the most significant performance : increase. High speed 10k rpm drives (shameless plug for Seagate's : Cheetah...) allow for fast queue retrieval and the cache allows for fast : queue filling. I would put those fsyncs back in. No fsyncs is evil :) But : I'm sure you already knew that part. The Compaq's have a RAID controller on them. I'll have to break out the book and figure out how to work with it. Luckily, it's now supported under the Linux kernels. : Now this may or may not be an issue, but generating the messages on the same : server you send from may slow you down. We are able to fill a queue via : qmail-smtpd at about 300 messages or so per second to any one qmail but via : qmail-inject it's only around 400--not that significant of an increase. With : that in mind, it doesn't seem like its worth wasting processor cycles to : save that extra time. In fact if you send via qmtp it would probably be even : closer to 400 per second. Generate them on one machine and use qmtp to pass them to the client machines? That's pretty much what I was doing already although I haven't bothered to time it yet. How have you timed it? : Also, what's wrong with a 100k+ queue? The majority of your messages are not : deferalls, they succeed. That tells me that your messages are getting : through the first time the queue picks them up and processes them. A lot of : messages should only slow you down if they continually fail. If 50% fail, it : is only sending half as many messages per second as it could. Fill the queue : so qmail doesn't have to worry about doing it while you're sending.. I would : fill it as fast as I can so qmail doesn't have to worry about doing 2 things : at once. Then again, I'm wrong sometimes too. :) Well, without the big-todo patch that allows a hashed queue that many messages is supposed to slow qmail down badly. I personally haven't done time trials on it but I have noticed a change. Even with the patch I just assumed it must be detrimental to load it up that badly. I would be glad to hear that isn't the case, though. thanks for all the info. -- Matthew Harrell Nondeterminism means never Bit Twiddlers, Inc. having to say you are wrong. [EMAIL PROTECTED]
Matthew Harrell <[EMAIL PROTECTED]> wrote: >Okay, I'm trying to pull even more out of my qmail box. It's a dual P2 450 >with 256 MB of RAM and the following qmail configuration: > > qmail with fsync's removed > concurrencyremote set to 120 > big-todo patch installed > using cyclog and not syslog Do you ever hit 120 qmail-remotes? If so, upping the concurrencyremote will help. You'll have to change conf-spawn and rebuild. >I'll send along vmstat entries if anyone thinks it would help. Couldn't hurt. >Any ideas? You have to locate the bottleneck before you can remove it (and reveal the next bottleneck). Why are you only getting 60k msgs/hr? Is it queue disk I/O? Network bandwidth? Memory (doubtful)? CPU (also doubtful)? -Dave
Matthew Harrell <[EMAIL PROTECTED]> wrote: >Even with the [big-todo] patch I just assumed it must be detrimental >to load it up that badly. ``Profile. Don't speculate.'' --DJB -Dave
> -----Original Message----- > From: Matthew Harrell [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 02, 1999 3:07 PM > To: [EMAIL PROTECTED]; Qmail List > Subject: Re: Any ideas? > > > > : Your problem is not QMail, it's disk. We've been > configuring an array of > : servers to allow us to send approximately 1000 messages per > second from a > : span of 4 servers, each running 4 separate qmail queues on > 4 separate disks. > > Actually, one of my next thoughts was to try multiple > instantiations of qmail > on the same machine. I'm getting in a series of Compaqs with > four drives each > on them and I thought this might be a good utilization of all > that disk space > if it made sense. I wasn't sure how much of a difference multiple > instantiations might make on the same machine but I was going > to give it a > try. You have four queues - do those machines have four > processors or less? > The machines are Dual's. Proc load is not an issue though, they never peak. Too many processors, IMO, just compromises stability. Each queue is bound to a different network card, which isn't really necessary, but convenient. I feel that it makes a big difference having multiple qmails on multiple disks. You are undoubtedly not maximizing your memory and cpu on the machine. If you have all separate drives on a RAID with good cache, you probably aren't maximizing your SCSI bus either. It is nice to get every ounce possible out of your equipment. > : My first recommendation is to turn up the > concurrencyremote. The majority of > : the time in *most* SMTP transactions is establishing the > connection and then > : closing it at the finish. You can bypass QMail's limit of > 255 by making a > : small code modification, but do this carefully--you may > need to turn up your > : operating system's max procs. > > Agreed. I thought the limit was 120 but I was going to go > digging into the > code today to find out where it's listed. > > How do I turn up the number of concurrent processes under Linux? > Hopefully you're using 2.2.x. If this is the case you shouldn't need to, just make sure your file descriptors are high enough (/proc/sys/kernel/file-max). > : I'd build a RAID configuration with a large disk cache. Of > all the various > : things we've done, the raid cache made the most significant > performance > : increase. High speed 10k rpm drives (shameless plug for Seagate's > : Cheetah...) allow for fast queue retrieval and the cache > allows for fast > : queue filling. I would put those fsyncs back in. No > fsyncs is evil :) But > : I'm sure you already knew that part. > > The Compaq's have a RAID controller on them. I'll have to > break out the book > and figure out how to work with it. Luckily, it's now > supported under the > Linux kernels. > > : Now this may or may not be an issue, but generating the > messages on the same > : server you send from may slow you down. We are able to fill > a queue via > : qmail-smtpd at about 300 messages or so per second to any > one qmail but via > : qmail-inject it's only around 400--not that significant of > an increase. With > : that in mind, it doesn't seem like its worth wasting > processor cycles to > : save that extra time. In fact if you send via qmtp it would > probably be even > : closer to 400 per second. > > Generate them on one machine and use qmtp to pass them to the > client machines? > That's pretty much what I was doing already although I > haven't bothered to > time it yet. How have you timed it? > What I'm referring to is building the messages on a server separate to the one you're sending the mail from. Your server should still send to clients via SMTP (just because I imagine most clients don't support QMTP)... > : Also, what's wrong with a 100k+ queue? The majority of your > messages are not > : deferalls, they succeed. That tells me that your messages > are getting > : through the first time the queue picks them up and > processes them. A lot of > : messages should only slow you down if they continually > fail. If 50% fail, it > : is only sending half as many messages per second as it > could. Fill the queue > : so qmail doesn't have to worry about doing it while you're > sending.. I would > : fill it as fast as I can so qmail doesn't have to worry > about doing 2 things > : at once. Then again, I'm wrong sometimes too. :) > > Well, without the big-todo patch that allows a hashed queue > that many messages > is supposed to slow qmail down badly. I personally haven't > done time trials > on it but I have noticed a change. Even with the patch I > just assumed it must > be detrimental to load it up that badly. I would be glad to > hear that isn't > the case, though. > The big-todo patch does not affect the entire queue, it only affects the todo directory. It hashes out the todo directory which is where messages are dumped when they come into QMail for the first time, before they are processed. You shouldn't have any probs with it hashed. > thanks for all the info. > > -- > Matthew Harrell Nondeterminism means never > Bit Twiddlers, Inc. having to say you > are wrong. > [EMAIL PROTECTED] > Good luck. Keep an eye on your pipe's bandwidth. :)
: Do you ever hit 120 qmail-remotes? If so, upping the concurrencyremote : will help. You'll have to change conf-spawn and rebuild. To be honest, one machine doesn't, one might. The instantaneous checks I can do show a high number of qmail-remotes running but I've never seen 120. I figured I would try it and see if the number increased or not. :>I'll send along vmstat entries if anyone thinks it would help. : Couldn't hurt. I'll have to get some the next time we run a large email and post some. I don't really know what to make of vmstat results. : You have to locate the bottleneck before you can remove it (and reveal : the next bottleneck). Why are you only getting 60k msgs/hr? Is it : queue disk I/O? Network bandwidth? Memory (doubtful)? CPU (also : doubtful)? We've got a limited T3 and the bandwidth monitors don't show it being a problem. I'm guessing disk I/O is the problem but I'm not positive. I'm going to try spreading my queue across disks and possibly things like reiserfs to see what improvements I might get. Top always shows memory all used, but then it's always like that. There's never a large amount of swap being used. I'm not really sure how to check CPU but I would guess it's not the real problem. -- Matthew Harrell Behind every great computer sits Bit Twiddlers, Inc. a skinny little geek. [EMAIL PROTECTED]
: The machines are Dual's. Proc load is not an issue though, they never peak. : Too many processors, IMO, just compromises stability. Each queue is bound to : a different network card, which isn't really necessary, but convenient. I : feel that it makes a big difference having multiple qmails on multiple : disks. You are undoubtedly not maximizing your memory and cpu on the : machine. If you have all separate drives on a RAID with good cache, you : probably aren't maximizing your SCSI bus either. It is nice to get every : ounce possible out of your equipment. That's what I'm going to try for. The machines do have dual ethernet cards so I may even fiddle with that and see if it helps. : Hopefully you're using 2.2.x. If this is the case you shouldn't need to, : just make sure your file descriptors are high enough : (/proc/sys/kernel/file-max). 2.2.x and sometimes 2.3.x. I remember in the past I had a problem with the file descriptors but I haven't anytime in the last couple months. : What I'm referring to is building the messages on a server separate to the : one you're sending the mail from. Your server should still send to clients : via SMTP (just because I imagine most clients don't support QMTP)... That's what I meant. I was using "client machines" to refer to the machines in my client/server configuration which send out the mail. Thanks. You've given me some good ideas to check on and at least I know that I should be getting more out of the systems. -- Matthew Harrell The perversity of the universe Bit Twiddlers, Inc. tends to a maximum. [EMAIL PROTECTED]
: The qmail logs show remote concurrency over any given time period. Good point. I see it all the time and never think about it. Yes, the one fast machine nears that limit. Without searching hard I see 111 qmail-remotes in the first part of one of my log files. : > Top always shows memory all used, but then it's : > always like that. There's never a large amount of swap being used. : : Ekk! Avoid *any* swapping if at all possible. The processes that are being swapped are ones that aren't being used my the mail process. Things like mingetty and portmap which are even being swapped when the mail system isn't doing anything. : If the load avg. is consistantly below 1 your CPU has room to breathe. Well, it's above 1 but below 10. : Your qmail machine should have local, fast, reliable caching nameserver. : If it's on the qmail machine, perhaps it could be moved to a machine on : the same segment to free memory - nameservers are memory hogs. They're on the same machine. Memory didn't seem to be my limitation and I thought a remote nameserver might cause more latency. I might try it and see what happens, though. -- Matthew Harrell Quantum Mechanics: Bit Twiddlers, Inc. The dreams stuff is made of. [EMAIL PROTECTED]
>: The qmail logs show remote concurrency over any given time period. Not directly, as far as I can tell. Anyone have a script that'll parse a log and chart concurrency? -Dave
: :>I'll send along vmstat entries if anyone thinks it would help. : : Couldn't hurt. One machine shows procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 and the other procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 Does this help ayone? I'm not really sure what to read out of this. -- Matthew Harrell I used to have a handle on life, Bit Twiddlers, Inc. then it broke. [EMAIL PROTECTED]
Feed directly into qmail-remote, not qmail-queue. Only queue when you abosolutely have to. Dirk On Thu, Sep 02, 1999 at 08:04:44AM -0400, Matthew Harrell wrote: > > Okay, I'm trying to pull even more out of my qmail box. It's a dual P2 450 > with 256 MB of RAM and the following qmail configuration: > > qmail with fsync's removed > concurrencyremote set to 120 > big-todo patch installed > using cyclog and not syslog > > I'm getting what appears to be around 60K messages per hour and I'm wondering > what I can do to get a higher throughput. Any ideas are welcome. I'm using > a Perl script talking directly to qmail-queue to pump the messages in (each > of which is slightly unique) and I know that's not the limiter because I have > to slow the script down to avoid filling the queue up (100K+ messages). Here's > some output from qmailanalog: > > Completed messages: 196952 > Recipients for completed messages: 196956 > Total delivery attempts for completed messages: 197869 > Average delivery attempts per completed message: 1.00466 > Bytes in completed messages: 1152135331 > Bytes weighted by success: 1140658136 > Average message qtime (s): 12.2331 > > Total delivery attempts: 202944 > success: 195605 > failure: 2398 > deferral: 4941 > Total ddelay (s): 2338545.236874 > Average ddelay per success (s): 11.955447 > Total xdelay (s): 806842.48747 > Average xdelay per delivery attempt (s): 3.975690 > Time span (days): 0.198014 > Average concurrency: 47.1606 > > I'll send along vmstat entries if anyone thinks it would help. Any ideas? > I've got multiple boxes here with the same hardware configuration just slated > for this project but if I'm not able to get the rate much higher I'm probably > going to have to consider this whole effort a failure. > > thanks > > -- > Matthew Harrell Behind every great computer sits > Bit Twiddlers, Inc. a skinny little geek. > [EMAIL PROTECTED]
: Feed directly into qmail-remote, not qmail-queue. Only queue : when you abosolutely have to. That's possible. The only problem there is that I would have to set up a set number of connections I would like to use (say 150) and only allow that many qmail-remotes to start plus I would have to determine what to do with unanswered connections. I guess I could jut ignore them and assume they were going to be bounces. It's an option. Have you tried it and noticed much of a speedup over normal qmail processing? -- Matthew Harrell You're just jealous because the Bit Twiddlers, Inc. voices only talk to me. [EMAIL PROTECTED]
Matthew Harrell <[EMAIL PROTECTED]> wrote: >One machine shows > > procs memory swap io system cpu > r b w swpd free buff cache si so bi bo in cs us sy id > 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 > >and the other > > procs memory swap io system cpu > r b w swpd free buff cache si so bi bo in cs us sy id > 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 They look mighty similar. >Does this help ayone? I'm not really sure what to read out of this. It's more informative to run "vmstat 10" while it's peaking. These are the cumulative-since-boot stats. What OS is this? -Dave
On Thu, Sep 02, 1999 at 10:55:35AM -0400, Matthew Harrell wrote: > Well, it's above 1 but below 10. It's a dual-CPU box, right? Then you should be aiming for load avg. less than 2, otherwise runable jobs are waiting for a CPU. > They're on the same machine. Memory didn't seem to be my limitation and I > thought a remote nameserver might cause more latency. I might try it and see > what happens, though. You had said that top was showing full memory usage, and your machine was swapping a little. If the nameserver is on the same ethernet segment you shouldn't see latency problems and the extra memory should reduce swapping further. What's being swapped isn't really an issue - the act of swapping causes severe performance degredation. james -- James Raftery (JBR54) - Programmer Hostmaster IE Domain Registry Preferred Contact by Email: [EMAIL PROTECTED] UCD Computing Services Web: http://www.domainregistry.ie/ Computer Centre Tel: (+353 1) 7062375 Fax: (+353 1) 7062862 Belfield, Dublin 4, IE
> You had said that top was showing full memory usage, and your machine > was swapping a little. If the nameserver is on the same ethernet segment > you shouldn't see latency problems and the extra memory should > reduce swapping further. What's being swapped isn't really an issue - > the act of swapping causes severe performance degredation. If the system in question is a Linux box, a) full memory usage is the normal state and b) a small amount of swap usage is normal and not neccessarily performance inhibiting. As far as a) goes, the system doesn't free up memory unless it is out of memory. The idea is, why waste cycles freeing up stuff until you need the space? The side effect is that system tools always show full memory. I'm not sure why a small amount of swap is always in use but it seems to be true, and not a performance inhibitor. Check the amount of swap in use at boot time, quiet time, and heavy use time - if they stay the same, then it isn't actually actively swapping. -- gowen -- Greg Owen -- [EMAIL PROTECTED]
On Thu, Sep 02, 1999 at 01:20:49PM -0400, Greg Owen wrote: > in use at boot time, quiet time, and heavy use time - if they stay the same, > then it isn't actually actively swapping. Absolutely. "the act of swapping" is the problem. Assigned swap space is fine - in fact it's quite good, as otherwise you'd be out of memory - but moving stuff into and out of swap is a killer. james -- James Raftery (JBR54) - Programmer Hostmaster IE Domain Registry Preferred Contact by Email: [EMAIL PROTECTED] UCD Computing Services Web: http://www.domainregistry.ie/ Computer Centre Tel: (+353 1) 7062375 Fax: (+353 1) 7062862 Belfield, Dublin 4, IE
Linux swaps. It always does. It has no relevance on performance unless its doing a lot of it. Linux will nice a process down so low that it will decide it's not even worth memory because it never uses it and swap it. It is BETTER to swap this memory than waste it, which is why Linux does it. > -----Original Message----- > From: James Raftery [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 02, 1999 6:32 PM > To: Qmail List > Subject: Re: Any ideas? > > > On Thu, Sep 02, 1999 at 01:20:49PM -0400, Greg Owen wrote: > > in use at boot time, quiet time, and heavy use time - if > they stay the same, > > then it isn't actually actively swapping. > > Absolutely. "the act of swapping" is the problem. Assigned swap space > is fine - in fact it's quite good, as otherwise you'd be out of > memory - but moving stuff into and out of swap is a killer. > > james > -- > James Raftery (JBR54) - Programmer Hostmaster IE Domain Registry > Preferred Contact by Email: [EMAIL PROTECTED] UCD Computing Services > Web: http://www.domainregistry.ie/ Computer Centre > Tel: (+353 1) 7062375 Fax: (+353 1) 7062862 Belfield, Dublin 4, IE >
:> procs memory swap io system cpu :> r b w swpd free buff cache si so bi bo in cs us sy id :> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 :> :>and the other :> :> procs memory swap io system cpu :> r b w swpd free buff cache si so bi bo in cs us sy id :> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 : They look mighty similar. You're right, now that I look at them they do but I swear they're from different machines. : It's more informative to run "vmstat 10" while it's peaking. These are : the cumulative-since-boot stats. : What OS is this? Linux. I'll get peak results next time a big message has to go out. -- Matthew Harrell Quantum Mechanics: Bit Twiddlers, Inc. The dreams stuff is made of. [EMAIL PROTECTED]
On Thu, Sep 02, 1999 at 01:20:49PM -0400, Greg Owen wrote: > I'm not sure why a small amount of swap is always in use but it > seems to be true, and not a performance inhibitor. Check the amount of swap > in use at boot time, quiet time, and heavy use time - if they stay the same, > then it isn't actually actively swapping. When Linux (as of the 2.2 kernel) tries to allocate pages of memory for cache, it may push some inactive pages of processes into swap. This lets it allocate more cache, which is a performance enhancement. -- Bruce Guenter, QCC Communications Corp. EMail: [EMAIL PROTECTED] Phone: (306)249-0220 WWW: http://www.qcc.sk.ca/~bguenter/
: If the system in question is a Linux box, a) full memory usage is : the normal state and b) a small amount of swap usage is normal and not : neccessarily performance inhibiting. : As far as a) goes, the system doesn't free up memory unless it is : out of memory. The idea is, why waste cycles freeing up stuff until you : need the space? The side effect is that system tools always show full : memory. : I'm not sure why a small amount of swap is always in use but it : seems to be true, and not a performance inhibitor. Check the amount of swap : in use at boot time, quiet time, and heavy use time - if they stay the same, : then it isn't actually actively swapping. Yep, this describes the way my systems have always run. The swap never really changes on any of these machines. If it ever did change radically then I know something bad is up. -- Matthew Harrell I no longer need to punish, deceive, Bit Twiddlers, Inc. or compromise myself, unless I want [EMAIL PROTECTED] to stay employed.
Quoting Matthew Harrell ([EMAIL PROTECTED]): > :> procs memory swap io system cpu > :> r b w swpd free buff cache si so bi bo in cs us sy id > :> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 > :> > :>and the other > :> > :> procs memory swap io system cpu > :> r b w swpd free buff cache si so bi bo in cs us sy id > :> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 > > : They look mighty similar. > > You're right, now that I look at them they do but I swear they're from different > machines. Fascinating. I would think the odds certainly are greatly against two machines showing the exact same vmstat output after a number of days uptime. Though not quite astronomical, I suppose. Aaron
:> You're right, now that I look at them they do but I swear they're from different :> machines. : Fascinating. I would think the odds certainly are greatly against two : machines showing the exact same vmstat output after a number of days : uptime. Though not quite astronomical, I suppose. Odds are I screwed up somewhere. It wouldn't surprise me with the last couple of days I've been having. I'll swear I did it right, though. Now I'll just go sulk in my corner... -- Matthew Harrell The Earth is like a tiny grain of Bit Twiddlers, Inc. sand, only much, much heavier. [EMAIL PROTECTED]
-----BEGIN PGP SIGNED MESSAGE----- On Thu, 2 Sep 1999, Aaron L. Meehan wrote: > Quoting Matthew Harrell ([EMAIL PROTECTED]): > > :> procs memory swap io system cpu > > :> r b w swpd free buff cache si so bi bo in cs us sy id > > :> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 > > :>and the other > > :> procs memory swap io system cpu > > :> r b w swpd free buff cache si so bi bo in cs us sy id > > :> 4 2 1 1288 21824 9368 124868 0 0 15 22 18 12 8 21 29 > > : They look mighty similar. > > You're right, now that I look at them they do but I swear they're from different > > machines. > Fascinating. I would think the odds certainly are greatly against two > machines showing the exact same vmstat output after a number of days > uptime. Though not quite astronomical, I suppose. > Aaron Not really... run "vmstat 1" and ignore the first line.... notice anything? iostat 1, mpstat 1, etc. Scott -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN88YpR4PLs9vCOqdAQG6mAQAsfwv5mJMI6tfT+cPqHWcHi31BCOv/8EQ pxMKsZdTB9JhS/5V3vIxG04JwpHYaSygk0wyZ2ZRoTxJ0wwKq85oLDPFT+WpUl1b 0zyeYepPWVCR4+Rim92SGHQm1RxqjDXuswada/+bATQ++zphx4QqgQlsImmcZtyD 44SNbhYFTsg= =JN0K -----END PGP SIGNATURE-----
The following message has appeared in my syslog every four minutes for the past few weeks: Sep 2 08:26:20 T1-IAS-2 qmail: 936278780.744319 warning: trouble injecting bounce message, will try later I am relatively new to qmail, so can anyone tell me where to begin to solve this problem? Thanks! -Carlos
On Tue, 31 Aug 1999, Russell Nelson wrote: > You're solving the wrong problem (which means that you'll never > succeed, except at random). The problem is that Mail.com has no clue. > If you don't give them a clue, you are failing to do the right thing. > Tell Mail.com's customers why their mail isn't going through, and let > *them* LART Mail.com. Would'nt it make sense to ask the fine people at the MAPSRBL to explain the meaning of their test? And to point to qmail as an example of an MTA which will properly bounce back.
I think this has been done. Repeatedly. > -----Original Message----- > From: Nicolas MONNET [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 02, 1999 3:55 PM > To: Russell Nelson > Cc: [EMAIL PROTECTED] > Subject: Re: Mail.com blacklisting > > > > On Tue, 31 Aug 1999, Russell Nelson wrote: > > You're solving the wrong problem (which means that you'll never > > succeed, except at random). The problem is that Mail.com > has no clue. > > If you don't give them a clue, you are failing to do the > right thing. > > Tell Mail.com's customers why their mail isn't going > through, and let > > *them* LART Mail.com. > > Would'nt it make sense to ask the fine people at the MAPSRBL > to explain > the meaning of their test? And to point to qmail as an > example of an MTA > which will properly bounce back. > > >
Nicolas MONNET <[EMAIL PROTECTED]> writes on 2 September 1999 at 16:54:52 +0200 > Would'nt it make sense to ask the fine people at the MAPSRBL to explain > the meaning of their test? And to point to qmail as an example of an MTA > which will properly bounce back. They do explain it now. There are a small number of unusual mail server configurations that will yield a false positive result ("server susceptible to relay") to this test. These servers initially accept the test message, but later take a closer look, detect the relay attempt, and bounce it. They generally involve configurations such as a dumb firewall proxy that accepts anything, backed up by a smart mail hub that does all the hard work. If you are one of the rare folks who has a mail server like this, you already know it's going to do this, so it shouldn't be a problem. This web page is not for you. This also means that if you go probing other people's networks with this form, you may get false positive results. (On the "is my mailer vulnerable?" page, http://maps.vix.com/tsi/ar-test.html, where you run the test from.) It doesn't specifically mention qmail, but it certainly says enough to make it clear that failing this test should not be considered grounds for blocking. The test is clearly intended to help people vet their own sites. For that purpose, false positives are better than flase negatives, especially false positives that come with warnings as these do. Unfortunately, there is no tool so good and no explanation so clear that it will not be misused and misunderstood. -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED] http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
On Thu, 2 Sep 1999 09:36:24 -0500 (CDT), David Dyer-Bennet wrote: >Unfortunately, there is no tool so good and no explanation so clear >that it will not be misused and misunderstood. They do already prevent excessive testing of hosts. Thus, actually doing a relay test wouldn't be excessively abusive on those "small number of unusual mail server configurations" that fail test 7. Getting a relayed response would prove that the relay is open. It could be logged and used to prevent further testing that day/hour/whatever and one could prevent more than say 5 "open" tests in an hour so that relaying load wouldn't be excessive. In addition, a bounce could be counted as evidence that the host doesn't relay. Anyway ... -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
There is a customer getting his internet connection through our node, =
using a Leased Line. Unfortunately the LL is very low quality and the =
connection some times is completely refusing to came up (Greek Users =
will understand :-) OTE ! ). For that reason, I have setup our main SMTP =
with AUTOTURN, so his e-mails are queued localy in our machine, and when =
his LL get's connected his SMTP is retrieving his mails. So far all =
good. Now our customer is asking for a "backup" solution, so we are =
thinking to give him a static IP dialup capability. My problem and =
question is how to configure autoturn to be triggered by two different =
IP addresses....?=20
Best Regards
Filippos Slavik################################################################
Filippos Slavik
Part of the SIAMS's implementation development team. For more
information, please check http://www.siams.net
e-mail : [EMAIL PROTECTED]
################################################################
"The software said 'runs on Win95 or better,' so I installed
it on Linux..."
Hello, I have users get email for their domains via dialup. They use different Mail Server programs allows to fetch msgs via POP3 and toss it for LAN users. Everything is fine till some of LAN users try to get in maillists. The problem is MailServers (like Mdaemon, Winproxy, serialmail, etc..) toss messages by "TO:" field, and since maillists messages dont contain user address in "TO:" (there is a maillist address), so MailServer programs can't recognize whom this messages came for.. Is it any solution for a such problem? Best regards, Egor Nikolaev , [EMAIL PROTECTED] Russian FarPost http://www.farpost.com ICQ: 15044193
egor writes: > Hello, > > I have users get email for their domains via dialup. They use different > Mail Server programs allows to fetch msgs via POP3 and toss it for LAN users. > > Everything is fine till some of LAN users try to get in maillists. > > The problem is MailServers (like Mdaemon, Winproxy, serialmail, etc..) > toss messages by "TO:" field, and since maillists messages dont > contain user address in "TO:" (there is a maillist address), so > MailServer programs can't recognize whom this messages came for.. > > Is it any solution for a such problem? Probably, but this has nothing to do with Qmail. -- Sam
Delivered-To: -- Many are called, few are chosen. Fewer still choose. On Fri, 3 Sep 1999, egor wrote: > Hello, > > I have users get email for their domains via dialup. They use different > Mail Server programs allows to fetch msgs via POP3 and toss it for LAN users. > > Everything is fine till some of LAN users try to get in maillists. > > The problem is MailServers (like Mdaemon, Winproxy, serialmail, etc..) > toss messages by "TO:" field, and since maillists messages dont > contain user address in "TO:" (there is a maillist address), so > MailServer programs can't recognize whom this messages came for.. > > Is it any solution for a such problem? > > Best regards, > Egor Nikolaev , [EMAIL PROTECTED] > Russian FarPost > http://www.farpost.com > ICQ: 15044193 > > >
Is anyone running qmail on an alpha based machine out there? If so, what are your thoughts on it? Any problems that would affect choosing to run this on an alpha? Thanks Chris
We do it all the time. I highly recommend it. :) On Thu, 2 Sep 1999, Kulish, Chris (Des Moines) wrote: > Is anyone running qmail on an alpha based machine out there? If so, what > are your thoughts on it? Any problems that would affect choosing to run > this on an alpha? > > Thanks > Chris > --------------------------------- Timothy L. Mayo mailto:[EMAIL PROTECTED] Senior Systems Administrator localconnect(sm) http://www.localconnect.net/ The National Business Network Inc. http://www.nb.net/ One Monroeville Center, Suite 850 Monroeville, PA 15146 (412) 810-8888 Phone (412) 810-8886 Fax
On Thu, 2 Sep 1999, Kulish, Chris (Des Moines) wrote: > Is anyone running qmail on an alpha based machine out there? If so, what > are your thoughts on it? Any problems that would affect choosing to run > this on an alpha? We run qmail as the mail transport agent for a very active Listserv on an AlphaServer 2100 with Tru64 Unix. It works very nicely although it was a pain in the neck to configure it to work properly with Listserv due to a lack of documentation on how the two work together.
Stan Horwitz <[EMAIL PROTECTED]> wrote: >It works very nicely although it was a >pain in the neck to configure it to work properly with Listserv due to a >lack of documentation on how the two work together. If you kept notes and you'd like to donate a section to "Life with qmail", let me know. -Dave
"Kulish, Chris (Des Moines)" wrote: > > Is anyone running qmail on an alpha based machine out there? If so, what > are your thoughts on it? Any problems that would affect choosing to run > this on an alpha? > > Thanks > Chris I do. It seems to compile best with gcc-2.95 (latest); some pointed that the -O2 optimization option should be removed in order to compile. Regards Fabrice Scemama -- "A l'encontre de ce que pourraient penser d'aucuns quidams mal renseignes un contestataire est un homme en colere qui conteste, et non un idiot en fureur qui fait son testament." -- Pierre Dac
Has anyone successfully gotten daemontools 0.6x working perfectly with qmail? I was able to make it mostly work, I think. I get it up and running, all my processes start and log but it doesn't seem to stop or shutdown properly. I send it a svc -dx /supervisedir/ and it kills supervise but all the processes stay running. If necessary I can post examples of my commands and ./run files that I use to start. Thanks for any help Tim Hunter CIMx Company 1001 Ford Circle Cincinnati, OH 45150 ph: (513) 248-7700 FX: (513) 248-7711 [EMAIL PROTECTED] http://www.cimx.com
I believe your run files are messed up. Please post them. On Thu, 2 Sep 1999, Tim Hunter wrote: > Has anyone successfully gotten daemontools 0.6x working perfectly with qmail? > I was able to make it mostly work, I think. I get it up and running, all > my processes start and log but it doesn't seem to stop or shutdown properly. > I send it a svc -dx /supervisedir/ and it kills supervise but all the > processes stay running. If necessary I can post examples of my commands > and ./run files that I use to start. > Thanks for any help > > Tim Hunter > CIMx Company > 1001 Ford Circle > Cincinnati, OH 45150 > ph: (513) 248-7700 > FX: (513) 248-7711 > [EMAIL PROTECTED] > http://www.cimx.com > > --------------------------------- Timothy L. Mayo mailto:[EMAIL PROTECTED] Senior Systems Administrator localconnect(sm) http://www.localconnect.net/ The National Business Network Inc. http://www.nb.net/ One Monroeville Center, Suite 850 Monroeville, PA 15146 (412) 810-8888 Phone (412) 810-8886 Fax
At 02:49 PM 9/2/99 -0400, you wrote: >I believe your run files are messed up. Please post them. from /etc/rc.d/init.d/qmail echo -n "Starting qmail: qmail-send" supervise /var/qmail/supervise/send | setuidgid qmaill multilog /var/log/qmail & echo -n " qmail-smtpd" supervise /var/qmail/supervise/smtpd | setuidgid qmaill multilog /var/log/qmail/smtpd & echo -n " qmail-pop3d" supervise /var/qmail/supervise/pop3d | setuidgid qmaill multilog /var/log/qmail/pop3d & from /var/qmail/supervise/send/run #!/bin/sh # Using daemontools for logging # Using control/defaultdelivery from qmail-local to deliver messages by default exec env - PATH="/var/qmail/bin:$PATH" \ qmail-start "`cat /var/qmail/control/defaultdelivery`" | tai64n | tai64nlocal from /var/qmail/supervise/smtpd/run #!/bin/sh exec env - PATH="/var/qmail/bin:$PATH" \ tcpserver -v -x/etc/tcp.smtp.cdb -u503 -g503 0 smtp qmail-smtpd-wrapper 2>&1 | tai64n | tai64nlocal from /var/qmail/supervise/pop3d/run #!/bin/sh exec env - PATH="/var/qmail/bin:$PATH" \ tcpserver -v -R 0 pop-3 qmail-popup xxx.org \ /home/vpopmail/bin/vchkpw qmail-pop3d Maildir 2>&1 | tai64n | tai64nlocal Thanks again for any help
Tim Hunter <[EMAIL PROTECTED]> wrote: >from /var/qmail/supervise/send/run >#!/bin/sh ># Using daemontools for logging ># Using control/defaultdelivery from qmail-local to deliver messages by default >exec env - PATH="/var/qmail/bin:$PATH" \ >qmail-start "`cat /var/qmail/control/defaultdelivery`" | tai64n | tai64nlocal Pipes in run files are no-no's. Remove the tai64n and tai64nlocal, and let multilog timestamp the entries. -Dave
I'd like to set up a CGI script that allows certain users to modify certain aliases from a Web form. This would include creating and deleting a few, which would require write access to the alias directory. Looking at the permissions on that directory, I see they're "drwxr-sr-x", which leads me to wonder: Does anyone know if qmail would have a problem with changing those permissions? While we're at it, there's got to be a better way than making that directory world-writable. A SUID script and use of sudo also come to mind. However, none of these options sound fantastically attractive, and if anyone has other ideas on how to do this, I'd be open to suggestions. ----------------------------------------------------------------- Kai MacTane System Administrator Online Partners.com, Inc. ----------------------------------------------------------------- >From the Jargon File: (v4.0.0, 25 Jul 1996) hired gun /n./ A contract programmer, as opposed to a full-time staff member. All the connotations of this term suggested by innumerable spaghetti Westerns are intentional.
Try setting up a tcpserver/tcpclient system to do what you want. tcpserver runs as alias or root. tcpclient passes in the info you want to change and you can set up your authentication rules/access restrictions in a way that make sense for your system. I use this quite a bit and it has been VERY useful. On Thu, 2 Sep 1999, Kai MacTane wrote: > I'd like to set up a CGI script that allows certain users to modify certain > aliases from a Web form. This would include creating and deleting a few, > which would require write access to the alias directory. > > Looking at the permissions on that directory, I see they're "drwxr-sr-x", > which leads me to wonder: Does anyone know if qmail would have a problem > with changing those permissions? > > While we're at it, there's got to be a better way than making that > directory world-writable. A SUID script and use of sudo also come to mind. > However, none of these options sound fantastically attractive, and if > anyone has other ideas on how to do this, I'd be open to suggestions. > > ----------------------------------------------------------------- > Kai MacTane > System Administrator > Online Partners.com, Inc. > ----------------------------------------------------------------- > From the Jargon File: (v4.0.0, 25 Jul 1996) > > hired gun /n./ > > A contract programmer, as opposed to a full-time staff member. All > the connotations of this term suggested by innumerable spaghetti > Westerns are intentional. > > --------------------------------- Timothy L. Mayo mailto:[EMAIL PROTECTED] Senior Systems Administrator localconnect(sm) http://www.localconnect.net/ The National Business Network Inc. http://www.nb.net/ One Monroeville Center, Suite 850 Monroeville, PA 15146 (412) 810-8888 Phone (412) 810-8886 Fax
At 1:05 pm -0700 2/9/99,the wonderful Kai MacTane wrote: >I'd like to set up a CGI script that allows certain users to modify certain >aliases from a Web form. This would include creating and deleting a few, >which would require write access to the alias directory. > >Looking at the permissions on that directory, I see they're "drwxr-sr-x", >which leads me to wonder: Does anyone know if qmail would have a problem >with changing those permissions? I have a little system where by people can add entries to a mysql database, with passwords and stuff. every 15 mins, a root crond job comes along, rebuilds virtualdomains, rcpthosts and /etc/aliases and reloads qmail, and thus, users change their forwarding settings. (using the fastforward package of course) as long as your cgi does enough syntax checking, your /etc/aliases shouldn't get broken. peter -- peter at gradwell dot com; http://www.gradwell.com/ gradwell dot com Ltd. Enabling the internet you don't see. ** Cheap and easy ecommerce: http://www.gradwell.net/ **
Oy. Guess I get to delurk now. Hi, my name is Nathan J. Mehl. I run qmail on my home system, blank.org. I also happen to be the Senior Systems Administrator for Mail.Com. Let me state this for the record: MAIL.COM DOES NOT, NEVER HAS, AND NEVER WILL BLACKLIST SERVERS BASED ON THE http://maps.vix.com/tsi/new-rlytest.cgi SCRIPT. I'm afraid that the message sent by the abuse staff at Mail.Com to Mr. Bell was somewhat unclear. iq-ss5.iquest.net was blocked because we received an unexpectedly high volume of mail from it. Period. The speculation that it was an open relay was just that, speculation, and we provided the pointer to the vix.com relay tester as a courtesy to Mr. Bell. Here is the crux of the matter: we would have blacklisted the server even if it had "passed" the TSI Relay Test. Allow me to offer my apologies to Mr. Bell for the inconvenience suffered. And please don't flood our abuse desk with requests to stop something we never did; they're busy enough as it is. :) -n ------------------------------------------------------------<[EMAIL PROTECTED]> SENDING JUNK EMAIL TO MY ADDRESS CONSTITUTES YOUR LEGALLY-BINDING ACCEPTANCE OF MY OFFER TO REMOVE BOTH OF YOUR NIPPLES WITH AN ORBITAL SANDER. (--Andy Ihnatko) <http://www.blank.org/memory/>------------------------------------------------
Hi Nathan, Thanks for the response. I have received one mail from Mail.com and that was the one claiming my machine may be an open relay, and of course it isn't, that was a few days ago now. I have not heard back from several messages sent since, and I need this machine unblacklisted ASAP as the many different domains that mail.com et al use are too numerous to keep track of and route through other machines, and many of our subscribers are being dropped from the lists through no fault of their own. WHat can I do to get this resolved? Thanks, Justin Bell On Thu, Sep 02, 1999 at 04:16:07PM -0400, Nathan J. Mehl wrote: # # Oy. Guess I get to delurk now. # # Hi, my name is Nathan J. Mehl. I run qmail on my home system, # blank.org. # # I also happen to be the Senior Systems Administrator for Mail.Com. # # Let me state this for the record: # # MAIL.COM DOES NOT, NEVER HAS, AND NEVER WILL BLACKLIST SERVERS BASED # ON THE http://maps.vix.com/tsi/new-rlytest.cgi SCRIPT. # # I'm afraid that the message sent by the abuse staff at Mail.Com to Mr. # Bell was somewhat unclear. iq-ss5.iquest.net was blocked because we # received an unexpectedly high volume of mail from it. Period. The # speculation that it was an open relay was just that, speculation, and # we provided the pointer to the vix.com relay tester as a courtesy to # Mr. Bell. # # Here is the crux of the matter: we would have blacklisted the server # even if it had "passed" the TSI Relay Test. # # Allow me to offer my apologies to Mr. Bell for the inconvenience # suffered. And please don't flood our abuse desk with requests to stop # something we never did; they're busy enough as it is. :) # # -n # # ------------------------------------------------------------<[EMAIL PROTECTED]> # SENDING JUNK EMAIL TO MY ADDRESS CONSTITUTES YOUR LEGALLY-BINDING ACCEPTANCE # OF MY OFFER TO REMOVE BOTH OF YOUR NIPPLES WITH AN ORBITAL SANDER. # (--Andy Ihnatko) # <http://www.blank.org/memory/>------------------------------------------------ -- /- [EMAIL PROTECTED] --------------- [EMAIL PROTECTED] -\ |Justin Bell NIC:JB3084| Time and rules are changing. | |Pearson | Attention span is quickening. | |Developer | Welcome to the Information Age. | \-------- http://www.superlibrary.com/people/justin/ ----------/
How on earth can you block based on volume? Our company sends out alerts to subscribers daily. This is very high volume and only sent to those who explicitly request it. That most certainly is not spam. The very nature of what you do lends itself to receiving high mail counts that are completely legitimate. Not to start yet another flame war or anything, but I could deal with the fact that the relay tests were misleading people into this. This, on the other hand, is outrageous. If I was in the shoes of Mr Bell, I would be more offended now than in the first place. If his mail was in fact legitimate, which I think he said it was, I think you are making some actions which could have potential legal ramifications should he chose to take that route. If it is in fact spam, by your own admissions, you didn't check to see, you blindly blacklisted it. If I was in his shoes, I can say unequivocably that you would be receiving a call from my lawyer. I suggest you seriously reevaluate this policy and focus on filtering spam, not mail. I would rather delete 500 spam email messages than lose a SINGLE valid email. By filtering out good mail, you make YOU the problem, not spam. Keep that in mind. Be a service, not a detriment. > -----Original Message----- > From: Nathan J. Mehl [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 02, 1999 9:16 PM > To: David Harris; Justin Bell; [EMAIL PROTECTED] > Subject: Re: Lobby mail.com > > > > Oy. Guess I get to delurk now. > > Hi, my name is Nathan J. Mehl. I run qmail on my home system, > blank.org. > > I also happen to be the Senior Systems Administrator for Mail.Com. > > Let me state this for the record: > > MAIL.COM DOES NOT, NEVER HAS, AND NEVER WILL BLACKLIST SERVERS BASED > ON THE http://maps.vix.com/tsi/new-rlytest.cgi SCRIPT. > > I'm afraid that the message sent by the abuse staff at Mail.Com to Mr. > Bell was somewhat unclear. iq-ss5.iquest.net was blocked because we > received an unexpectedly high volume of mail from it. Period. The > speculation that it was an open relay was just that, speculation, and > we provided the pointer to the vix.com relay tester as a courtesy to > Mr. Bell. > > Here is the crux of the matter: we would have blacklisted the server > even if it had "passed" the TSI Relay Test. > > Allow me to offer my apologies to Mr. Bell for the inconvenience > suffered. And please don't flood our abuse desk with requests to stop > something we never did; they're busy enough as it is. :) > > -n > > ------------------------------------------------------------<m > [EMAIL PROTECTED]> > SENDING JUNK EMAIL TO MY ADDRESS CONSTITUTES YOUR > LEGALLY-BINDING ACCEPTANCE > OF MY OFFER TO REMOVE BOTH OF YOUR NIPPLES WITH AN ORBITAL SANDER. > > (--Andy Ihnatko) > <http://www.blank.org/memory/>-------------------------------- ----------------
Nathan J. Mehl <[EMAIL PROTECTED]> writes on 2 September 1999 at 16:16:07 -0400 > > Oy. Guess I get to delurk now. So, welcome to the qmail list. Were you hoping for a nice, quiet, lurk? Oh well :-) . > Hi, my name is Nathan J. Mehl. I run qmail on my home system, > blank.org. > > I also happen to be the Senior Systems Administrator for Mail.Com. > > Let me state this for the record: > > MAIL.COM DOES NOT, NEVER HAS, AND NEVER WILL BLACKLIST SERVERS BASED > ON THE http://maps.vix.com/tsi/new-rlytest.cgi SCRIPT. > > I'm afraid that the message sent by the abuse staff at Mail.Com to Mr. > Bell was somewhat unclear. iq-ss5.iquest.net was blocked because we > received an unexpectedly high volume of mail from it. Period. The > speculation that it was an open relay was just that, speculation, and > we provided the pointer to the vix.com relay tester as a courtesy to > Mr. Bell. > > Here is the crux of the matter: we would have blacklisted the server > even if it had "passed" the TSI Relay Test. Well, that clears up one issue, but raises another. In the nature of things, mail.com is likely to get lots of mail from certain servers -- those hosting mailing lists, those belonging to other big email providers. My server, for example, hosts one fairly large monthly newsletter that has over 1000 subscribers at hotmail.com. (Only something like 12 at mail.com, or I'd be using you for the example). So, each month when that goes out, hotmail.com will receive a big batch of emails from me. If that list had 1000 subscribers at mail.com, would you have blacklisted me? Blacklisting anybody who sends you a lot of email sounds like a short trip to a situation where your users can't subscribe to any large email lists, or any email lists hosted by large list providers, because you'll have blacklisted them all. This is so completely nonsensical that it must not be, really, what mail.com is doing. You're under no obligation to try to explain your employer's policies to us, of course. And for that matter, your employer is not required to have rational policies :-) . I don't really want to convene the high court of marsupial justice right here in the mailing list. -- David Dyer-Bennet ***NOTE ADDRESS CHANGES*** [EMAIL PROTECTED] http://dd-b.lighthunters.net/ (photos) Minicon: http://www.mnstf.org/minicon http://www.dd-b.net/dd-b (sf) http://ouroboros.demesne.com/ Ouroboros Bookworms Join the 20th century before it's too late!
Nathan J. Mehl [mailto:[EMAIL PROTECTED]] wrote: [snip] > Hi, my name is Nathan J. Mehl. I run qmail on my home system, > blank.org. > > I also happen to be the Senior Systems Administrator for Mail.Com. > > Let me state this for the record: > > MAIL.COM DOES NOT, NEVER HAS, AND NEVER WILL BLACKLIST SERVERS BASED > ON THE http://maps.vix.com/tsi/new-rlytest.cgi SCRIPT. > > I'm afraid that the message sent by the abuse staff at Mail.Com to Mr. > Bell was somewhat unclear. iq-ss5.iquest.net was blocked because we > received an unexpectedly high volume of mail from it. Period. The > speculation that it was an open relay was just that, speculation, and > we provided the pointer to the vix.com relay tester as a courtesy to > Mr. Bell. > > Here is the crux of the matter: we would have blacklisted the server > even if it had "passed" the TSI Relay Test. [snip] I've been hearing that one the list for the past day or two, and I have come to believe it. However, I only really believed it _after_ I wrote the original e-mail to your help desk which I posted to the list. But the reason I have not spoken up and retracted my complaint is this: _The fact that your blacklisting was not based on any kind of relay test scares me even more._ What happens when an ISP sets up a mail server with tends of thousands of legitimate mail users sending you legitimate mail? What about a list-serv handing out gobs of e-mail specifically requested by your users? Do you black list them too? I don't care particularly _how_ you came to blacklist a legitimate server... but the blacklisting of legitimate servers is what poses a threat to the Internet mail system and what offends people. You sound like you got a large negative reaction to blacklisting the server based on the TSI relay test (which we all thought you did). However, don't just discount this negative reaction. If it had been apparent from the beginning that you blacklisted the server solely on the mail volume, I expect that the reaction would have been just as large. A legitimate mail server got blacklisted. Complaint still stands. - David Harris Principal Engineer, DRH Internet Services bcc: "mail.com corporate address" <[EMAIL PROTECTED]>
# > MAIL.COM DOES NOT, NEVER HAS, AND NEVER WILL BLACKLIST SERVERS BASED # > ON THE http://maps.vix.com/tsi/new-rlytest.cgi SCRIPT. # > # > I'm afraid that the message sent by the abuse staff at Mail.Com to Mr. # > Bell was somewhat unclear. iq-ss5.iquest.net was blocked because we # > received an unexpectedly high volume of mail from it. Period. The # > speculation that it was an open relay was just that, speculation, and # > we provided the pointer to the vix.com relay tester as a courtesy to # > Mr. Bell. # > # > Here is the crux of the matter: we would have blacklisted the server # > even if it had "passed" the TSI Relay Test. # # Well, that clears up one issue, but raises another. In the nature of # things, mail.com is likely to get lots of mail from certain servers -- # those hosting mailing lists, those belonging to other big email # providers. My server, for example, hosts one fairly large monthly # newsletter that has over 1000 subscribers at hotmail.com. (Only # something like 12 at mail.com, or I'd be using you for the example). # So, each month when that goes out, hotmail.com will receive a big # batch of emails from me. If that list had 1000 subscribers at # mail.com, would you have blacklisted me? Yes, they probably would have, of the mail.com etc. domains that they host, one of our three daily large volume lists has the following breakdown: List Total: 46633 iname.com 100 .iname.com 100 altavista.net 12 cheerful.com 20 cybergal.com 7 email.com 64 financier.com 1 iname.com 100 indiamail.com 1 innocent.com 3 mail.com 4352 mail.org 5 mindless.com 16 nightly.com 1 null.net 2 rocketship.com 1 scotlandmail.com 1 seductive.com 1 techie.com 2 unforgettable.com 5 usa.com 59 writeme.com 35 All these people requested to be on this list. So, because your customers want to receive these emails you find it necessary to block us? -- /- [EMAIL PROTECTED] --------------- [EMAIL PROTECTED] -\ |Justin Bell NIC:JB3084| Time and rules are changing. | |Pearson | Attention span is quickening. | |Developer | Welcome to the Information Age. | \-------- http://www.superlibrary.com/people/justin/ ----------/
I am, as of now, speaking for nobody but my own fine self. If you have any questions about Mail.Com's policies, regarding spam or anything else, please direct them to the appropriate addresses at Mail.Com. Also, at this point this is really not even slightly qmail-related, so here's my offer: those of you with something to say who feel you have to say it in public, say it now. I won't answer any more questions on the list after tonight. You can mail me privately if you like, but you takes your chances just like everybody else if you do. In the immortal words of Daniluk, Cris ([EMAIL PROTECTED]): > How on earth can you block based on volume? A better question: how can anybody NOT? Spammers can change their names, change their addresses, alter the length and content of their mail, forge their headers, hide behind proxies, register their assets in the Carribean, get sex changes and crouch down behind shubberies, but there is one fingerprint they can never, ever change: in order to have a prayer of making a profit, they have to send out a lot of mail, really quickly. If I see a host that I do not recognize appear out of the blue and start pumping hundreds or thousands of messages an hour into my mail server, the odds are pretty on that it's a spammer. If it's not, I'm not averse to apologizing later on. > I would rather delete 500 spam email messages than lose a SINGLE valid > email. That's a very noble goal, and it works fine if you've only got a single mail server and a handful of users. You'll find that it doesn't scale very well once you hit the dozens-of-servers and millions-of-users mark. There comes a point (and it comes pretty damn quickly, believe me) where you have to balance mildly inconveniencing a few of your customers against royally pissing off a lot of them by letting the spammers swamp your system to the point where it's of no use to anybody. No, it's not pretty, but of such compromises is the real world made. -n ------------------------------------------------------------<[EMAIL PROTECTED]> Calling Motif a GUI is like calling a pile of bricks an apartment building. <http://www.blank.org/memory/>------------------------------------------------
[Again, speaking for nobody but my own cranky self here.] In the immortal words of David Dyer-Bennet ([EMAIL PROTECTED]): > > So, welcome to the qmail list. Were you hoping for a nice, quiet, > lurk? Oh well :-) . Hey, I managed to go about six months up until this point. :) > Well, that clears up one issue, but raises another. In the nature of > things, mail.com is likely to get lots of mail from certain servers -- > those hosting mailing lists, those belonging to other big email > providers. [...] > This is so completely nonsensical that it must not be, really, what > mail.com is doing. Of course, since we're all idiots who were born yesterday, that possibility never occurred to us. Who'd've thought that people who use our email service might subscribe to mailing lists? :-) Suffice it to say that yes, we take measures to prevent false positives when blacklisting servers. Obviously they didn't work in this case; hence my apology. The usual reviews and post-mortems will of course take place to try to make certain it doesn't happen again. -n ------------------------------------------------------------<[EMAIL PROTECTED]> five claws each rear paw seven claws on the front paws a cat named Haiku (--Mark Amidon) <http://www.blank.org/memory/>------------------------------------------------
[Speaking, as before, only for my own irritable self.] In the immortal words of David Harris ([EMAIL PROTECTED]): > > But the reason I have not spoken up and retracted my complaint is > this: _The fact that your blacklisting was not based on any kind of > relay test scares me even more._ I have a small news flash here: not all spam comes from open relays. > What happens when an ISP sets up a > mail server with tends of thousands of legitimate mail users sending > you legitimate mail? What about a list-serv handing out gobs of > e-mail specifically requested by your users? Do you black list them > too? See my other note on that subject. > A legitimate mail server got blacklisted. Complaint still stands. The server is out of the blacklist, the affected party has been apologized to, and I guess your complaint is noted. -n ------------------------------------------------------------<[EMAIL PROTECTED]> Transported to a surreal landscape, a young girl kills the first woman she meets and then teams up with three complete stangers to kill again. (-- TV listing for the movie, The Wizard of Oz, in the Marin Paper.) <http://www.blank.org/memory/>------------------------------------------------
Daniluk, Cris writes: > If his mail was in fact legitimate, which I think he said it was, I think > you are making some actions which could have potential legal ramifications > should he chose to take that route. If it is in fact spam, by your own > admissions, you didn't check to see, you blindly blacklisted it. If I was in > his shoes, I can say unequivocably that you would be receiving a call from > my lawyer. And you would be as wrong as you ever have been. As soon as your lawyer heard what your beef was, he'd laugh in your face and throw you out of his office. No matter how dumb or not dumb mail.com's action was, they had every legal right to do what they did. It's their servers, their private property, and their bandwidth. Even if you managed to find some dumb yutz who'd bring this to court on your behalf, the only thing that would happen is a quick summary judgement, with you forced to pay the other guy's legal fees. -- Sam
I would hope not. > Daniluk, Cris writes: > > If his mail was in fact legitimate, which I think he said > it was, I think > > you are making some actions which could have potential > legal ramifications > > should he chose to take that route. If it is in fact spam, > by your own > > admissions, you didn't check to see, you blindly > blacklisted it. If I was in > > his shoes, I can say unequivocably that you would be > receiving a call from > > my lawyer. > No matter how dumb or not dumb mail.com's action was, they > had every legal > right to do what they did. It's their servers, their private > property, and > their bandwidth. Which, if you would note, are used by people who enter into a contractual arrangement by which they either pay mail.com (iname.com users with a POP account, for example) directly or access their e-mail via a web interface where they agree to view ads in exchange for, ahem, receiving e-mail. I don't know what type of list the guy is running, but if, for example, it was a high importance list and the customers of said list lost money or similar because of mail.com's actions (or the list maintainer lost money because of mail.com's non-researched actions), then either the customers and/or himself have a very decent case. IOW, you're forgetting mail.com sells their servers and bandwidth. It's only private if you don't make money on it. > Even if you managed to find some dumb yutz who'd bring this > to court on > your behalf, the only thing that would happen is a quick > summary judgement, > with you forced to pay the other guy's legal fees. I wouldn't be so sure.
On Thu, 2 Sep 1999, Ben Kosse wrote: > IOW, you're forgetting mail.com sells their servers and bandwidth. It's only > private if you don't make money on it. Heh, by that definition, Mail.com, Critical Path, and all the other email outsourcing companies are private. Not a good definition, though. Mail.com can write their contracts however they want; I suspect they include provisions which cover their spam filtering and not being held liable for any damages from filtering errors that inadvertently prevent legitimate mail from getting through. Jim Lippard [EMAIL PROTECTED] http://www.discord.org/ Unsolicited bulk email charge: $500/message. Don't send me any. PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
> Heh, by that definition, Mail.com, Critical Path, and all the > other email > outsourcing companies are private. Not a good definition, though. Let me rephrase the "make money" part. It's only private if you don't receive goods or services in exchange for use of your services. Bleh, if I knew there were lawyers on this list. > Mail.com can write their contracts however they want; I suspect they > include provisions which cover their spam filtering and not being held > liable for any damages from filtering errors that > inadvertently prevent legitimate mail from getting through. Possibly, but unless they're covered by article 2B, they probably have no protection from that.
Ben Kosse writes: > > No matter how dumb or not dumb mail.com's action was, they > > had every legal > > right to do what they did. It's their servers, their private > > property, and > > their bandwidth. > Which, if you would note, are used by people who enter into a contractual > arrangement by which they either pay mail.com (iname.com users with a POP > account, for example) directly or access their e-mail via a web interface > where they agree to view ads in exchange for, ahem, receiving e-mail. I In that case, it's those individuals, and not their system administrator, who have a cause of action to take against mail.com. They might have a legitimate issue, however it is their issue only, and nobody else's. > don't know what type of list the guy is running, but if, for example, it was > a high importance list and the customers of said list lost money or similar > because of mail.com's actions (or the list maintainer lost money because of > mail.com's non-researched actions), then either the customers and/or himself > have a very decent case. The customers may in fact do, I never said that they don't. However, unless they appointed the admin to be their official spokesman, and explicitly delegated to him the authority to take action on their behalf, it's none of the admin's business. -- Sam
On Thu, 2 Sep 1999, Ben Kosse wrote: > > Heh, by that definition, Mail.com, Critical Path, and all the > > other email > > outsourcing companies are private. Not a good definition, though. > Let me rephrase the "make money" part. It's only private if you don't > receive goods or services in exchange for use of your services. Bleh, if I > knew there were lawyers on this list. Nah, I'm not a lawyer, I've just had to deal with them a lot. > > Mail.com can write their contracts however they want; I suspect they > > include provisions which cover their spam filtering and not being held > > liable for any damages from filtering errors that > > inadvertently prevent legitimate mail from getting through. > Possibly, but unless they're covered by article 2B, they probably have no > protection from that. Check out http://www.ljextra.com/internet/UCC2Bintro.html, specifically: ---begin quote--- The second question every asks about Article 2B is, "Will my existing contracts be valid?" This vital question is answered by Section 2B-107(b), which provides: "Except as expressly provided in this article or in Article 1, the effect of any provision of this article, including allocation of risk or imposition of a burden, may be varied by agreement of the parties". This means that you may contract out of virtually any restriction, right, or obligation in the statute. Of course, there is a short list of obligations that may not be varied by contract, but they are common sense exclusions: " ---end quote--- The exclusions are listed on the web page. I don't think any would apply here--UCC 2B won't have any effect on a pre-existing contract that contains such a limitation on liability. Jim Lippard [EMAIL PROTECTED] http://www.discord.org/ Unsolicited bulk email charge: $500/message. Don't send me any. PGP Fingerprint: 0C1F FE18 D311 1792 5EA8 43C8 7AD2 B485 DE75 841C
In the immortal words of Ben Kosse ([EMAIL PROTECTED]): > > It's only private if you don't make money on it. Some statements are just so stunning that they should be framed on their own. Really, I have no response to this, except to gaze at it in sheer awe. -n p.s. http://www.mail.com/mailcom/serviceagreement.html ------------------------------------------------------------<[EMAIL PROTECTED]> My motorcycle/ stands forlorn on Hurlbut Street. The fucker won't start. (--me) <http://www.blank.org/memory/>------------------------------------------------
This may sound rude, but it's not intended to be--what country do you live in? I think you're either under a different set of laws, or have a fundamental misunderstanding of them. Your claims are very inaccurate. VERY inaccurate. The only reason I bring this to the list is that there may be other people in the same situation as mail.com out there and I think they may be reading everything that comes through here as fact. It is illegal for them to block out legitimate email from customers when they agree to provide the mail to customers. They can make you sign contracts that say this is not so, but those contracts can have their legality tried in court. All ISPs and similar services have these contractual agreements that basically disclaim everything they do and quite frankly, out of personal experience, I can say they don't last a second in court. If mail.com accidentally blocked out this and fixed it later that's one thing, but if it was intentional--which in this case it could be construed as, since they made no effort on their part to verify the validity of the mail, they are directly liable. Moreover, the customer and/or the sender would be within their legal rights to sue. The customer lost his mail and that was bad, but the sender potentially lost money as well (in the case of premium content subscriptions such as WSJ.com or others). Customers pay for this service and therefore blocking out a large and significant chunk of users impedes on their profits. In this instance I think all is well between Mail.com and the offender, but I think that they, as well as anyone in similar situations, need to be aware that this is in fact dangerous. Exercise discretion. For your own sakes. -----Original Message----- From: Sam [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 02, 1999 9:19 PM Cc: Qmail (E-mail) Subject: Re: Lobby mail.com Ben Kosse writes: > > No matter how dumb or not dumb mail.com's action was, they > > had every legal > > right to do what they did. It's their servers, their private > > property, and > > their bandwidth. > Which, if you would note, are used by people who enter into a contractual > arrangement by which they either pay mail.com (iname.com users with a POP > account, for example) directly or access their e-mail via a web interface > where they agree to view ads in exchange for, ahem, receiving e-mail. I In that case, it's those individuals, and not their system administrator, who have a cause of action to take against mail.com. They might have a legitimate issue, however it is their issue only, and nobody else's. > don't know what type of list the guy is running, but if, for example, it was > a high importance list and the customers of said list lost money or similar > because of mail.com's actions (or the list maintainer lost money because of > mail.com's non-researched actions), then either the customers and/or himself > have a very decent case. The customers may in fact do, I never said that they don't. However, unless they appointed the admin to be their official spokesman, and explicitly delegated to him the authority to take action on their behalf, it's none of the admin's business. -- Sam
I can understand customers suing for not having their mail delivered. However, I can't see where you make the mental leap to the sender being able to sue. If you are really serious about these claims, then please cite resources and court decisions that support them. The real question is, "are you a lawyer?" If you're not, then you really have no business speaking about the law in any forum. By the way, I noticed that you responded to Sam's message, but you failed to respond to Jim Lippard's posts which had a much more specific objection to your viewpoint, with a relevant quoted source. Is there a reason for this? --Adam On Fri, Sep 03, 1999 at 01:13:33AM -0400, Cris Daniluk wrote: > This may sound rude, but it's not intended to be--what country do you live > in? I think you're either under a different set of laws, or have a > fundamental misunderstanding of them. Your claims are very inaccurate. VERY > inaccurate. The only reason I bring this to the list is that there may be > other people in the same situation as mail.com out there and I think they > may be reading everything that comes through here as fact. It is illegal for > them to block out legitimate email from customers when they agree to provide > the mail to customers. They can make you sign contracts that say this is not > so, but those contracts can have their legality tried in court. All ISPs and > similar services have these contractual agreements that basically disclaim > everything they do and quite frankly, out of personal experience, I can say > they don't last a second in court. If mail.com accidentally blocked out this > and fixed it later that's one thing, but if it was intentional--which in > this case it could be construed as, since they made no effort on their part > to verify the validity of the mail, they are directly liable. Moreover, the > customer and/or the sender would be within their legal rights to sue. The > customer lost his mail and that was bad, but the sender potentially lost > money as well (in the case of premium content subscriptions such as WSJ.com > or others). Customers pay for this service and therefore blocking out a > large and significant chunk of users impedes on their profits. > > In this instance I think all is well between Mail.com and the offender, but > I think that they, as well as anyone in similar situations, need to be aware > that this is in fact dangerous. Exercise discretion. For your own sakes. > > -----Original Message----- > From: Sam [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 02, 1999 9:19 PM > Cc: Qmail (E-mail) > Subject: Re: Lobby mail.com > > > Ben Kosse writes: > > > > No matter how dumb or not dumb mail.com's action was, they > > > had every legal > > > right to do what they did. It's their servers, their private > > > property, and > > > their bandwidth. > > Which, if you would note, are used by people who enter into a contractual > > arrangement by which they either pay mail.com (iname.com users with a POP > > account, for example) directly or access their e-mail via a web interface > > where they agree to view ads in exchange for, ahem, receiving e-mail. I > > In that case, it's those individuals, and not their system administrator, > who have a cause of action to take against mail.com. They might have a > legitimate issue, however it is their issue only, and nobody else's. > > > don't know what type of list the guy is running, but if, for example, it > was > > a high importance list and the customers of said list lost money or > similar > > because of mail.com's actions (or the list maintainer lost money because > of > > mail.com's non-researched actions), then either the customers and/or > himself > > have a very decent case. > > The customers may in fact do, I never said that they don't. However, > unless they appointed the admin to be their official spokesman, and > explicitly delegated to him the authority to take action on their behalf, > it's none of the admin's business. > > -- > Sam > >
On Thu, Sep 02, 1999 at 04:16:07PM -0400, Nathan J. Mehl wrote: > Oy. Guess I get to delurk now. > > Hi, my name is Nathan J. Mehl. I run qmail on my home system, > blank.org. > > I also happen to be the Senior Systems Administrator for Mail.Com. > > Let me state this for the record: > > MAIL.COM DOES NOT, NEVER HAS, AND NEVER WILL BLACKLIST SERVERS BASED > ON THE http://maps.vix.com/tsi/new-rlytest.cgi SCRIPT. > I'm afraid that the message sent by the abuse staff at Mail.Com to Mr. > Bell was somewhat unclear. Uh, Nathan, I'm sure that might be your policy, but you should take another look at the message sent: ----------------- If you check http://maps.vix.com/tsi/new-rlytest.cgi?ADDR=iq-ss5.iquest.net you will see that this machine is an open relay. We therefore blocked it. ----------------- Not only does that indicate that the block was based on the relay test, but it says so very clearly. :) -- John White johnjohn at triceratops.com PGP Public Key: http://www.triceratops.com/john/public-key.pgp
-----Original Message----- From: Adam D . McKenna [mailto:[EMAIL PROTECTED]] Sent: Friday, September 03, 1999 2:06 AM To: Cris Daniluk Cc: Sam; Qmail (E-mail) Subject: Re: Lobby mail.com >I can understand customers suing for not having their mail delivered. >However, I can't see where you make the mental leap to the sender being able >to sue. If you are really serious about these claims, then please cite >resources and court decisions that support them. There are no current court cases. There is, however, strong legal basis. I sell content to a customer which I deliver via email. You cut my route to my customer who has an email account with you. That prevents us from fulfilling our end of the deal between us and our customer. They paid us money, we didn't deliver. If you will all remember, Network Solutions' lawyers were in a similar situation when they were threatened with a blacklist for their high volume of spam. They made this very same argument. That never saw a court room, but then again they aren't blacklisted are they? >The real question is, "are you a lawyer?" If you're not, then you really >have no business speaking about the law in any forum. Are you? Is Sam? Are any of us? No. My point is that. I do have legal background in this subject area though, as it is intimately involved with my job. >By the way, I noticed that you responded to Sam's message, but you failed to >respond to Jim Lippard's posts which had a much more specific objection to >your viewpoint, with a relevant quoted source. Is there a reason for this? Mr. Lippards points are completely irrelevant. He's citing a bill that doesn't exist. Moreover, if it would suit the fancy of those of you who are legal evangalists, I can bring in a list of court cases in which actual statutes were cited, where entire sections of user agreements like what we're discussing were thrown out as unreasonable. I don't have any desire to sift through legal cases to prove a point, so I'd prefer you look it up yourself if you don't believe me. >--Adam This could (and I think has) evolved into a needless flamewar. Whether you think that it is illegal or not, it is STILL a reasonable substantiation to fight in court and it would be a long and expensive battle for both parties and no, Sam, legal fees would not be awarded. If you'll do your homework, legal fees are rarely awarded except in exceptionally erroneous claims. My question is this: Why would you want to go through all this for filtering out one more possible spam sender? And as far as I'm concerned, mail.com or whomever it may be could win a court case by a landslide, but you won't win any customers that way.
On Fri, Sep 03, 1999 at 02:33:01AM -0400, Cris Daniluk wrote: > There are no current court cases. There is, however, strong legal basis. I > sell content to a customer which I deliver via email. You cut my route to my > customer who has an email account with you. That prevents us from fulfilling > our end of the deal between us and our customer. They paid us money, we > didn't deliver. If you will all remember, Network Solutions' lawyers were in > a similar situation when they were threatened with a blacklist for their > high volume of spam. They made this very same argument. That never saw a > court room, but then again they aren't blacklisted are they? > > >The real question is, "are you a lawyer?" If you're not, then you really > >have no business speaking about the law in any forum. > > Are you? Is Sam? Are any of us? No. My point is that. I do have legal > background in this subject area though, as it is intimately involved with my > job. I'm not speaking about the law. I'm just asking you to qualify your own statements. I normally refrain from such discussions unless I'm making claims that I've researched and am ready to stand behind. > >By the way, I noticed that you responded to Sam's message, but you failed > to > >respond to Jim Lippard's posts which had a much more specific objection to > >your viewpoint, with a relevant quoted source. Is there a reason for this? > > Mr. Lippards points are completely irrelevant. He's citing a bill that > doesn't exist. Moreover, if it would suit the fancy of those of you who are > legal evangalists, I can bring in a list of court cases in which actual > statutes were cited, where entire sections of user agreements like what > we're discussing were thrown out as unreasonable. I don't have any desire to > sift through legal cases to prove a point, so I'd prefer you look it up > yourself if you don't believe me. In general, it is desirable for someone who is arguing a point to cite relevant sources, and not argue based (apparently) solely upon his own opinion. This is even more desirable in discussions where the people involved are uninformed, and/or do not trust the other side to give accurate information. In any event, my opinion is that anyone who tries to sue an ISP for refusing to accept mail from them will fail miserably. --Adam
On Thu, 2 Sep 1999, Nathan J. Mehl wrote: (...) > Spammers can change their names, change their addresses, alter the > length and content of their mail, forge their headers, hide behind > proxies, register their assets in the Carribean, get sex changes and > crouch down behind shubberies, but there is one fingerprint they can > never, ever change: in order to have a prayer of making a profit, they > have to send out a lot of mail, really quickly. > > If I see a host that I do not recognize appear out of the blue and > start pumping hundreds or thousands of messages an hour into my mail > server, the odds are pretty on that it's a spammer. If it's not, I'm > not averse to apologizing later on. (...) Is Nathan trying to explain that qmail sends mail so fast that it can't be natural ? ;-)
Actually I'm subscribed to [EMAIL PROTECTED] to gain some wisdom around qmail and it's solution. I think the subject "Re: Lobby mail.com" and it's legal issues is some kind of boring now. (Time to stop or move to another list for legal issues?) What I really would like, is someone telling me how to make qmail check the RCPT TO: against the actual users on my machine. (PLEASE...... ;) ------------------------------------------------------------------- IDG New Media Einar Bordewich System Manager Phone: +47 2205 3034 E-Mail: [EMAIL PROTECTED] -------------------------------------------------------------------
Hi. I'm trying to get qpopup and qpop3d to work with Maildir style directories under Solaris and am running into some baffling problems. I already have it working fine under Linux but our production servers run Solaris. Here's the problem. I can get authorized fine, but qpop3d seems to not be reading the new mail properly and also is then getting confused about things and deleting the whole new directory. Here's a sample login session followed by a truss output. Connected to xxxx.worldway.net. Escape character is '^]'. +OK <[EMAIL PROTECTED]> user test +OK pass **** +OK list +OK 1 512 2 512 3 512 . The result of the list command seems to be the 3 directories in the Maildir directory. Here's what truss shows when I have it hooked up to run qmail-pop3d. [snipped all the library loading stuff] chdir("Maildir") = 0 time() = 936305064 open("tmp", O_RDONLY|O_NDELAY) = 3 fcntl(3, F_SETFD, 0x00000001) = 0 fstat(3, 0xEFFFF558) = 0 brk(0x00026F88) = 0 brk(0x00028F88) = 0 getdents(3, 0x00026FA0, 1048) = 28 stat("tmp/", 0xEFFFF640) = 0 stat("tmp/", 0xEFFFF640) = 0 getdents(3, 0x00026FA0, 1048) = 0 close(3) = 0 time() = 936305064 open("new", O_RDONLY|O_NDELAY) = 3 fcntl(3, F_SETFD, 0x00000001) = 0 fstat(3, 0xEFFFF4E8) = 0 getdents(3, 0x00026FA0, 1048) = 148 stat("new/", 0xEFFFF5D8) = 0 stat("new/", 0xEFFFF5D8) = 0 stat("new/6220688.19039.worldway.net", 0xEFFFF5D8) Err#2 ENOENT stat("new/6221131.20124.worldway.net", 0xEFFFF5D8) Err#2 ENOENT stat("new/6221131.20129.worldway.net", 0xEFFFF5D8) Err#2 ENOENT getdents(3, 0x00026FA0, 1048) = 0 close(3) = 0 open("cur", O_RDONLY|O_NDELAY) = 3 fcntl(3, F_SETFD, 0x00000001) = 0 fstat(3, 0xEFFFF4E8) = 0 getdents(3, 0x00026FA0, 1048) = 44 stat("cur/6221131.20129.worldway.net", 0xEFFFF5D8) Err#2 ENOENT stat("cur/", 0xEFFFF5D8) = 0 stat("cur/,", 0xEFFFF5D8) Err#2 ENOENT getdents(3, 0x00026FA0, 1048) = 0 close(3) = 0 stat("cur/", 0xEFFFF728) = 0 stat("new/", 0xEFFFF728) = 0 stat("new/", 0xEFFFF728) = 0 poll(0xEFFFD610, 1, 1200000) = 1 +OK write(1, " + O K \r\n", 6) = 6 poll(0xEFFFD4F0, 1, 1200000) (sleeping...) poll(0xEFFFD4F0, 1, 1200000) = 0 _exit(0) Here's a listing of the directories for this test user's Maildir total 3 drwxrwxrwx 2 testuser 512 Sep 2 22:26 cur drwxr-xr-x 2 testuser 512 Sep 2 22:24 new drwxrwxrwx 2 testuser 512 Sep 1 22:25 tmp cur: total 0 new: total 5 -rw-rwxrwx 1 testuser 1003 Sep 1 22:18 936220688.19039.worldway.net -rw-rwxrwx 1 testuser 1177 Sep 1 22:25 936221131.20124.worldway.net -rw-rwxrwx 1 testuser 1095 Sep 1 22:25 936221131.20129.worldway.net tmp: total 0 Now if you look where it is stat'ing the files in new and cur, you will see that they have actually been truncated, as the 93 has been chopped off the filename. All this appears to be taking place inside the readdir in maildir.c as none of the qmail files call getdents or stat directly. Also, the message move of the file to cur fails and I get a bogus :2, directory created inside the cur directory then all the messages from new get moved there and the new directory gets deleted. Has anyone seen such bizarre behaviour before? I am completely baffled. The exact same code run the exact same way works fine under Linux. I've compiled this using both gcc and Sun's compiler on the Solaris machine and the results are the same. -- Artificial Intelligence stands no chance against Natural Stupidity. GAT d- -p+(--) c++++ l++ u++ t- m--- W--- !v b+++ e* s-/+ n-(?) h++ f+g+ w+++ y*
Is there a patch, or some internal method, by which I might determine how many messages per second are accumulating in the qmail queue, and how many messages are being successfully delivered per second? I've considered tail -f on the logs, piped through Perl, but as I am running cyclog, this is all but impossible (at least from what I can tell.) Does anyone have a good solution? Thanks in advance. Bill Johnson ([EMAIL PROTECTED]) MicroStrategy
Hi,
I just switched our entire Email system to qmail, and everything went pretty
much without a glitch except for one detail: Of the 300+ messages that came in and out
of my server yesterday (the day I made the switch), there's one that just refuses to be delivered.Symptoms: qmail connects to the remote SMTP server and hangs ...
Here's the exerpt from the maillog (message # if 743435):
hydra# grep 743435 /var/log/maillog
Sep 1 16:00:56 hydra qmail: 936226856.381235 new msg 743435
Sep 1 16:00:56 hydra qmail: 936226856.382047 info msg 743435: bytes 833 from <[EMAIL PROTECTED]> qp 2456 uid 7770
Sep 1 16:00:56 hydra qmail: 936226856.426950 starting delivery 95: msg 743435 to remote [EMAIL PROTECTED]
Sep 1 16:10:49 hydra qmail: 936227449.427495 starting delivery 97: msg 743435 to remote [EMAIL PROTECTED]
Sep 1 16:33:13 hydra qmail: 936228793.021252 starting delivery 99: msg 743435 to remote [EMAIL PROTECTED]
Sep 1 17:09:13 hydra qmail: 936230953.152275 starting delivery 101: msg 743435 to remote [EMAIL PROTECTED]
Sep 1 17:58:33 hydra qmail: 936233913.032295 starting delivery 125: msg 743435 to remote [EMAIL PROTECTED]
Sep 1 19:01:13 hydra qmail: 936237673.714442 starting delivery 151: msg 743435 to remote [EMAIL PROTECTED]
Sep 1 20:17:13 hydra qmail: 936242233.769397 starting delivery 161: msg 743435 to remote [EMAIL PROTECTED]
Sep 1 21:46:33 hydra qmail: 936247593.416575 starting delivery 166: msg 743435 to remote [EMAIL PROTECTED]
Sep 1 23:29:13 hydra qmail: 936253753.454411 starting delivery 173: msg 743435 to remote [EMAIL PROTECTED]
Sep 2 01:25:13 hydra qmail: 936260713.575009 starting delivery 179: msg 743435 to remote [EMAIL PROTECTED]
Sep 2 03:34:33 hydra qmail: 936268473.332109 starting delivery 192: msg 743435 to remote [EMAIL PROTECTED]
Sep 2 05:57:13 hydra qmail: 936277033.414733 starting delivery 214: msg 743435 to remote [EMAIL PROTECTED]
Sep 2 08:33:13 hydra qmail: 936286393.548644 starting delivery 224: msg 743435 to remote [EMAIL PROTECTED]
Sep 2 11:22:33 hydra qmail: 936296553.810199 starting delivery 275: msg 743435 to remote [EMAIL PROTECTED]
Now what's really weird is that I can telnet into the remote server and it seems to behave:
hydra#
hydra# nslookup
Default Server: dns2.softaware.com
Address: 206.83.160.10> set querytype=mx
> cinesite.com
Server: dns2.softaware.com
Address: 206.83.160.10cinesite.com preference = 0, mail exchanger = onramp.cinesite.com
onramp.cinesite.com internet address = 199.35.162.2
>^Dhydra#
hydra# telnet 199.35.162.2 25
Trying 199.35.162.2...
Connected to 199.35.162.2.
Escape character is '^]'.
HELO nothingreal.com
250 (nothingreal.com) pleased to meet you.
MAIl TO:
QUIT
Connection closed by foreign host.
hydra# telnet 199.35.162.2 25
Trying 199.35.162.2...
Connected to 199.35.162.2.
Escape character is '^]'.
HELO nothingreal.com
250 (nothingreal.com) pleased to meet you.
MAIL FROM: [EMAIL PROTECTED]
250 [EMAIL PROTECTED] Sender Ok
RCPT TO: [EMAIL PROTECTED]
250 [EMAIL PROTECTED] OK
DATA
354 Enter mail, end with "." on a line by itself
SubeThis is a test
.
250 Mail accepted
QUIT
221 Closing connection
Connection closed by foreign host.
hydra#
Any help would be greatly appreciated,
- Emmanuel
"Stephen C. Comoletti" wrote: > I know this has been asked before, however I've been unable to find it > in the archives. I need to be able to deliver incomming mail for user A > to the maildir for both user A and user B. I've tried a few things with > the .qmail-A file, and ended up with a few mail loops and undeliverable > errors. Anyone able to give the correct syntax for this? /home/A/Maildir/ /home/B/Maildir/ Except of course both directories must be writeable by A, otherwise how can he deliver mail there? It's probably much better to use /home/A/Maildir/ &B@localhost And let B deal with the delivery of his own mail. Regards, --Steve
Hi I am new to Qmail . We have Installed Qmail and configured . It is Working fine. Now we need to Authenticate SMTP connections. How to go about? Is there any way to authenticate using unix password /etc/passwd While I was going through archives I saw SMTP authentication using RADIUS. Please give the details about configuration of Radius. Also I want to know Is there any standard front end for QMAIL.(Web based mail client) Please send us details Thanks in advance [EMAIL PROTECTED] N.Saravanan DSQ Software Limited Chennai INDIA 600 035
Hello Everyone. I used Redhat Linux 5.2. I could not start qmail whether using csh -cf '/var/qmail/rc &' or execute the qmail-start ... command directly. It just exit with code 111. Any hints ? ( By the way, I did this in another machine also using Redhat 5.2 and was successful. I was able to create user accounts, virtual domains ... ) Thanks. Regards, Tong
Hi, I would like to block any emails coming from a specific host from being received by my server... is there an easy way to do this? -- Thanks, Cesar
On Fri, Sep 03, 1999 at 12:32:20AM -0500, Cesar A. Iriarte wrote: If you use tcpserver, use the rules file to deny connections from the IP of that host. man tcprules. If you use tcp_wrappers, use the /etc/hosts.deny file to block connections from the IP address. > Hi, > > I would like to block any emails coming from a specific host from being > received by my server... is there an easy way to do this? -- See complete headers for more info
On Fri, 03 Sep 1999 at 11:22:11 +0300, Anand Buddhdev wrote: > On Fri, Sep 03, 1999 at 12:32:20AM -0500, Cesar A. Iriarte wrote: > > If you use tcpserver, use the rules file to deny connections from the IP > of that host. man tcprules. If you use tcp_wrappers, use the > /etc/hosts.deny file to block connections from the IP address. Or, just in case Cesar meant originating email address, not host really sending a message, one can use /var/qmail/control/badmailfrom . See qmail-smtpd(8) . > > Hi, > > > > I would like to block any emails coming from a specific host from being > > received by my server... is there an easy way to do this? -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros.
