qmail Digest 12 Feb 2000 11:00:01 -0000 Issue 909
Topics (messages 37097 through 37138):
Re: HTML -> TEXT convertors
37097 by: Mitja Sarp
Re: Egg on my face
37098 by: Dave Sill
37132 by: Sam
Re: fsync semantics (was Re: Linux kernel ....)
37099 by: Andre Oppermann
Re: Journalling and email loss
37100 by: Len Budney
37103 by: Anthony DeBoer
Re: checkpw, APOP
37101 by: Dave Sill
37104 by: schinder.leprss.gsfc.nasa.gov
Re: qmail on FFS with softupdates
37102 by: Len Budney
37110 by: Andre Oppermann
37112 by: Len Budney
37113 by: cmikk.uswest.net
37119 by: Andre Oppermann
37120 by: Andre Oppermann
37122 by: Jeff Hayward
fastforward problem
37105 by: Adam McKenna
imap, CRAM-MD5
37106 by: Dave Sill
37107 by: Paul Schinder
37133 by: Sam
change mailer-daemon address
37108 by: Magnus �stergaard
37111 by: Mads E Eilertsen
Re: fastforward problem -- nevermind
37109 by: Adam McKenna
flooding a qmail server to test it
37114 by: Matt Harrington
qmail + amavis
37115 by: marchart.schotten.at
37118 by: Rainer Link
37121 by: Rainer Link
cyrus authenticating out of CDB
37116 by: Mullen, Patrick
37117 by: Dave Sill
forwarding outbound mail to hub
37123 by: Mark E. Drummond
37124 by: Charles Cazabon
37126 by: Mark E. Drummond
37127 by: Charles Cazabon
37128 by: Manfred Bartz
37134 by: Manfred Bartz
Re: Logging
37125 by: Martin Lesser
empty msg from:
37129 by: Uwe Boettjer
37130 by: Timothy L. Mayo
37131 by: Uwe Boettjer
is there any way to redirect deferrals?
37135 by: Jeremy Hansen
37137 by: Magnus Bodin
patch to qmail-remote outgoingip patch
37136 by: Aaron Nabil
complex user routing
37138 by: sachin
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]
----------------------------------------------------------------------
On Fri, Feb 11, 2000 at 01:58:54AM -0700, Andy Bradford wrote: > Thus said Curtis Generous on Wed, 26 Jan 2000 03:58:21 EST: > > > Are there any standalone, fast HTML -> TEXT convertors > > available that would convert message body information on the > > fly? > > You might try to conjure up something with sed or even perl. I'm not > certain how much overhead each would impose, but it isn't hard to strip > out those dumb formatting tags. It might not leave the document in a > *pretty* state though. :) > Andy lynx -dump or w3m -dump will leave, with more overhead.
[EMAIL PROTECTED] wrote: >> False. Mail will not be lost if if rename() or link() (depending on > >Who said anything about the message already being on the filesystem? If it's not, then qmail hasn't accepted responsibility for delivering the message, so the sender, either local or remote, should resend it. -Dave
On Fri, 11 Feb 2000, Dave Sill wrote: > [EMAIL PROTECTED] wrote: > > >> False. Mail will not be lost if if rename() or link() (depending on > > > >Who said anything about the message already being on the filesystem? > > If it's not, then qmail hasn't accepted responsibility for delivering > the message, so the sender, either local or remote, should resend it. As far as Qmail knows, the message has been written out.
Magnus Bodin wrote: -snip- > > fsync the data if you want the data on disk. > > fsync the directory if you want the metadata on disk. > > > > What's complicated or difficult about that? > > According to McKusick yesterday when I asked specifically about this problem > discussed here, he admitted that fsync:ing a directory could be a costly > operation if directories had to be fsynced recursively. In e.g. a > queue-directory or a Maildir, it will probably have no impact. > > Therefore, a fsync() of the file would be sufficient he said. > Really two. > Maildir-example: > > 1. write to tmp > 2. fsync() > 3. rename(tmp, new) > 4. fsync() This last fsync() is not needed. We only need the guarantee that the unlink() happens AFTER the link() on the disk. Ordered metadata writes give us that (in the standard FFS and softupdates case, not with EXT2 unless sync mounted). -- Andre
Pavel Kankovsky <[EMAIL PROTECTED]> wrote: > On Thu, 10 Feb 2000, Len Budney wrote: > > > Any MTA which returns success before writing a message to the > > filesystem, and syncing it, should be thrown away... > > What if the MTA has already forwarded the message in question to other MTA > and got an acknowledgement? What if the message has already been processed > by some program? Why should MTA bother making sure a copy of the message > has been saved to the disk in these situations? In those situations, storing a copy on disk would not be necessary, of course. I'd be fascinated to know whether that's _ever_ a good idea. In the situations you describe, the MTA _must_ stall the sender until it finished processing the message. If the MTA is forwarding via SMTP, then senders will typically suffer a delay of over ten seconds. If the MTA is filtering through a program, then senders will suffer an unpredictable delay which can easily be manipulated by a malicious recipient. (Now imagine a mail which makes several hops, and suppose that each MTA in the chain stalled the caller while forwarding the message. Gack.) As an added bonus, you get all the code bloat which goes into deciding whether to forward, filter or queue messages. > Qmail's design has advantages but it is not the only way to design > MTA in the universe. Zeroseek promises an improvement <http://cr.yp.to/qmail/future.html>, so qmail's _exact_ strategy is not the only one--even in Dan's opinion. The examples which you gave don't look like viable alternatives, though. Len. -- Good ciphers are designed by good cryptanalysts. -- Bruce Schneier
Len Budney <[EMAIL PROTECTED]> writes: > Journalling is absolutely orthogonal to the reliability issue. The > reliability issue is: What are the semantics of fsync(), link() and > rename()? If they return after the requested operation completes to disk, > we can guarantee reliability. If not, we can't. Rename() is _supposed_ to guarantee that the target file is intact upon completion, although IMHO one should still fsync() the source file itself before rename()ing it to its destination. The rename() call was originally meant more for operations like installing a new /bin/sh safely; you want guarantees that another user won't get "/bin/sh: not found" while you're working, and that an untimely crash won't leave you without a valid /bin/sh. Things are less critical in applications where the target does not already exist, but IMHO a rename() that doesn't sync FS metadata before returning is broken. In this connection, I should mention http://www.qef.com/ftp/rename.ps, the classic rename() paper that describes real-world grief in a lot of the early implementations. A lot may have changed since then, but I wouldn't count on sudden industry-wide clue acquisition. -- Anthony DeBoer <[EMAIL PROTECTED]>
Paul Schinder <[EMAIL PROTECTED]> wrote: >At 3:21 PM -0500 2/10/00, Dave Sill wrote: >> >>Solaris 7 SPARC, gcc 2.8.1. > >Compiler bug, maybe? Well, I did some "printf" debugging, and it looks like a bug in the checkappopw code. It reads the username/password from descriptor 3 into a string called "up", then sets "login" and "password" to point into that string. Later, right before it compares the calculated digest to "password", it fills "up" with nulls, clearing "password". I commented out the line: for (i = 0;i < sizeof(up);++i) up[i] = 0; And it works fine. Are you using checkpw 0.51? Thanks for your help. -Dave
On Fri, Feb 11, 2000 at 09:25:09AM -0500, Dave Sill wrote: } Paul Schinder <[EMAIL PROTECTED]> wrote: } } >At 3:21 PM -0500 2/10/00, Dave Sill wrote: } >> } >>Solaris 7 SPARC, gcc 2.8.1. } > } >Compiler bug, maybe? } } Well, I did some "printf" debugging, and it looks like a bug in the } checkappopw code. It reads the username/password from descriptor 3 } into a string called "up", then sets "login" and "password" to point } into that string. Later, right before it compares the calculated } digest to "password", it fills "up" with nulls, clearing "password". } I commented out the line: } } for (i = 0;i < sizeof(up);++i) up[i] = 0; } } And it works fine. Are you using checkpw 0.51? 0.50, I think. I don't seem to have the source available on my Suns any more, but it's still on my Mac, and I installed them around the same time. It looks as if 0.50 might check the password before clearing the string, if I read this right: doit(login); digest(timestamp,stored); if (strcmp(encrypted,password)) _exit(1); for (i = 0;i < sizeof(up);++i) up[i] = 0; for (;*stored;++stored) *stored = 0; if (prot_gid((int) pw->pw_gid) == -1) _exit(1); if (prot_uid((int) pw->pw_uid) == -1) _exit(1); I assume this will be fixed in 0.52 :-) } } Thanks for your help. } } -Dave -- -------- Paul J. Schinder NASA Goddard Space Flight Center [EMAIL PROTECTED]
(This post is still on-topic, but hanging by a thread.) Magnus Bodin <[EMAIL PROTECTED]> wrote: > On Thu, Feb 10, 2000 at 11:21:08PM -0500, Len Budney wrote: > > ...the reliability impact of soft updates on FFS--giving us a good > > example of both a reliable journalled filesystem, and an unreliable > > journalled filesystem. > > Thanks. Yes. Let's make the clarification. FFS with soft updates is NOT a > journaling file system. Thanks for the correction. Do you have a reference for that? I couldn't find one. It is possible to use soft update technology while still maintaining a journal of metadata. I assumed, apparently incorrectly, that FFS did this. (If the metadata journal has been discarded, I would have thought that the filesystem would be different enough to warrant a new name.) > It DOES NOT MEAN that rename() is no longer an atomic operation in respect > to other applications, but if you get a crash between the rename() and the > fsync() you cannot be sure that the rename has been done when you come up > again. > > The impact of qmail is however dim to me. qmail-queue never calls rename; only link. If I'm wrong in assuming that your remarks transfer to link, please let me know. With that disclaimer, here's how qmail-queue enqueues a message: 1. Create a file in a temporary directory (queue/pid). It's inode becomes the message number (say 457). 3. Link the tempfile to queue/mess/457. 4. Write the message to queue/mess/457 (via the open file descriptor in queue/pid). fsync(). 5. Create queue/intd/457, and write the envelope to the file. fsync(). 6. link queue/intd/457 to queue/todo/457. If the link in #6 succeeds, qmail-queue will return success. If the link in queue/todo later vanishes, then so does the mail message. > Do we have to add extra fsyncs here? I'm not sure. In your other post (subject: ``fsync semantics''), you didn't supply the arguments to fsync. Is it necessary to open each of queue/mess, queue/intd and queue/todo and fsync them? In that case we need three more fsyncs (under FFS with softupdates, at least). Does fsyncing an open file descriptor sync not only metadata but hard links as well? In that case fsyncing queue/intd/messnum again after #6 suffices. Len. -- In general, I'm not going to blindly copy sendmail features---even useful features. I want to understand what problem they're trying to solve; then I'll provide the best solution for that problem. -- Dan Bernstein, author of qmail
Len Budney wrote: > > (This post is still on-topic, but hanging by a thread.) > > Magnus Bodin <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 10, 2000 at 11:21:08PM -0500, Len Budney wrote: > > > ...the reliability impact of soft updates on FFS--giving us a good > > > example of both a reliable journalled filesystem, and an unreliable > > > journalled filesystem. > > > > Thanks. Yes. Let's make the clarification. FFS with soft updates is NOT a > > journaling file system. > > Thanks for the correction. Do you have a reference for that? I couldn't > find one. > > It is possible to use soft update technology while still maintaining a > journal of metadata. I assumed, apparently incorrectly, that FFS did > this. (If the metadata journal has been discarded, I would have thought > that the filesystem would be different enough to warrant a new name.) Appearantly you mixed something up here. FFS never did journaling and neither does softupdates. > > It DOES NOT MEAN that rename() is no longer an atomic operation in respect > > to other applications, but if you get a crash between the rename() and the > > fsync() you cannot be sure that the rename has been done when you come up > > again. > > > > The impact of qmail is however dim to me. > > qmail-queue never calls rename; only link. If I'm wrong in assuming > that your remarks transfer to link, please let me know. With that > disclaimer, here's how qmail-queue enqueues a message: > > 1. Create a file in a temporary directory (queue/pid). It's inode > becomes the message number (say 457). > 3. Link the tempfile to queue/mess/457. > 4. Write the message to queue/mess/457 (via the open file descriptor > in queue/pid). fsync(). > 5. Create queue/intd/457, and write the envelope to the file. fsync(). > 6. link queue/intd/457 to queue/todo/457. > > If the link in #6 succeeds, qmail-queue will return success. If the link > in queue/todo later vanishes, then so does the mail message. And should be resent later by the sending MTA because qmail did not say "250 ok". Transaction not completed, roll-back. > > Do we have to add extra fsyncs here? > > I'm not sure. In your other post (subject: ``fsync semantics''), you > didn't supply the arguments to fsync. > > Is it necessary to open each of queue/mess, queue/intd and queue/todo > and fsync them? In that case we need three more fsyncs (under FFS with > softupdates, at least). NoNoNo! You are wrong for softupdates, it does not need an fsync() on the directory. Linux EXT2 does need one. > Does fsyncing an open file descriptor sync not only metadata but hard > links as well? In that case fsyncing queue/intd/messnum again after > #6 suffices. (Hard) links are metadata. On *BSD/SYSV and derivates link() is supposed to be atomically. Remember, qmail handles the message like a transactioning system with roll-forward and roll-back. -- Andre
Andre Oppermann <[EMAIL PROTECTED]> wrote: > Len Budney wrote: > > > > 1. Create a file in a temporary directory (queue/pid). It's inode > > becomes the message number (say 457). > > 3. Link the tempfile to queue/mess/457. > > 4. Write the message to queue/mess/457 (via the open file descriptor > > in queue/pid). fsync(). > > 5. Create queue/intd/457, and write the envelope to the file. fsync(). > > 6. link queue/intd/457 to queue/todo/457. > > > > If the link in #6 succeeds, qmail-queue will return success. If the link > > in queue/todo later vanishes, then so does the mail message. > > And should be resent later by the sending MTA because qmail did not > say "250 ok". Transaction not completed, roll-back. I'm not sure if we're communicating. Does FFS offer the guarantee that when link() succeeds, the hard link exists on the physical disk? If not, then you are incorrect. When the link in #6 above succeeds, qmail-queue returns success. qmail-smtp interprets that as success, and returns "250 ok". The client interpets that as success, and discards the message. All of this occurs if link() returns success. If link() can return success, yet the link itself vanish after a reboot, then mail can be lost. Where does that leave us? Len.
On Fri, 11 Feb 2000 13:25:19 -0500 , "Len Budney" writes: > Andre Oppermann <[EMAIL PROTECTED]> wrote: > > And should be resent later by the sending MTA because qmail did not > > say "250 ok". Transaction not completed, roll-back. > > I'm not sure if we're communicating. Does FFS offer the guarantee that > when link() succeeds, the hard link exists on the physical disk? FFS with sync metadata (the default) does. I'm not sure on FFS/softupdates. > If not, then you are incorrect. When the link in #6 above succeeds, > qmail-queue returns success. qmail-smtp interprets that as success, > and returns "250 ok". The client interpets that as success, and > discards the message. All of this occurs if link() returns success. > > If link() can return success, yet the link itself vanish after a reboot, > then mail can be lost. Where does that leave us? FFS with softupdates honors fsync() calls. I.e. if fsync() has returned, the file (both data and metadata) is guaranteed to be on the disk. Again, I don't know if the link() call guarantees the new link will be on disk. If it doesn't, then fsync()ing the directory of the target link should flush the link to disk[1]. However, all this discussion is moot if the softupdates code preserves the semantics of link() and/or rename(). -- Chris Mikkelson | If you throw your bread upon the waters, it shall come [EMAIL PROTECTED] | back threefold, but only if you are willing to throw the | recipe upon the waters as well... -- Terry Lambert [1] The update containing the new link should only depend on the target of the link being on disk. This was provided by the fsync() of the file. Thus, fsync()ing the directory should ensure that the link is on disk -- i.e. softupdates probably does not break fsync() anymore than Linux does.
Len Budney wrote: > > Andre Oppermann <[EMAIL PROTECTED]> wrote: > > Len Budney wrote: > > > > > > 1. Create a file in a temporary directory (queue/pid). It's inode > > > becomes the message number (say 457). > > > 3. Link the tempfile to queue/mess/457. > > > 4. Write the message to queue/mess/457 (via the open file descriptor > > > in queue/pid). fsync(). > > > 5. Create queue/intd/457, and write the envelope to the file. fsync(). > > > 6. link queue/intd/457 to queue/todo/457. > > > > > > If the link in #6 succeeds, qmail-queue will return success. If the link > > > in queue/todo later vanishes, then so does the mail message. > > > > And should be resent later by the sending MTA because qmail did not > > say "250 ok". Transaction not completed, roll-back. > > I'm not sure if we're communicating. Does FFS offer the guarantee that > when link() succeeds, the hard link exists on the physical disk? Yes. > If not, then you are incorrect. When the link in #6 above succeeds, > qmail-queue returns success. qmail-smtp interprets that as success, > and returns "250 ok". The client interpets that as success, and > discards the message. All of this occurs if link() returns success. I know. > If link() can return success, yet the link itself vanish after a reboot, > then mail can be lost. Where does that leave us? qmail is written for FFS semantics. EXT2 does NOT guarantee these semantics, eg. the link() returns as soon as the link is done in the file system cache. EXT2 writes metadata every 30s by default to the disk. With EXT2 you need to fsync() the directory to get the metadata (the link) onto the disk. -- Andre
[EMAIL PROTECTED] wrote: > > On Fri, 11 Feb 2000 13:25:19 -0500 , "Len Budney" writes: > > Andre Oppermann <[EMAIL PROTECTED]> wrote: > > > And should be resent later by the sending MTA because qmail did not > > > say "250 ok". Transaction not completed, roll-back. > > > > I'm not sure if we're communicating. Does FFS offer the guarantee that > > when link() succeeds, the hard link exists on the physical disk? > > FFS with sync metadata (the default) does. I'm not > sure on FFS/softupdates. It does also for softupdates. The only case FFS does not guarantee this is when you mount FFS async. > > If not, then you are incorrect. When the link in #6 above succeeds, > > qmail-queue returns success. qmail-smtp interprets that as success, > > and returns "250 ok". The client interpets that as success, and > > discards the message. All of this occurs if link() returns success. > > > > If link() can return success, yet the link itself vanish after a reboot, > > then mail can be lost. Where does that leave us? > > FFS with softupdates honors fsync() calls. I.e. if > fsync() has returned, the file (both data and > metadata) is guaranteed to be on the disk. Exactly. softupdates does NOT change FFS semantics, it's just faster. > Again, I don't know if the link() call guarantees > the new link will be on disk. If it doesn't, then > fsync()ing the directory of the target link should > flush the link to disk[1]. > > However, all this discussion is moot if the softupdates > code preserves the semantics of link() and/or > rename(). It does. -snip- > [1] The update containing the new link should only > depend on the target of the link being on disk. > This was provided by the fsync() of the file. Thus, > fsync()ing the directory should ensure that the link > is on disk -- i.e. softupdates probably does not > break fsync() anymore than Linux does. It beaks fsync() in no way. The only thing softupdates does is it creates a dependency graph of all outstanding and cached metadata transactions and ensures that they hit the disk in the right order to keep the usual FFS semantics we always had. For deeper information on softupdates and DOW (delayed ordered writes) look at the paper by Ganger & Patt. -- Andre
On Fri, 11 Feb 2000, Andre Oppermann wrote: > I'm not sure if we're communicating. Does FFS offer the guarantee that > when link() succeeds, the hard link exists on the physical disk? Yes. Are you certain? My understanding (possibly wrong) is that the only guarantee is that if you do link() then unlink(), that the unlink will not be committed to disk before the link. Soft updates is all about letting the link() be asyncronous and still meet the guarantee. -- Jeff Hayward
The fastforward docs say: "to /var/qmail/control/rcpthosts so that qmail accepts mail for virt.dom from remote hosts. Now you can handle virt.dom in /etc/aliases: [EMAIL PROTECTED]: joe, fred (this line catches all other addresses)@virt.dom: joe" The problem is, it doesn't work like this. If you have: @virt.dom: joe then ALL mail for virt.dom will go to joe, no matter what the other aliases for virt.dom are. Is there some secret magic trick I'm missing here? Because it doesn't seem to work as documented. --Adam
I'm having the same trouble with imap-4.5 (with David Harris' maildir patches) that I had with APOP: plaintext login authentication works fine, but CRAM-MD5 authentication fails every time. With APOP, the challenge/response are easy to calculate, e.g.: echo -n "<[EMAIL PROTECTED]>apoptest"|md5 where the message-ID-looking thing is the challenge, and "apoptest" is the password. But CRAM-MD5 does something different...some sort of "keyed md5". Anyone know how to manually generate the proper response? Anyone know if fetchmail does it right? Anyone using imap-4.5 with CRAM-MD5 successfully? -Dave
At 11:55 AM -0500 2/11/00, Dave Sill wrote: >I'm having the same trouble with imap-4.5 (with David Harris' maildir >patches) that I had with APOP: plaintext login authentication works >fine, but CRAM-MD5 authentication fails every time. > >With APOP, the challenge/response are easy to calculate, e.g.: > > echo -n "<[EMAIL PROTECTED]>apoptest"|md5 > >where the message-ID-looking thing is the challenge, and "apoptest" is >the password. But CRAM-MD5 does something different...some sort of >"keyed md5". > >Anyone know how to manually generate the proper response? > >Anyone know if fetchmail does it right? Yes, it does. I can log into courier-imap with it: leprss% fetchmail -vv -c --protocol IMAP-CRAMMD5 mors.gsfc.nasa.gov Enter password for [EMAIL PROTECTED]: fetchmail: 5.2.0 querying mors.gsfc.nasa.gov (protocol IMAP-LOGIN) at Fri, 11 Fe b 2000 12:01:18 -0500 (EST) fetchmail: IMAP< * OK Courier-IMAP ready. Copyright 1998-1999 Double Precision, Inc. See COPYING for distribution information. fetchmail: IMAP> A0001 CAPABILITY fetchmail: IMAP< * CAPABILITY IMAP4rev1 NAMESPACE AUTH=CRAM-MD5 fetchmail: IMAP< A0001 OK CAPABILITY completed fetchmail: Protocol identified as IMAP4 rev 1 fetchmail: CRAM-MD5 authentication is supported fetchmail: IMAP> A0002 AUTHENTICATE CRAM-MD5 fetchmail: IMAP< + PDMwMjkxM0I4QjlDNEMyRDc3ODVDNjJBOTg2RjRFMjJBQG1vcnMuZ3NmYy5uY XNhLmdvdj4= fetchmail: decoded as <[EMAIL PROTECTED]> fetchmail: replying with schinder 4513b42652255597820d812cdfe3e0a5 fetchmail: IMAP> c2NoaW5kZXIgNDUxM2I0MjY1MjI1NTU5NzgyMGQ4MTJjZGZlM2UwYTU= fetchmail: IMAP< A0002 OK LOGIN Ok. fetchmail: selecting or re-polling default folder fetchmail: IMAP> A0003 EXAMINE INBOX fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Recent) fetchmail: IMAP< * OK [PERMANENTFLAGS ()] No permanent flags permitted fetchmail: IMAP< * 10 EXISTS fetchmail: IMAP< * 1 RECENT fetchmail: IMAP< * OK [UIDVALIDITY 947781516] fetchmail: IMAP< A0003 OK [READ-ONLY] Ok 10 messages (9 seen) for schinder at mors.gsfc.nasa.gov. fetchmail: IMAP> A0004 LOGOUT fetchmail: IMAP< * BYE Courier-IMAP server shutting down fetchmail: IMAP< A0004 OK LOGOUT completed fetchmail: normal termination, status 0 > >Anyone using imap-4.5 with CRAM-MD5 successfully? I'm using courier-imap with CRAM-MD5. Both fetchmail and MacOS Eudora can log in. > >-Dave -- Paul J. Schinder NASA Goddard Space Flight Center Code 693 [EMAIL PROTECTED]
On Fri, 11 Feb 2000, Dave Sill wrote: > the password. But CRAM-MD5 does something different...some sort of > "keyed md5". > > Anyone know how to manually generate the proper response? RFC 2104
How can I change the mailer-daemon address to [EMAIL PROTECTED] instead of [EMAIL PROTECTED] ? TIA // Magnus
On Fri, 11 Feb 2000, Magnus �stergaard wrote: > How can I change the mailer-daemon address to [EMAIL PROTECTED] > instead of [EMAIL PROTECTED] ? echo domain.foo > /var/qmail/control/bouncehost Then restart qmail. Read the qmail-send(8) man page. Look for bouncehost and bouncefrom. Mads
Nevermind, I found the problem. thanks, --Adam On Fri, Feb 11, 2000 at 11:38:59AM -0500, Adam McKenna wrote: > The fastforward docs say: > > "to /var/qmail/control/rcpthosts so that qmail accepts mail for virt.dom > from remote hosts. Now you can handle virt.dom in /etc/aliases: > > [EMAIL PROTECTED]: joe, fred > (this line catches all other addresses)@virt.dom: joe" > > The problem is, it doesn't work like this. If you have: > > @virt.dom: joe > > then ALL mail for virt.dom will go to joe, no matter what the other aliases > for virt.dom are. > > Is there some secret magic trick I'm missing here? Because it doesn't seem > to work as documented. > > --Adam >
old system: irix, sendmail, /bin/mail, pine, qpopper, homedirs on flaky NFS disks. new system: FreeBSD, qmail, maildir, mutt, qmail-pop3d, less flaky NFS, qmail-users, quotas. i lose power about every 6 weeks in this building. the network is flaky. i want to test qmail by flooding it with incoming mail and then unplugging the network, etc. i can easily flood the server with perl, but i don't know the best way to compare the mail sent with the mail received. any opinions? i want to tell my users that i tested the new server with 100,000 emails a day and it never dropped or corrupted a single one. anyone have scripts for testing qmail? if not then i'll just write my own. ---matt
Is there any documentation or mini howto outhere to get amavis run under qmail? ThX
[EMAIL PROTECTED] wrote: > > Is there any documentation or mini howto outhere to get amavis run under > qmail? Well, AMaViS 0.2.0-pre6 (from http://amavis.org) does not work (well) with qmail. You have to use AMaViS 0.2.0-pre6-clm-rl-5 from http://www.unizone.com/virus - follow the instruction on the web page and it should work. :-) HTH cu, Rainer -- Member of Virus Help Munich (www.vhm.haitec.de) | Rainer Link Member of AMaViS Development Team (amavis.org) | [EMAIL PROTECTED] Maintainer FAQ "antivirus for Linux" (av-linux.w3.to) | rainer.w3.to
Rainer Link wrote: > Well, AMaViS 0.2.0-pre6 (from http://amavis.org) does not work (well) > with qmail. > You have to use AMaViS 0.2.0-pre6-clm-rl-5 from > http://www.unizone.com/virus - follow the instruction on the web page Uups, I'm sorry. I was typing too fast and missed a character. :-) The correct URL is: http://www.unixzone.com/virus/ This should work now. best regards, Rainer Link -- Rainer Link, eMail: [EMAIL PROTECTED], WWW: http://rainer.w3.to/ Student of Communication Engineering/Computer Networking, University of Applied Sciences,Furtwangen,Germany,http://www.ce.is.fh-furtwangen.de/
>From qmail.org -- Jason van Zyl has a patch to the cyrus imap server so that it authenticates out of a cdb (the same hash format that users/assign uses) instead of kerberos or /etc/passwd. And he has a perl script that allow you to enter users into the system and it takes care of updating the users/assign file, and the cdb file that cyrus is using to authenticate from. Does anyone have the package or know the current location of that site? The name does not DNS resolve, even when connecting directly to the name server from whois. The listed URL is -- http://www.periapt.com/qmail-cyrus/ Other than the above, does anyone know how to set up Cyrus and Qmail to work together to use a single system UID, including using a different password for a username that is also in /etc/passwd (as in make them both ignore /etc/passwd altogether)? Thanks, ~Patrick
"Mullen, Patrick" <[EMAIL PROTECTED]> wrote: >The listed URL is -- > >http://www.periapt.com/qmail-cyrus/ Try: http://www.compusense.com/qmail-cyrus/ -Dave
If I want to forward all outbound mail from my machine to my mail hub (because we only allow outbound mail from there) can I just put ":hub.mydomain.com" in my smtproutes? -- ______________________________________________________ Mark Drummond|ICQ#19153754|mailto:[EMAIL PROTECTED] Gang Warily|http://signals.rmc.ca/ Kingston Linux Users Group|http://signals.rmc.ca/klug/
Mark E. Drummond <[EMAIL PROTECTED]> wrote: > If I want to forward all outbound mail from my machine to my mail hub > (because we only allow outbound mail from there) can I just put > ":hub.mydomain.com" in my smtproutes? Yes. Charles -- ---------------------------------------------------- Charles Cazabon <[EMAIL PROTECTED]> Any opinions expressed are just that -- my opinions. ----------------------------------------------------
Charles Cazabon wrote: Yes.I keep getting "sorry_could_not_establish_ an_smtp_connection".-- ______________________________________________________ Mark Drummond|ICQ#19153754|mailto:[EMAIL PROTECTED] Gang Warily|http://signals.rmc.ca/ Kingston Linux Users Group|http://signals.rmc.ca/klug/
Mark E. Drummond <[EMAIL PROTECTED]> wrote: > > ���k6��|+�������� z� �ا��(���r�������������j����r��y�b Geez, I hate multipart/alternative and base64-encoded email. However, I think I managed to get at least to 'I keep getting "failed to establish an SMTP connection" from your message. This probably means one of the following: -you specified an incorrect address for your hub in smtproutes -your hub's name is not resolvable through your host's DNS facilities -the DNS for your hub is incorrect (MX is a CNAME or something else) -your hub is not listening on port 25, or is blocking connections from your host Charles -- ---------------------------------------------------- Charles Cazabon <[EMAIL PROTECTED]> Any opinions expressed are just that -- my opinions. ----------------------------------------------------
"Mark E. Drummond" <[EMAIL PROTECTED]> writes: > If I want to forward all outbound mail from my machine to my mail hub > (because we only allow outbound mail from there) can I just put > ":hub.mydomain.com" in my smtproutes? Yes. In addition you need to allow your mail hub to relay for those clients. The authors qmail FAQ explains the procedure under: ``5.4. How do I allow selected clients to use this host as a relay?'' If you have a recent tcpserver, use the alternative procedure. Works fine for me. I don't know if there is an easier procedure which would allow relaying for all of the local domain. Maybe someone has a suggestion? -- Manfred Bartz
"Mark E. Drummond" <[EMAIL PROTECTED]> writes: > If I want to forward all outbound mail from my machine to my mail hub > (because we only allow outbound mail from there) can I just put > ":hub.mydomain.com" in my smtproutes? Yes. In addition you need to allow the mail-hub to relay for your clients. I have this: ----------8><--------------------------------------------------------- # tcp.smtp source list of acceptable relay clients # # compile with: # tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp # 127.0.0.1:allow,RELAYCLIENT="" 192.168.1.10-19:allow,RELAYCLIENT="" ----------8><--------------------------------------------------------- Refer to the FAQ: 5.4. How do I allow selected clients to use this host as a relay? -- Manfred Bartz
Brian Johnson <[EMAIL PROTECTED]> writes: > I'm looking for a way to add a Bcc: line to all e-mails that come > through my smtp server. Why? Respect privacy. > I'm trying to log all the e-mail that people send through my server to > another pop box so I can just download the messages, and then filter > them or whatever I want with my mailreader. has someone written a > wrapper or something that could help me do something like this? Have a look at qmail FAQ 8.2 Martin
Hello qmail-users... How do I tell qmail-smtpd to not accepting eMails where the sender says: msg from: <> I see this here very often, and I don't like it.. -- Bye Uwe
On Sat, 12 Feb 2000, Uwe Boettjer wrote: > Hello qmail-users... > > How do I tell qmail-smtpd to not accepting eMails where the sender says: > msg from: <> > > I see this here very often, and I don't like it.. > > -- > Bye > Uwe You are REQUIRED by the internet standards to accept these messages. PERIOD. Do NOT under any circumstances reject these messages. All SMTP error messages are REQUIRED to use an empty envelope sender address. See RFC 821 and RFC 1123 Section 5.2.9. --------------------------------- 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
Hello Timothy, On Fri, 11 Feb 2000, Timothy L. Mayo wrote: TLM > > TLM > > How do I tell qmail-smtpd to not accepting eMails where the sender says: TLM > > msg from: <> TLM > > TLM > TLM > You are REQUIRED by the internet standards to accept these messages. TLM > TLM > --------------------------------- TLM > Timothy L. Mayo mailto:[EMAIL PROTECTED] Argh... i frogot this... Thank you... -- Bye Uwe
Is there any way to have deferrals redirect to another system? Basically I have a machine that I need to do a large amount of outgoing mail and I'd like to keep deferrals away from the queue. Thanks -jeremy
On Sat, Feb 12, 2000 at 02:50:49AM -0500, Jeremy Hansen wrote: > > Is there any way to have deferrals redirect to another system? Basically > I have a machine that I need to do a large amount of outgoing mail and I'd > like to keep deferrals away from the queue. If the deferrals should be redirected, it would pass the queue anyhow! if you mean that you would like to change the address <[EMAIL PROTECTED]> to <[EMAIL PROTECTED]> then put "deferrals.example.com" in QMAILHOME/control/bouncehost Or did you refer to anything else? /magnus -- http://x42.com/
Thanks for the "qmail-remote outgoingip patch", I was able to successfully apply it (by hand) to qmail 1.03. Unfortunatly, it didn't fix the problem I was having, which was that qmail was connecting to itself (it was the backup MX for a down system) because the MX record was bound to a secondary IP address, thus looping mail. The reason is because ipme still just looks at the primary interface and qmail-remote uses that to compare against the MX record instead of the bound address. Here is a very lightly (oh, about 5 minutes) tested patch. I was kinda in a hurry and am not quite sure if [0] of a ip_address is the most or least significant octet, I was betting on it being the most but this should still work even if it's the least, as I don't think zero is legal for either. *** ../qmail-ldap/qmail-remote.c Tue Jan 11 01:43:02 2000 --- qmail-remote.c Sat Feb 12 01:47:31 2000 *************** *** 29,34 **** --- 29,35 ---- #include "timeoutconn.h" #include "timeoutread.h" #include "timeoutwrite.h" + #include "byte.h" #define HUGESMTPTEXT 5000 *************** *** 396,402 **** prefme = 100000; for (i = 0;i < ip.len;++i) ! if (ipme_is(&ip.ix[i].ip)) if (ip.ix[i].pref < prefme) prefme = ip.ix[i].pref; --- 407,413 ---- prefme = 100000; for (i = 0;i < ip.len;++i) ! if (outip.d[0] ? byte_equal(&ip.ix[i].ip,4,&outip.d[0]) : ipme_is(&ip.ix[i].ip)) if (ip.ix[i].pref < prefme) prefme = ip.ix[i].pref; -- Aaron Nabil
From: sachin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, February 05, 2000 4:55 PM
Subject: complex user routing
hi all , sachin here ,
what i want is i am useing aceindia.com as local mail server. some user are located at diffrent location . there is also qmail mail server with aceindia.com as local mail server. what i want for that location user mail should send to my isp smtp server without changing the rcpt & from header.
ex local user [EMAIL PROTECTED] other location user is [EMAIL PROTECTED]
when i compose message for [EMAIL PROTECTED] it should user my isp smtp server fro sending mail . it is possible in sendmail why not in qmail
or here is any way to do this
further help is required
