qmail Digest 18 Aug 2000 10:00:00 -0000 Issue 1096
Topics (messages 46850 through 46937):
Re: qmail-default and bounce
46850 by: Petr Novotny
46851 by: Chris, the Young One
46929 by: Marc-Adrian Napoli
Interesting MAPS issue
46852 by: Tyler J. Frederick
46855 by: Petr Novotny
46856 by: Peter Green
46858 by: Tyler J. Frederick
46862 by: OK 2 NET - Andr� Paulsberg
Re: qmail prefered platform??
46853 by: Peter Green
46857 by: TAG
Settng up qmail with ldap
46854 by: Joerg Ebel
46864 by: tigre21.gamma.qnet.com.pe
Re: Is This Annoying Enough?
46859 by: Dave Sill
46866 by: Charles Cazabon
Re: Fallback MX Host?
46860 by: Dave Sill
46881 by: Ihnen, David
Re: auth/identd?
46861 by: Peter van Dijk
46874 by: Greg Owen
46927 by: Chris, the Young One
Re: qmail-pop3d problem: No mail delivery to Maildirs
46863 by: Dave Sill
Forwarding Mail
46865 by: Joerg Ebel
46867 by: Tim Hunter
46868 by: Charles Cazabon
46871 by: Joerg Ebel
46876 by: Chris, the Young One
Server hanging w/qmail 1.03
46869 by: Brian Estes
46872 by: Charles Cazabon
46873 by: Petr Novotny
46875 by: Joel Gautschi
46878 by: Charles Cazabon
Re: Error: Deferred: Connection refused
46870 by: Greg Owen
Required POP3 behavior of RETR command/RFC 1939
46877 by: Rogerio Brito
46885 by: Jenny Holmberg
46892 by: Ihnen, David
Queue Time
46879 by: Shane Wise
46880 by: James Raftery
46882 by: David Dyer-Bennet
46886 by: Michael T. Babcock
46893 by: Tim Hunter
46896 by: markd.bushwire.net
46897 by: Ian Lance Taylor
46898 by: David Dyer-Bennet
46899 by: Michael T. Babcock
46901 by: Ian Lance Taylor
46902 by: markd.bushwire.net
46903 by: David Dyer-Bennet
46904 by: Ian Lance Taylor
46905 by: Charles Cazabon
46906 by: markd.bushwire.net
46908 by: markd.bushwire.net
46909 by: Dave Sill
46910 by: Michael T. Babcock
46912 by: Ian Lance Taylor
46913 by: Charles Cazabon
46914 by: Charles Cazabon
46915 by: markd.bushwire.net
46917 by: M.B.
46919 by: markd.bushwire.net
46920 by: Eric Cox
46925 by: Rogerio Brito
46926 by: Rogerio Brito
46931 by: David Dyer-Bennet
46933 by: Rogerio Brito
Re: Happy Meal ERROR
46883 by: Jenny Holmberg
46916 by: Uwe Ohse
Re: 4.7.1 error reported to netscape mail client
46884 by: Aaron L. Meehan
46923 by: Dale Miracle
46937 by: Jenny Holmberg
looping tcprules ?
46887 by: Jeff Garvas
46895 by: Tim Hunter
46907 by: Jeff Garvas
46911 by: Charles Cazabon
Proper secondary MX configuration
46888 by: Michael T. Babcock
46894 by: David Dyer-Bennet
46900 by: Michael T. Babcock
RFC821 bounce compliance
46889 by: tibbs.joshd.kendle.com
46890 by: James Raftery
46891 by: James Raftery
string based blocking in Qmail
46918 by: Enrique Vadillo
Re: rblsmtpd emergency
46921 by: Michael T. Babcock
46930 by: Mate Wierdl
Lot of accounts...
46922 by: Dimitri SZAJMAN
46924 by: Dale Miracle
46932 by: Tim Hunter
Numbering scheme
46928 by: Kai Peters
46935 by: Magnus Bodin
determing local path
46934 by: Duane L.
46936 by: Magnus Bodin
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]
----------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17 Aug 2000, at 21:59, Chris, the Young One wrote:
> &[EMAIL PROTECTED]
> |bouncesaying "No such user"
>
> This should work without requiring tweaks to ownership.
This will NOT work. Excerpt from man dot-qmail:
> qmail-local handles forwarding
> after all other instructions, so any error in another type of
> delivery will prevent all forwarding.
What you describe will not work. You would have to forward to two
pseudo-accounts, "deliverer" and "bouncer"; bouncer would call
"bouncesaying".
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBOZuql1MwP8g7qbw/EQIccgCfaydvfMUPZ1Sd5quo/MQpXvVB8ssAoMFV
3qB/XXHWIY0FW14Djsjgo+xL
=3wG5
-----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]
On Thu, Aug 17, 2000 at 12:04:23PM +0200, Petr Novotny wrote:
> What you describe will not work. You would have to forward to two
> pseudo-accounts, "deliverer" and "bouncer"; bouncer would call
> "bouncesaying".
Okay, I stand corrected. Marc-Adrian, please disregard my last post.
(Note to self: always consult the sources first.)
---Chris K.
--
Chris, the Young One |_ but what's a dropped message between friends?
Auckland, New Zealand |_ this is UDP, not TCP after all ;) ---John H.
http://cloud9.hedgee.com/ |_ Robinson, IV
Hi all,
> > &[EMAIL PROTECTED]
> > |bouncesaying "No such user"
> >
> > This should work without requiring tweaks to ownership.
>
> This will NOT work. Excerpt from man dot-qmail:
> > qmail-local handles forwarding
> > after all other instructions, so any error in another type of
> > delivery will prevent all forwarding.
>
> What you describe will not work. You would have to forward to two
> pseudo-accounts, "deliverer" and "bouncer"; bouncer would call
> "bouncesaying".
Yep, i tried every way i could and the only way to do it is this:
in .qmail-default put:
&[EMAIL PROTECTED]
&[EMAIL PROTECTED]
and then have defaultaliasmailbox as your catchall mailbox, and a
|bouncesaying file in the .qmail for bouncer.
Thanks for everyone who's helped.
Regards,
Marc-Adrian Napoli
Network Admin
Connect Infobahn Australia
+61 2 9281 1750
Hi folks
I just installed rblsmtpd last nite, and it seems to work correctly. Here
is my command line:
/usr/local/bin/tcpserver -x /etc/rules/smtp.cdb -u 1003 -g 102 0 25 \
/usr/local/bin/rblsmtpd \
-r rbl.maps.vix.com \
-r dul.maps.vix.com \
-r relays.mail-abuse.org \
/var/qmail/bin/qmail-smtpd &
I've tested it with Russ's test-bots, and the rbl and dul work fine, rss
doesn't, but after searching the list, I guess I have to apply a patch for
that as MAPS removed the TXT records. What I don't understand is this,
HOW can the rbl and dul work if my machine can't resolve those
names? Check it out:
[root@mail:~]# nslookup rbl.maps.vix.com
Server: ns1.supplyguys.net
Address: 205.247.132.3
*** smtp.supplyguys.net can't find rbl.maps.vix.com: Non-existent
host/domain
and I get the same response if I lookup DUL. Makes no sense. Also, with
the cmd line I have above, how can I get the rblsmtpd logs to go into my
syslog with the qmail logs. Do I need to pipe the whole cmd to splogger?
- T
--
Tyler J. Frederick
Systems Administrator
Sportsline.com, Inc.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17 Aug 2000, at 8:06, Tyler J. Frederick wrote:
> [root@mail:~]# nslookup rbl.maps.vix.com
> Server: ns1.supplyguys.net
> Address: 205.247.132.3
>
> *** smtp.supplyguys.net can't find rbl.maps.vix.com: Non-existent
> host/domain
It's a domain, not a host.
[root@saturnin /root]# nslookup -q=ns rbl.maps.vix.com
Server: saturnin.antek.cz
Address: 195.250.137.225
Non-authoritative answer:
rbl.maps.vix.com nameserver = ns-ext.vix.com
rbl.maps.vix.com nameserver = ns.eu.net
rbl.maps.vix.com nameserver = max.bungi.com
rbl.maps.vix.com nameserver = ns3.above.net
rbl.maps.vix.com nameserver = ns2.sztaki.hu
rbl.maps.vix.com nameserver = nn.uninett.no
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBOZvJyFMwP8g7qbw/EQJ1cgCgm8iti4tN6ZDp15WIJduyPAg2uVUAoNlS
NHyBuxxwKuqFcFL6j1zgIKrq
=vO7l
-----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]
also sprach tyler:
> What I don't understand is this,
> HOW can the rbl and dul work if my machine can't resolve those
> names?
Those aren't names to be resolved; they are zones in which rblsmtpd checks
an IP address for an entry.
IOW, if 1.2.3.4 connects to your machine to attempt to send mail, your
machine will do a lookup on 4.3.2.1.rbl.maps.vix.com (I think; please
correct me if I'm wrong). If a record exists, it's on the list.
/pg
--
Peter Green : Gospel Communications Network, SysAdmin : [EMAIL PROTECTED]
---
One thing vampire children have to be taught early on is, don't run with a
wooden stake. - Jack Handy
(Jack Handey)
Ahhhh! Thanks. I had been reading the list archives last nite, and
people having problems with other listings were asked "well, is it
pingable?" and such, so thought it was a host. Thanks for clearing that
up. How bout the logging thing now?
- T
--
Tyler J. Frederick
Systems Administrator
Sportsline.com, Inc.
On Thu, 17 Aug 2000, Petr Novotny wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17 Aug 2000, at 8:06, Tyler J. Frederick wrote:
>
> > [root@mail:~]# nslookup rbl.maps.vix.com
> > Server: ns1.supplyguys.net
> > Address: 205.247.132.3
> >
> > *** smtp.supplyguys.net can't find rbl.maps.vix.com: Non-existent
> > host/domain
>
> It's a domain, not a host.
> [root@saturnin /root]# nslookup -q=ns rbl.maps.vix.com
> Server: saturnin.antek.cz
> Address: 195.250.137.225
>
> Non-authoritative answer:
> rbl.maps.vix.com nameserver = ns-ext.vix.com
> rbl.maps.vix.com nameserver = ns.eu.net
> rbl.maps.vix.com nameserver = max.bungi.com
> rbl.maps.vix.com nameserver = ns3.above.net
> rbl.maps.vix.com nameserver = ns2.sztaki.hu
> rbl.maps.vix.com nameserver = nn.uninett.no
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 6.0.2 -- QDPGP 2.60
> Comment: http://community.wow.net/grt/qdpgp.html
>
> iQA/AwUBOZvJyFMwP8g7qbw/EQJ1cgCgm8iti4tN6ZDp15WIJduyPAg2uVUAoNlS
> NHyBuxxwKuqFcFL6j1zgIKrq
> =vO7l
> -----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]
>
> [root@mail:~]# nslookup rbl.maps.vix.com
> Server: ns1.supplyguys.net
> Address: 205.247.132.3
>
> *** smtp.supplyguys.net can't find rbl.maps.vix.com: Non-existent host/domain
>
> and I get the same response if I lookup DUL. Makes no sense.
You are using NSLOOKUP to find a A, CNAME or PTR record which is default, try:
nslookup -type=SOA rbl.maps.vix.com
or try lookin up IP 209.210.138.47 with:
nslookup -type=TXT 47.138.210.209.rbl.maps.vix.com
&
nslookup 47.138.210.209.rbl.maps.vix.com
> Also, with the cmd line I have above,
> how can I get the rblsmtpd logs to go into my syslog with the qmail logs.
> Do I need to pipe the whole cmd to splogger?
Just direct you MESSAGE to STD/ERR like this.
echo "rblsmtpd: $TCPREMOTEIP pid $P: 553 Blackholed - see
<URL:http://mail-abuse.org/cgi-bin/lookup?209.210.138.47>" 1>&2
MVH Andr� Paulsberg
also sprach eric:
> TAG wrote:
> > What is the prefered platform for qmail to run on - say I have a 100 000
> > mailboxes that are VERY busy - what do I want to run this on .
> It really comes down to how much you're willing to spend on hardware,
> then what OS supports your hardware the best, what you want in the
> way of support, etc...
Even more than that, it comes down to what *you* know best. I can guarantee
you that if I put together a *BSD system for you, any Linux admin worth
his/her salt could whip up a machine that would blow my *BSD box away. It's
not because BSD is worse, it's because I don't know BSD from LSD.
Use what you know and make it work well. (Okay, within certain limits.)
/pg
--
Peter Green : Gospel Communications Network, SysAdmin : [EMAIL PROTECTED]
---
C++ is a ridiculously complicated travesty that few have the excess IQ
points to understand enough not to screw up massively.
--- Tom Christiansen
HI,
Thanks for the reply - BUT what if I have accesss to a IBM H70 and D40
configuration - 4 way 2gb ram - against a SUN E450 4 way 1.5G ram and a
A5100 network storage array.
Which is better - or are they both below a Intel machine ???
Runnign BSD or Redhat or Mandrake ????
Any ideas??
Thanks Again
Tonino
Eric Cox wrote:
>
> TAG wrote:
> >
> > Hi ALL,
> >
> > What is the prefered platform for qmail to run on - say I have a 100 000
> > mailboxes that are VERY busy - what do I want to run this on .
> >
> > Your advise is greatly appreciated...
>
> Unix.
>
> Badoomboom-Crash! *roaring laughter*
>
> But, seriously folks....
>
> I've heard that Linux can have more of a tendency to fold-up-and-die
> under extremely high loads, and that on *BSD this behavior is much less
> pronounced - but I've personally never seen it, and use Linux exclusively.
> You really should look through the archives - I've seen platform
> specific problems on the list, but not many.
>
> It really comes down to how much you're willing to spend on hardware,
> then what OS supports your hardware the best, what you want in the
> way of support, etc...
>
> Eric
--
---- TAG (Tonino [EMAIL PROTECTED] | ICQ # 38609461 )
Hi,
i have successfully installed qmail with the help of "Life with qmail".
(Very good dokumentation, thanks to Dave Sill!)
Now I want to set up qmail with the ldap-patch, because we need that for a
bigger pop-toaster.
Is there no good dokumentation on using qmail with ldap?
I have patched the qmail source and compiled it. But how to start qmail now?
Das anyone have start/stop-scripts for qmail with ldap? The script i made
with the help of "Life with qmail" dont work for that.
I'am thankful for any hint/link/...
Best Regards,
Joerg
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Please friend
I need these information than say you
Send me please.......
I am trying install qmail with mysql for authentification but i have
little information about it...
Thanks you
Friend Joerg
Juan Enciso
LIMA - PERU
On Thu, 17 Aug 2000, Joerg Ebel wrote:
> Hi,
>
> i have successfully installed qmail with the help of "Life with qmail".
> (Very good dokumentation, thanks to Dave Sill!)
>
> Now I want to set up qmail with the ldap-patch, because we need that for a
> bigger pop-toaster.
>
> Is there no good dokumentation on using qmail with ldap?
>
> I have patched the qmail source and compiled it. But how to start qmail now?
>
> Das anyone have start/stop-scripts for qmail with ldap? The script i made
> with the help of "Life with qmail" dont work for that.
>
> I'am thankful for any hint/link/...
>
> Best Regards,
> Joerg
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
Bruno Prior <[EMAIL PROTECTED]> wrote:
>A short while before the self-righteous thread on How To Annoy People
>Whose Help You Need, I posted a request for help with a problem I was
>experiencing.
Pardon me for trying to humorously and constructively address a
problem the list has been having.
I'll go back to dryly answering FAQ's and quietly suffering list
abuses now.
>Not a single one of the supposedly helpful people of
>this list have bothered to reply. Having read the thread, it occurs to
>me that perhaps the original message wasn't annoying enough to merit a
>reply, so this is my next attempt.
Oops, you forgot the part about *not* mentioning the previous
attempts. Otherwise, this was a pretty annoying message.
>I am fetching my mail from my ISP using fetchmail and passing it to
>the SMTP port (with qmail as mail server). I believe my ISP is using
>qpopper, if that makes any difference. This mostly works fine, but
>occasionally I get the following response, which I can't get past (I
>get round it by using Netscape to download that message):
>
>fetchmail: SMTP< 451 See http://pobox.com/~djb/docs/smtplf.html.
>fetchmail: SMTP listener refused delivery
I suspect the problem messages contain bare LF's. The forcecr option
to fetchmail only (as far as I know) causes fetchmail to end SMTP
commands with CR-LF, it doesn't deal with embedded bare LF's.
-Dave
Bruno Prior <[EMAIL PROTECTED]> wrote:
> A short while before the self-righteous thread on How To Annoy People
> Whose Help You Need, I posted a request for help with a problem I was
> experiencing.
The thread wasn't self-righteous; it was humourous and tongue-in-cheek. Your
post is self-righteous.
> Not a single one of the supposedly helpful people of
> this list have bothered to reply.
We're volunteers, helping people who have made a reasonable effort to
understand qmail (and Unix/Linux/etc, SMTP) administer their systems. Your
question is a common one, and the common resources out there deal with it.
However, to be nice, here's the cause:
-qmail enforces the rfc requirement of line endings being <CR><LF>
-many other MTAs and POP3 servers do not enforce this requirement.
-fetchmail retrieves mail froma POP3 server and fiddles with it, then tries to
re-inject it with SMTP to the local system (by default). It's not particularly
bright about this, and it's a broken design to start with.
-fetchmail is therefore feeding your local system with a broken SMTP
transaction. qmail is refusing it, legitimately.
To solve your problem, either configure sendmail to deliver directly to
the destination mbox files or Maildirs (with procmail or another MDA),
or switch to 'getmail', which doesn't do SMTP re-injection, and has
good support for many qmail features.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
"Shane Wise" <[EMAIL PROTECTED]> wrote:
>Is there any way to setup qmail with sendmail's Fallback MX host
>option?
No, qmail doesn't need that capability since it's not a bloated,
inefficient pig. :-)
>My
>DSL line sometimes has problems with certain places and i would like to
>route it out my ISDN as a backup automatically.
You could set up smtproutes entries for these "certain places", but
only after you've discovered that they're problematic. The real fix is
to find out why the DSL has problems with them.
-Dave
Sounds like an IP routing issue.
Set up a static route for the destinations that your DSL link can't reach.
Then traffic to that host will go out your isdn.
David
> -----Original Message-----
> From: Shane Wise [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 16, 2000 11:45 PM
> To: [EMAIL PROTECTED]
> Subject: Fallback MX Host?
>
>
> Is there any way to setup qmail with sendmail's Fallback MX
> host option? My
> DSL line sometimes has problems with certain places and i
> would like to
> route it out my ISDN as a backup automatically.
>
> Thanks
>
> Shane Wise
> For the latest Nashville Weather Conditions
> Check http://www.nashvilleweather.net
>
On Thu, Aug 17, 2000 at 04:58:43PM +1200, Chris, the Young One wrote:
> In-Reply-To: <[EMAIL PROTECTED]>
> Mail-Reply-To: [EMAIL PROTECTED]
>
> On Wed, Aug 16, 2000 at 07:55:22PM -0000, John Conover wrote:
> > Is it wise to run auth/identd on an email gateway?
>
> It's up to you. Since your gateway software probably always runs as the
> same user, the ident conveys no additional information.
One thing that *is* wise is to make sure that if you don't run
auth/ident, make sure traffic to port 113 is visibly rejected and not
just dropped. Dropping it will cause timeout hell to be spawned upon
you.
Greetz, Peter.
--
[ircoper] [EMAIL PROTECTED] - Peter van Dijk / Hardbeat
[student] Undernet:#groningen | IRCnet:#koffie/#alliance
[developer] _____________
[madly in love] (__VuurWerk__(--*-
> Is it wise to run auth/identd on an email gateway?
If you do run it, then you don't have to worry about delays or time
penalties when doing mail transactions with other servers that do ident
lookups.
If you don't run it, that is one less service you have to worry
about the security of (read, the possibility of buffer overflows).
As Peter said, forcibly rejecting connections rather than dropping
packets is preferred if you don't run it. Different firewalls make this
easier or harder.
I personally consider it easier to run it than to spend time
worrying about the interactions with mail servers that prefer to use it.
But you may want to look for a "fake" identd that is stripped down for
security purposes; freshmeat lists a few different identd implementations.
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
On Thu, Aug 17, 2000 at 11:35:51AM -0400, Greg Owen wrote:
> If you don't run it, that is one less service you have to worry
> about the security of (read, the possibility of buffer overflows).
Under Linux and BSD, you can run identd as ``nobody'' (or any other user
you care to name). Under OpenBSD, you can even run it under chroot (with
a fake /etc/passwd if you want UID -> name mapping). (In Linux, you can
also chroot it if you can loopback mount /proc/net to somewhere inside
the new root directory.)
---Chris K.
--
Chris, the Young One |_ but what's a dropped message between friends?
Auckland, New Zealand |_ this is UDP, not TCP after all ;) ---John H.
http://cloud9.hedgee.com/ |_ Robinson, IV
David Benfell <[EMAIL PROTECTED]> wrote:
>So would it work to create an alias in /var/qmail/alias/ with a lower
>case version to forward it to the uppercase version?
No.
>Or would this
>still get caught by the lowercase conversion?
Yes.
-Dave
Hi out there! :-)
Is there a way to crate Mailforwardings (without using openldap)? (Like
sendmails virtusertable)
Best Regards,
Joerg
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
I assume you mean virtual hosts?
look into vpopmail
http://www.inter7.com
-----Original Message-----
From: Joerg Ebel [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 17, 2000 12:46 PM
To: [EMAIL PROTECTED]
Subject: Forwarding Mail
Hi out there! :-)
Is there a way to crate Mailforwardings (without using openldap)? (Like
sendmails virtusertable)
Best Regards,
Joerg
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Joerg Ebel <[EMAIL PROTECTED]> wrote:
>
> Is there a way to crate Mailforwardings (without using openldap)? (Like
> sendmails virtusertable)
I don't know sendmail from a hole in the ground, but look into qmail's
virtual domains capability, /var/qmail/users/assign, /var/qmail/users/mailnames,
/var/qmail/users/subusers, and `man qmail-pw2u`.
The short answer is very probably 'yes'.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
>
>I assume you mean virtual hosts?
yes, too. but i dont want to store the mails locally. i want to redirect
them.
sendmails has a file in which these redirects are listed:
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
...
Best Regards,
Joerg
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
On Thu, Aug 17, 2000 at 05:30:35PM +0200, Joerg Ebel wrote:
> sendmails has a file in which these redirects are listed:
>
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> ...
Sounds just (almost) like what fastforward(1) does. The data file used
by fastforward is created by setforward(1). These programs are in the
fastforward package, which is probably installed with qmail.
---Chris K.
--
Chris, the Young One |_ but what's a dropped message between friends?
Auckland, New Zealand |_ this is UDP, not TCP after all ;) ---John H.
http://cloud9.hedgee.com/ |_ Robinson, IV
I am having the following problem on my qmail server ...
running the LATEST version of qmail 1.03
Sun E-450 2CPU, 1G RAM
The server hangs and is unresponseive to anything but pings
load on the server skyrokets to 300+
server is NOT loggin anything, in fact the server is doing nothing (cron
can not even run)
the only way to resolve this problem is to reboot the box
Sun believes we are running out of memory, but that doesn't jive w/sar
reports
has anyone experienced this or anything like this
I will summerize
<><
thanks
Brian
Brian Estes <[EMAIL PROTECTED]> wrote:
> I am having the following problem on my qmail server ...
>
> running the LATEST version of qmail 1.03
> Sun E-450 2CPU, 1G RAM
>
> The server hangs and is unresponseive to anything but pings
> load on the server skyrokets to 300+
> server is NOT loggin anything, in fact the server is doing nothing (cron
> can not even run)
What is your logging configuration for qmail on that box? If you're going
to the syslog, that could be your problem. syslog has been known to bring
even large boxes to their knees with a busy qmail server. Try
multilog or something instead. It could also be that you've got the
concurrent remote connection limit or inbound connection limit set too high
for your hardware, although that seems unlikely. What are the values of
/var/qmail/control/concurrencyremote and your tcpserver limit on SMTP
connections?
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 17 Aug 2000, at 11:21, Brian Estes wrote:
> The server hangs and is unresponseive to anything but pings
> load on the server skyrokets to 300+
> server is NOT loggin anything, in fact the server is doing nothing
> (cron can not even run)
Can "top" run? "ps"? What's chewing up on CPU? (Don't tell me it's
syslogd :-))
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBOZv3clMwP8g7qbw/EQIFxACfcXtmnNTNcSehqA/SS3cXeA8CKmUAnjhM
TxX6fflvjLHi4OnBE4eS0xAI
=06xS
-----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]
> has anyone experienced this or anything like this
not the same...
just qmail-smtpd crashed ones with the following message in the logs:
--- from /var/log/messages ---
Jul 31 05:42:59 joshua -- MARK --
Jul 31 05:52:52 joshua kernel: Oops: 0000
Jul 31 05:52:52 joshua kernel: CPU: 0
Jul 31 05:52:52 joshua kernel: EIP: 0010:[cached_lookup+37/84]
Jul 31 05:52:52 joshua kernel: EFLAGS: 00010206
Jul 31 05:52:52 joshua kernel: eax: 10000000 ebx: c0f172a0 ecx: 00000000
edx: c08da6d3
Jul 31 05:52:52 joshua kernel: esi: 0000000b edi: 0000000b ebp: c0bd8980
esp: c0999f5c
Jul 31 05:52:52 joshua kernel: ds: 0018 es: 0018 ss: 0018
Jul 31 05:52:52 joshua kernel: Process qmail-send (pid: 174, process nr: 14,
stackpage=c0999000)
Jul 31 05:52:52 joshua kernel: Stack: c01298c5 c0bd8980 c0999f80 0000000b
c0937000 c0937000 00000001 bffffb1c
Jul 31 05:52:52 joshua kernel: c0937000 c0937005 00000001 00000031
c012999d c0937000 00000000 00000001
Jul 31 05:52:52 joshua kernel: c0998000 bffffb54 bffffadc c01279d3
08052230 00000001 c0998000 bffffb54
Jul 31 05:52:52 joshua kernel: Call Trace: [lookup_dentry+253/428]
[__namei+41/92] [sys_newstat+19/100] [system_call+52/56]
Jul 31 05:52:52 joshua kernel: Code: 8b 00 85 c0 74 23 56 53 ff d0 83 c4 08
85 c0 75 18 53 e8 78
Jul 31 06:02:59 joshua -- MARK --
---
cya
Joel
Brian Estes <[EMAIL PROTECTED]> wrote:
>
> > What is your logging configuration for qmail on that box? If you're going
> > to the syslog, that could be your problem. syslog has been known to bring
> > even large boxes to their knees with a busy qmail server. Try
> > multilog or something instead.
>
> tell me more about mulitlog, we are running syslog but during this
> process nothing is being logged
qmail and qmail-smtpd log to stdout; 'splogger' forwards this logging
information to syslogd. syslogd will happily suck 100% of the CPU on a
busy mail server, preventing useful work from being done.
multilog is part of the daemontools package
(http://cr.yp.to/daemontools.html); see
(http://cr.yp.to/daemontools/multilog.html). It flexible, configurable,
and much easier on the system. You really should install the dameontools
if you're not already running them.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
> I have a problem with qmail. A mail sent through the
> qmail-smtp to a local user is delivered properly, but
> when I send the same mail through another smtp server
> I get this error message:
>
> ----- The following addresses had permanent fatal errors -----
> <[EMAIL PROTECTED]>
>
> ----- Transcript of session follows -----
> <[EMAIL PROTECTED]>... Deferred: Connection refused by mydomain.com.
First, let me repeat what I heard you say, to make sure we're on the
same page. You have qmail running on 'mydomain.com' (whatever that resolves
to.) When logged into 'mydomain.com', you can send mail to another user
just fine. When other machines try to deliver mail to 'mydomain.com',
however, they get the above error.
This implies that qmail-smtpd is not running and/or not listening
correctly on port 25. The "Connection refused" message usually means
exactly that.
You can test this theory by typing 'telnet mydomain.com 25' and
seeing if the connection is accepted or rejected.
If the connection is truly rejected, then find out why. Is
qmail-smtpd running (ps -auxwww | grep qmail-smtpd). If so, is it listening
to port 25 (look at the tcpserver command line, use 'lsof', or possibly
'netstat')?
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
I have a very simple question here that I'm discussing with a
local ISP about their POP3 server: Should the POP3 server send
or not the "Return-Path:" header and its contents when the
client issues the RETR command?
I've checked RFC 1939 and it only states that the server
should send the message ("the POP3 server sends the entire
message here"), but it isn't specific enough of what
constitutes "the entire message".
Dan's POP3 server *does* send the "Return-Path:" header (which
I would say is The Right Thing), but I sincerely don't know
what is the required behaviour.
Could anybody let me know of a definitive source of
information for this?
Thank you very much for any help, Roger...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
Nectar homepage: http://www.linux.ime.usp.br/~rbrito/nectar/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito <[EMAIL PROTECTED]> writes:
> I have a very simple question here that I'm discussing with a
> local ISP about their POP3 server: Should the POP3 server send
> or not the "Return-Path:" header and its contents when the
> client issues the RETR command?
>
> I've checked RFC 1939 and it only states that the server
> should send the message ("the POP3 server sends the entire
> message here"), but it isn't specific enough of what
> constitutes "the entire message".
IMHO, since the Return-Path is supposed to be added by the final
transport system that delivers the message to its recipient, it is a
part of the message.
> Dan's POP3 server *does* send the "Return-Path:" header (which
> I would say is The Right Thing), but I sincerely don't know
> what is the required behaviour.
>
> Could anybody let me know of a definitive source of
> information for this?
The closest I could get is RFC 822, paragraph 4.3.1. This specifies
the format for emails, and it most definitely includes the Return-Path
section.
--
"I live in the heart of the machine. We are one."
Particularly if the message may not have reached its final recipient, its
important that the Return-Path header be in place.
David
> -----Original Message-----
> From: Rogerio Brito [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 17, 2000 8:42 AM
> To: [EMAIL PROTECTED]
> Subject: Required POP3 behavior of RETR command/RFC 1939
>
>
>
> I have a very simple question here that I'm discussing with a
> local ISP about their POP3 server: Should the POP3 server send
> or not the "Return-Path:" header and its contents when the
> client issues the RETR command?
>
> I've checked RFC 1939 and it only states that the server
> should send the message ("the POP3 server sends the entire
> message here"), but it isn't specific enough of what
> constitutes "the entire message".
>
> Dan's POP3 server *does* send the "Return-Path:" header (which
> I would say is The Right Thing), but I sincerely don't know
> what is the required behaviour.
>
> Could anybody let me know of a definitive source of
> information for this?
>
>
> Thank you very much for any help, Roger...
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
> Nectar homepage: http://www.linux.ime.usp.br/~rbrito/nectar/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
Is there any way to change the queue time to where it will retry more often?
On Thu, Aug 17, 2000 at 11:12:30AM -0500, Shane Wise wrote:
> Is there any way to change the queue time to where it will retry more often?
No, I'm afraid not.
However, giving qmail-send and ALRM signal will cause all deferred
deliveries to be retried.
james
--
James Raftery (JBR54) - Programmer Hostmaster - IE TLD Hostmaster
IE Domain Registry - www.domainregistry.ie - (+353 1) 706 2375
"Managing 4000 customer domains with BIND has been a lot like
herding cats." - Mike Batchelor, on [EMAIL PROTECTED]
Shane Wise <[EMAIL PROTECTED]> writes on 17 August 2000 at 11:12:30 -0500
> Is there any way to change the queue time to where it will retry more often?
No. Why do you think you need this?
The current algorithm is essentially exponential backoff by host. It
tries more often at first, and gradually less often as the message
gets older, until eventually it gives up and bounces after one last
try.
Do you think you have something that's a general improvement on this?
Or special requirements?
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
The current algorithm is probably fine for most users, but what about
configuring the initial frequency? I can see some people being interested
in trying again in 5 or 30 seconds, and others wanting to wait a few hours.
----- Original Message -----
From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
> Shane Wise <[EMAIL PROTECTED]> writes on 17 August 2000 at
11:12:30 -0500
> > Is there any way to change the queue time to where it will retry more
often?
>
> No. Why do you think you need this?
>
> The current algorithm is essentially exponential backoff by host. It
> tries more often at first, and gradually less often as the message
> gets older, until eventually it gives up and bounces after one last
> try.
This doesn't even make sense, are you looking to configure a different time
period for different users?
This isn't even possible, or neccessary. This is not a feature that really
even affects a user. qmail will continue to deliver throughout the week in
the essentially exponential backoff by host algorithm.
----- Original Message -----
From: "Michael T. Babcock" <[EMAIL PROTECTED]>
To: "David Dyer-Bennet" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, August 17, 2000 10:23 AM
Subject: Re: Queue Time
> The current algorithm is probably fine for most users, but what about
> configuring the initial frequency? I can see some people being interested
> in trying again in 5 or 30 seconds, and others wanting to wait a few
hours.
>
> ----- Original Message -----
> From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
>
>
> > Shane Wise <[EMAIL PROTECTED]> writes on 17 August 2000 at
> 11:12:30 -0500
> > > Is there any way to change the queue time to where it will retry more
> often?
> >
> > No. Why do you think you need this?
> >
> > The current algorithm is essentially exponential backoff by host. It
> > tries more often at first, and gradually less often as the message
> > gets older, until eventually it gives up and bounces after one last
> > try.
>
>
On Thu, Aug 17, 2000 at 02:17:37PM -0700, Tim Hunter wrote:
> This doesn't even make sense, are you looking to configure a different time
> period for different users?
>
> This isn't even possible, or neccessary.
Hmm. I think this'd be a pretty useful feature actually.
If I send an email to mother saying "I'll be home for lunch" I'd like to tell my
MTA to drop/bounce the mail after that event has occurred. Likewise I'm sure that
e-letter establishments have different cutoff times for when a mailout should be
dropped - especially for very time-sensitive info.
I can't see much harm in being able to define the queuelifetime on an individual
submission - perhaps limited to between 0 and some multiple of control/queuelifetime.
Regards.
Date: Thu, 17 Aug 2000 11:32:00 -0700
From: [EMAIL PROTECTED]
On Thu, Aug 17, 2000 at 02:17:37PM -0700, Tim Hunter wrote:
> This doesn't even make sense, are you looking to configure a different time
> period for different users?
>
> This isn't even possible, or neccessary.
Hmm. I think this'd be a pretty useful feature actually.
If I send an email to mother saying "I'll be home for lunch" I'd like to tell my
MTA to drop/bounce the mail after that event has occurred. Likewise I'm sure that
e-letter establishments have different cutoff times for when a mailout should be
dropped - especially for very time-sensitive info.
I can't see much harm in being able to define the queuelifetime on an individual
submission - perhaps limited to between 0 and some multiple of
control/queuelifetime.
Setting queuelifetime isn't the same thing as controlling the backoff
algorithm. I personally agree that setting queuelifetime is useful.
I wrote up a patch to do that a while back:
http://www.ornl.gov/its/archives/mailing-lists/qmail/2000/05/msg00140.html
Ian
[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 17 August 2000 at 11:32:00 -0700
> I can't see much harm in being able to define the queuelifetime on
> an individual submission - perhaps limited to between 0 and some
> multiple of control/queuelifetime.
The harm is in the increased complexity of the queue itself, and in
the programs that manage and access it. Increased complexity costs in
reliability, security, and resources consumed.
I do agree that that feature has some benefit. I'm doubtful it's
worth the cost, but I have little idea what the cost would *actually*
be. Remember that there'd have to be some way to get the information
passed to the queueing engine, too.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
----- Original Message -----
From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 17 August 2000 at
11:32:00 -0700
>
> > I can't see much harm in being able to define the queuelifetime on
> > an individual submission - perhaps limited to between 0 and some
> > multiple of control/queuelifetime.
>
> The harm is in the increased complexity of the queue itself, and in
> the programs that manage and access it. Increased complexity costs in
> reliability, security, and resources consumed.
>
> I do agree that that feature has some benefit. I'm doubtful it's
> worth the cost, but I have little idea what the cost would *actually*
> be. Remember that there'd have to be some way to get the information
> passed to the queueing engine, too.
Oh come now. It may cost in speed. But it adds functionality. Any
functionality like this can be coded in a secure and reliable manner, so
those shouldn't be cited as reasons to avoid the issue.
From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
Date: Thu, 17 Aug 2000 13:49:00 -0500 (CDT)
[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 17 August 2000 at 11:32:00 -0700
> I can't see much harm in being able to define the queuelifetime on
> an individual submission - perhaps limited to between 0 and some
> multiple of control/queuelifetime.
The harm is in the increased complexity of the queue itself, and in
the programs that manage and access it. Increased complexity costs in
reliability, security, and resources consumed.
I do agree that that feature has some benefit. I'm doubtful it's
worth the cost, but I have little idea what the cost would *actually*
be. Remember that there'd have to be some way to get the information
passed to the queueing engine, too.
I think my patch shows the actual cost of this feature. It is
non-zero, but is not high.
The information is passed via the environment variable
QMAILQUEUELIFETIME to qmail-inject, which uses a new code (L) in the
todo file. qmail-send moves this new code over to the info file, and
honors it when bouncing messages.
Ian
On Thu, Aug 17, 2000 at 11:59:08AM -0700, Ian Lance Taylor wrote:
> From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
> Date: Thu, 17 Aug 2000 13:49:00 -0500 (CDT)
>
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 17 August 2000 at 11:32:00 -0700
>
> > I can't see much harm in being able to define the queuelifetime on
> > an individual submission - perhaps limited to between 0 and some
> > multiple of control/queuelifetime.
>
> The harm is in the increased complexity of the queue itself, and in
> the programs that manage and access it. Increased complexity costs in
> reliability, security, and resources consumed.
>
> I do agree that that feature has some benefit. I'm doubtful it's
> worth the cost, but I have little idea what the cost would *actually*
> be. Remember that there'd have to be some way to get the information
> passed to the queueing engine, too.
>
> I think my patch shows the actual cost of this feature. It is
> non-zero, but is not high.
>
> The information is passed via the environment variable
> QMAILQUEUELIFETIME to qmail-inject, which uses a new code (L) in the
> todo file. qmail-send moves this new code over to the info file, and
> honors it when bouncing messages.
Hmm. A more devious hack might be to adjust the mtime of the info file to be
time() + QMAILQUEUELIFETIME - control/queuelifetime. The cost would be
much closer to zero then - albeit at the cost of a misleading info file...
Regards.
Michael T. Babcock <[EMAIL PROTECTED]> writes on 17 August 2000 at 14:52:40 -0400
>
> ----- Original Message -----
> From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
>
>
> > [EMAIL PROTECTED] <[EMAIL PROTECTED]> writes on 17 August 2000 at
> 11:32:00 -0700
> >
> > > I can't see much harm in being able to define the queuelifetime on
> > > an individual submission - perhaps limited to between 0 and some
> > > multiple of control/queuelifetime.
> >
> > The harm is in the increased complexity of the queue itself, and in
> > the programs that manage and access it. Increased complexity costs in
> > reliability, security, and resources consumed.
> >
> > I do agree that that feature has some benefit. I'm doubtful it's
> > worth the cost, but I have little idea what the cost would *actually*
> > be. Remember that there'd have to be some way to get the information
> > passed to the queueing engine, too.
>
> Oh come now. It may cost in speed. But it adds functionality. Any
> functionality like this can be coded in a secure and reliable manner, so
> those shouldn't be cited as reasons to avoid the issue.
I'm not an expert on software complexity and error probabilities. But
what you've just said is someting I understand to be a very common
misconception. Features add complexity. Complexity adds chances for
things to go wrong in unexpected ways. Even apparently simple,
isolated, features. But to get deeper analysis and more detail, you'd
need to find somebody more knowledgable than me; I know the results
more than the evidence.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
Date: Thu, 17 Aug 2000 12:07:24 -0700
From: [EMAIL PROTECTED]
> The information is passed via the environment variable
> QMAILQUEUELIFETIME to qmail-inject, which uses a new code (L) in the
> todo file. qmail-send moves this new code over to the info file, and
> honors it when bouncing messages.
Hmm. A more devious hack might be to adjust the mtime of the info file to be
time() + QMAILQUEUELIFETIME - control/queuelifetime. The cost would be
much closer to zero then - albeit at the cost of a misleading info file...
The problem is that the information has to get from qmail-inject to
the info file. qmail-inject creates a todo file. It is qmail-send
which reads the todo file, and creates the info file. So the
information must be recorded in the todo file in some fashion. It
could be done by fiddling the mtime of the todo file, and having
qmail-send copy the mtime of the todo file over to the info file. But
I don't think that is significantly cheaper than what I implemented.
Also it would make the qmail-qread output misleading.
Ian
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 17, 2000 at 02:17:37PM -0700, Tim Hunter wrote:
> > This doesn't even make sense, are you looking to configure a different time
> > period for different users?
> >
> > This isn't even possible, or neccessary.
>
> Hmm. I think this'd be a pretty useful feature actually.
>
> If I send an email to mother saying "I'll be home for lunch" I'd like to tell my
> MTA to drop/bounce the mail after that event has occurred.
One frequently-proposed (and possibly implemented) solution for such
time-critical email is to avoid queuing the message in the first place.
Instead, you call qmail-remote directly with your message. If it succeeds,
you know immediately that the message reached the MX you pointed it at.
If it fails -- then you can queue it, if you think it might still get there
before the information is obsolete.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
On Thu, Aug 17, 2000 at 12:13:11PM -0700, Ian Lance Taylor wrote:
> Date: Thu, 17 Aug 2000 12:07:24 -0700
> From: [EMAIL PROTECTED]
>
> > The information is passed via the environment variable
> > QMAILQUEUELIFETIME to qmail-inject, which uses a new code (L) in the
> > todo file. qmail-send moves this new code over to the info file, and
> > honors it when bouncing messages.
>
> Hmm. A more devious hack might be to adjust the mtime of the info file to be
> time() + QMAILQUEUELIFETIME - control/queuelifetime. The cost would be
> much closer to zero then - albeit at the cost of a misleading info file...
>
> The problem is that the information has to get from qmail-inject to
> the info file. qmail-inject creates a todo file. It is qmail-send
> which reads the todo file, and creates the info file. So the
> information must be recorded in the todo file in some fashion. It
> could be done by fiddling the mtime of the todo file, and having
> qmail-send copy the mtime of the todo file over to the info file. But
> I don't think that is significantly cheaper than what I implemented.
>
> Also it would make the qmail-qread output misleading.
Agreed. Off tangent, how does an SMTP submission get at this feature? Interestingly,
it should probably be something that each MTA knows about to be truly useful,
consider secondary MXes gateway systems, etc. Ahh, a change in SMTP - fat chance!
Regards.
> > If I send an email to mother saying "I'll be home for lunch" I'd like to tell my
> > MTA to drop/bounce the mail after that event has occurred.
>
> One frequently-proposed (and possibly implemented) solution for such
> time-critical email is to avoid queuing the message in the first place.
> Instead, you call qmail-remote directly with your message. If it succeeds,
> you know immediately that the message reached the MX you pointed it at.
> If it fails -- then you can queue it, if you think it might still get there
> before the information is obsolete.
That might help the >0.1% of the population that composes and submits email
on a Unix system that has qmail-remote installed, but what of the other poor
sods?
Regards.
[EMAIL PROTECTED] wrote:
>Hmm. A more devious hack might be to adjust the mtime of the info file to be
>time() + QMAILQUEUELIFETIME - control/queuelifetime. The cost would be
>much closer to zero then - albeit at the cost of a misleading info file...
And qmail-send would be using the tail end of the usual retry
schedule, not the front end.
-Dave
----- Original Message -----
From: "Charles Cazabon" <[EMAIL PROTECTED]>
> > If I send an email to mother saying "I'll be home for lunch" I'd like to
tell my
> > MTA to drop/bounce the mail after that event has occurred.
>
> One frequently-proposed (and possibly implemented) solution for such
> time-critical email is to avoid queuing the message in the first place.
> Instead, you call qmail-remote directly with your message. If it
succeeds,
> you know immediately that the message reached the MX you pointed it at.
> If it fails -- then you can queue it, if you think it might still get
there
> before the information is obsolete.
... on which note ... how much of a hack would it be to qmail-inject to add
this as an option?
Date: Thu, 17 Aug 2000 12:21:33 -0700
From: [EMAIL PROTECTED]
Off tangent, how does an SMTP submission get at this feature? Interestingly,
it should probably be something that each MTA knows about to be truly useful,
consider secondary MXes gateway systems, etc. Ahh, a change in SMTP - fat chance!
Yes, doing this properly would require an SMTP extension. I think it
could be fairly easily added to the DSN extension in RFC 1891. (Of
course, qmail doesn't support DSN.)
Ian
Michael T. Babcock <[EMAIL PROTECTED]> wrote:
> > One frequently-proposed (and possibly implemented) solution for such
> > time-critical email is to avoid queuing the message in the first place.
> > Instead, you call qmail-remote directly with your message. If it succeeds,
> > you know immediately that the message reached the MX you pointed it at. If
> > it fails -- then you can queue it, if you think it might still get there
> > before the information is obsolete.
> ... on which note ... how much of a hack would it be to qmail-inject to add
> this as an option?
Not a hack at all. Don't touch the qmail-inject code; instead, write a
wrapper around it (in Python, Perl, or even C). Try qmail-remote; check it's
exit code, and if necessary, call /var/qmail/bin/qmail-inject-orig or
whatever you move the 'real' qmail-inject to. Make sure you return the
same exit codes that the real one does, or you'll confuse qmail when it's
injecting bounce messages and such.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > One frequently-proposed (and possibly implemented) solution for such
> > time-critical email is to avoid queuing the message in the first place.
> > Instead, you call qmail-remote directly with your message. If it succeeds,
> > you know immediately that the message reached the MX you pointed it at. If
> > it fails -- then you can queue it, if you think it might still get there
> > before the information is obsolete.
> That might help the >0.1% of the population that composes and submits email
> on a Unix system that has qmail-remote installed, but what of the other poor
> sods?
They're out of luck; they're trying to do reliable, realtime communication
with a protocol which was never designed for either. They need to either
change their tools, change their requirements, or pick up the phone.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
On Thu, Aug 17, 2000 at 03:27:35PM -0400, Dave Sill wrote:
> [EMAIL PROTECTED] wrote:
>
> >Hmm. A more devious hack might be to adjust the mtime of the info file to be
> >time() + QMAILQUEUELIFETIME - control/queuelifetime. The cost would be
> >much closer to zero then - albeit at the cost of a misleading info file...
>
> And qmail-send would be using the tail end of the usual retry
> schedule, not the front end.
Yeah, but apart from these really good counterpoints, what else is wrong with
my suggestion? (with apologies to Mr Cleese).
Regards.
why not just run 2 instances of qmail. one w/ a queuelifetime of a few
days or a week and one with a lifetime of a few hours. if it has to go
out and can't it'll end up bouncing out of the queue quickly. it'll be
queued often in that short amount of time as desired.
--
Michael Boyiazis
[EMAIL PROTECTED]
Mail Architect, NetZero, Inc.
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
On Thu, Aug 17, 2000 at 02:39:11PM -0700, M.B. wrote:
> why not just run 2 instances of qmail. one w/ a queuelifetime of a few
> days or a week and one with a lifetime of a few hours. if it has to go
> out and can't it'll end up bouncing out of the queue quickly. it'll be
> queued often in that short amount of time as desired.
So if lunch is four hours away I need a four-hour queue,
if lunch is six hours away, I also need a six-hour queue,
if lunch is two days away, I also need a two-day queue,
and if I happen to send it an hour earlier than usual, I need a five-hour queue,
a seven hour queue and a two-days+one-hour queue.
If you only go to an hour granularity and assume a queuelifetime of no
more than seven days, then you only need 168 instances. I was kinda thinking
of something a little more elegant than that...
Regards.
[EMAIL PROTECTED] wrote:
>
> If you only go to an hour granularity and assume a queuelifetime of no
> more than seven days, then you only need 168 instances. I was kinda thinking
> of something a little more elegant than that...
How about using Netscape's X-Priority header to set the queue lifetime
according to the admin's wishes. Set 5 different queue lifetimes
according to based on the 5 settings of the X-Priority header. This
could be accomplished with Ian's patch, and some preprocessing before
qmail-inject.
Eric
On Aug 17 2000, David Dyer-Bennet wrote:
> The harm is in the increased complexity of the queue itself, and in
> the programs that manage and access it. Increased complexity costs
> in reliability, security, and resources consumed.
As far as I can see (but I may be wrong here), there's no
increased complexity. Just change a function in qmail-send.c
and your new version of qmail, with a different retry schedule
is there, brand spanking new.
The function's name is nextretry (and it is quite short).
BUT, before changing qmail's retry schedule, please read the
comments that Dan has put on THOUGHTS (which I reproduce
below).
BTW, Dan, where could I read more about optimal schedules? I'm
particularly interested in learning more about the following
paragraph of yours (I'm not very experienced on Statistics,
but I'm willing to learn more about it):
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mathematical amusement: The optimal retry schedule is essentially,
though not exactly, independent of the actual distribution of message
delay times. What really matters is how much cost you assign to retries
and to particular increases in latency. qmail's current quadratic retry
schedule says that an hour-long delay in a day-old message is worth the
same as a ten-minute delay in an hour-old message; this doesn't seem so
unreasonable.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Any references would be greatly appreciated.
Thanks for any information, Roger...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
Nectar homepage: http://www.linux.ime.usp.br/~rbrito/nectar/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Aug 17 2000, David Dyer-Bennet wrote:
> The current algorithm is essentially exponential backoff by host.
I don't think so. qmail uses a quadratic schedule for
deliveries (both local and remote, with the difference being
the coefficient of the quadratic function -- a function of the
number of retires; the coefficients are 10^2 for local
deliveries and 20^2 for remote deliveries).
I've posted this to the list some time ago and Dave Sill's
excellent document also contains a discussion about this. I
guess that he could post the formula of next retry in a next
version of his document.
[]s, Roger...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
Nectar homepage: http://www.linux.ime.usp.br/~rbrito/nectar/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito <[EMAIL PROTECTED]> writes on 17 August 2000 at 22:20:26 -0300
> On Aug 17 2000, David Dyer-Bennet wrote:
> > The harm is in the increased complexity of the queue itself, and in
> > the programs that manage and access it. Increased complexity costs
> > in reliability, security, and resources consumed.
>
> As far as I can see (but I may be wrong here), there's no
> increased complexity. Just change a function in qmail-send.c
> and your new version of qmail, with a different retry schedule
> is there, brand spanking new.
I'd agree for simply changing the schedule (assuming the new algorithm
isn't more complicated). My response was to a proposal for making the
schedule *variable* by message.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
On Aug 17 2000, David Dyer-Bennet wrote:
> I'd agree for simply changing the schedule (assuming the new
> algorithm isn't more complicated). My response was to a proposal
> for making the schedule *variable* by message.
Oh, sorry for responding to a different matter (I confess that
I read that pretty quickly without paying as much attention as
I should).
I'd imagine that yes, each message having its own retry
schedule would really blow the complexity without limits (each
message having a data structure to describe its schedule?)
So, we do agree on that. And I just love the KISS principle.
[]s, Roger...
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
Nectar homepage: http://www.linux.ime.usp.br/~rbrito/nectar/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Ricardo Albano" <[EMAIL PROTECTED]> writes:
> Hello, I was installed a NETRA T1 Server with RH6.2/sparc and QMAIL-1.03, When I put
>my new box in production I get tons of errors in my console like this :
>
> eth0: Link is up using external transceiver at 100Mb/s, Half Duplex.
> eth0: Error interrupt for happy meal, status = 00000400
> eth0: Happy Meal MAX Packet size error.
> eth0: Resetting...
That would indicate that you are having a problem with the network
interface. (Solaris calls this hme0; there's a story that the Sun
engineers actually call the 100Mb interfaces "happy meal", but I won't
vouch for the veracity...).
> Any know if this is a common problem ?
I've seen problems with Netras when I've neglected to install the
proper patches to Solaris, but since I've never used Linux on anything
other than a PC, I wouldn't know whether the problem is common there.
In any case it's certainly not a qmail-related problem. You might get
better answers in a Linux-related newsgroup or mailinglist.
--
"I live in the heart of the machine. We are one."
On Wed, Aug 16, 2000 at 11:05:51PM -0300, Ricardo Albano wrote:
> Hello, I was installed a NETRA T1 Server with RH6.2/sparc and
> QMAIL-1.03, When I put my new box in production I get tons of errors
> in my console like this :
check your ethernet configuration.
"Happy Meal" is the name for the SUN hme device. That error message:
> eth0: Link is up using external transceiver at 100Mb/s, Half Duplex.
> eth0: Error interrupt for happy meal, status = 00000400
> eth0: Happy Meal MAX Packet size error.
means: Driver error, tried to transmit something larger than ethernet
max mtu.
That may be an configuration problem (MTU too large?).
> Any know if this is a common problem ?
i don't know.
Regards, Uwe
Quoting Dale Miracle ([EMAIL PROTECTED]):
> "Ihnen, David" wrote:
[...]
> > SO - My conclusion is that the system *MUST* be talking to some other
> > service, than qmail-smtpd, or it would say something more like "syntax error
> > (#5.5.4)" or "out of memory (#4.3.0)", rather than just "4.7.1".
> >
> > Troubleshoot the client's settings and the IP path. Maybe its trading off
> > to different smtp servers? Maybe the dns or IP he's going to maps to more
> > than one server?
> >
> > Of course, my source analysis may be flawed, and I invite all to look it
> > over.
> >
> > Netscape source: http://lxr.mozilla.org/seamonkey/search
> >
> > David (who is having more fun that he probably is allowed to.)
>
> Thanks for looking that up. I set my concurrency remote to 120 so that
> should take care of the back log during busy periods. Hopefully that
> will also get rid of this problem. I talked with the user and he ok
Your concurrency remote setting has no bearing on how many smtp
connections tcpserver will allow. Also, tcpserver does not output
smtp status codes when it reaches its configured connection limit (set
with the "-c" switch). That's why I feel special attention should be
paid to the paragraph written by Mr. Ihnen that I've quoted above.
Aaron
"Aaron L. Meehan" wrote:
>
> Quoting Dale Miracle ([EMAIL PROTECTED]):
> > "Ihnen, David" wrote:
> [...]
> > > SO - My conclusion is that the system *MUST* be talking to some other
> > > service, than qmail-smtpd, or it would say something more like "syntax error
> > > (#5.5.4)" or "out of memory (#4.3.0)", rather than just "4.7.1".
> > >
> > > Troubleshoot the client's settings and the IP path. Maybe its trading off
> > > to different smtp servers? Maybe the dns or IP he's going to maps to more
> > > than one server?
> > >
> > > Of course, my source analysis may be flawed, and I invite all to look it
> > > over.
> > >
> > > Netscape source: http://lxr.mozilla.org/seamonkey/search
> > >
> > > David (who is having more fun that he probably is allowed to.)
> >
> > Thanks for looking that up. I set my concurrency remote to 120 so that
> > should take care of the back log during busy periods. Hopefully that
> > will also get rid of this problem. I talked with the user and he ok
>
> Your concurrency remote setting has no bearing on how many smtp
> connections tcpserver will allow. Also, tcpserver does not output
> smtp status codes when it reaches its configured connection limit (set
> with the "-c" switch). That's why I feel special attention should be
> paid to the paragraph written by Mr. Ihnen that I've quoted above.
I know the remote setting and how many connection tcpserver will allow
have no bearing.
I was having two problems, 1. my queue at times was backing up to much
max'ing out my deliveries. 2. A user was getting an error in netscape
when he tried to send mail but didn't happen very frequently (about 10
times last month and about half that this month so far).
I agree with Mr. Ihnen conclusion and was merely stating that for my one
problem I raised my concurrency remote to 120 and I was saying (with
fingers crossed) that I hope this problem will go away but knowing that
it is most likely something else entirely. Sort of like a 2 for 1 fix
which doesn't happen often enough...normally its like fix one problem
break something else. ;)
I have done some research and have found this in my maillog. He uses
the aol dialup e-mail for junk e-mail and etc but uses mine as his
primary e-mail source. I have sent him some mail to his e-mail address
and found this error while delivering his mail in the maillog. I know
they defer quite bit of mail from time to time but I have never see dns
failure messages. Problem with aol mail servers is a given and widely
known, a great part of my back log at time is all the mail going to aol.
Aug 15 22:14:31 atlas qmail: 966392071.402535 starting delivery 662: msg
28806 to remote [EMAIL PROTECTED]
Aug 15 22:14:31 atlas qmail: 966392071.404950 status: local 0/10 remote
1/20
Aug 15 22:14:48 atlas qmail: 966392088.232922 delivery 662: deferral:
Connected_to_152.163.224.66_but_sender_was_rejected./Remote_host_said:_421_SERVICE_NOT_AVAILABLE,_TEMPORARY_DNS_FAILURE/
Aug 15 22:14:48 atlas qmail: 966392088.234289 status: local 0/10 remote
0/20
I have searched through the mail log and only aol has this error,
actually I don't many deferal's mostly aol and Time warner cable's cable
modem service (or dis service as some call it) are pretty much the only
ones. So it looks like they have a dns problem some where in their
system and it could possibly affect the dialup connections.
I am going to keep an eye on this problem and see what happens. I asked
the guy to let me know with date, times and ip address if he has a
problem again. I looked at his settings and they look fine. I think it
is probably as David pointed out an ip route or dns fault.
--
Dale Miracle
System Administrator
Teoi Virtual Web Hosting
Dale Miracle <[EMAIL PROTECTED]> writes:
> Aug 15 22:14:31 atlas qmail: 966392071.402535 starting delivery 662: msg
> 28806 to remote [EMAIL PROTECTED]
> Aug 15 22:14:31 atlas qmail: 966392071.404950 status: local 0/10 remote
> 1/20
> Aug 15 22:14:48 atlas qmail: 966392088.232922 delivery 662: deferral:
>
>Connected_to_152.163.224.66_but_sender_was_rejected./Remote_host_said:_421_SERVICE_NOT_AVAILABLE,_TEMPORARY_DNS_FAILURE/
> Aug 15 22:14:48 atlas qmail: 966392088.234289 status: local 0/10 remote
> 0/20
>
> I have searched through the mail log and only aol has this error,
> actually I don't many deferal's mostly aol and Time warner cable's cable
> modem service (or dis service as some call it) are pretty much the only
> ones. So it looks like they have a dns problem some where in their
> system and it could possibly affect the dialup connections.
> I am going to keep an eye on this problem and see what happens. I asked
> the guy to let me know with date, times and ip address if he has a
> problem again. I looked at his settings and they look fine. I think it
> is probably as David pointed out an ip route or dns fault.
This is due to AOL returning too big a DNS record when you query for
their MX. There are basically two solutions to this - either apply a
patch, which you'll find on the qmail web site, or set up a static
route to the AOL MX of your choice. The latter solution is of course
subject to problems should AOL discontinue the use of the MX you've
chosen.
--
"I live in the heart of the machine. We are one."
Hi everyone. I have a strange occurance with my first qmail server ever
installed, so I appologize if this is a stupid question.
Up until today I was running eight different domains off the system
flawlessly. This morning I added a ninth customer and sent them off on
their way to the website interface.
About 15 minutes ago the machine had a load of 48+ and everything came to
a crawl. It appears I had about 75+ instances of tcprules running and a
mysqld for each tcprules process.
Being new to qmail I'm a bit confused as to what to do next. This has
basically brought my machine to a halt. I stopped qmail, killed all the
tcprules processes and restart it. The machine instantly became fast, but
it seems to have gone right back into that loop.
Is there something simple I'm missing? Incidentally I am utilzing mysql
based authentication. If I missed something in a FAQ or Document just
point me there. I'm really thrown off because this system has been stable
for well over a month and this is the first "issue".
-jeff
I might be wrong since I do not use mysql, but my guess would be that the
new domain admin is adding users, apparently too fast for your machine to
process.
Each time a new user is added it attempts to recompile the vpasswd file to
cdb; correct?
Check what the tcprules process it doing, it should tell you.
-- Tim
----- Original Message -----
From: "Jeff Garvas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 17, 2000 10:16 AM
Subject: looping tcprules ?
>
> Hi everyone. I have a strange occurance with my first qmail server ever
> installed, so I appologize if this is a stupid question.
>
> Up until today I was running eight different domains off the system
> flawlessly. This morning I added a ninth customer and sent them off on
> their way to the website interface.
>
> About 15 minutes ago the machine had a load of 48+ and everything came to
> a crawl. It appears I had about 75+ instances of tcprules running and a
> mysqld for each tcprules process.
>
> Being new to qmail I'm a bit confused as to what to do next. This has
> basically brought my machine to a halt. I stopped qmail, killed all the
> tcprules processes and restart it. The machine instantly became fast, but
> it seems to have gone right back into that loop.
>
> Is there something simple I'm missing? Incidentally I am utilzing mysql
> based authentication. If I missed something in a FAQ or Document just
> point me there. I'm really thrown off because this system has been stable
> for well over a month and this is the first "issue".
>
> -jeff
>
>
>
The user only had five email addresses to add, no where near the 75
processes I've had running.
Should tcprules be running once per instance?
Is a mysqld process spawned for each user authentication?
That sounds a bit extreme if not absurd. I could understand if a client
was being invoked, but not a daemon process for each request.
I'm somehow back down to just one tcprules process with what appears to be
a single associated mysqld process (they're a single pid apart)
-jeff
On Thu, 17 Aug 2000, Tim Hunter wrote:
> I might be wrong since I do not use mysql, but my guess would be that the
> new domain admin is adding users, apparently too fast for your machine to
> process.
>
> Each time a new user is added it attempts to recompile the vpasswd file to
> cdb; correct?
>
> Check what the tcprules process it doing, it should tell you.
>
> -- Tim
> ----- Original Message -----
> From: "Jeff Garvas" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, August 17, 2000 10:16 AM
> Subject: looping tcprules ?
>
>
> >
> > Hi everyone. I have a strange occurance with my first qmail server ever
> > installed, so I appologize if this is a stupid question.
> >
> > Up until today I was running eight different domains off the system
> > flawlessly. This morning I added a ninth customer and sent them off on
> > their way to the website interface.
> >
> > About 15 minutes ago the machine had a load of 48+ and everything came to
> > a crawl. It appears I had about 75+ instances of tcprules running and a
> > mysqld for each tcprules process.
> >
> > Being new to qmail I'm a bit confused as to what to do next. This has
> > basically brought my machine to a halt. I stopped qmail, killed all the
> > tcprules processes and restart it. The machine instantly became fast, but
> > it seems to have gone right back into that loop.
> >
> > Is there something simple I'm missing? Incidentally I am utilzing mysql
> > based authentication. If I missed something in a FAQ or Document just
> > point me there. I'm really thrown off because this system has been stable
> > for well over a month and this is the first "issue".
> >
> > -jeff
> >
> >
> >
>
Jeff Garvas <[EMAIL PROTECTED]> wrote:
>
> The user only had five email addresses to add, no where near the 75
> processes I've had running.
Sounds more like a script which is looping due to an uncaught error
somewhere, or a return value not understood. We don't know enough about
your setup to tell you more.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
What is the correct way to configure a secondary MX machine (qmail using
qmqp) so that the messages are sent with the standard exponential backoff
until '24 hours', and then every day for two weeks?
I've been asked to secondary a machine that is down sometimes for extended
periods of time (they won't upgrade, but they'll pay us to host secondary
...) and they don't want to lose their mail.
Michael T. Babcock <[EMAIL PROTECTED]> writes on 17 August 2000 at 13:30:37 -0400
> What is the correct way to configure a secondary MX machine (qmail using
> qmqp) so that the messages are sent with the standard exponential backoff
> until '24 hours', and then every day for two weeks?
>
> I've been asked to secondary a machine that is down sometimes for extended
> periods of time (they won't upgrade, but they'll pay us to host secondary
> ...) and they don't want to lose their mail.
One way is to configure that domain as virtual on the secondary, and
direct it all into a maildir. Then run maildirsmtp (or maildirqmtp)
on the maildir under cron or other control to make attempts at
delivery to the primary on whatever schedule you want.
Remember that a small amount of mail will end up at the secondary even
when the primary is actually up, due to connectivity and DNS
flakiness; so you need a system that delivers that mail fairly
promptly. You can't, for example (as I wanted to before I realized
this problem), hold the mail and require a manual trigger to deliver
it.
--
Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon
Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b
David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]
----- Original Message -----
From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
> Michael T. Babcock <[EMAIL PROTECTED]> writes on 17 August 2000 at
13:30:37 -0400
> > What is the correct way to configure a secondary MX machine (qmail
using
> > qmqp) so that the messages are sent with the standard exponential
backoff
> > until '24 hours', and then every day for two weeks?
> >
> One way is to configure that domain as virtual on the secondary, and
> direct it all into a maildir. Then run maildirsmtp (or maildirqmtp)
> on the maildir under cron or other control to make attempts at
> delivery to the primary on whatever schedule you want.
>
> Remember that a small amount of mail will end up at the secondary even
> when the primary is actually up, due to connectivity and DNS
> flakiness; so you need a system that delivers that mail fairly
> promptly. You can't, for example (as I wanted to before I realized
> this problem), hold the mail and require a manual trigger to deliver
> it.
Right ... because of ignorance of preference levels and/or the primary
simply rejecting a connection because of tcpserver hitting its max.
That said, there's no way to do this more ... integrated-ly with QMQP
without having the exponential failure rate increase and bounces?
Hi all,
Long story short here. I need to convince a business partner's admin that
we are correct in sending their users bounce messages with a null envelope
sender.
The partner is using Exchange and they are relaying a bounce message from
us to one of their internal non-M$ systems and rewriting the envelope
sender to <unknown>. M$ acknowledges the problem, it is documented. The
partner admins will refute the M$ document (it has happened before!) and
continue to assert that our MTA is to fault for this. I hate doing other
people's work.
Now, we all know that's the correct way to do it, but I went to RFC821 to
back me up. RFC821 states that this is "permissible". Fair enough - if it's
"permissible" then a compliant MTA that receives such a message should be
able to deliver or relay as appropriate. Permissible implies to me that you
may choose to use that feature, but you MUST support it when used by
another MTA delivering a message to yours. I think my argument is sound
here.
My real question is the reference in 821 (page 15) that the sender
(apparantly header sender) is server-SMTP. Now typically this is
mailer-daemon. Does this RFC really say that I should be using some form of
`cat /var/qmail/control/me`-SMTP instead? I really don't think it matters
in practice, but I want to have my ducks in a row when I take my position.
Bottom line: Should I change my bouncefrom if I want to stand by the RFC
100%?
Josh Tibbs
Kendle International
On Thu, Aug 17, 2000 at 01:28:57PM -0400, [EMAIL PROTECTED] wrote:
> may choose to use that feature, but you MUST support it when used by
> another MTA delivering a message to yours. I think my argument is sound
> here.
RFC1123, section 5.2.9: "An empty reverse path MUST be supported.".
Regards,
james
--
James Raftery (JBR54) - Programmer Hostmaster - IE TLD Hostmaster
IE Domain Registry - www.domainregistry.ie - (+353 1) 706 2375
"Managing 4000 customer domains with BIND has been a lot like
herding cats." - Mike Batchelor, on [EMAIL PROTECTED]
On Thu, Aug 17, 2000 at 06:57:18PM +0100, James Raftery wrote:
> RFC1123, section 5.2.9: "An empty reverse path MUST be supported.".
Apologies for following my own message...
Section 5.3.3 is probably more useful:
"If there is a delivery failure after acceptance of a message,
the receiver-SMTP MUST formulate and mail a notification
message. This notification MUST be sent using a null ("<>")
reverse path in the envelope; see Section 3.6 of RFC-821."
james
--
James Raftery (JBR54) - Programmer Hostmaster - IE TLD Hostmaster
IE Domain Registry - www.domainregistry.ie - (+353 1) 706 2375
"Managing 4000 customer domains with BIND has been a lot like
herding cats." - Mike Batchelor, on [EMAIL PROTECTED]
Hi,
I'd like to block any email sent to my host using Multimailer, since it's a
well kown program widely used to send SPAM.
The header line that identifies Multimailer is: X-Mailer: MultiMailer (3.1.0)
I'm using qmail 1.03 with tcpserver with syslog logging.
How can this be done? thanks.. really.
Enrique-
----- Original Message -----
From: "Mate Wierdl" <[EMAIL PROTECTED]>
> On Wed, Aug 16, 2000 at 09:55:53AM -0500, Ben Beuchler wrote:
> > On Wed, Aug 16, 2000 at 07:08:28AM -0500, Mate Wierdl wrote:
> >
> > That would not allow for the rapid changes necessary in a blackhole
> > list. Imagine you are an ISP with several thousand customers. Through
> > an oversight, your mail server is blacklisted. Would you rather wait
> > for the tens or hundreds of thousands of sysadmins out there
> > administering mail servers to remove you from their blackhole list or
> > just submit it to the maintainer of the list and have it fixed in minute
> > or hours?
>
> The fact is a few thousand mail servers running rblsmtpd cannot use
> relays.mail-abuse.org. So now they all have to apply for a domain so
> that they can use rbldns. Or they can start patching rblsmtpd to use
> A records---until relays.mail-abuse.org will change the record
> structure again.
The best approach to this is to have rblsmtpd use A records, as it should
have from the beginning (that's what you get for optimising solely for
speed, not for correctness).
On Thu, Aug 17, 2000 at 06:34:21PM -0400, Michael T. Babcock wrote:
> The best approach to this is to have rblsmtpd use A records, as it should
> have from the beginning (that's what you get for optimising solely for
> speed, not for correctness).
But then the TXT record is really useful: it does give a clue to the
client how to get out of the mess.
Mate
Hi!
Just a little question ;-)
My box running qmail 1.03 was primary designed to host lot of mails for
virtualdomains... so I installed vpopmail and I am happy with it.
But now I am creating more and more accounts NOT into virtualhost. I
explain : my box is joke.xinus.net and I am creating @xinus.net accounts,
and I don't want to create via adduser for each new user, so can I admin
@xinus.net emails like virtualhosts ?
I hope you understood me ! Thanks !
_______________
Dimitri SZAJMAN
Dimitri SZAJMAN wrote:
>
> Hi!
>
> Just a little question ;-)
> My box running qmail 1.03 was primary designed to host lot of mails for
> virtualdomains... so I installed vpopmail and I am happy with it.
>
> But now I am creating more and more accounts NOT into virtualhost. I
> explain : my box is joke.xinus.net and I am creating @xinus.net accounts,
> and I don't want to create via adduser for each new user, so can I admin
> @xinus.net emails like virtualhosts ?
>
> I hope you understood me ! Thanks !
>
> _______________
> Dimitri SZAJMAN
You could just do what I do and that is make all domains virtual even
your own. That way you have all the domains under one directory tree
and all the passwords and etc is handled by vpopmail. That way you can
use vpopbull and send out mass e-mail to all users on the box if you
have to. I think it works out better then just using the vpopmail just
for virtual hosts.
Making your own domain virtual makes it so you don't have as many or any
accounts in the systems own passwd file (beyond root and one user
account that you can use to su to root with) which means if there isn't
an account there then no one can try to gain access using it. If
someone would happen to get a password from pop3 it would only let them
send mail and not get into your box. This adds some security to your
box and allows easier management.
This is one way of doing what you want I would imagine there are other
ways but I think this way works best for me. I hope this is what you
are talking about.
Take Care,
--
Dale Miracle
System Administrator
Teoi Virtual Web Hosting
This would be better talked about on the vpopmail list but you can just
compile vpopmail with default host of xinus.net and have them login as
normal. As soon as you recreate all the users.
-- Tim
----- Original Message -----
From: Dimitri SZAJMAN <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 17, 2000 4:28 PM
Subject: Lot of accounts...
> Hi!
>
> Just a little question ;-)
> My box running qmail 1.03 was primary designed to host lot of mails for
> virtualdomains... so I installed vpopmail and I am happy with it.
>
> But now I am creating more and more accounts NOT into virtualhost. I
> explain : my box is joke.xinus.net and I am creating @xinus.net accounts,
> and I don't want to create via adduser for each new user, so can I admin
> @xinus.net emails like virtualhosts ?
>
> I hope you understood me ! Thanks !
>
>
> _______________
> Dimitri SZAJMAN
>
Hi,
does anyone know if the dir numbering scheme (0..22) for some of
qmail's queue subdirs sits follows some logic?
Thanks,
Kai
On Thu, Aug 17, 2000 at 07:00:22PM -0700, Kai Peters wrote:
>
> Hi,
>
> does anyone know if the dir numbering scheme (0..22) for some of
> qmail's queue subdirs sits follows some logic?
It's an arithmetic serie ;-)
Formula: a(n)=n; a(0) = 0, a(n) = a(n-1)+1; G.f.: x/(1-x)^2.
Jokes aside,
First: It's 0..22 per default, since conf-split contains 23 per default.
Yor milage may vary.
See hier.c for creation function "void dsplit(base,uid,mode)".
See fmtqfn.c for queue filename format function "unsigned int
fmtqfn(s,dirslash,id,flagsplit)"
See qmail-showctl.c and readsubdir.c for use of auto_split.
See qmail-qread for examples how to read the queue.
[Note: qmail-queue, qmail-send and qmail-clean also uses fmtqfn()]
/magnus
--
http://x42.com/
Someone enlightened me of a very helpful qmail command that took a local
email address as an argument, and then it spat out the path to where it
would delivery the message... except I can't recall the command and I've
lost that email, and (of course) can't remember who sent it.
I'm having some difficulties trouble shooting a mail delivery problem for
one of our users, and I'm sure the output of this command (whatever it is)
would be most helpful. If you happen to have a guess, please let me know.
Duane L - [EMAIL PROTECTED] -
On Thu, Aug 17, 2000 at 09:30:34PM -0700, Duane L. wrote:
> Someone enlightened me of a very helpful qmail command that took a local
> email address as an argument, and then it spat out the path to where it
> would delivery the message... except I can't recall the command and I've
> lost that email, and (of course) can't remember who sent it.
/var/qmail/bin/qmail-getpw duane | less
/magnus
--
http://x42.com/
