On Mon, 08 Jan 2001 15:45:25 +0100, Toni Mueller writes:
>On Mon, Jan 08, 2001 at 02:46:54PM +0100, Robert Waldner wrote:
>> On Tue, 09 Jan 2001 00:03:17 +1100, Jeremy Lunn writes:
>> >On Mon, Jan 08, 2001 at 01:12:23PM +0100, Stephane Bortzmeyer wrote:
>> >> > > Does your ISP offer some kind of smtp-queuing? We do (mail is put int
>o
>> >> > > a queue, there?s a script watching the dialin-logs, when it sees that
>> >> > > there?s a queue for that user, sendmail is started with on-the-fly
>
>yuck. This sounds *very* complicated... At least when running
>RADIUS I think that other options could be available.
it runs perfectly stable since we set it up intially: mid-´98...
>> >Which makes me think, if your their provider, why not give them a static
>> >IP Address?
>
>Hmmm. Where do _you_ get your IP numbers from? Afaik - here in
>RIPE-land - there is a policy expressly forbidding this, and it
>could therefore result in your not getting IP numbers later...
we don´t have a problem with RIPE, but that comes from the fact that
we´re playing by their rules ;-) (which we (for small parts of "we")
helped to develop in the early ´90s. sometimes it´s good being one of
the oldest ISPs in service).
>> this is where the salesmen came into play :/
>>
>> is they have a static IP, we cannot limit them in the number of
>> recipients (which _I_ do not want, but the salesforce does). this way,
>> they get _all_ their mail via our queue (and they have to set up each
>> &every mailaddress with us <ARGH>).
>
>Only the tiny dumb user does this, imho. Anyone with half a clue
>and any kind of Internet gateway system running, as opposed to a
>bunch of ISDN cards or simply a NAT'ing router, wants to do it
>himself and surely finds a way to sort it out (but you _can_
>reasonably charge significantly more than for people only
>using dynamic addresses).
sure, anyone with half a clue would take granny´s old 386, install *n?x
and never need to bother our helpdesk...but the other 99,998 % are
just a bunch of lusers.
>> >static IP address is viable. For the remaining ones, I don't see what's
>> >wrong with UUCP.
>
>Wrong with UUCP are imho two points:
>- It's unreliable (yes. I mean it. It eats much support because
> not all UUCP versions talk to each other, and also this tends to
> block itself for no good reason and needs manual cleanup - I did
> news and mail over UUCP for over a year :( ).
hmm, our UUCP didn´t need any service in the last years, but hey, maybe
that´s because nearly noone still uses it ;-)
>- It's unavailable, basically. While anyone with their pretty
> Linux or BSD box has no problems getting at appropriate UUCP
> software, everyone else has to go to their nearest computer
> museum to find one, as it seems. Also, customers usually can't
> administrate neither SMTP nor UUCP, but SMTP is easier to
> set up.
ack. and you cannot cook a new solution for each and every (US$30/
month) customer...
>> why bother with the source if all you have to do is set up your rules
>> ;-) . our setup is ldap-only since ~ 2 years, so that kind of things
>> are quite easy to implement.
>
>That's an interesting statement. How do you do it, and how
>reliable is it?
feed all your information into a replicated ldap-database. have
sendmail look up there at the right times, eg:
->helo host.bla.com
<is host.bla.com in MAPS RBL? no, ok, go on>
<-hello...
->mail from: <[EMAIL PROTECTED]>
<domain exists? mx or a record there? yes, ok, go on>
<- ok
->rcpt to: <[EMAIL PROTECTED]>
<aah, now we have all the information, go ahead:
- do we serve customers.at and some@..?
- what´s the maildrop, an mbox-file to be pop3ed sometime? a special
queue? on which machine/storage? a forward or vacation or
$otherspecialty?
- does the recipient use any spamprotection? which (ORBS, MAPS DUL,
RSS etc pp, now´s the time to reject if anything fails)?
...
>
<- ok
-> data...
as long as your ldap´s stable everything´s fine. and openldap is _very_
stable...
-> http://www.austria.eu.net/~az/ who did all this.
cheers,
&rw
--
/ Ing. Robert Waldner | Network Engineer | T: +43 1 89933 F: x533 \
\ <[EMAIL PROTECTED]> | KPNQwest/AT | Diefenbachg. 35, A-1150 /
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
