Hello, Vadim! At 01:06 1/10/2003 +0100, Vadim Zeitlin wrote: >XN> > 1. Provided you are familiar with Eudora, how would you contrast the >XN> > feature set between M and Eudora? (I realize one could probably write >XN> > a thesis on this, I'm just curious about the "big picture") >XN> >XN> I never used Eudora, so.... > > Me neither but I think that Eudora should provide more bells and whistles.
It is undeniable that Eudora has a great many bells and whistles, however I find that many of them are either not optimally useful, or they are a bit buggy. I would much prefer a client which is lean and tight, but provides the extensibility to implement some of this "bell and whistle" functionality. But that is my dream! ;-) >XN> Could someone elaborate on its use of identities? > > You can indeed achieve almost everything you can do with identities by >using folders. However some people feel uncomfortably with organizing their >folders hierarchically like this and prefer the concept of the identities. > > Identities and folders are really orthogonal so by uding both of them you >can achieve maximal flexibility -- and maximal confusion, of course ;-) I am beginning to understand the approach that M takes to identities & folders. The terminology is far less important than the flexibility, in my opinion. I will need to play around with these features! >XN> > 7. Supposing a user has 2 different network connections (or dial-up >XN> > accounts), and since SMTP servers are generally no longer "open >XN> > relays", will M automatically switch to whatever SMTP server is >XN> > appropriate for the current subnet/domain? >XN> >XN> I did not use the dial-up feature of M since a long time, so I'm not >XN> sure about the answer. I'm affraid the answer is no, and it was one >XN> reason for me to use a personal SMTP server to handle this problem. > > M dial up support doesn't deal with that but you can configure different >SMTP servers for different folder (and/or, alternatively, identities). I often find myself in the position of switching between a number of different network access points. At any given time, I may be replying to an email which was received by ISP "A", but sending the reply while connected to ISP "B". If I understand you correctly, the SMTP server which would be used for the outgoing message is dependant upon which folder the message is located in, which implies that I would need to move the email for which I'm constructing the reply, to the ISP "B" folder. Have I understood you correctly? >XN> > 9. Can M break apart mailing list digests if requested? >XN> >XN> No, but I guess this could be an interesting feature. > > Yes, I even think there is a bug tracker entry for it. Excellent! >XN> > 13. Can an incoming email filter change fields in the incoming email >XN> > header? >XN> >XN> No. Filters in M don't change the content of the message itself. > > But procmail can do this. Yes, but if I understand the situation correctly, it would not be possible to invoke procmail as an email pre-processor during the course of M email processing? So any header munging would need to be performed up-stream somewhere (on a proxy, or at the server). > The new/recent/unread/flagged/deleted messages have their own colour. This >is stored in the folder itself (as a message flag). A feature to set >(custom) colour for individual messages is planned but doesn't work >currently. Just to make sure I understand -- this type of information is stored within the actual message headers? So there might be a "Status: " header, or perhaps an "X-Mahogany:" header? >XN> > What happens to the attachments? >XN> >XN> Nothing. > > I.e. they're stored in the mailbox file with the message itself. As they were originally received, in their original encoded form? >XN> > 16. When an outgoing message is PGP/GPG encrypted and a copy of the >XN> > outgoing email is saved, is the pre-encrypted plaintext saved, or the >XN> > actual outgoing email saved? >XN> >XN> Encryption is not yet implemented. > > But when it will be, only the encrypted message will be saved (meaning >that it will actually be quite useless unless you encrypted it with your >own public key as well...). Excellent! In my view, this is an excellent design choice. Vadim, thank you very much for your thoughtful reply! I'm very grateful that you and Xavier have taken such pains to address my questions. You have given me a much better understanding of Mahogany, and some of the design choices that you've made. I look forward to having a little time to read the code! Thank you, again! Hannes. -- Email: [EMAIL PROTECTED] <*> PGP ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Mahogany-Users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-users
