|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: "hold" queues and ETRN
Subject: Re: "hold" queues and ETRN
From: Cor Bosman (cor
xs4all.net)
Date: Wed Jan 26 2000 - 20:26:40 CST
- Next message: Wietse Venema: "Re: Slow downstream site wedged my Postfix..."
- Previous message: Andrew McNamara: "Re: Slow downstream site wedged my Postfix..."
- In reply to: Wietse Venema: "Re: "hold" queues and ETRN"
- Reply: Cor Bosman: "Re: "hold" queues and ETRN"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Wietse,
I'll say this in sendmail terms, cause we've just started to migrate to
postfix, and Im not sure yet how everything here fits into postfix.
I havent looked at that yet cause we're switching some other mailservers first.
>> We made our own hack for this. We authenticate users with radius. If the
>> authentication works, we look up the user in a table of users who have this
>> service of 'hold queues'. If the user is in it, we fire a radius packet with
>> the username and queuename to another daemon (we call it radmaild).
All the above happens within radiusd. Should work with any other authentication
server.
>> This radmaild daemon then basically starts a queue run for this specific site.
This is basically just a radius daemon with most functionality stripped off.
All it does it accept an incoming radius packet, and fork a sendmail.
>> Works like a charm, for hundreds, if not thousands of queues. Shouldnt be so
>> hard to implement at your own site.
>Consider me interested. How does the mail enter the hold queue, and
>how does delivery relate to the rest of Postfix (so that bounces
>work as one would expect).
Every bsmtp (thats how we call it, and most others I assume) node gets
MX records like these:
demand.xs4all.nl. 86400 MX 100 mx2.xs4all.nl.
demand.xs4all.nl. 86400 MX 100 mx3.xs4all.nl.
demand.xs4all.nl. 86400 MX 100 mx4.xs4all.nl.
demand.xs4all.nl. 86400 MX 10 demand.xs4all.nl.
demand.xs4all.nl. 86400 MX 100 mx1.xs4all.nl.
The 4 mx hosts are our 4 incoming mail servers. On the bsmtp
boxes we run a small daemon that spews out every host it knows
how to deliver locally. Like this:
(xs4 ~ 117) telnet list1.xs4all.nl 2500
Trying 194.109.6.56...
Connected to list1.xs4all.nl.
Escape character is '^]'.
demand.xs4all.nl
ynnoz-foobar.xs4all.nl
.ynnoz-foobar.xs4all.nl
bla.xs4all.nl
bla.foo.bar.com
-END-
Connection closed by foreign host.
>From that list our 4 MX boxes generate a mailertable pointing to the
right machine(s). (We're btw in the process of changing this into a mysql
table instead.)
On the bsmtp boxes we create a 'bsmtp' mailer definition, and a mailertable
pointing every bsmtp node to this mailer.
demand.xs4all.nl bsmtp:demand.xs4all.nl
ifdef(`BSMTP_PATH',,
`define(`BSMTP_PATH', `/usr/local/lib/mail/bin/bsmtpwrap')')
ifdef(`BSMTP_MAILER_ARGS',,
`define(`BSMTP_MAILER_ARGS', `sendmail -oee -oi -oQ/var/spool/requeue/$h
-C/usr/local/lib/mail/bsmtp.cf $u')')
The bsmtp.cf is a very simple cf file. It disables the mailertable so it wont
call the bsmtp mailertable definitions again, and basically just reverts
to using the MX hosts. And, to make sure it doesnt loop back towards our
backup MX hosts, we put "mx1.xs4all.nl" in the sendmail.cw. I told you it
was ugly :) All other delivery basically points back to our central mailhubs
through a SMARTHOST parameter in the cf file, including bounces.
Because it's so ugly (but again, its been working very nicely for years with
about 3000 to 4000 sites), we are working on changing some aspects.
- we're putting the mailertable stuff in a mysql db.
- we're currently running tests where we've integrated the queues with a
users normal mailbox, so bsmtp/webmail/pop/elm/mutt is all 1 mailbox.
About 20 users use this now with great succes. It immensely lowers the
overhead for our helpdesk when people ask our helpdesk to remove large
mails or fix any other problems. Users can now just use webmail and fix
their problems themselves.
- we're running tests with another (self made) program that delivers the
mail to the user's machine instead of sendmail itself
(cause of all the hackery that needs)
- and finally, the one above is a prelude to also doing this on dynamic
hosts (which is possible with a very very high degree of accuracy, unlike
previous mails I saw here seem to indicate) We've still got to see if we
can make it 100% though :) It involves making semi-static IP numbers by
making your radius server give out dynamic ip numbers a bit differently.
Takes about 10 to 20% more dynamic ip#'s than ports, but it doesnt need
statics, which is a huge win.
Think this can be changed to postfix? :)
Cor
- Next message: Wietse Venema: "Re: Slow downstream site wedged my Postfix..."
- Previous message: Andrew McNamara: "Re: Slow downstream site wedged my Postfix..."
- In reply to: Wietse Venema: "Re: "hold" queues and ETRN"
- Reply: Cor Bosman: "Re: "hold" queues and ETRN"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This archive was generated by hypermail 2b27 : Wed Jan 26 2000 - 20:29:39 CST