hMailServer IssueTracker

As a quick fix, open up the hm_messages table, insert a new a new row where messageid is higher than the number of messages you've received (like 2000000 or something similar). If you are using SQL Server, you can change the identity seed of the table.

What database engine / version are you using?

Could it be that you're using MySQL with the InnoDB table? If so, this is a side effect of that. :-

Assuming that you're using MySQL with InnoDB and that you've received less than 2 million messages, run the folloing:

ALTER TABLE hm_messages AUTO_INCREMENT = 2000000;

Yes I am using MySQL. I did the ALTER TABLE and the next message has come in with ID 2000001 so all is well.

Thank you.

I'm not sure though how or why the sequence got reset. I did move hMS to a new VM a week or two back but the MySQL database has stayed the same (on my server).

MySQL may decrease the number (did not know, I just learned about it). I guess it's not a very common problem since you're the first one to report it and MySQL has apparantly always behaved that way. However, it's still a serious issue.

I've started to implement this feature:
http://www.hmailserver.com/devnet/?page=issuetracker_display&issueid=145

Which will indirectly solve this problem. hMailServer will keep track of the UID's manually instead of incorrectly relying on database info which it does today.

I presume you will store and increment UIDs via a database record. That should be fine but there is still potential for problems.

I may be collecting mail by POP3 from several different servers and if they all use just numerical sequences then the potential for overlap (considering I may retain mail for a very long time) is still there.

I would think the only guaranteed solution is to use a random character string.

I feel that's going a bit over the top (if I recall the expression correct). If a POP3 client assumes that a message ID is globally, world-wide, unique, it would be broken.

It's OK to assume that UIDs in a specific POP3 mailbox are unique, but it would be weird to assume that messages in different mailboxes (potentially on on different servers) are unique.

If a client can't get that right, I don't think using a random string would be a guarantee that everything will be fine. :-

I will probably rely on the RFC in this. One reason is that the same UID's will be used in the IMAP protocol, and to have two different UIDs for POP3 and IMAP would require some additional work (and processing resources in every installation later on)

I bow to your superior wisdom in these matters. I was making assumptions in the absence of any specific knowledge.

Now that I have looked closer at the headers of a received message, I see that the UID is in fact made up of the serial number provided by hMS + mailbox name + IP of the mail server. So obviously no problem with mail from different mailboxes.

Well, considering this bug report it wouldn't be the first time I was wrong if you turned out to be right, right? ;-)

But I really believe that mailbox-unique unique-id's should be enough.

Was advised today of an other missing email. MySQL had again reset :( I fixed it as before (ALTER TABLE) using a different start point. I have now set my POP3 client not to remove messages when downloading so hopefully MySQL will not reset (I assume it only resets when the table is empty).

When are you likely to publish 5.2?

I'm still working on it. It's quite a big redesign in hMailServer which is why it takes time. It affects almost all parts in hMailServer and upgrade scripts to upgrade all possible database engines have been a pain. I've wanted to do this change for some time, but the reason I haven't is that it's a lot of work. :-

I'm hoping for a beta in the beginning of next week.

If you want a quick fix you could temporarily change the MySQL table type on hm_messages to MyISAM (backup first). This is the table engine used by the internal MySQL database and this database engine is not subject to this problem.

The downside is that MyISAM is less fault tolerant to crashes. If your Windows crashes and reboots, the table may become corrupt (but it should still be repairable).

If I were you, I would take a backup of the database and give it a try.

This is resolved in 5.2 build 349. Will be put up as beta soon.
Available as alpha in the development section of the forum. Not recommended for production.