> So it takes 20 days for a bad address to get kicked off?
That's right. This gives people time to fix configuration errors.
> so a bad address doesn't get kicked off the list
> until I've sent out as many as 2000 messages that won't be delivered??
Right. What's the problem? It's not as if you have to read the bounces.
Only the first one is saved, so you don't need much disk space.
> It also assumes that users
Some users won't read the warning, but many users appreciate seeing the
missing message numbers and the first bounce message.
> are smart enough to know how to use a list archive.
Oh, yes, how silly of me to forget. Users are so stupid. The trouble
they have has nothing to do with the design of the command interface or
the quality of the instructions they receive. ``Send a message to
net to retrieve message 12345'' is just as
confusing as ``... get <list> <filename>: Get a file related to <list>.
... Commands should be sent in the body of an email message ...''
> And I think a lot of system administrators would take umbrage at your
> statement that bouncing messages because of an exceeded quota is foolish.
Bouncing messages because of a _temporarily_ exceeded quota is a bug.
This bug was in many versions of binmail but was fixed in mail.local.
> I'm lost here. If my mail is being forwarded to a bad address,
``You forward copies of incoming mail to a summer account.'' Copies.
> I'm no expert, but I don't think there's such a thing as a cryptographically
> secure address for a bulk mailer. Please elucidate.
Warnings and probes are not sent in bulk.
> > All of this depends on qmail's VERPs, which reliably identify the
> > subscription address and message number for every bounce message.
> Which depends on all MTA's and MUA's that handle the message sending back
> decipherable bounce messages that uniquely identify both the message and
> the intended receiver.
Wrong. The contents of the bounce message are irrelevant.
You obviously have no idea what VERPs are, so I don't understand how you
could possibly feel competent to contradict my comments about them.
You should have asked, ``Really? DSN needs support from all intermediate
hosts as well as the final MTA. Do these `VERPs' remove that limitation?
Can VERPs deal with hosts that return completely uninformative bounce
And I would have answered, ``Yes. DSN is obsolete. Subscribe to the
ezmlm mailing list and you'll see how VERPs work.''
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html