> NOTE: SPACES INSERTED IN CERTAIN WORDS TO PREVENT IMAIL FROM SUDDENLY > DECIDING IT WANTS TO WORK PROPERLY.
Wrong. RTM. IMail subscribe and unsubscribe requests are sent to [EMAIL PROTECTED], not the list posting address. In no way would it be "proper" for IMail to honor a putative unsubscribe request erroneously posted to the list address. This is the way Imail has always worked (read some old manuals as well, read some mailing list archives too). Indeed, professional mailing list managers work this way as well. Subscription management messages aren't sent to the same address as list posts. OTOH, IMail's dirt-primitive MLM has historically suffered from a lack of support for anything but plain text, a lack of double opt-in, lack of standard list headers, lack of bounce management, and a raft of other features common to professional MLMs. But those are other issues. You have to send list commands to the right address before you bellyache about it not working. > Additionally, when responding to a message and you want to un sub > scribe, the word, un sub scribe must be the only think in the > subject field. (without the spaces as shown in this example). NO > "RE:", NO "[IMail Forum]", just the word un sub scribe, without > spaces. Wrong. RTM. List commands are sent to imailsrv in the message body. The only way auto-processing aliases and other list management procedures exist is if you create them. > In the case of this list, it would be > "[EMAIL PROTECTED]" with NOTHING in either > the SUBJECT or BODY of the message as a PLAIN TEXT MESSAGE. Wrong. RTM. Such aliases only exist if you create them. There are no magical list management aliases that always exist that you cannot see in the Aliases area in IMail admin tools. IMail is extremely upfront that way. Other servers might have hidden the Program Alias to imailsrv. IMail does not, making it easy for users to see... and unfortunately possible to delete. > I wrote a web interface this, that forces a confirmation response by > the person subscribing or unsubscribing, and that response MUST also > be PLAIN TEXT. Such a "web interface" does nothing vis-a-vis the plain text issue: you describe it yourself as having the exact same processing problems with non-plain-text responses. (Not surprising, since you didn't write anything new on the incoming end.) If you want to work around the issue, write a real SMTP-HTTP list management interface that generates outbound e-mails containing hard-to-guess, expiring URL links that act as confirmations when the URL is visited. It's not like any of this is rocket science: the freakin' subscriber lists are text files. Of course, you have to *really* want to use imailsrv, instead of myriad other options, to bother with this. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
