> Maybe I will try that but after reading link you sent I am not sure > if it worth it.
It isn't worth it in the sense that it won't work with existing tools only. The task is worth it, but IMAILSRV won't help you. > I guess I may just rethink the whole thing. Yep. > But about the mail client...would it work if you setup an inbound > rule in Imail to search the body and/or header of bounced messages > sent back to the list owner? No, for at least two discrete reasons: (1) DSNs are sent from Postmaster accounts, not accounts that fail delivery (when you think about this, you'll realize how ridiculous the manual's suggestion really is). (2) It is beyond the Rules engine's ability to parse out the 600+ DSN formats flying around the Internet, triage them into transient and permanent delivery templates (not to mention bounce thresholds, which you likely didn't think about either), and redirect the message to the '-unsubscribe' alias with the bad recipient as the From: address. > Would this not be consider a redirect at the server and not a > forwarded message? Just trying to understand. You are right that a server-side forward is in fact a redirect, but it has no real bearing on the overall feasibility. > I really would not mind doing the editing, but I have 300 agents > that add names to these list. So even if the email is bad and I > delete it, which agent did it come from. What if they add the same > email to another list the next day. Certainly valid points in creating your functional spec for this project. But the project is not what you thought it was. :) > 1. Agents add names to CRM > 2. Agents check names in CRM to go to preconfigured list i.e. list 1, 2, > 3, 4... > (Note list name is set but header and footer could be changed and say > once an agent rights to that list it is closed for a couple hours so > they pick the next list available) This way we do not need a bunch of > list Admins just one for the CRM to use. FTR, we did some thing like this (pre-creating list1@, list2@, etc. and then customizing outgoing messages using friendly names: "Who's using this list now" <[EMAIL PROTECTED]>) for a client a few years ago. It did work (providing for race conditions and such). But that's not including bounce processing. > 3. List is sent Yep. > 4. Opt_outs and bounces come back Imail removes names For a deliberate opt-out by an existing user, this will work (provided they don't just reply, but actually create a blank message to your -unsubscribe alias). For a non-existing user, I think the reasons it doesn't work are made clear above. > 5. CRM checks list at night names that are not on the .lst get marked in > CRM as bad emails and/or having OPT-Out. Well, just pursuing this for fun at this point, not being able to whether or why someone bounced makes for a pretty broken architecture. > 6. Agents can either at this point contact client and verify address > or mark not to use for email (actually email would be marked not to > use till agent verifies and/or get permission from client) Ah, yes. "Recently, you opted out of our mailings. Would you like to ignore the fact the I'm writing to you in direct defiance of that opt-out order and resume your subscription?" Dangerous ground, obviously no problem in many accidental opt-out cases or transient bounces, but a sure way to get SpamCopped in other cases. You really need a traceable system with more adequate case logging. > I don't like that you can not tell which is which Opt-out or a unknown > user/host. Uh, yeah, neither do I. > In other words I think my great idea got sunk! Afraid so. > Anyone have a better idea? I think it's time for eCartis, Lyris, or one of those guys. -Sandy 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/
