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 - [EMAIL PROTECTED]
