Re: mail sorting tool
On Sat, Jan 06, 2001 at 09:20:36AM +0100, Robert Waldner wrote:
> On Sat, 06 Jan 2001 13:03:19 +1100, Craig Sanders writes:
> >because POP is not a mail transport protocol. it's not designed to be
> >one, and can not even be reliably kludged to act like one.
>
> ack. I already stand corrected. see Message-id:
> <[🔎] 200101041053.LAA07781@cruncher.Austria.EU.net>. I never ran into that
> sort of problems because I?m not on any lists or the like at home.
it's fine for a home-use domain with only a single user, then there's
basically nothing that can go wrong (unless you're subscribed to mailing
lists - but since there's only one user you can configure fetchmail to
deliver all incoming mail to the one account...no problem).
for anything else, it doesn't work.
> Does your ISP offer some kind of smtp-queuing? We do (mail is put into
> 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
> rewritten options for that queue, eg smarthost set to the dynamic IP).
>
> Way easier than UUCP (imho) and even working for
> exhaust^Wexchange-boxes at the customer.
sounds like a complicated and not very reliable way of avoiding the
simplicity and reliability of uucp.
like MX records pointing to dynamic DNS entries, this still has the
small chance of delivering the mail to another system - e.g. when the
client logs off and another user immediately logs in and gets the same
IP address. SMTP isn't appropriate for delivering mail to dynamic IP
addresses.
it also doesn't scale very well - it clutters up (and slows down) the
ISP's mail queue with mail that would be better stored in a uucp queue.
one obvious big difference is that the mail queue is scanned regularly
(and also when "sendmail -q" or similar command is run). compare that
to uucp where the mail is just dumped into the client's uucp queue
directory and basically ignored until the client logs in to download it
(ignored, that is, except for a nightly cron job to bounce mail that
has been waiting in the queue for too long because the client hasn't
bothered to log in for a fortnight)
this can be particularly bad if you're using sendmail (which only has
one queue directory) rather than, say, postfix (which has a multi-level
queue directory hash). in either case, it still takes a lot longer to
scan a few thousand queued messages than a few hundred.
another obvious difference is that if one client ends up with thousands
of small mail files in the one directory then the resulting speed
slowdown (on pretty nearly any filesystem except for reiserfs) only
affects that client and not every other client as well.
add to that the fact that the uucp queued mail can be stored compressed
with gzip, or can be compressed and encrypted on-the-fly if you're using
stunnel and openssl to wrap the uucp transfers and it's hard to see any
valid reason for using smtp to do a job that uucp was designed to do.
smtp delivery to dynamic IP hosts just isn't very reliable. it can be
kludged to be *almost* reliable but "almost reliable" is just another
way of saying "not reliable" and that's not really good enough for mail.
craig
--
craig sanders
Reply to: