[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Feb 2003 15:40:06 -0600
From: Thomas Hays <thays@...isgroup.com>
To: popa3d-users@...ts.openwall.com
Subject: Re: Outlook 2002 duplicate emails
Thanks for the response, I've provided additional info below under the
relevant questions/observations.
On Fri, Feb 28, 2003 at 11:55:57PM +0300, Solar Designer wrote:
> On Fri, Feb 28, 2003 at 11:57:30AM -0600, Thomas Hays wrote:
>
> Hi,
>
> > Here is a sample mbox file that I am using to reproduce the error:
> > http://gold.aegisgroup.com/test.bad.gz
>
<SNIP>
> My opinion is that this should be dealt with in Postfix. I did test
> Postfix for this property previously and my results were different
> from yours (qmail had the unfortunate property, while the versions of
> sendmail and Postfix that I've tested didn't). What version of
> Postfix are you using? Could you share the details of how the two
> mail aliases are setup?
>
Postfix behaviour does differ from Sendmail in this case. I won't even
try to guess which is the "correct" behaviour, however, it appears
that Postfix isn't planning on changing if I read their FAQ
correctly:
http://www.postfix.org/faq.html#duplicate
I am using Postfix version 1.1.11. I do note they have two newer
releases 1.1.12 and 2.0.4. Unfortunately, the release notes do not
appear to have been updated to show what's different in 1.1.12 versus
1.1.11. I can't move to 2.0.x until I have time to test it since it's
quite different. Unfortunately, based on the FAQ above, it seems
unlikely this has changed.
Specifically, to reproduce the problem I have a user called "test"
defined in my /etc/passwd file and in my /etc/aliases file I have a
group defined as:
testgroup: test
When I then send an email to "testgroup" and cc "test" I get the mbox
that causes the problem.
I was reading over rfc 1939 earlier and noticed it says:
The unique-id of a message is an arbitrary server-determined
string, consisting of one to 70 characters in the range 0x21
to 0x7E, which uniquely identifies a message within a
maildrop and which persists across sessions.
Based on this, could we not tack on an extra 8 (or 16 or whatever)
characters that would make the message unique. I have a patch that
does this and seems to work. Basically, I modified
pop_trans_list_or_uidl_all() and added a counter to the "for" loop and
append that to the hash. For example, I now have hashes that look
like:
80c3fb08daf1feed00000000
80c3fb08daf1feed00000001
I also changed pop_trans_list_or_uidl() and did the same thing, only
I append "number - 1".
I may be completely wrong in suggesting the above, and the solution
below is probably better. However, here's the patch I did that seems
to work on some very small tests I've done (ie. no real world tests):
http://gold.aegisgroup.com/popa3d-0.6-tdh.patch.gz
> BTW, I have a qmail 1.03 patch which solves this by adding an
> X-Delivery-ID: header, which popa3d is prepared to handle. I should
> probably make it available.
It would be great to see this patch if what I mentioned above isn't
good.
Thanks again for the reply and info.
<SNIP>
>
> --
> /sd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
