Roundup Tracker - Issues

Message4524

Author vries
Recipients vries
Date 2012-03-30.11:16:59
Message-id <1333106220.03.0.265807397089.issue2550752@psf.upfronthosting.co.za>
In-reply-to
Hi,

we're using roundup as issue tracker and exchange as email server.

We have a problem related to an issue with both:
- me and,
- a mailing list I'm a member of
in the nosy list.

When I do an update of the issue, emails get send to me and the mailing
list (due to configuration option NOSY_EMAIL_SENDING == single), with
each email containing only a single addressee.

when the 2 messages arrive, one stays in my inbox, the other one is
filtered to the mailing list folder.

The problem is that sometimes only one message arrives (any of the two).
I've tracked this down to the following:
when a message arrives at the exchange server, and that message has the
same Message-id and the same Date field as an earlier message, the
second message is dropped (documented here:
http://technet.microsoft.com/en-us/library/dd577073%28v=exchg.80%29.aspx#1
).

When roundup sends the 2 emails, it sends it with the same message-id,
but not necessarily with the same Date.

So if the Date field is different, I receive 2 emails. If the Date field
is the same I receive 1 email (the first one to arrive).

From my user perspective, this is bad: I expect the email addressed to
me to appear in my inbox.

I looked at the sources for roundup-1.4.19 and I think the behaviour is
the same there. This piece of code is of interest:
roundupdb.py:send_message:
...
        # send an individual message per recipient?
        if self.db.config.NOSY_EMAIL_SENDING != 'single':
            sendto = [[address] for address in sendto]
        else:
            sendto = [sendto]

        # tracker sender info
        tracker_name = unicode(self.db.config.TRACKER_NAME, 'utf-8')
        tracker_name = nice_sender_header(tracker_name, from_address,
            charset)

        # now send one or more messages
        # TODO: I believe we have to create a new message each time as we
        # can't fiddle the recipients in the message ... worth testing
        # and/or fixing some day
        first = True
        for sendto in sendto:
            # create the message
            mailer = Mailer(self.db.config)

            message = mailer.get_standard_message(sendto, subject, author,
                multipart=message_files)

            # set reply-to to the tracker
            message['Reply-To'] = tracker_name

            # message ids
            if messageid:
                message['Message-Id'] = messageid
            if inreplyto:
                message['In-Reply-To'] = inreplyto
...
In the single mode (each in the cc-list an individual message), we call
get_standard_message for each recipient, which creates a Date field with
current time. We then stamp the same message-id on each email, but don't
change the date field.

If we force the Date to be the same for all messages, I'll never get two
messages, only one (timing-dependent which one).

If we force the Date to be different for all messages, I always get two
messages, but it's a not so pretty workaround for the specifics of
exchange duplicate message detection, and may not work for other similar
duplicate elimination programs.

I think the cleanest fix would be to have a different message-id for
each message. But, I'm not sure about the drawbacks of doing that.

What I understand from the standard (http://tools.ietf.org/html/rfc5322)
though is that same or different message-id depends on the intent of the
sender:
...
In all cases, it is the meaning that the sender of the message wishes to
convey (i.e., whether this is the same message or a different message)
that determines whether or not the "Message-ID:" field changes, not any
particular syntactic difference that appears (or does not appear) in the
message.
...
One could argue that the 2 emails messages are different because each
has a different addressee.

Thanks,
- Tom
History
Date User Action Args
2012-03-30 11:17:00vriessetrecipients: + vries
2012-03-30 11:17:00vriessetmessageid: <1333106220.03.0.265807397089.issue2550752@psf.upfronthosting.co.za>
2012-03-30 11:16:59vrieslinkissue2550752 messages
2012-03-30 11:16:59vriescreate