ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
1375
|
Thu Aug 4 22:59:12 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.0b3 | Re: Email subject garbaged when set? |
Chris Green wrote: | The email I get has:
Subject:
=?ISO-8859-1?B?W0Jvb05FLUVMT0ddIE5ldyBzdWJtaXNzaW9uIHRvIENoYXJnZWQgQ3Vyc
mVudCBQaSBQbHVzIGZyb20gQ2hyaXMgR3JlZW4=?=
... which isn't particularly illuminating. |
This is the BASE64 encoding of the subject. It was discussed here and I implemented it according to RFC2047. All subjects I receive look fine in Outlook and Thunderbird, but not under Pine, which apparently does not implement the RFC correctly. One could of course put a switch into elog to encode it or not. But as soon as you want to send some non-ASCII characters (like the Norwegian as described in the thread mentioned above) you have a problem. Maybe you can configure your email client correctly to interprete the encoded subject? |
1376
|
Fri Aug 5 01:13:13 2005 |
| Chris Green | greenc@fnal.gov | Question | Linux | 2.6.0b3 | Re: Email subject garbaged when set? |
Stefan Ritt wrote: |
Chris Green wrote: | The email I get has:
Subject:
=?ISO-8859-1?B?W0Jvb05FLUVMT0ddIE5ldyBzdWJtaXNzaW9uIHRvIENoYXJnZWQgQ3Vyc
mVudCBQaSBQbHVzIGZyb20gQ2hyaXMgR3JlZW4=?=
... which isn't particularly illuminating. |
This is the BASE64 encoding of the subject. It was discussed here and I implemented it according to RFC2047. All subjects I receive look fine in Outlook and Thunderbird, but not under Pine, which apparently does not implement the RFC correctly. One could of course put a switch into elog to encode it or not. But as soon as you want to send some non-ASCII characters (like the Norwegian as described in the thread mentioned above) you have a problem. Maybe you can configure your email client correctly to interprete the encoded subject? |
Apparently the pine people think they're implementing it correctly. Indeed the default subject, "[ISO-8859-1] New ELOG entry" appears just fine. The one for membership confirmation, and anything set in Use Email Subject, however, is borked as above. Maybe the pine bug is something that can be worked around with something simple (like spaces after the ISO spec, or something? Some things work just fine, as I said.
Thanks,
Chris. |
1384
|
Fri Aug 5 11:18:08 2005 |
| Heiko Scheit | h.scheit@mpi-hd.mpg.de | Question | Linux | 2.6.0b3 | Re: Email subject garbaged when set? |
Stefan Ritt wrote: |
Chris Green wrote: | The email I get has:
Subject:
=?ISO-8859-1?B?W0Jvb05FLUVMT0ddIE5ldyBzdWJtaXNzaW9uIHRvIENoYXJnZWQgQ3Vyc
mVudCBQaSBQbHVzIGZyb20gQ2hyaXMgR3JlZW4=?=
... which isn't particularly illuminating. |
This is the BASE64 encoding of the subject. It was discussed here and I implemented it according to RFC2047. |
Well not quite. According to the RFC the encoded word must not be longer than 75 characters! Indeed
shorter subjects are displayed by pine, but not longer ones as they do not follow RFC2047.
Below is the quote from the RFC.
Stefan Ritt wrote: |
All subjects I receive look fine in Outlook and Thunderbird, but not under Pine, which apparently does not implement the RFC correctly.
|
Actually pine implements it correctly but not elogd 
The relevant text from the RFC
An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.
|
1386
|
Fri Aug 5 12:37:42 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.0b3 | Re: Email subject garbaged when set? |
Heiko Scheit wrote: | Well not quite. According to the RFC the encoded word must not be longer than 75 characters! Indeed shorter subjects are displayed by pine, but not longer ones as they do not follow RFC2047.
Below is the quote from the RFC. |
You are right , thanks for this information, I overlooked it.
Now I split a long subject into separate chunks of encoded words, and my pine is happy. Update in CVS. |
66244
|
Mon Mar 9 19:00:26 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Windows | 2.7.5 | Re: Email recall function similar to what exists say in something like Outlook |
Niall Dooley wrote: |
Hi,
Is there a way perhaps of implementing an email recall feature into E-Log? In other words, to recall an email before the recipient (s) read the email originating from the e-log. Something perhaps along the lines of what exists in something like Outlook.
Thks in advance.
Regards,
Niall
|
No, this is not implemented. What I usually do is to check "Suppress Email notification", submit and revise my entry. Once I'm satisfied, I edit again and do not check "Suppress Email notification" so that the email is finally sent out. |
65637
|
Fri Oct 26 11:44:36 2007 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.6.5-1844 | Re: Email notification: "Use Email From = " always set to admin |
Alan Stone wrote: |
My current syntax is:
; Email notification
Suppress Email to users = 0
Omit Email To = 1
Use Email Subject = $system: $subject
#Use Email From = Author Email
Email Report General = hn-cms-dataopslog@cern.ch, cms-dataops@fnal.gov
I had to comment out the 'Use Email From' option because all forwarded
entries to the CMS HyperNews or Fermilab ListServer appeared to originate
from me (alstone@fnal.gov), even though other users were logged in and
saving the entries to the logbook. After commenting out this line, the
entries were properly credited when forwarded, although the
There are two admins defined in the [global] section, and "alstone" is
not the first name in the "Admin user" list.
Is this a bug, or have I used this option incorrectly?
Alan |
Documentation says:
If Use Email From is present, it is always used. If not, the email address of the currently logged in user is used for the "From:" field. If no user is logged in, or the current user has not specified a email address in the password database, the setting of the option Default Email From is used for the "From:" field. Only if this option is not specified, a generic address ELOG@<hostname> is used, which might be rejected by the SMTP server however.
So if you write
Use Email From = me@some.where
then of course all emails have "me@some.where" in the From: field. If you want the email of the people logged in, you either remove this option (since it's the default anyhow), or you write explicitly
Use Email From = $user_email |
1826
|
Wed May 10 16:16:33 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.1 | Re: Email notification question |
Kevin McCarty wrote: | Hello,
I've just set up an ELog server for my research group. (Running on Debian, package version 2.6.1+r1642-1)
I have a question about the email notifications. I read through the config file documentation, but couldn't find the answer (maybe I am just unobservant\?) Is it possible to have the email notifications contain only the title of the log entry (as well as the usual attributes), but not the full text or any attachments? I have users who are worried about their email going over quota from ELog's emails, but who nevertheless would like some kind of notification when new log entries are posted.
Thanks in advance! |
Have a look at the option Email format = <n> |
1828
|
Wed May 10 16:55:28 2006 |
| Kevin McCarty | kmccarty@princeton.edu | Question | Linux | 2.6.1 | Re: Email notification question |
Stefan Ritt wrote: |
Kevin McCarty wrote: | Hello,
I've just set up an ELog server for my research group. (Running on Debian, package version 2.6.1+r1642-1)
I have a question about the email notifications. I read through the config file documentation, but couldn't find the answer (maybe I am just unobservant\?) Is it possible to have the email notifications contain only the title of the log entry (as well as the usual attributes), but not the full text or any attachments? I have users who are worried about their email going over quota from ELog's emails, but who nevertheless would like some kind of notification when new log entries are posted.
Thanks in advance! |
Have a look at the option Email format = <n> |
Ah, thank you! Somehow I overlooked that. My apologies, and thanks for your very fast response. |
|