Hi, I just noticed that the lack of emails from my backup program seems to be because of the missing message ids in the mail script I use. In case of no message id inside the header, sup uses the md5sum of the whole header (see lib/sup/message.rb:74). This effectively means that messages having the same md5sum of their header (which happened, since the header was also generated completely by the script and the values did not change) will "overwrite" the old message. As a workaround, I now added the current time to my script, so that every header will have a different md5 sum. But maybe we can think of a more clever way to generate faked message ids? Maybe also hash the body of the message? Best regards, Michael
Reformatted excerpts from Michael Stapelberg''s message of 2009-10-15:> I just noticed that the lack of emails from my backup program seems to be > because of the missing message ids in the mail script I use. In case of > no message id inside the header, sup uses the md5sum of the whole header > (see lib/sup/message.rb:74). This effectively means that messages having > the same md5sum of their header (which happened, since the header was also > generated completely by the script and the values did not change) will > "overwrite" the old message.Doesn''t the header include the date? -- William <wmorgan-sup at masanjin.net>
Hi William, Excerpts from William Morgan''s message of Thu Oct 15 15:47:36 +0200 2009:> Doesn''t the header include the date?No, in my case it did not. The reason for that is calling "deliver" directly, that is without talking SMTP to a mailserver. Thus, no headers are getting added. Surely this is a corner case, but I think it will cause headache for system administrators running into this one, if they notice it all (overwriting messages is quite dangerous). Best regards, Michael
Reformatted excerpts from Michael Stapelberg''s message of 2009-10-15:> No, in my case it did not. The reason for that is calling "deliver" > directly, that is without talking SMTP to a mailserver. Thus, no > headers are getting added. Surely this is a corner case, but I think > it will cause headache for system administrators running into this > one, if they notice it all (overwriting messages is quite dangerous).Ok. I think it''s fine to generate the message id via another mechanism, e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}"). -- William <wmorgan-sup at masanjin.net>
Excerpts from William Morgan''s message of Thu Oct 15 17:29:29 +0200 2009:> Reformatted excerpts from Michael Stapelberg''s message of 2009-10-15: > > No, in my case it did not. The reason for that is calling "deliver" > > directly, that is without talking SMTP to a mailserver. Thus, no > > headers are getting added. Surely this is a corner case, but I think > > it will cause headache for system administrators running into this > > one, if they notice it all (overwriting messages is quite dangerous). > > Ok. I think it''s fine to generate the message id via another mechanism, > e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}").This way we loose the reproducibility, but I concede that we can''t have both. -- Nicolas Pouillard http://nicolaspouillard.fr
Excerpts from William Morgan''s message of Thu Oct 15 08:29:29 -0700 2009:> Ok. I think it''s fine to generate the message id via another mechanism, > e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand > 10000}@#{hostname}").Won''t that then make sup insert duplicate documents into the index for any run of sup-sync --all over the relevant sources? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091015/78f02bbd/attachment.bin>