| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68577
|
Wed Feb 8 18:16:30 2017 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1 | Re: Possible misuse of email headers Message-Id and In-Reply-To |
A pull request would be highy appreciated, because you can then test it thoroughly on your side. Adding a random number to the message id is simple. "Reply-to" indeed does not make sense since elog cannot receive emails. Most sites use a generic "noreply@<domain>" to indicate to the user that a reply does not make sense. I guess the "Reply-to" does not have to be unique, right?
| fbretel wrote: |
|
Hi,
As mentionned before, we happen to fail to receive email messages related to updates on elog entries at our site. My understanding is that the SMTP header Message-Id MUST be unique for each email message. Whereas all elogd email messages get something like <logbook>-<entryId>@<domain>. See source code. For this header to become unique, there should be a random part in it.
Having the same Message-Id in multiple email messages results in only the first one being delivered on some email systems.
Moreover, elogd sets the In-Reply-To: header in the same manner (<logbook>-<entryId>@<domain>). Which is incorrect because this header relates to email messages, not elog entries, and should contain the email Message-Id of the email message to which it replies, itself handled by the email messaing system. But elogd hasn't received any email messsage in the first place. So I believe this header should simply be dropped.
I think I can provide a pull request on bitbucket for the Message-Id issue, and probably also for the In-Reply-To: if you decide it can be removed.
Cheers
|
|
|
68578
|
Wed Mar 15 16:04:13 2017 |
| fbretel | nothx@hello.com | Bug report | Linux | 3.1.1 | Re: Possible misuse of email headers Message-Id and In-Reply-To |
Pull-request posted. Cheers. |
|
68579
|
Wed Mar 15 16:42:35 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1 | Re: Possible misuse of email headers Message-Id and In-Reply-To |
Pull-request merged.
|
|
68268
|
Fri Feb 26 09:09:03 2016 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1-1 | Re: Possible bug in elogd execute_shell |
Absolutely correct! Nice to see compilers getting better and better. I changed the code and committed it.
| Nigel Warr wrote: |
|
I was just playing around with gcc6's new feature for warning about misleading indentation (which can often hide real bugs) and I think it found one in elog-3.1.1-1 at src/elogd.c:22538. Here there is an if statement, which looks as though it should be inside a loop, but it isn't. The code is:
for (i = 0; i < MAX_ATTACHMENTS; i++)
generate_subdir_name(att_file[i], subdir, sizeof(subdir));
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strl$
< sizeof(shell_cmd) + 1) {
strcpy(p, "\"");
strcat(p, lbs->data_dir);
strlcat(str, subdir, sizeof(str));
strlcpy(str, att_file[i], sizeof(str));
str_escape(str, sizeof(str));
strcat(p, str);
strcat(p, "\" ");
p += strlen(p);
}
and the if statment is accessing the loop variable i but it is actually outside the loop. Presumably, there should be some more curly brackets here. gcc6 gave the warning:
src/elogd.c: In function ‘execute_shell’:
src/elogd.c:22538:10: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strlen(subdir) + strlen(att_file[i])
^~
src/elogd.c:22536:7: note: ...this ‘for’ clause, but it is not
for (i = 0; i < MAX_ATTACHMENTS; i++)
^~~
|
|
|
606
|
Thu Jul 15 09:44:08 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.5.3 | Re: Possible Formatting bug: Summary view |
> A temporary fix for this is to set summary lines = 0
Right, that's the only way. I would call this "permanent fix" (;-) |
|
611
|
Fri Jul 16 04:37:47 2004 |
 | Steve Jones | steve.jones@freescale.com | Bug report | All | 2.5.3 | Re: Possible Formatting bug: Summary view |
> > A temporary fix for this is to set summary lines = 0
>
> Right, that's the only way. I would call this "permanent fix" (;-)
I would too - and it actually produces the output that I wanted to see anyway.
Thanks! |
|
347
|
Tue May 20 14:23:56 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | | | Re: Possible Bug: 2.3.7 : Welcome Title = < img src= |
> I noticed that my custom start page did not display the Welcome title icon.
> It worked fine in prior elogs.
>
> any hints?
Indeed there is a bug, it has to do that some icons wnt into the themes
directory and are served now from there. So the bug will fixed in the next
version (the fix is already avaliable from CVS). As a temporary workaround
you just move your image to the themese/default/ directory and it should
work.
An absolute path like /usr/local/... does not work, because this would open
a security hole (someone could access any picture on your computer just by
requesting an absolute path in the URL), so I removed that option from the
software and the documentation. |
|
348
|
Tue May 20 19:09:26 2003 |
| Fred Hooper | fhooper@sushisoft.com | Bug report | | | Re: Possible Bug: 2.3.7 : Welcome Title = < img src= |
> > I noticed that my custom start page did not display the Welcome title icon.
> > It worked fine in prior elogs.
> >
> > any hints?
>
> Indeed there is a bug, it has to do that some icons wnt into the themes
> directory and are served now from there. So the bug will fixed in the next
> version (the fix is already avaliable from CVS). As a temporary workaround
> you just move your image to the themese/default/ directory and it should
> work.
>
> An absolute path like /usr/local/... does not work, because this would open
> a security hole (someone could access any picture on your computer just by
> requesting an absolute path in the URL), so I removed that option from the
> software and the documentation.
I did the work-around (moving icon to theme/default) and it worked. Thanks.
Now if you just port elog over to an apache and mysql enviroment, it would be
perfect! |