Quite.Scott... how hard would it be for Declude to split the message when faced with a conflict like this.
Imagine the following scenarios:
[1] An E-mail addressed to "[EMAIL PROTECTED]", that gets delivered to "[EMAIL PROTECTED]"
[2] An E-mail addressed to "[EMAIL PROTECTED]" that gets delivered to "[EMAIL PROTECTED]"
[3] An E-mail addressed to "[EMAIL PROTECTED]" that gets delivered to "[EMAIL PROTECTED]" and "[EMAIL PROTECTED]"
That's just the first recipient -- the second one could be any of those combinations as well.
So in case "1-1" (2 recipients, both addressed to the properly user account), it's relatively easy to deal (make a copy of the D*.SMD file and Q*.SMD file, then split up the recipients in the Q*.SMD files).
In a case such as "1-2" (one recipient addressed to a user, another to an alias), it gets a bit trickier.
In case 1-3 (one recipient addressed to a user, another addressed to an alias that expands to 2 users), there isn't any way to split the E-mail properly -- IMail will end up delivering two E-mails that are both addressed to an alias, but the actual recipients will differ. That could potentially cause problems with IMail.
There are also some other issues, such as creating a unique filename for the new E-mail (one that IMail can use). Also, there is the extra resources used -- every extra copy created would require an extra SMTP32.exe process to run (which means that Declude JunkMail would have to determine in which case(s) the E-mail should be split, and if split, where it should be split (rather than making one copy for each recipient). That's going to be difficult, and even harder to debug.
-Scott
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
---
This E-mail came from the Declude.JunkMail mailing list. To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail". The archives can be found
at http://www.mail-archive.com.
