Tasos,
Others have pointed this out, but I wanted to reinforce it: if you
are already using qmail then handling list-traffic-bounces is so
tremendously easy using VERP that there really isn't any comparison
to DSN. In the most recent survey that I am aware of, DJB's Jan
1998 survey, about 41% of sites claimed DSN support in their MTA.
100% of sites support VERP, except for some that violate the
fundamental requirements of RFC 821/RFC 1123.
Parsing VERP is dead simple. I do it in a small shell script, and
can certainly parse megabytes of bounces if need be. Use of VERP
does not require ezmlm as someone else has suggested.
Your statement that qmail's lack of DSN makes it unusable for
enterprise class mail systems such as you describe does not stand
up; several large enterprises, including the one I work for, use
qmail as their primary MTA.
The only reason to use DSN, in my judgement, is if you have to
support mail clients (people or programs) that can't function
without it.
So my suggestion is that you look in to VERP, and if you conclude
that it won't work for you get back to us, there's a good chance
you've overlooked something. At the least, I would appreciate a
descriptive report on a case where VERP is unusable for mailing
list bounces.
Regards,
-- Jeff Hayward
On Tue, 18 May 1999, Tasos Kotsikonas wrote:
Trevor Harrison wrote:
> Ease up everyone... Tasos isn't a flame-baiting troller... he probably really
needs DSN (I feel your pain Tasos, I need it too).
>
> Anyway, he's also the author of Listproc (yeah!), which I'm still using to this
day because everything else (read majordomo) I've tried sucks hard; anyway, he's cool.
>
> -Trevor
> ps. here's a good reason for DSN: SMTP<->X.400 gateways. X.400 supports all
kinds of return receipts, and right now, DSN is the way our X.400 MTA provider
interfaces this stuff. I've got a sendmail box that I have to keep using because we
need to be able to turn on DSN when we send messages into X.400.
> However, DSN is also a major cause of headaches for us, either Micros~1 Exchange
MTA's saying that they support it, but they really don't, to someone else's home-grown
bad implementation, to firewall smtp filters rejecting it, etc.
>
Thanks everyone for the responses. Indeed our need for DSNs is
simply TREMENDOUS. Email Solutions is setting up an
enterprise-level services organization and the software we have
developed (newsletter delivery if you care to know) needs a high
speed farm of MTAs. Our software-customers at this point have lists
as large as 3 million subscribers each. Our services organization
should be able to support thousands of lists like that.
With so much volume of email going out we need to cut down
on the number of bounces. As we expect megabytes of bounces
each day coming back from each such list, we need to keep
our lists as clean as possible. Nothing else other than DSNs will
allow us to be 100% successful. I am well aware that installing
MTAs that do DSNs does not necessarily mean that we will
not be getting non-DSN bounces back. In fact, our bounce handling
code resolves about 99.2% of them (on a test of half a million random
bounces). But we need to cut down on the processing time parsing
non-DSN bounces, and indeed DSNs are very easy to parse with
linear algorithms or better.
For enterprise-level delivery needs qmail in its current form
does not cut it for us. It is very unfortunate because it's extremely
fast and reliable, and we take full advantage of its PIPELINE mode.
The freeware sendmail is not an option for us either.
>From the responses I got (again, thank you immensely), I became
aware of commercial "versions" of qmail and that may be an option.
Sendmail Inc also has a high-speed commercial version of its
product which we will be looking at. Exim came up while exploring
the market. I agree that security may be a problem with it.
And if all fails, we'll do it ourselves, as they say ;-)
I am not sure where Dan stands on DSNs (although I gather he
just agree it's the right thing?), and all I can say is that he would
have been a millionaire by now with the right product for business
and a good business strategy. You know, despite what we all think
of freeware sendmail, they did get $6mil in VC funding, they
do have a high speed version of the product (of unknown as yet
performance capabilities), they will be successful in converting
large-scale operations using freeware sendmail like AOL.COM
(e.g. see 205.188.156.161), and they are in the process of rewriting
their product.
My apologies to all of you who thought I was trying to stir up the
waters here. But the similarity of responses I got re: qmail was
very striking and the message was: use qmail but if your business
depends on it and you need to get something done by the author,
well, good luck! That's a chance we cannot afford to take.
Finally, I have a serious proposal for all of you out there with a
business mind. We may have a need for advisors should we
decide to write our own SMTP delivery engine. Interested
parties should email me privately to discuss this furhter.
Thanks all for listening and good luck!
tasos
