You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(12) |
Jul
(6) |
Aug
(40) |
Sep
(13) |
Oct
(32) |
Nov
(15) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(8) |
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(14) |
Sep
(6) |
Oct
(19) |
Nov
|
Dec
(8) |
2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(4) |
Oct
(4) |
Nov
(8) |
Dec
|
2012 |
Jan
|
Feb
(9) |
Mar
|
Apr
|
May
(7) |
Jun
(2) |
Jul
|
Aug
(6) |
Sep
(4) |
Oct
|
Nov
(3) |
Dec
|
2013 |
Jan
(1) |
Feb
(4) |
Mar
(3) |
Apr
(25) |
May
(10) |
Jun
(12) |
Jul
(1) |
Aug
(4) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
2014 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2015 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Lars N. <lar...@gm...> - 2013-05-21 07:36:58
|
Thanks. On Mon, 20 May 2013, Joshua Miller wrote: > Gmail's IMAP behavior is non-standard. As far as I know, there's nothing built > into Alpine to work around its oddities. This post has some relative information > in the reply (first hit from a google search for "gmail imap alpine delete"): > > http://superuser.com/questions/454263/deleting-gmail-messages-from-alpine [snip] This seems different from the behavior I am seeing. If I hit "d", it gets marked for deletion, but I don't see it showing up in the Trash folder on Gmail. I see it staying in the Inbox (or whichever folder) When it's eXpunged, it's gone for good from the inbox even if I had previously pressed "u" to undelete it. When it's gone, it's not in the Trash folder or All Mail or anywhere else I can think to look. > Seems like it would be possible to do a bunch of patching to alpine and have work > around those issues to make it behave more like a standard IMAP server. If > someone took on that challenge, it'd probably be better to redo the commands as > well and make it behave like gmail (have a command to add/remove labels; have a > mark-as-spam; have a move-to-trash; add an archive command; maybe map the labels > to message keywords; etc). I doubt this has or will be done though... if you want > an IMAP address to use with pine/alpine, there's plenty of providers out there > (ie. why use gmail if you don't want it to behave like gmail?). Might be a good > Google Summer of Code project :-) That would be nice to have but I don't have the skill to make it so. Google seems to have trouble with standards of late. Maybe they could clean up their IMAP. Regards, /Lars |
From: Joshua M. <un...@gm...> - 2013-05-20 20:26:07
|
On Mon, May 20, 2013 at 2:54 PM, Lars Nooden <lar...@gm...> wrote: > In my Gmail account, accessed via IMAPS, if I mark a message for deletion, > it gets expunged even if I subsequently unmark it for deletion. Say for > example I choose a message, press "d" to mark it for deletion, then choose > the same message and press "u" to unmark it for deletion. Then if I press > "x" to eXpunge the message, it still vanishes even though it is not marked > for deletion. Is there a way around this that I can set in the > configuration for re-Alpine or else on Gmail's servers? > > This is on (re-)Alpine 2.03 (BSO 1266 2009-07-14) from OpenBSD-current > ports. > Gmail's IMAP behavior is non-standard. As far as I know, there's nothing built into Alpine to work around its oddities. This post has some relative information in the reply (first hit from a google search for "gmail imap alpine delete"): http://superuser.com/questions/454263/deleting-gmail-messages-from-alpine In short: * Hitting "D" on a message immediately removes the label that makes that folder. * exception to that is in Spam and Trash labels - "D" deletes it. * another exception to that rule in in the "All Mail" folder... "D" has no impact at all. * To actually delete a message, use "S"ave and save it to Trash. Seems like it would be possible to do a bunch of patching to alpine and have work around those issues to make it behave more like a standard IMAP server. If someone took on that challenge, it'd probably be better to redo the commands as well and make it behave like gmail (have a command to add/remove labels; have a mark-as-spam; have a move-to-trash; add an archive command; maybe map the labels to message keywords; etc). I doubt this has or will be done though... if you want an IMAP address to use with pine/alpine, there's plenty of providers out there (ie. why use gmail if you don't want it to behave like gmail?). Might be a good Google Summer of Code project :-) -- Josh I. |
From: Lars N. <lar...@gm...> - 2013-05-20 18:54:58
|
In my Gmail account, accessed via IMAPS, if I mark a message for deletion, it gets expunged even if I subsequently unmark it for deletion. Say for example I choose a message, press "d" to mark it for deletion, then choose the same message and press "u" to unmark it for deletion. Then if I press "x" to eXpunge the message, it still vanishes even though it is not marked for deletion. Is there a way around this that I can set in the configuration for re-Alpine or else on Gmail's servers? This is on (re-)Alpine 2.03 (BSO 1266 2009-07-14) from OpenBSD-current ports. Regards, /Lars |
From: Werner S. <W.S...@we...> - 2013-04-29 22:15:52
|
... and I'm sure it is not necessary to write to them in German because people dealing in IT business are supposed to speak a reasonable English. |
From: Andreas S. <sch...@fa...> - 2013-04-29 21:01:45
|
On Mon, 29 Apr 2013, at 22:12, Tim Kroeger wrote: > The bug is clearly on the GMX side. On the other hand, for a user > of a free GMX account, it is impossible to contact the technical > support without having to pay for it. FACK. > If somebody else might be interested in making contact with GMX > (either by paying, or if they use a premium GMX account, ... I don't use Twitter, but apparently they are on Twitter. So, maybe someone could twitter it!? -- -- Andreas :-) |
From: Tim K. <Tim...@gm...> - 2013-04-29 20:12:39
|
On Sat, 27 Apr 2013, Joshua Miller wrote: > The right fix is really to get GMX to fix their stuff. This is a draw: re-alpine will not be "fixed" because it's actually not at all buggy. The bug is clearly on the GMX side. On the other hand, for a user of a free GMX account, it is impossible to contact the technical support without having to pay for it. Since I am not willing to pay a company just for being allowed to help them fix their software (compare this with Donald Knuth's TeX software, where you *earn* money when you find a bug!), GMX aparently won't be fixed in the near future either. For me, this is okay at the moment, because my very dirty patch works as required for me. If somebody else might be interested in making contact with GMX (either by paying, or if they use a premium GMX account, in which case the support is free of charge), I would appreciate though. If required, I could help to formulate their email and explain the problem (in German, since GMX is a German company). Best Regards, Tim |
From: Joshua M. <un...@gm...> - 2013-04-27 19:04:04
|
I've got no say in the matter, and I don't really care either way, but... On Sat, Apr 27, 2013 at 12:43 PM, <ml...@en...> wrote: > On Thu, 18 Apr 2013, Tim Kröger wrote: > > Thank you everybody for your great help! >> >> With your help, I was now able to find a workaround for the problem. That >> is, I modified the re-alpine source code such that outgoing mails have >> content-type "text/plain" rather than "TEXT/PLAIN". >> > > this is necessary for all the other content-types, too (like "multipart" > etc.). > > Is anybody on to incorporating Tims fix into the main distribution? (I, > for sure, would appreciate it.) > Who's to say that some other provider won't come alone, or already exists, that has broken their handling of the mime types in the opposite way. IE. perhaps some other mail client(s) only work with all caps on the mime type? Using a per-recipient-domain setting and sending filter could work, but that would also break email signatures (gpg and S/MIME) since it would change the content of the mail body. The right fix is really to get GMX to fix their stuff. Just thought that was worth keeping in mind if someone is contemplating making this change official - it could break more than it fixes. Thanks, -- Josh i. |
From: <ml...@en...> - 2013-04-27 17:03:34
|
Hi, On Thu, 18 Apr 2013, Tim Kröger wrote: > Thank you everybody for your great help! > > With your help, I was now able to find a workaround for the problem. That is, > I modified the re-alpine source code such that outgoing mails have > content-type "text/plain" rather than "TEXT/PLAIN". this is necessary for all the other content-types, too (like "multipart" etc.). Is anybody on to incorporating Tims fix into the main distribution? (I, for sure, would appreciate it.) Kind regards, Malte |
From: Werner S. <W.S...@we...> - 2013-04-19 17:04:23
|
Am 19.04.2013 schrieb Lars Nooden: > Werner, yours is lowercase: > Content-Type: text/plain; charset="us-ascii" Yes, that's why I wondered. When I look in my local "sent-mail", I see "TEXT/PLAIN", but my post in the list here appears as "text/plain". When I consider the posts of Tim or Nicolas, I see a part of them with uppercase, a part with lowercase let- ters in the content type, although they all were composed with Alpine. It seems to be a question of luck, maybe depending on which SMTP servers the e-mail passes on its way. Very strange! > Either way, GMX should not be case sensitive, but it is. Btw., my e-mail provider Web.de has exactly the same problem in its web interface, which is no surprise because it is the same company as GMX. Time to write a complaint. :-) Werner |
From: Lars N. <lar...@gm...> - 2013-04-19 15:11:19
|
On Fri, 19 Apr 2013, Werner Scheinast wrote: > I read the other posts, yes, the problem seems to be solved - or at least > explained. But what I don't understand: Why does my Alpine produce headers > different from yours? > I'm using Alpine 2.00 without any special patches, just the standard > package in the FreeBSD operating system. Werner, yours is lowercase: Content-Type: text/plain; charset="us-ascii" I have re-alpine 2.03 via OpenBSD ports and it is producing uppercase: Content-Type: TEXT/PLAIN; charset=US-ASCII But it gets the source from upstream. Either way, GMX should not be case sensitive, but it is. Regards, /Lars |
From: Werner S. <W.S...@we...> - 2013-04-19 14:48:22
|
Am 18.04.2013 schrieb Nicolas Pitre: > I wouldn't be surprised if that was enough to make your email display > properly. Dear Nicolas, I read the other posts, yes, the problem seems to be solved - or at least explained. But what I don't understand: Why does my Alpine produce headers different from yours? I'm using Alpine 2.00 without any special patches, just the standard package in the FreeBSD operating system. Curiously, Werner |
From: Nicolas P. <ni...@fl...> - 2013-04-18 18:33:54
|
On Thu, 18 Apr 2013, Tim Kröger wrote: > Thank you everybody for your great help! > > With your help, I was now able to find a workaround for the problem. That is, > I modified the re-alpine source code such that outgoing mails have > content-type "text/plain" rather than "TEXT/PLAIN". Ah! No kidding. So this is confirmed. > For those who might be interested: I only changed the file pith/send.c. See > the attached patch about the details of my changes. I know that this is very > dirty, but at least, it seems to solve the problem for me. > > I would appreciate if the re-alpine developer team would include some > less-dirty version of this patch, possibly available via some run-time option, > in one of the next versions. This would certainly help other users. If you > decide to do so, please let me know. I did a quick grep in my various mailboxes, and all the major MUAs appear to use lowercase "text/plain". So it might be best if Alpine just did the same. I don't think this warrants a config option. Nicolas |
From: Nicolas P. <ni...@fl...> - 2013-04-18 18:19:26
|
On Wed, 17 Apr 2013, Werner Scheinast wrote: > Dear Tim and others, > > could this be a problem with the line separator characters? I mean, the > web interface might expect CRLF (Windows) rather than LF (Unix). Which > operating system are you using Alpine on? > > What about my e-mail here? I don't use flowed text but explicit line > breaks - on Unix, i.e. LF. Your mail header shows: Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I can't tell how it displays on the dmx webmail interface. However your email header has lowercase "text/plain" which is one of the difference with Tim's (and mine) which have "TEXT/PLAIN". I wouldn't be surprised if that was enough to make your email display properly. Nicolas |
From: Tim K. <Tim...@gm...> - 2013-04-18 16:25:46
|
Thank you everybody for your great help! With your help, I was now able to find a workaround for the problem. That is, I modified the re-alpine source code such that outgoing mails have content-type "text/plain" rather than "TEXT/PLAIN". For those who might be interested: I only changed the file pith/send.c. See the attached patch about the details of my changes. I know that this is very dirty, but at least, it seems to solve the problem for me. I would appreciate if the re-alpine developer team would include some less-dirty version of this patch, possibly available via some run-time option, in one of the next versions. This would certainly help other users. If you decide to do so, please let me know. Of course, it is clear that the origin of this problem is a bug in the GMX webmail interface. I will write another email to them, explaining the problem in detail (now that I know it), but I guess they won't fix the bug in the near future. Best Regards, Tim On Wed, 17 Apr 2013, Tim Kröger wrote: > Dear all, > > GMX has recently released a new webmail user interface. While this > doesn't affect POP3-access to one's GMX account with re-alpine, I > notice that emails composed usings re-alpine (version 2.02) are not > displayed correctly inside the new GMX webmail user interface. That > is, the complete mail contents are displayed in one long line. > > This is not a problem for me directly, because I am hardly using the > webmail interface. But several friends of mine are using it, and they > start complaining that my emails are difficult to read. > > For me, this looks like a bug in the new GMX interface, in particular > because the same emails are displayed correctly in the old interface. > (The old interface is, however, no longer available since today.) > Nevertheless, I would like to ask the following questions: > > 1. Has anybody else also experienced this problem? Or, can anybody > say that this does *not* happen to them? (In the latter case, I would > like to compare the settings with you ...) > > 2. Since I doubt that GMX will fix this bug: Is there any chance that > the next version of re-alpine will be able to send emails that are > displayed correctly in the new GMX webmail interface? (In particular, > this problem does not seem to occur with emails sent by any other user > agent.) > > Thank you very much in advance for your advise. > > Best Regards, > > Tim > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Re-alpine-devel mailing list > Re-...@li... > https://lists.sourceforge.net/lists/listinfo/re-alpine-devel > |
From: Andreas S. <sch...@fa...> - 2013-04-17 21:43:58
|
For 1 of the main causes see [Alpine-info] No line breaks in GMX for TEXT/PLAIN http://mailman2.u.washington.edu/pipermail/alpine-info/2013-March/004935.html On Wed, 17 Apr 2013, at 20:30, Tim Kroeger wrote: > Yes, adding a "<br>" at the end of each line fixes the problem. I didn't know this, yet. It's related to the above. And GMX apparently does filter some HTML (I just tried <script> ;) it still is a severe vulnerability. Anyway, you should contact GMX and ask them to fix this ASAP. -- -- Andreas :-) |
From: Werner S. <W.S...@we...> - 2013-04-17 20:58:27
|
Dear Tim and others, could this be a problem with the line separator characters? I mean, the web interface might expect CRLF (Windows) rather than LF (Unix). Which operating system are you using Alpine on? What about my e-mail here? I don't use flowed text but explicit line breaks - on Unix, i.e. LF. Best regards, Werner |
From: Tim K. <Tim...@gm...> - 2013-04-17 19:59:49
|
Hi Joshua, Thank you for your help. I am using re-alpine also for my business emails, where the outbound email server is not GMX. If I send such an email to my GMX account, it is distorted in the same way. May I send you my .pinerc file and let you check what differences there are compared to yours? Or, alternatively, would it be okay for you that you send me your .pinerc file? Best Regards, Tim On Wed, 17 Apr 2013, Joshua Miller wrote: > Hi Tim, > > On Wed, Apr 17, 2013 at 2:30 PM, Tim Kröger <Tim...@gm...> wrote: > Hi Nicolas, > > On Wed, 17 Apr 2013, Nicolas Pitre wrote: > > Are those other user agents sending plain text or HTML emails? > > > > I'd suspect that the webmail interface you're talking about is > failing > > when displaying plain text email content. To confirm that, you may > try > > adding HTML markers in your email such as </p> or <br> at the end of > a > > paragraph to see if the displayed result gets better. > > Yes, adding a "<br>" at the end of each line fixes the problem. > However, the webmail interface itself also offers the possibility to > compose plain text emails, and *those* emails are displayed correctly. > (And I have no experience with other user agents that send plain text > emails.) > > > I did a quick test myself. FWIW to non-gmx users, gmx is a free email > service. So, I created an account and tried it out. > I sent email via alpine 2.02 (from ubuntu repo) to my new gmx account, and > it formatted correctly. I sent two ways: > > 1. S/MIME signed plain text > 2. plain text with no sig or attachments > > Both displayed correctly in the gmx webmail interface. This leads me to > believe there is something weird with either your alpine settings, your mail > transport agent, or your outbound mail server. Have you tried sending > through a different outbound mail server, perhaps using a different account > (ex. through google)? That could rule out an alpine-specific issue, or > confirm it. > > I also tried sending from GMX to myself. It looks like a normal plain text > email. For those interested: > > Content-Type: text/plain; charset="utf-8" > Date: Wed, 17 Apr 2013 15:32:43 -0400 > From: "Joshua Miller" <un...@gm...> > Message-ID: <201...@gm...> > MIME-Version: 1.0 > Subject: test to gmail from gmx > To: un...@gm... > X-Flags: 0001 > X-Mailer: GMX.com Web Mailer > x-registered: 0 > Content-Transfer-Encoding: 8bit > X-GMX-UID: jJ0cccEj3zOlOKyaD30hSVN+IGRvb8BT > > Hi there myself, > > testing mail from gmx. > Going to gmail. > > Stuff and things. > Thanks, > -- > Josh I. > > > So, I'd suggesting testing sending through a different outbound email > provider to gmx, and then looking over your alpine config (maybe starting > from scratch). > Hope that helps, > -- > Josh I. > > |
From: Joshua M. <un...@gm...> - 2013-04-17 19:45:05
|
Hi Tim, On Wed, Apr 17, 2013 at 2:30 PM, Tim Kröger <Tim...@gm...> wrote: > Hi Nicolas, > > On Wed, 17 Apr 2013, Nicolas Pitre wrote: > > Are those other user agents sending plain text or HTML emails? > > > > I'd suspect that the webmail interface you're talking about is failing > > when displaying plain text email content. To confirm that, you may try > > adding HTML markers in your email such as </p> or <br> at the end of a > > paragraph to see if the displayed result gets better. > > Yes, adding a "<br>" at the end of each line fixes the problem. > However, the webmail interface itself also offers the possibility to > compose plain text emails, and *those* emails are displayed correctly. > (And I have no experience with other user agents that send plain text > emails.) > > I did a quick test myself. FWIW to non-gmx users, gmx is a free email service. So, I created an account and tried it out. I sent email via alpine 2.02 (from ubuntu repo) to my new gmx account, and it formatted correctly. I sent two ways: 1. S/MIME signed plain text 2. plain text with no sig or attachments Both displayed correctly in the gmx webmail interface. This leads me to believe there is something weird with either your alpine settings, your mail transport agent, or your outbound mail server. Have you tried sending through a different outbound mail server, perhaps using a different account (ex. through google)? That could rule out an alpine-specific issue, or confirm it. I also tried sending from GMX to myself. It looks like a normal plain text email. For those interested: Content-Type: text/plain; charset="utf-8" Date: Wed, 17 Apr 2013 15:32:43 -0400 From: "Joshua Miller" <un...@gm...> Message-ID: <201...@gm...> MIME-Version: 1.0 Subject: test to gmail from gmx To: un...@gm... X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: jJ0cccEj3zOlOKyaD30hSVN+IGRvb8BT Hi there myself, testing mail from gmx. Going to gmail. Stuff and things. Thanks, -- Josh I. So, I'd suggesting testing sending through a different outbound email provider to gmx, and then looking over your alpine config (maybe starting from scratch). Hope that helps, -- Josh I. |
From: Nicolas P. <ni...@fl...> - 2013-04-17 19:03:07
|
On Wed, 17 Apr 2013, Tim Kröger wrote: > On Wed, 17 Apr 2013, Nicolas Pitre wrote: > > > Are those other user agents sending plain text or HTML emails? > > > > I'd suspect that the webmail interface you're talking about is failing > > when displaying plain text email content. To confirm that, you may try > > adding HTML markers in your email such as </p> or <br> at the end of a > > paragraph to see if the displayed result gets better. > > Yes, adding a "<br>" at the end of each line fixes the problem. However, the > webmail interface itself also offers the possibility to compose plain text > emails, and *those* emails are displayed correctly. (And I have no experience > with other user agents that send plain text emails.) Clearly, if the web interface does interpret the HTML markers you put in a plain text email, that means it failed to recognize it as a plain text email and assumes it is HTML by default. Could you compose such a plain text email in the web interface and send it to me? I'm curious to see how its header would look like. Nicolas |
From: Tim K. <Tim...@gm...> - 2013-04-17 18:30:40
|
Hi Nicolas, On Wed, 17 Apr 2013, Nicolas Pitre wrote: > On Wed, 17 Apr 2013, Tim Kröger wrote: > >> This is not a problem for me directly, because I am hardly using the >> webmail interface. But several friends of mine are using it, and they >> start complaining that my emails are difficult to read. >> >> For me, this looks like a bug in the new GMX interface, in particular >> because the same emails are displayed correctly in the old interface. >> (The old interface is, however, no longer available since today.) >> Nevertheless, I would like to ask the following questions: >> >> 1. Has anybody else also experienced this problem? Or, can anybody >> say that this does *not* happen to them? (In the latter case, I would >> like to compare the settings with you ...) > > I have no familiarity with gmx what so ever. But you might try playing > with the alpine flowed text settings to see if they make any difference. I tried that already, it doesn't help. Also, I can say that your email gets distorted the same way as mine does. >> 2. Since I doubt that GMX will fix this bug: Is there any chance that >> the next version of re-alpine will be able to send emails that are >> displayed correctly in the new GMX webmail interface? (In particular, >> this problem does not seem to occur with emails sent by any other user >> agent.) > > Are those other user agents sending plain text or HTML emails? > > I'd suspect that the webmail interface you're talking about is failing > when displaying plain text email content. To confirm that, you may try > adding HTML markers in your email such as </p> or <br> at the end of a > paragraph to see if the displayed result gets better. Yes, adding a "<br>" at the end of each line fixes the problem. However, the webmail interface itself also offers the possibility to compose plain text emails, and *those* emails are displayed correctly. (And I have no experience with other user agents that send plain text emails.) > If so that would be a serious bug in that web interface and I'd > strongly advise you press them to fix it. I don't see any chance for this at the moment. They are not replying to emails, and the only phone number they offer is extremely expensive. Best Regards, Tim |
From: Nicolas P. <ni...@fl...> - 2013-04-17 18:16:27
|
On Wed, 17 Apr 2013, Tim Kröger wrote: > This is not a problem for me directly, because I am hardly using the > webmail interface. But several friends of mine are using it, and they > start complaining that my emails are difficult to read. > > For me, this looks like a bug in the new GMX interface, in particular > because the same emails are displayed correctly in the old interface. > (The old interface is, however, no longer available since today.) > Nevertheless, I would like to ask the following questions: > > 1. Has anybody else also experienced this problem? Or, can anybody > say that this does *not* happen to them? (In the latter case, I would > like to compare the settings with you ...) I have no familiarity with gmx what so ever. But you might try playing with the alpine flowed text settings to see if they make any difference. > 2. Since I doubt that GMX will fix this bug: Is there any chance that > the next version of re-alpine will be able to send emails that are > displayed correctly in the new GMX webmail interface? (In particular, > this problem does not seem to occur with emails sent by any other user > agent.) Are those other user agents sending plain text or HTML emails? I'd suspect that the webmail interface you're talking about is failing when displaying plain text email content. To confirm that, you may try adding HTML markers in your email such as </p> or <br> at the end of a paragraph to see if the displayed result gets better. If so that would be a serious bug in that web interface and I'd strongly advise you press them to fix it. Nicolas |
From: Tim K. <Tim...@gm...> - 2013-04-17 17:42:37
|
Dear all, GMX has recently released a new webmail user interface. While this doesn't affect POP3-access to one's GMX account with re-alpine, I notice that emails composed usings re-alpine (version 2.02) are not displayed correctly inside the new GMX webmail user interface. That is, the complete mail contents are displayed in one long line. This is not a problem for me directly, because I am hardly using the webmail interface. But several friends of mine are using it, and they start complaining that my emails are difficult to read. For me, this looks like a bug in the new GMX interface, in particular because the same emails are displayed correctly in the old interface. (The old interface is, however, no longer available since today.) Nevertheless, I would like to ask the following questions: 1. Has anybody else also experienced this problem? Or, can anybody say that this does *not* happen to them? (In the latter case, I would like to compare the settings with you ...) 2. Since I doubt that GMX will fix this bug: Is there any chance that the next version of re-alpine will be able to send emails that are displayed correctly in the new GMX webmail interface? (In particular, this problem does not seem to occur with emails sent by any other user agent.) Thank you very much in advance for your advise. Best Regards, Tim |
From: Lars N. <lar...@gm...> - 2013-04-07 18:14:55
|
I looked into gnupg/PGP some more and here is a possible solution to get re-alpine to encrypt, decrypt and sign using PGP keys. Here is one way to set .pinerc for that: display-filters=_BEGINNING("-----BEGIN PGP ")_ /usr/local/bin/gpg -d _TMPFILE_ | less sending-filters=/usr/local/bin/gpg-encrypt --armor --encrypt --recipient _RECIPIENTS_ --recipient gpg-identifier, /usr/local/bin/gpg-sign --clearsign _INCLUDEALLHDRS_, /usr/local/bin/gpg-sign-encrypt --sign --armor --encrypt --recipient _INCLUDEALLHDRS_ _RECIPIENTS_ -r gpg-identifier Substitute 'gpg-identifier' for the appropriate value for your key. This is needed so you can decrypt the message stored in sent-mail. I'd like to think there was a way to decrypt without using _TMPFILE_ but I could not find it on my own. The only fiddling that needs to be done on the system is to symlink gpg-sign, gpg-encrypt and gpg-sign-encrypt to the gpg executable. That is only needed to make it clear what the sending filter is really doing. However, if something goes wrong, the error is only on the screen for a fraction of a second which makes it harder to diagnose. Also, this method doesn't allow for quoting of encrypted messages in replies. Regards, /Lars |
From: Andreas S. <sch...@fa...> - 2013-04-06 13:25:48
|
On Sat, 6 Apr 2013, at 16:11, Lars Nooden wrote: > Are there any good into guides that > you know of for S/MIME certificates? I wish I knew. I learned a lot from the Mozilla (Thunderbird) docs, e.g. Getting an SMIME certificate - MozillaZine Knowledge Base http://kb.mozillazine.org/Getting_an_SMIME_certificate and the OpenSSL howtos, e.g. How To Encrypt Mails With SSL Certificates (S/MIME) | HowtoForge http://www.howtoforge.com/how-to-encrypt-mails-with-ssl-certificates-s-mime For Alpine there are of course the built-in help screens and http://www.washington.edu/alpine/tech-notes/config-notes.html HTH, -- -- Andreas |
From: Lars N. <lar...@gm...> - 2013-04-06 13:12:19
|
On Sat, 6 Apr 2013, Andreas Schamanek wrote: > On Sat, 6 Apr 2013, at 15:54, Lars Nooden wrote: > > > re-alpine has built-in support for encryption and signing messages > > using certificates. Can these certificates be generated from > > existing PGP keys? If so, how? > > Wait, I don't understand. Alpine has built-in support for S/MIME, not > for PGP (there add-ons, though). I've never heard of a way to convert > PGP keys to S/MIME certificates. Ok. That would be the answer then. Are there any good into guides that you know of for S/MIME certificates? Regards, /Lars |