On Fri, 10 Jan 2003 08:55:47 -0600 R Hannes Beinert <[EMAIL PROTECTED]> wrote:
RHB> I would much prefer a client which is lean and tight, but provides the RHB> extensibility to implement some of this "bell and whistle" RHB> functionality. Mahogany is not lean and tight (it has never been the main goal and so, unsurprizingly, it hasn't been achieved) but there was a goal to provide just such extensibility. Unfortunately it's been a failure because nobody was motivated enough to neither use nor work on it and so it was a vicious circle: the API wasn't used because it wasn't well developped and I don't want to work on it because nobody uses it anyhow. RHB> I often find myself in the position of switching between a number of RHB> different network access points. At any given time, I may be replying RHB> to an email which was received by ISP "A", but sending the reply while RHB> connected to ISP "B". If I understand you correctly, the SMTP server RHB> which would be used for the outgoing message is dependant upon which RHB> folder the message is located in, which implies that I would need to RHB> move the email for which I'm constructing the reply, to the ISP "B" RHB> folder. Have I understood you correctly? Yes. But, as this is clearly inconvenient for you in this case, you can also use the identities to achieve the same result. There has been some talk about implementing "network locations" which would be yet another thing, orthogonal to both folders and identities and Thomas Finneid was going to do this but AFAIK this has never been done. It's a pity because I understand that it could be quite useful in your example. RHB> >XN> > 9. Can M break apart mailing list digests if requested? RHB> >XN> RHB> >XN> No, but I guess this could be an interesting feature. RHB> > RHB> > Yes, I even think there is a bug tracker entry for it. RHB> RHB> Excellent! Well, to be honest I must say that this doesn't say much -- there are about 100 opened bugs right now and so some time may pass before they are all closed (one may always dream ;-) RHB> Yes, but if I understand the situation correctly, it would not be RHB> possible to invoke procmail as an email pre-processor during the RHB> course of M email processing? So any header munging would need to be RHB> performed up-stream somewhere (on a proxy, or at the server). Yes. And IMO this is how it should be. M does integrate the filters (although some might argue that a MUA shouldn't do this neither) but it wouldn't be very useful in a Windows world without them. However I don't think it should modify the mail messages. RHB> Just to make sure I understand -- this type of information is stored RHB> within the actual message headers? So there might be a "Status: " RHB> header, or perhaps an "X-Mahogany:" header? This depends on the format. In MBOX format there is indeed an X-Status header. In MBX format they are stored in the binary metadata part of the file. RHB> >XN> > What happens to the attachments? RHB> >XN> RHB> >XN> Nothing. RHB> > RHB> > I.e. they're stored in the mailbox file with the message itself. RHB> RHB> As they were originally received, in their original encoded form? Yes. Regards, VZ ------------------------------------------------------- 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
