>> >> Headers for a regular message are not relevant since the sending >> process is not the same. If you made the sending process more >> similar, that is, let the user choose who to send the message out just >> like on the normal compose screen, then it could send the message as >> the desired alias. Otherwise, you could try to make SM guess what >> alias to use, such as by parsing the TO and CC headers and seeing if a >> match to one of your aliases is found, but that's not 100% reliable, >> since you could have been BCC'd etc. > > Of course the sending process is different. But at my novice level of > understanding, a read receipt should be send with the account of TO* and > CC* and never with your primary login account of sm. Again, SM simply *cannot* assume that it will find a valid address to sent the receipt from in the TO or CC headers. Period. Again, in 95% of the SM installations out there, the SM login *is* the correct address to send from. The original code made some assumptions, yes, but they are by far the best assumptions to have made. > BCC should never get > a read receipt (my private thinking, rfc should know it better). > >>> In this example when I accept sending read receipt, I got the read >>> receipt >>> by my primary private email address. )-; Yes, patches are welcome. I'm >>> perl programmer and able to read/modify php, but it seems it's a mistake >>> by design and not just fixed be one line. And maybe there are some other >>> issue I can't see, so this behavior is "correct"? >> >> It's very much correct in 95% of the environments out there. Yours is >> not the norm. If you want to make accusations about bad design (sure >> it could have been designed differently), then that's not going to >> motivate anyone to take the time to redesign it I think. > > You are right, in 95% all sm user aren't affected or most of the sm-user > think it's not important. For me, now I know I will never allow sending > read receipt with sm while using one of my aliases. And believe me I'm a > big fan of sm and know your work as a maintainer. You make a great job! Thank you, that's very kind. > I'm also really interested to solve this problem and give my solution back > to sm. But this will need time. I have to investigate the code and I need > some time and I need your help. Maybe I'm completly wrong? I have just the You're not wrong - this would be a marginally useful functionality - to allow choice of what alias to send receipts as or allow auto-detection. How it is done can be tricky, especially if the automated JavaScript popup method is used. > view of a normal user and no experience of php or the code of sm. > Also I hope this could be a point of your todo list. Maybe at the end of > this list (sm 1.9?) because the problem is not important. Feel free to add an enhancement request to the SM tracker at sf.net. Cheers, Paul ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
