At 12:22 PM 2002-05-18 -0400, Sean Brunnock wrote:
>The problem was they were using an MTA which would accept all messages
>and spool them. The servers were croaking from all of the bogus bounce
>messages in their queue. I was using Sendmail which would bounce messages
>for bogus users without accepting them. They wouldn't believe me though.
>They insisted that MTAs had to accept messages and spool them.
Actually, had you given them a complete list of all valid addresses on your
system?
I provide relay services for a few domains using postfix, generally in
conjunction with running mailing lists for them. If I know all of the end
user addresses in the domain (which I do for some), I can list them all in
the virtual map, include a special entry that indicates that this is a
complete list, and postfix will bounce mail that is sent to that domain for
a localpart which is not in that virtual map, with a "550 User Unknown"
during the RFC821 interaction.
But if I am providing backup MX for someone, or if I am doing cherrypicking
(I run lists for a couple of domains where I am on their MX lists as the
final mail destination for a domain part which contains their mailing list,
and which also contains end user addresses), and I do not know all of the
addresses in their domain, I have no choice but to take the mail that
someone tells me is to be delivered to that domain.
Where I do not know all of the possible local parts for a domain, I
cherrypick the mail off for the lists using postfix's virtual tables, and I
forward everything else to them manually using the transport map. I would
have to accept and spool all mail for that domain because I do not know
what the complete list of valid recipients is.
And if I were providing backup MX for someone I would have to accept and
spool every piece of mail sent to their domain, unless they gave me (and
kept me updated with) a complete list of *all* valid localparts in the
domain. Then I could keep that list in their virtual map or another
postfix map and reject everything else.
The way most people run backup MX sites is that they take everything and
then forward it.
So, in this case, you may be both right. If you can look up all possible
valid recipients to mail, including in domains you may eventually relay to,
you can reject at the point of RCPT TO: and significantly cut your losses
regarding processing cost for mail sent to bogus addresses in domains you
relay for - as you point out, it is a cheap operation for you. If you do
not have that list of all possible valid recipients, you are going to have
to accept, queue, and then when your MX destination rejects it, bounce and
retransmit (or just swallow with a MAIL FROM:<>) all of the stuff relayed
to the bogus addresses that don't exist on your or their machine.
My point is that sendmail has little to do with it, unless you were
mentioning that to indicate that even a slow, expensive mailer should be
able to do this sort of bouncing at the border where the mailer actually
knows the complete list of recipients. I have not looked seriously at
sendmail for years, but last time I looked at it, I don't recall it having
a way to deal with the case where it was a backup MX for someone and there
was a need to filter invalid addresses regarding forwarding. It may now be
able to do this, I honestly do not know.
Postfix used to accept and bounce. It can now run either way, depending on
whether or not it has complete mapping for the local and relay target
domains. There is specific support for a local mapping, and you can filter
the relay addresses either in virtual if you are relabeling for the domain,
or by plugging maps into smtpd_recipient_restrictions -
check_recipient_access can have any of several sorts of databases plugged
into it (btree, dbm, mysql) for lookup of the "rcpt to:". So were I to
have this problem with a situation like yours, I might tune this by asking
you for a complete list of recipients and then adding a map so that I could
reject the invalid users (or, more than that, not reject the valid users),
at least for the duration of the crisis. But without this list, if I am
acting as a backup MX for you, I am going to have to spool and attempt to
deliver to you, at which point I will learn, over and over again, that you
have not created this user on your system in the last quarter second. :-)
Whereas this is not a "user's group" for any particular MLM, it seems that
it is reasonable as a place to compare MLMs. I recently was faced with
either rewriting my bounce handler or replacing Majordomo with something
that had a better built-in bounce handler. I decided that I was also
interested in features, and that I would do the latter.
For a number of weeks, I searched for what I thought was the "best" tool to
replace my aging majordomo classic installation. I installed and evaluated
(based strictly on what I wanted to do) listserv/listproc, listar, and a
few others. If they seemed to have the basics of what I wanted, I joined
the mailing lists to try and get a feeling for what the mailing list's
development and state of bugginess was. I know that picking one MLM over
another and then saying why is like kicking someone's favorite puppy (if
you have not picked theirs), but my end choice was majordomo2. I had a not
good feeling about that package when I started the evaluation and would not
have guessed that it would eventually be the winner, but the end result was
that it was the winner. It is extremely flexible, has a reasonably complete
web interface for both archives and end users, has a good web interface for
administration, and a good bounce handler. It had the best multiple domain
support that any of the MLMs that I evaluated had, and it interfaced
smoothly with postfix, including automatically maintaining alias files
and in postfix format, as well as postfix's virtual domain tables. All of
my lists are now converted.
I have yet to find a thing I can't do with it. A couple of things that
were seriously non-standard (producing aliases in a non-default format to
support demime) required minor hacks, but most of the stuff I had hacked in
to majordomo1 (for example, on some lists, requiring non-members to confirm
their posts before sending them to a moderator for confirmation so that the
moderator would not see the spam) were just configuration issues.
I mention this because, as part of this thread, Russ Allbery talked about
how cufty listserv/proc had gotten and hoped that people would implement
software that would do everything that it would do so that people would
eventually shoot it. I honestly think that with majordomo2, we are
there. The only listserv features I can think of that are missing are the
distributed lists and the lists of lists, and I do not believe that the
central servers that supported those features are up anymore).
Now, I'll admit that my listserv evaluation was cut short - one of my
primary goals was a solid, integrated web interface. I had written my own
web interface for majordomo (I decided I did not like Majorcool, it was a
matter of style) and it worked pretty well --- it also understood my system
where most lists actually consisted of three associated majordomo lists,
and it understood my extensions to the majordomo command syntax. I wanted
something that had a web interface at least that good.
I had hopes for listserv after using the web interface as a mailing list
admin at listserv.Brown.edu, but the implementation/installation of the web
part seemed to be completely decoupled from the MLM. The MLM was a separate
package from the web interface and it seemed to be something that was kind
of a chore to get going - my choice at the end was to give up on it mostly
because of that. But I did have a general feeling for its features, and I
believe that Majordomo2 has a superset of those features. I've made my
decision, I think, but does anyone who has more of a feeling for these two
packages have any comments on my observation? Does Majordomo2 have
everything that Listserv/Listproc has? What is it missing?
--
War is an ugly thing, but it is not the ugliest of things. The decayed and
degraded state of moral and patriotic feeling which thinks that nothing is
worth war is much worse. A man who has nothing for which he is willing to
fight, nothing he cares about more than his own personal safety, is a
miserable creature who has no chance of being free, unless made so by the
exertions of better men than himself. -- John Stuart Mill
Nick Simicich - njs@scifi.squawk.com
References:
|
|
