LuKreme wrote: >Well, for one thing if you did it to ME with several hundred users I >would consider it an attack
I see. No one has pointed this part out yet, though: You mean that if you are a mail provider for many users, and many of your users have subscribed to my list, then my "feature" would initiate lots of connections where only one seems appropriate. I understand this now, but the explanations before were all talking about the sending side, not the receiving side (although several people pointed out that, in order to be able to support my request, individual mails on the receiving side would be necessary). So, if I would run a list where many of the recipients would be coming from one mail provided, e.g, AOL, this could be considered flooding the mail server. Om then here is my point in return: I considers this feature useful to users who have their own domain (such as me) and who are free to use whatever mail addr they want under this domain. Such users will usually not subscribe with different names to the same list, and even if they did, they would be responsible themselves for having their mail server flooded by multiple copied of each list msg. However, those mail server, that are similar to yours, where you have many clients and all may be indidually subscribed to the mail list of mine, will very unlikely have an infinite amount of random e-mail addrs that they would not be able to keep track of. So, in such a case where there are multiple recipients at the same mail server, the mailing list delivery software is quite safe to assume that this is a case like yours and then make one combined delivery, without individual To: headers for each recipient, to your server just as it always has been done. With this technique, which could be automatically handled by the mailing list software, we could both be made happy: Your server with all the individual users will not get flooded, and people like me, running their own mail server, will get their individually constructed mails. This feature will have only one drawback: If the list server does not do its own mail delivery, it will have to create many more mails for all the separate domain recipients, which can overload the local mail delivery system if there are many mails, while the "classic" approach would just create one mail with a long recipient list and send this one mail to the SMTP server for delivery. But this problem is, as I said before, a performance problem solely of the list server side, and does not have to concern you on the receiving side. Agreed? >You can compile and run mailman under OS X if you like. It sends a >monthly reminder message with the email address of the subscription. Ah, that is a nice alternative. Even better it would be if macjordomo could identify users also by their names - after all, one has to give one's name when subscribing - why can't the server use this information later again to look up a subscriber again? That is, if I send a msg to the server, it could still try to match my name if it can not match the return mail address. Then it could send a verification mail to the mail address the name belongs to and thus make sure it has identified the correct user and not an illegal impersonator. Thomas ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
