* [sup-talk] sup-sync & missing message-ids
@ 2007-07-23 17:48 Dan Sully
2007-07-24 17:56 ` William Morgan
0 siblings, 1 reply; 4+ messages in thread
From: Dan Sully @ 2007-07-23 17:48 UTC (permalink / raw)
For whatever reason, there are messages in my Maildir that don't have
message-ids in their headers. sup-sync bitches about that rather loudly..
would it be better to artificially construct a message-id?
Also, in the playing well with others category - sup doesn't seem to handle
the case where a message gets moved from Maildir/new/ to Maildir/cur/ if that
folder is read via IMAP from another client.. is this fixable in sup, or part
of the rubymail library?
Thanks
-D
--
<dsully> please describe web 2.0 to me in 2 sentences or less.
<jwb> you make all the content. they keep all the revenue.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [sup-talk] sup-sync & missing message-ids
2007-07-23 17:48 [sup-talk] sup-sync & missing message-ids Dan Sully
@ 2007-07-24 17:56 ` William Morgan
2007-07-24 18:13 ` Dan Sully
0 siblings, 1 reply; 4+ messages in thread
From: William Morgan @ 2007-07-24 17:56 UTC (permalink / raw)
Excerpts from Dan Sully's message of Mon Jul 23 10:48:09 -0700 2007:
> For whatever reason, there are messages in my Maildir that don't have
> message-ids in their headers. sup-sync bitches about that rather
> loudly.. would it be better to artificially construct a message-id?
If this really is a prevalent thing, then yes, I'm happy to fake a
message-id.
> Also, in the playing well with others category - sup doesn't seem to
> handle the case where a message gets moved from Maildir/new/ to
> Maildir/cur/ if that folder is read via IMAP from another client.. is
> this fixable in sup, or part of the rubymail library?
This has nothing to do with RubyMail; Sup simply doesn't play well with
other clients. Part of the tradeoff I made with Sup was to assume by
default that the source never changes except through Sup. If that
assumption fails, Sup should detect it and ask you to run sup-sync
--changed, which should bring everything back in sync.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [sup-talk] sup-sync & missing message-ids
2007-07-24 17:56 ` William Morgan
@ 2007-07-24 18:13 ` Dan Sully
2007-07-25 0:05 ` William Morgan
0 siblings, 1 reply; 4+ messages in thread
From: Dan Sully @ 2007-07-24 18:13 UTC (permalink / raw)
* William Morgan shaped the electrons to say...
>> For whatever reason, there are messages in my Maildir that don't have
>> message-ids in their headers. sup-sync bitches about that rather
>> loudly.. would it be better to artificially construct a message-id?
>
>If this really is a prevalent thing, then yes, I'm happy to fake a
>message-id.
Yeah - I see it a lot. Also seeing mail with missing Date: headers. Most (but
not all) is sent from automated systems, ie: order confirmation, etc.
I've attached a patch which is working for me with message-id.. a bit of a
hack.
>This has nothing to do with RubyMail; Sup simply doesn't play well with
>other clients. Part of the tradeoff I made with Sup was to assume by
>default that the source never changes except through Sup. If that
>assumption fails, Sup should detect it and ask you to run sup-sync
>--changed, which should bring everything back in sync.
Yeah.. just a little inconvient if I'm checking mail via my iPhone then have
to sup-sync before reading when I'm back in front of a terminal. Any issues
with running sup-sync via cron ?
-D
--
<dsully> please describe web 2.0 to me in 2 sentences or less.
<jwb> you make all the content. they keep all the revenue.
-------------- next part --------------
--- message.rb.orig 2007-07-23 11:16:12.000000000 -0700
+++ message.rb 2007-07-23 11:42:15.000000000 -0700
@@ -107,7 +107,8 @@
def read_header header
header.each { |k, v| header[k.downcase] = v }
- %w(message-id date).each do |f|
+ #%w(message-id date).each do |f|
+ %w(date).each do |f|
raise MessageFormatError, "no #{f} field in header #{header.inspect} (source #@source offset #@source_info)" unless header.include? f
raise MessageFormatError, "nil #{f} field in header #{header.inspect} (source #@source offset #@source_info)" unless header[f]
end
@@ -124,7 +125,7 @@
@to = PersonManager.people_for header["to"]
@cc = PersonManager.people_for header["cc"]
@bcc = PersonManager.people_for header["bcc"]
- @id = header["message-id"]
+ @id = header["message-id"] || header["from"].match(/\b(\S+?@\S+)\b/).captures.to_s + "." + @date.to_i.to_s
@refs = (header["references"] || "").gsub(/[<>]/, "").split(/\s+/).flatten
@replytos = (header["in-reply-to"] || "").scan(/<(.*?)>/).flatten
@replyto = PersonManager.person_for header["reply-to"]
^ permalink raw reply [flat|nested] 4+ messages in thread* [sup-talk] sup-sync & missing message-ids
2007-07-24 18:13 ` Dan Sully
@ 2007-07-25 0:05 ` William Morgan
0 siblings, 0 replies; 4+ messages in thread
From: William Morgan @ 2007-07-25 0:05 UTC (permalink / raw)
Excerpts from Dan Sully's message of Tue Jul 24 11:13:58 -0700 2007:
> I've attached a patch which is working for me with message-id.. a bit
> of a hack.
Thanks. I've committed a modification of this. (I create the message-id by
hashing the raw header text, which hopefully this should have all the nice
uniqueness and consistency properties a message id should have.)
> Any issues with running sup-sync via cron ?
Shouldn't be, though that only works if you haven't used your iphone
between the last cron run and when you invoke sup. Unless the folder is
really large, you might instead consider running sup-sync immediately
before running Sup and considering it an annoying startup delay. :)
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-07-25 0:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-07-23 17:48 [sup-talk] sup-sync & missing message-ids Dan Sully
2007-07-24 17:56 ` William Morgan
2007-07-24 18:13 ` Dan Sully
2007-07-25 0:05 ` William Morgan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox