qmail Digest 20 May 2000 10:00:00 -0000 Issue 1007
Topics (messages 42044 through 42103):
time until people get "failure notice"
42044 by: Hans Sandsdalen
42046 by: John P. Looney
42047 by: Frank Tegtmeyer
42048 by: Hans Sandsdalen
SMTP-proxy and qmail
42045 by: Hans Sandsdalen
SOLVED: qmail slowing down after a while
42049 by: qmail
Help with vchkpw
42050 by: mark
Re: The current status of IETF drafts concerning bare linefeeds
42051 by: Russell Nelson
42058 by: Greg Hudson
42063 by: Russell Nelson
42069 by: Lindsay Haisley
42075 by: Russell Nelson
42076 by: Lindsay Haisley
42077 by: Russell Nelson
42078 by: D. J. Bernstein
42079 by: Lindsay Haisley
42085 by: Racer X
Re: time error on qmail
42052 by: Zhiliang Hu
42053 by: Dave Sill
pop and client config- need help
42054 by: John Stile
42055 by: John Stile
42056 by: John Stile
42057 by: Chris Johnson
42061 by: John Stile
using /etc/aliases with qmail
42059 by: Michael Mannsberger
42060 by: Chris Johnson
Treating SMTP(remote) mails as locals
42062 by: ravivr.hss.hns.com
test
42064 by: Walid Kassab
42066 by: Petr Novotny
return receipt problem w/qmail
42065 by: Walid Kassab
42067 by: Jerry Walsh
Re: Where is the script that starts smtp server?
42068 by: Adam McKenna
Re: I want to leave this list
42070 by: Kai MacTane
42071 by: Kai MacTane
42072 by: Steve Wolfe
42073 by: markd.bushwire.net
42074 by: Kai MacTane
42080 by: Blaine Minazzi
42082 by: Lidia Marchioni
42086 by: Racer X
42089 by: Troy Frericks
42090 by: Troy Frericks
42097 by: Tom ONeil
42100 by: clemensF
42101 by: clemensF
Re: preline: _Not_enough_space
42081 by: Lidia Marchioni
42083 by: Uwe Ohse
42084 by: Lidia Marchioni
42087 by: Russell Nelson
42088 by: Adam McKenna
42093 by: Lidia Marchioni
Re: PROB. SOLVED -- qmail-qstat and qmaill-qread differences...
42091 by: Martin Gignac
42094 by: Rick Myers
New version of the Love worm This one is BAD
42092 by: bigkapusta.kapusta.com
42095 by: Alex Shipp
Doing logging from qmail-pop3d without going thru syslog?
42096 by: Chin Fang
42102 by: clemensF
maildir
42098 by: suresh
42099 by: Matthew
pop-3
42103 by: suresh
Administrivia:
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Hi People here are making complaints about the fact that mails are queued for A LONG TIME before they get a failure notice. Is this configurable? -- /hans
On Fri, May 19, 2000 at 12:26:10PM +0200, Hans Sandsdalen mentioned: > Hi > > People here are making complaints about the fact that mails are queued > for A LONG TIME before they get a failure notice. Is this configurable? "man qmail-control" will list all the files that you may need to configure qmail - they live in /var/qmail/control on my machine. One of them, "queuelifetime" is set to 604800 seconds, by default. You could make that lower. However, unlike other MTAs, qmail doesn't send the person who has sent a "This mail is being queued" message if there is a problem. The "queuelifetime" is how long it will sit on a letter, before returning it back as "undeliverable". Kate -- "The fool must be beaten with a stick, for an intelligent person the merest hint is sufficient" -- Zen Master Greg
> person who has sent a "This mail is being queued" message if there is a > problem. The "queuelifetime" is how long it will sit on a letter, before There is a program called qmail_bounce that works perfectly for this purpose. Look at www.qmail.org for "Brian T. Wightman has written a delayed-mail notifier." Regards, Frank
"John P. Looney" wrote: > > On Fri, May 19, 2000 at 12:26:10PM +0200, Hans Sandsdalen mentioned: > > Hi > > > > People here are making complaints about the fact that mails are queued > > for A LONG TIME before they get a failure notice. Is this configurable? > > "man qmail-control" will list all the files that you may need to > configure qmail - they live in /var/qmail/control on my machine. > > One of them, "queuelifetime" is set to 604800 seconds, by default. You > could make that lower. However, unlike other MTAs, qmail doesn't send the > person who has sent a "This mail is being queued" message if there is a > problem. The "queuelifetime" is how long it will sit on a letter, before > returning it back as "undeliverable". Thank you. I should have checked there by myself. I set it to a couple of days (216000), instead of one week (604800). > > Kate > > -- > "The fool must be beaten with a stick, for an intelligent person > the merest hint is sufficient" -- Zen Master Greg -- /hans
Hi I run qmail as mail server SW. When I configured my Watchguard Firewall II to use SMTP proxy a lot of mails stayed in the queue, and I got "connection died" in the maillog. The problem arised when MX-records pointed to a "closed" server. I don't now why, but qmail never tried the other servers according to MX-records? If I delete the SMTP proxy, and only alow traffic on port 25 this works fine..... -- /hans
<blush> power saving... <digging in the ground> sorry for the disturbance... /Ekki On Fri, 19 May 2000 03:11:43 +0200, qmail wrote: > Claudio, > sorry, detailed information will take some more time (we are trying to > track down things as exact as possible). > For now: > - patch is qmail-ldap-1.03-20000401.patch > - no imap around > - my mistake: pop3 is NOT affected, Curtis was right > - we're producing high load on smtp using "postal" > - BTW: symptoms appeared on systems with daemontools-0.53, > just upgraded these, no results yet... > > 'll be back... > so long, TIA > /Ekki > > ---------------------------------------------------------------------- > On Wed, May 17, 2000 at 04:39:22PM +0200, qmail wrote: > > Hi, > > any results on the below questions from the qmail list? I feel like > I'm > > experiencing the very same behaviour in my test environment. But IMHO > > not necessarilly related to NFS or Solaris (same with linux). Both > POP3 > > and SMTP seem to be affected. > > > > Which patch do you use? > And could you locate the possible bottleneck? > Have a look at ps, top, netstat and perhaps lsof. > I can not test this. I'm sorry. > > There could be a problem with the imap connections. A lot of tcp > sessions > to the imap server in the TIME_WAIT or simmilar state. > We know about this problem and try to fix that (with cldap perhaps) >
Lindsay Haisley writes: > Version 1.03 of qmail-smtpd is currently configured to reject incoming mail > with bare linefeeds. Yup. The problem with bare linefeeds is simple: their interpretation is ambiguous on a Unix machine. Same thing for a bare carriage-return on a Macintosh. No SMTP client should ever accept such a thing for transmission. Because some do, qmail rejects them. The problem, however, is not with qmail, it is with the SMTP client. Given the differing interpretations of bare linefeeds and carriage-returns, they must be disallowed by the SMTP specification, and they must not be accepted by SMTP clients or servers. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
> Yup. The problem with bare linefeeds is simple: their > interpretation is ambiguous on a Unix machine. This is an oversimplification. Unix machines are perfectly capable of interpreting bare LFs in whatever way the spec might say they should. There is a practical problem because MTA and MUA implementations like to allow the use of standard Unix tools to process messages; this can be considered an implementation issue, although it's a big one. > Given the differing interpretations of bare linefeeds and > carriage-returns, they must be disallowed by the SMTP specification, Certainly, given that sendmail munges them (or at least used to), the spec should disallow them, and the DRUMS draft does. > and they must not be accepted by SMTP clients or servers. This is a matter of philosophy. The IETF tendency on such matters is to regularly mandate that servers must accept invalid data as long as the data can be interpreted. I don't agree with this philosophy, at least for the initial deployment of a protocol ("be liberal in what you accept" increases robustness now at the expense of encouraging interoperability problems later), but it is somewhat defensible. The DRUMS draft should probably become clearer about the proper interpretation of a bare LF before it becomes a standard, if it ever does. (Given that it has much more precisely specified grammar rules than RFC 822 does, I would love to see it become a standard, but I don't know how likely that is.)
Greg Hudson writes: > > Yup. The problem with bare linefeeds is simple: their > > interpretation is ambiguous on a Unix machine. > > This is an oversimplification. I don't believe so. Email messages consist of lines of text. While in transit, those lines are separated by the Tenex newline, CRLF. When stored on the destination system, the lines are separated by the local newline. Therefore, lines in email cannot contain any characters which may be interpreted as local newlines. Fortunately, this is only CR and LF. > > and they must not be accepted by SMTP clients or servers. > > This is a matter of philosophy. The IETF tendency on such matters is > to regularly mandate that servers must accept invalid data as long as > the data can be interpreted. I don't agree with this philosophy, at > least for the initial deployment of a protocol ("be liberal in what > you accept" increases robustness now at the expense of encouraging > interoperability problems later), but it is somewhat defensible. No one would ever send bare CR's and/or LF's if servers didn't accept them. "Be liberal in what you accept" allows people to put broken clients into production and makes it politically difficult to get them repaired. It's a much, much better philosophy for servers to be strict in what they accept. That way, you never get broken (protocol-violating) clients deployed. Life *is* change. You can detect the absence of life by the absence of change. "Be liberal in what you accept" means accepting multiple versions of a protocol. This allows for change. It doesn't mean accepting anything thrown down your gullet, and choosing one of multiple interpretations of it. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
Thus spake Russell Nelson on Fri, May 19, 2000 at 06:58:35AM CDT > > Given the differing interpretations of bare linefeeds and > carriage-returns, they must be disallowed by the SMTP specification, > and they must not be accepted by SMTP clients or servers. Russ, thanks. How do you reconcile this with the draft spec, which appears to require that receiving systems (SMTP servers) MUST process bare linefeeds in some fashion. Do you think I'm misreading the spec, and if so, in what way? -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at [EMAIL PROTECTED] | (The Roadie) | <http://www.fmp.com/pubkeys> http://www.fmp.com | |
Lindsay Haisley writes: > Thus spake Russell Nelson on Fri, May 19, 2000 at 06:58:35AM CDT > > > > Given the differing interpretations of bare linefeeds and > > carriage-returns, they must be disallowed by the SMTP specification, > > and they must not be accepted by SMTP clients or servers. > > Russ, thanks. > > How do you reconcile this with the draft spec, which appears to require that > receiving systems (SMTP servers) MUST process bare linefeeds in some > fashion. Do you think I'm misreading the spec, and if so, in what way? I would point out to the author of the spec that it is requiring that messages be mangled when received on Unix systems. Also, the patch is there on www.qmail.org, if it bothers you overmuch. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
Thus spake Russell Nelson on Fri, May 19, 2000 at 01:22:36PM CDT > > I would point out to the author of the spec that it is requiring that > messages be mangled when received on Unix systems. I'm sure the IETF process permits such input. > Also, the patch is there on www.qmail.org, if it bothers you overmuch. Thanks, Russ. The 'fix' is fairly trivial and I've already done it, and in fact routinely do it for qmail installs I do. In real-world terms, it costs more in tech support time to deal with complaints and problems resulting from rejection of non-compliant email than it does to deal with problems arising from accepting it. My purpose here was to inquire regarding what appears to be a conflict between qmail and an emerging standard. If the draft I referenced becomes an RFC, then, whether we like it or not, qmail will apparently be out of compliance with accepted specifications for email in this regard. RFCs are, after all, the final authority for what is and is not appropriate technical behavior on the Internet, and departure from these standards shouldn't be done lightly. As you're well aware, Microsoft and others have played fast and loose with standards compliance, to the general detriment of the Internet. I'm not close enough to the qmail development and maintenance community to do this, but perhaps it would be appropriate for you or Dan or someone else who can deal with this issue knowledgably to provide some input into the IETF standards process on this before the draft becomes an RFC. Please note that I'm in general agreement with your position on this, and question the wisdom of establishing a dual standard for originating and receiving email, but this is indeed what the draft proposes. This is as much as anything a head's up to you and others regarding the issue. -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at [EMAIL PROTECTED] | (The Roadie) | <http://www.fmp.com/pubkeys> http://www.fmp.com | |
Lindsay Haisley writes: > Thanks, Russ. The 'fix' is fairly trivial and I've already done it, and in > fact routinely do it for qmail installs I do. In real-world terms, it costs > more in tech support time to deal with complaints and problems resulting > from rejection of non-compliant email than it does to deal with problems > arising from accepting it. That's the point -- the munging is hard to detect but the bouncing is easy to detect. Plus, the munging hurts the recipient, who didn't generate the message and has no idea that the line shouldn't be broken where it was. The recipient may be completely unable to detect the munging. The bouncing is detected by the sender, who is in a position to download a repaired version of the SMTP client. The tech support response should be "Your email client has a bug. Update it to the newest version. If the problem is still present, ask your email client vendor to fix it. Give them the smtplf URL." OTOH, Dan could have links to updated versions of software in his smtplf.html file. That would make it less likely that tech support would even be contacted. > My purpose here was to inquire regarding what appears to be a conflict > between qmail and an emerging standard. If the draft I referenced becomes > an RFC, then, whether we like it or not, qmail will apparently be out of > compliance with accepted specifications for email in this regard. RFCs are, > after all, the final authority for what is and is not appropriate technical > behavior on the Internet, and departure from these standards shouldn't be > done lightly. Very few vendors implement IEEE 802.3. Some standards are too stupid to comply with. > Please note that I'm in general agreement with your position on this, and > question the wisdom of establishing a dual standard for originating and > receiving email, but this is indeed what the draft proposes. This is as > much as anything a head's up to you and others regarding the issue. Thanks! -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
Lindsay Haisley writes: > My purpose here was to inquire regarding what appears to be a conflict > between qmail and an emerging standard. You are misinterpreting 822bis. If someone tries to relay some spam through your server, and the spam uses obsolete syntax, do you think that your server is required to accept the message? The word ``accept'' in 822bis means that parsers won't die. It doesn't mean that servers are required to permit delivery of a message. Servers can reject messages for any reason they want. > RFCs are, after all, the final authority for what is and is not > appropriate technical behavior on the Internet, No. RFCs are merely one source of information about the Internet, and not a particularly accurate source. We implementors decided years ago to allow non-MIME 8-bit mail, for example, even though the relevant RFCs specifically require that such mail be rejected. ---Dan
Thus spake Russell Nelson on Fri, May 19, 2000 at 02:28:22PM CDT > > The tech support response should be "Your email client has a bug. > Update it to the newest version. If the problem is still present, ask > your email client vendor to fix it. Give them the smtplf URL." OTOH, > Dan could have links to updated versions of software in his > smtplf.html file. That would make it less likely that tech support > would even be contacted. Some people are totally clueless. This thread was inspired by the problems of a business customer of an ISP for which I do consulting and mail administration. Said customer was getting ecommerce order notifications bounced because the ecommerce service provider's order management system was out of compliance and sending bare linefeeds in email to our qmail system. The ecommerce people saw the bounce message and told the customer that the ISP was using pobox.com to send email, and that pobox.com wasn't a "true email system" and that pobox.com was blocking all their order notifications because they thought they were spam. The chief tech person at the ISP basically told everyone involved pretty much what you've said above, but I doubt that ecommerce people got it. Some tech support folks would be better off flipping burgers :( -- Lindsay Haisley | "Everything works | PGP public key FMP Computer Services | if you let it" | available at [EMAIL PROTECTED] | (The Roadie) | <http://www.fmp.com/pubkeys> http://www.fmp.com | |
----- Original Message ----- From: "Russell Nelson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Fri 19 May 2000 8:26 Subject: Re: The current status of IETF drafts concerning bare linefeeds > Life *is* change. You can detect the absence of life by the absence > of change. "Be liberal in what you accept" means accepting multiple > versions of a protocol. This allows for change. It doesn't mean > accepting anything thrown down your gullet, and choosing one of > multiple interpretations of it. I prefer a different interpretation. "Be liberal in what you accept" means only that your program should not behave erratically or unpredictably in the face of bad data. It does not in any way mean that your program should never return an error code or blindly accept and attempt to deal with bad data. That philosophy leads to crappy software: sendmail, bind, etc. shag
Thanks for the replies from Martin Gignac and Timothy Mayo -- I see how now. But for mails sent for local it does not make sense to use GMT time stamp. Any way to let it use local time? BTW, I noted mailx and qmail's sendmail use GMT time while mails sent by pine uses local time. Is that all outgoing mails triger qmail-inject? (I checked pine man page but didn't get a clue) Zhiliang On Thu, 18 May 2000, Timothy L. Mayo wrote: > Date: Thu, 18 May 2000 13:57:22 -0400 (EDT) > From: Timothy L. Mayo <[EMAIL PROTECTED]> > To: Zhiliang Hu <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: time error on qmail > > qmail ALWAYS uses UTC when recording dates in the mail headers it > generates. That is what the '-0000' means. The difference between UTC > and CDT is '-0500'. The time stamps are correct you are just misreading > them. :)
Zhiliang Hu <[EMAIL PROTECTED]> wrote: >Thanks for the replies from Martin Gignac and Timothy Mayo -- Did you not get my reply? I already answered your next question: >I see how now. But for mails sent for local it does not make >sense to use GMT time stamp. Any way to let it use local time? Use "datemail" instead of "sendmail". >BTW, I noted mailx and qmail's sendmail use GMT time while mails >sent by pine uses local time. Is that all outgoing mails triger >qmail-inject? (I checked pine man page but didn't get a clue) Pine adds a Date field with a local timestamp. -Dave
I've got qmail installed and I can send mail, and maildir's are filling up with new mail. I need to find docs on getting to my mail with netscape, from remote, and setting the pop3 server. Later I need to make the virtual domains work. Which docs should I read? Is there a grid of options so I can gain some perspective on on my options? I've been doing a lot of reading just to see if it's what I should be reading. Please give me a direction. My eyes are popping out. I hope O'Reilly publishes some organized stuff some day. Thanks for any direction you can offer.
I don't understand. are you joking with me? I'm talking about the mail program that this mailing list supports, and POP3 port and mail service that allows a person to get their mail with a pop3 lient. I appreciate the timelyness of your reply, but unfortunately I don't know how to interpret your answer into meaningful advice. Thank you for trying to help. Russel Nelson wrote: > PoP PoP PoP PoP PoP PoP PoP PoP PoP PoP PoP PoP PoP PoP PoP PoP PoP v > > EyE EyE EyE EyE EyE EyE EyE EyE EyE EyE EyE EyE EyE EyE > > EyEPoP EyEPoP EyEPoP EyEPoP EyEPoP EyEPoP EyEPoP EyEPoP EyEPoP > > YTOU MUST DO THIS IN ORDER TO GET IT TO BOOT THE LOADING SYSTEM ONTOP OF > THE JAVA EXPRESSION RUNTIME LIBRARYS > > : > > 1. > tr> > <td></td> > </tr> > <tr> > <td></td> > </tr> > </table> > > Hope that helps PoP > > Richie. > > At 07:22 AM 5/19/00 -0700, you wrote: > > >I've got qmail installed and I can send mail, and maildir's are filling > >up > >with new mail. > > > >I need to find docs on getting to my mail with netscape, from remote, > >and > >setting the pop3 server. Later I need to make the virtual domains work. > > > >Which docs should I read? > > > >Is there a grid of options so I can gain some perspective on on my > >options? > >I've been doing a lot of reading just to see if it's what I should be > >reading. > > > >Please give me a direction. My eyes are popping out. > > > >I hope O'Reilly publishes some organized stuff some day. > > > >Thanks for any direction you can offer. > > > >
Why are you on this mailing list? Weslie Turnip wrote: > Dear Mister Stile, > > I have read your question and i have found a solution, > I think the "new direction" you should take is to shove your head up your ass > > Regards, > > Weslie. > > At 07:22 AM 5/19/00 -0700, you wrote: > > >I've got qmail installed and I can send mail, and maildir's are filling > >up > >with new mail. > > > >I need to find docs on getting to my mail with netscape, from remote, > >and > >setting the pop3 server. Later I need to make the virtual domains work. > > > >Which docs should I read? > > > >Is there a grid of options so I can gain some perspective on on my > >options? > >I've been doing a lot of reading just to see if it's what I should be > >reading. > > > >Please give me a direction. My eyes are popping out. > > > >I hope O'Reilly publishes some organized stuff some day. > > > >Thanks for any direction you can offer. > > > >
On Fri, May 19, 2000 at 07:35:28AM -0700, John Stile wrote: > I don't understand. are you joking with me? I'd be surprised if Russell Nelson really wrote that. For one thing, the name is spelled incorrectly. It looks like some (insane) person is impersonating him. For information on setting up the POP server, see http://cr.yp.to/qmail/faq/servers.html#pop3d. You might also check out Dave Sill's "Life with qmail" at http://Web.InfoAve.Net/~dsill/lwq.html. Chris
KUDOS to you for having constructive advice and not being insane. Thank you. I'll be reading the FAQ's on pop3. Jerry Walsh wrote: > John, > > you need to use /var/qmail/bin/qmail-pop3d in conjunction with "checkpassword" > > For more information read /var/qmail/doc/FAQ > > and search for pop3 > > Regards, > > Jerry. > > At 07:22 AM 5/19/00 -0700, you wrote: > > >I've got qmail installed and I can send mail, and maildir's are filling > >up > >with new mail. > > > >I need to find docs on getting to my mail with netscape, from remote, > >and > >setting the pop3 server. Later I need to make the virtual domains work. > > > >Which docs should I read? > > > >Is there a grid of options so I can gain some perspective on on my > >options? > >I've been doing a lot of reading just to see if it's what I should be > >reading. > > > >Please give me a direction. My eyes are popping out. > > > >I hope O'Reilly publishes some organized stuff some day. > > > >Thanks for any direction you can offer. > > > >
hello, /etc/aliases is not working for me -i installed fastforward-0.51 on a host running linux 2.2.7 - i put the following line in ~alias/.qmail-default | fastforward -d /etc/aliases.cdb - installed the cdb package when u run "newaliases" it creates /etc/aliases.db - the fastforward package is looking for /etc/aliases.cdb which is obviously a different format so i created a cdb database like this /usr/local/sbin/cdbmake-sv /etc/aliases.cdb /etc/aliases.tmp < /etc/aliases -rw-r--r-- 1 root root 825 May 18 16:18 aliases -rw-r--r-- 1 root root 2048 May 18 16:28 aliases.cdb -rw-r--r-- 1 root root 16384 May 19 09:20 aliases.db can somebody help me with that? thanx, -mike
On Fri, May 19, 2000 at 09:53:17AM -0400, Michael Mannsberger wrote: > hello, > > /etc/aliases is not working for me > > -i installed fastforward-0.51 on a host running linux 2.2.7 > - i put the following line in ~alias/.qmail-default > > | fastforward -d /etc/aliases.cdb > > - installed the cdb package > > when u run "newaliases" it creates /etc/aliases.db - the fastforward > package is looking for /etc/aliases.cdb which is obviously a different > format You're running sendmail's newaliases (on my FreeBSD box it's /usr/bin/newaliases), not /var/qmail/bin/newaliases. The latter will create /etc/aliases.cdb. Chris
Dear all, I have already posted a query that all the remote mails(SMTP) are treated as "locals". My back up server is working fine with the same configuration. Is there any other files that i have to check it up other than control files. I checked up inetd.conf in /etc. It is also correct as that of back up servr. Rgds, RAVI
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 May 00, at 18:43, Walid Kassab wrote: > this is only a test Glad to know. Thanks. -----BEGIN PGP SIGNATURE----- Version: PGP 6.0.2 -- QDPGP 2.60 Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBOSVT/lMwP8g7qbw/EQK1JwCfXPLdbn56hSA1rQcLBgmVIX7z5/cAnAqO dA/XdddLBmvBw2ctylITKJI5 =jPlC -----END PGP SIGNATURE----- -- Petr Novotny, ANTEK CS [EMAIL PROTECTED] http://www.antek.cz PGP key ID: 0x3BA9BC3F -- Don't you know there ain't no devil there's just God when he's drunk. [Tom Waits]
I am not able to set return receipt feature for my virtual domains over a
qmail.
The qrecript feature requires .qmail for each user.
My virtual users do not have any .qmail on there home dir
is there a way to overcome this issue
Any help is appreaciated
Yes! there is: At 06:46 PM 5/19/00 +0200, Walid Kassab wrote: >Hi all, > >I am not able to set return receipt feature for my virtual domains over a >qmail. > >The qrecript feature requires .qmail for each user. >My virtual users do not have any .qmail on there home dir >is there a way to overcome this issue *drumroll* Put a .qmail in their home directory! Or else use the virtual domain added which you can host mail for lots of virtual domains with just one .qmail file. There's a link to it on the www.qmail.org/top.html site ;) >Any help is appreaciated > > Regards, Jerry.
On Thu, May 18, 2000 at 10:03:15PM -0700, James wrote: > Clemens wrote: > :please send us the scripts in question and the setup you got working. at > :the time beeing i can't tell you anything for final. and another thing: > :what do you mean by "roaming users"? > > By "roaming users" I mean users that don't have a static ip.. like users > using FreeInet or NetZero to connect to the internet. I need to be able > to allow them to relay messages, and receive. You most certainly don't need to give them access to relay. --Adam
At 5/18/2000 08:26 PM -0500, Troy Frericks wrote or quoted: > > >Don't burry it in the header, don't require them to keep something, don't >require them to remember a web site, just attach the information to the >end of each message; then those stupid people will feel real stupid if >they miss it. Actually, they won't. I've seen this kind of setup on a list devoted to Winamp skin creation; the overall intelligence level there was *much* lower than this list, and every single email had a footer saying "To unsubscribe, send a blank email to [some address I don't remember]." Roughly a half-dozen people *per day* sent in messages asking how to get off the list. When the footer was pointed out to them, some just vanished, a few apologized and then vanished, and quite a few sent back messages saying things like "Well, how was I supposed to notice *that*?!? It's all the way at the bottom of the message!" People who are determined to be stupid seem to be: a) 100% capable of being stupid, no matter how easy you try to make it for them to be smart (or at least average); and b) 100% incapable of being convinced that they're being stupid. They will rationalize and justify nearly anything. I used to think that a footer would be worth trying, until I saw that Winamp skins list. I now think it would be nearly useless. (OTOH, the bandwidth consumed wouldn't be *that* much, so I'm not as much against it as some on this list.) ----------------------------------------------------------------- Kai MacTane System Administrator Online Partners.com, Inc. ----------------------------------------------------------------- From the Jargon File: (v4.0.0, 25 Jul 1996) finger trouble /n./ Mistyping, typos, or generalized keyboard incompetence (this is surprisingly common among hackers, given the amount of time they spend at keyboards). "I keep putting colons at the end of statements instead of semicolons", "Finger trouble again, eh?".
At 5/18/2000 09:47 PM -0700, Russ Allbery wrote or quoted: >It breaks MIME structured bodies, which are often useful for particular >purposes. It breaks some signed posts. It's useless information for 99% >of the recipients. And I'm really sick of seeing mailing list posts >accumulate more and more worthless junk to the point that it's practically >more unwanted bytes in my mailbox than spam is. It's rather simple to >skip over the messages from the completely lost people; footers that any >intelligent person doesn't need are both intrusive and ugly. Say, here's an idea, which I'm not sure how difficult it would be to implement: What if, when you first subscribe, it automatically sends you messages with a footer, and the footer says something like: ---------------------------------------------- To unsubscribe, [do some stuff] To remove this footer, [do this other stuff]. Then people can self-select whether they're intelligent or not. Anyone that can remove the footer *must* have seen and noticed the unsubscription-instruction footer, and they can obviously read and follow directions (or they wouldn't have been able to ditch the footer in the first place). Since I use Majordomo, I know nothing of ezmlm internals, so I'm not sure how hard this would be to set up. But it's a thought for how to deal with the situation. ----------------------------------------------------------------- Kai MacTane System Administrator Online Partners.com, Inc. ----------------------------------------------------------------- From the Jargon File: (v4.0.0, 25 Jul 1996) finger trouble /n./ Mistyping, typos, or generalized keyboard incompetence (this is surprisingly common among hackers, given the amount of time they spend at keyboards). "I keep putting colons at the end of statements instead of semicolons", "Finger trouble again, eh?".
> Roughly a half-dozen people *per day* sent in messages asking how to get > off the list. A lot of that depends on how long the average person stays on the list. On another list that I belong to, most people stay there for months or more. Whenever someone asks "how do I unsubscribe", even though the instructions are at the bottom of the message, they generally get subjected to quite a bit of public humiliation and mockery. The good side is that other people on the list notice it, and realize "Hey, I ought to pay attention to things like that, otherwise I'll look like a fool." The rate dropped from a few a week to once every few months. However, in lists where the average person doesn't stay there very long, they don't ever get to learn from others' mistakes... steve
> Say, here's an idea, which I'm not sure how difficult it would be to implement: > > What if, when you first subscribe, it automatically sends you messages with > a footer, and the footer says something like: Here's another. WHy not have all the list email sent out with a reply address that is the unsubscribe address. That way, a reply to the email automatically goes to the unsubscribe address and only those smart enough to change the reply address get to send back to the list? Regards.
At 5/19/2000 10:44 AM -0700, [EMAIL PROTECTED] wrote or quoted: >Here's another. WHy not have all the list email sent out with a reply >address that is the unsubscribe address. That way, a reply to the email >automatically goes to the unsubscribe address and only those smart enough >to change the reply address get to send back to the list? Oooooh, sneaky! I kind of like it, actually. :) ----------------------------------------------------------------- Kai MacTane System Administrator Online Partners.com, Inc. ----------------------------------------------------------------- From the Jargon File: (v4.0.0, 25 Jul 1996) finger trouble /n./ Mistyping, typos, or generalized keyboard incompetence (this is surprisingly common among hackers, given the amount of time they spend at keyboards). "I keep putting colons at the end of statements instead of semicolons", "Finger trouble again, eh?".
Kai MacTane wrote: > People who are determined to be stupid seem to be: > > a) 100% capable of being stupid, no matter how easy you try to make it > for them to be smart (or at least average); and > b) 100% incapable of being convinced that they're being stupid. They > will rationalize and justify nearly anything. -------------------------- We all make occasional stupid mistakes, but the real difference between Genius and Stupidity is, Genius has it's limits. Bkm.
Paulo Jan wrote: > Based on my experience in other mailing lists, I can guarantee you > that, after adding unsubbing information in the footer of the message, > you will *still* receive mails from people asking "remove me" or "how do > I unsub". In our experience after adding a trailer the number of unsub requests went down from 3 a week to 1 every 2 weeks. But then, perhaps we have only smart users... :-) Lidia > > > Paulo Jan. > DDnet.
you'd have to post-process each and every message you delivered based on subscriber options. in this particular case, the option is on or off, so you could potentially have separate lists for the different options. but that could quickly spiral out of control if you had a bunch of options. personally i don't give a flip about stupid people who can't figure out how to unsubscribe. people will always find a way to get those damn messages through no matter what kind of hoops you make them jump through. i'd rather see mailing list owners boot people permanently from mailing lists for sending unsub requests to the list. maybe we could set up a blacklist of mailing list morons and ban them from every mailing list. shag ----- Original Message ----- From: "Kai MacTane" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Fri 19 May 2000 10:41 Subject: Re: I want to leave this list > At 5/18/2000 09:47 PM -0700, Russ Allbery wrote or quoted: > > >It breaks MIME structured bodies, which are often useful for particular > >purposes. It breaks some signed posts. It's useless information for 99% > >of the recipients. And I'm really sick of seeing mailing list posts > >accumulate more and more worthless junk to the point that it's practically > >more unwanted bytes in my mailbox than spam is. It's rather simple to > >skip over the messages from the completely lost people; footers that any > >intelligent person doesn't need are both intrusive and ugly. > > Say, here's an idea, which I'm not sure how difficult it would be to implement: > > What if, when you first subscribe, it automatically sends you messages with > a footer, and the footer says something like: > > ---------------------------------------------- > To unsubscribe, [do some stuff] > To remove this footer, [do this other stuff]. > > Then people can self-select whether they're intelligent or not. Anyone that > can remove the footer *must* have seen and noticed the > unsubscription-instruction footer, and they can obviously read and follow > directions (or they wouldn't have been able to ditch the footer in the > first place). > > Since I use Majordomo, I know nothing of ezmlm internals, so I'm not sure > how hard this would be to set up. But it's a thought for how to deal with > the situation. > > ----------------------------------------------------------------- > Kai MacTane > System Administrator > Online Partners.com, Inc. > ----------------------------------------------------------------- > From the Jargon File: (v4.0.0, 25 Jul 1996) > > finger trouble /n./ > > Mistyping, typos, or generalized keyboard incompetence (this is > surprisingly common among hackers, given the amount of time they > spend at keyboards). "I keep putting colons at the end of statements > instead of semicolons", "Finger trouble again, eh?". > >
At 04:47 PM 5/19/00 , Racer X wrote: [snip] i'd rather see mailing list owners boot people permanently >from mailing lists for sending unsub requests to the list. maybe we >could set up a blacklist of mailing list morons and ban them from every >mailing list. [snip] So, what you are saying is make it standard procedure to post "unsub" request to the list? The only caveat is that you will not be able to re-subscribe? #
At 01:19 PM 5/19/00 , Kai MacTane wrote: >At 5/19/2000 10:44 AM -0700, [EMAIL PROTECTED] wrote or quoted: > >>Here's another. WHy not have all the list email sent out with a reply >>address that is the unsubscribe address. That way, a reply to the email >>automatically goes to the unsubscribe address and only those smart enough >>to change the reply address get to send back to the list? > >Oooooh, sneaky! I kind of like it, actually. :) > I like it too! # [snip]
Steve Wolfe wrote: > <snip> > more. Whenever someone asks "how do I unsubscribe", even though the > instructions are at the bottom of the message, they generally get subjected > to quite a bit of public humiliation and mockery. The good side is that > other people on the list notice it, and realize "Hey, I ought to pay > attention to things like that, otherwise I'll look like a fool." The > rate dropped from a few a week to once every few months. <humor tag> Maybe you have a point - if this thread doesn't get there attention, make it part of the list culture to flame everyone severely who asks. Or rename the list to hotel-ca-qmail ? </humor> Seriously, If they can't get off a mailing list, be glad they are $RUNNING qmail. My vote - trailers... Tom -- Thomas J. ONeil [EMAIL PROTECTED] Two things are infinite, the universe and the human stupidity, but I am not yet sure about the universe. (Albert Einstein)
> Kai MacTane: > People who are determined to be stupid seem to be: > > a) 100% capable of being stupid, no matter how easy you try to make it > for them to be smart (or at least average); and > b) 100% incapable of being convinced that they're being stupid. They > will rationalize and justify nearly anything. that's what i call a perl. it is the simple truth, no matter where it is applied. and since is so hard to spot intelligence, this statement will make it easy to describe the opposite. may i quote you? -- clemens [EMAIL PROTECTED]
> Racer X: > >from mailing lists for sending unsub requests to the list. maybe we > could set up a blacklist of mailing list morons and ban them from every > mailing list. we can't ban newbies making newbie mistakes while learning, or else we will grow old together because fresh meat is missing. and if we wanted to learn something new ourselves with this attitide confronting us, we'd have to stay where we are for the rest of our lives. if we can't put up with other people and don't even mesh with them, we gonna see segregation. -- clemens [EMAIL PROTECTED]
Uwe Ohse wrote: > The system is running out of memory during the startup of perl. Is perl being started by one qmail users (qmails, qmaill, etc)? with ulimit added to .qmail file: deferral: time(seconds)_unlimited /file(blocks)_unlimited /data(kbytes)_unlimited /stack(kbytes)_2097148 /coredump(blocks)_unlimited /nofiles(descriptors)_1024 /memory(kbytes)_2048 /time(seconds)_unlimited /file(blocks)_unlimited /data(kbytes)_2097148 /stack(kbytes)_8192 /coredump(blocks)_unlimited /nofiles(descriptors)_64 /memory(kbytes)_2048 /ld.so.1:_/usr/bin/perl:_fatal:_/usr/lib/libc.so.1:_mmap_failed: _Not_enough_space/preline:_fatal:_child_crashed/ there is only one limit set in the qmail startup script: ulimit -v 2048 Should I just change it to unlimited? thanks Lidia > > Check your administrative limits, perhaps using this .qmail: > |ulimit -aH ; ulimit -a > |preline /var/qmail/alias/forums.ezmlm/filter.pl > and adjust them in your system startup scripts. > > You may also use top (or free, if your system knows that > command) to see how much memory is free. But note that the > output of top is misleading at times and consult your system > administrator on how to interpret these values if in doubt, > and note that the problem is most likely not free memory but > some adminstrative limit in your system startup scripts > or in the shell session used to start qmail. > > Regards, Uwe
On Fri, May 19, 2000 at 01:53:35PM -0700, Lidia Marchioni wrote: > Is perl being started by one qmail users (qmails, qmaill, etc)? No, not really - it's started by whoever own that .qmail. But the ulimit is inherited from the shell that started qmail. > /nofiles(descriptors)_64 > /memory(kbytes)_2048 both are somewhat small - although is think that the memory limit is the reason. > ulimit -v 2048 > Should I just change it to unlimited? or 8192 or something, yes. (well, check the manual page of the shell you are using - the ulimit command tends to do different things in different shells). Regards, Uwe
Russell Nelson wrote: > Lidia Marchioni writes: > > I always get the following error: deferral: > > ld.so.1:_/usr/bin/perl:_fatal:_/usr/lib/libc.so.1:_mmap_failed: > > _Not_enough_space/preline:_fatal:_child_crashed/ > > Hehe. How are you starting up qmail? From a /service/qmail/run file? > With a call to "softlimit -m 2000000"? I'm glad I managed to provide some entertainment, maybe not of the highest quality but always... ;-) >From /etc/rc2.d startup script (currently this is a copy of /etc/init.d/qmail file): "ulimit -v 2048" there are no other limits set. I understand that this limits the size of virtual memory available to qmail. Does it mean that qmaill tries to start perl but fails because of the above limit? What value is advisable here? thanks Lidia > > > -- > -russ nelson <[EMAIL PROTECTED]> http://russnelson.com > Crynwr sells support for free software | PGPok | "Ask not what your country > 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to > Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
Lidia Marchioni writes: > "ulimit -v 2048" > > I understand that this limits the size of virtual memory available to qmail. > Does it mean that qmaill tries to start perl but fails because of the above > limit? What value is advisable here? 4096 seems to work just fine. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
I removed that ulimit line from the init scripts I distribute a while back when it started causing erratic behavior on some systems. I asked on the list what people thought a "good" value would be, but I received no replies. I suggest experimenting with different values until you find one that you can live with. --Adam
Uwe Ohse wrote: > > ulimit -v 2048 > > Should I just change it to unlimited? > > or 8192 or something, yes. (well, check the manual page of the > shell you are using - the ulimit command tends to do different > things in different shells). geee, it's going to take 3 days to get this changed... long live outsourcing I'll report back on Monday <g> Thanks for advice. lidia > > > Regards, Uwe
Think I've figured out what was wrong. Read about queue-cleaning in the INTERNALS document that comes with qmail and I believe the problem is that a big email got stuck at the beginning of the queue while I was shutting down the system (I didn't leave time for qmail-send to exit properly). I guess preprocessing on the message never finished. According to INTERNALS, it should be cleaned up automatically within 36 hours. -Martin ----- Original Message ----- From: "Martin Gignac" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 19, 2000 00:02 Subject: qmail-qstat and qmaill-qread differences... > Hi, > > Just a quick question: > > When I run qmail-qstat on my FreeBSD system, I'll get something like this: > > messages in queue: 2 > messages in queue but not yet preprocessed: 0 > > But when I run qmail-qread immediately after, I get something along the > lines of: > > 18 May 2000 14:58:17 GMT #150795 4997 <[EMAIL PROTECTED]> > remote [EMAIL PROTECTED] > > I've tried this a couple of times when the queue is quiet and I always seem > to get this 'discreptancy'. Where is the second message qmail-qstat refers > to? Is this normal for qmail? Am I simply missing something here? Have I > missed something in the FAQ? > > Thanks, > > -Martin > > >
On May 19, 2000 at 20:40:26 -0400, Martin Gignac twiddled the keys to say: > Think I've figured out what was wrong. Read about queue-cleaning in the > INTERNALS document that comes with qmail and I believe the problem is that a > big email got stuck at the beginning of the queue while I was shutting down > the system (I didn't leave time for qmail-send to exit properly). I guess > preprocessing on the message never finished. According to INTERNALS, it > should be cleaned up automatically within 36 hours. I don't normally reply here, but since noone else has.... :) I have a qmail-check script that runs qmail-qstat and qmail-qread and mails it to me. It's always reported one more mail in the queue than was actually there. For years I thought it was just because I opened the pipe to qmail-inject before running the other programs. I just never looked back to see. Looking back now, that's not the case. While I have have no idea why qmail-qstat reports one more than actual, I don't find it any sort of bother. I've never experienced any sort of woe due to it, nor do I expect to. Rick Myers [EMAIL PROTECTED] ---------------------------------------------------- The Feynman Problem 1) Write down the problem. Solving Algorithm 2) Think real hard. 3) Write down the answer.
VBS/Newlove.a is a VB Script worm with virus qualities.
McAfee AVERT has assessed it as a HIGH-risk threat. This
worm searches all drives connected to the host system and
replaces all files with copies of itself and it adds the
extension .VBS to the original filename. The original file
is then deleted. The worm uses Microsoft Outlook to send
copies of itself to all entries in the address book.
When this worm is first run, it places a copy of itself in
the Windows folder and gives itself a name from either the
Recent Documents folder, or uses a random name with a
random extension.
This worm will arrive in an email message with this format:
Subject: Starts with "FW: " and is either a name from the
Recent Documents folder or a random name
Message: Empty
Attachment: Is the randomly-selected VBS filename from the
Windows folder
This virus will run if Windows Scripting Host is installed.
Running the email attachment received either accidentally or
intentionally will install to the local system.
> McAfee AVERT has assessed it as a HIGH-risk threat. It's now: Medium On Watch We haven't seen a single copy of this (compared to 13000 copies of LoveBug on day 1). Nor have any of the AV companies I've spoken to. There's no doubt that this new worm does exist, and that it is extremely harmful. However, its spread appears to be severely over-hyped. Perhaps Trend felt they missed out on all the press activity with the first LoveBug... :-P Or perhaps their timely announcement has put everyone on their guard and nipped this one in the bud -who can tell (damned if you do, damned if you don't) Alex ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alex Shipp Imagineer MessageLabs www.messagelabs.com E: [EMAIL PROTECTED] T: 44 1285 884496 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Control Centre. For further information visit http://www.messagelabs.com/stats.asp
A few days ago, I asked about "Metering POP related email traffic?" on this list. Markus Stumpf <[EMAIL PROTECTED]> suggested me to patch qmail-pop3d.c to output the number of bytes on every successfull "RETR" command (probably to STDERR). Today, I got some spare time, so I took a look of qmail-pop3d.c. I think overall it's quite easy to come up *most of* the patch. Basically, I would introduce a global long, and then use it to count bytes sent out by blast(), and then write out the bytesread in pop3_quit(). However, it's at the last stage I ran into an problem. I was trying not to use syslog for logging. But it seems to be that I can't write the logged info to STDERR, since the info would be sent to POP client (I confirmed this using telnet to port 110). Right now, I invoke qmail-pop3d in the following manner: [...] 'start_popd') # # start pop server # if [ -f $RULESDIR/pop3.cdb ]; then env - PATH="/var/qmail/bin:/usr/local/bin:$PATH" \ tcpserver \ -v -R -x $RULESDIR/pop3.cdb \ 0 pop3 qmail-popup $HOSTNAME \ $checkpassword qmail-pop3d Maildir 2>&1 \ | $setuidgid qmaill $tai64n 2>&1 \ | $setuidgid qmaill $multilog /var/log/pop3d & [...] At this stage, I don't see a way of using multilog shown above for logging. I really would like to get this patch free of syslog, and thus would be very appreciative for any tips. Regards, Chin Fang [EMAIL PROTECTED]
> Chin Fang: > However, it's at the last stage I ran into an problem. I was trying > not to use syslog for logging. But it seems to be that I can't write > the logged info to STDERR, since the info would be sent to POP client > (I confirmed this using telnet to port 110). > > Right now, I invoke qmail-pop3d in the following manner: > > [...] > 'start_popd') > # > # start pop server > # > if [ -f $RULESDIR/pop3.cdb ]; then > env - PATH="/var/qmail/bin:/usr/local/bin:$PATH" \ > tcpserver \ > -v -R -x $RULESDIR/pop3.cdb \ > 0 pop3 qmail-popup $HOSTNAME \ > $checkpassword qmail-pop3d Maildir 2>&1 \ > | $setuidgid qmaill $tai64n 2>&1 \ > | $setuidgid qmaill $multilog /var/log/pop3d & first of: if you want timestamps then integrate the last two lines from > | $setuidgid qmaill $tai64n 2>&1 \ > | $setuidgid qmaill $multilog /var/log/pop3d & to | $setuidgid qmaill $multilog t /var/log/pop3d & also, if you tell qmail-pop3d to output stderr on the stdout stream with the term "2>&1", telnet will give you error messages from pop3d too. if you leave out this term, you get separate output and error streams. -- clemens [EMAIL PROTECTED]
I have installed qmail.but not very sure whether i have done it properly.if
i telnet to port 25 it works but if i telnet to 110 ,I am getting this error
"- ERR this user has no $homeMaildir .Do i have to install maildir
Suresh----------------------------------------------------------------
Send and receive mails in Indian languages.
Register free with http://www.mailjol.com
On Sat, 20 May 2000, suresh wrote: > Hello > I have installed qmail.but not very sure whether i have done it properly.if > i telnet to port 25 it works but if i telnet to 110 ,I am getting this error > "- ERR this user has no $homeMaildir .Do i have to install maildir > you have to do "maildirmake /home/user/Maildir" for example. you can put your Maildir anywhere, just remember to put in the .qmail file on the users home to point to the maildir. eg. .qmail file: /home/user/Maildir/ don't forget this "/" at the end. if you want to use Mailbox format the strip off that last "/". > > Suresh > > ---------------------------------------------------------------- > Send and receive mails in Indian languages. > Register free with http://www.mailjol.com > > >
name_of_your_host qmail/bin/checkpassword qmail/bin/qmail-pop3d Maildir"(my own paths ) ,but by doing this the pop3 service just stops working(even if i remove the dash from pop-3)Suresh----------------------------------------------------------------
Send and receive mails in Indian languages.
Register free with http://www.mailjol.com
