Inlcude recipient address in hm_messages table

[pjsmith]

Hi,

I'm looking at using hmail to compliment/replace our current solution to store and forward to other servers.

Would it be possible to include the recipient address or at least recipient domain in the hm_messages table? The reason for this is to enable me to issue an sql query to see what mail for what domain is pending in the queue. On our current mail system, mail is queued pending delivery in separate folders per domain, so we can see those files. In hmail, it's all in one place and this can be 10s of thousands of files. Very difficult to say what mail is pending for what client. If the recipient address or domain was in the hm_messages table, it'd be a 1 second query. Very useful and I would have thought easy to add?

Of course, there might be another way to do this, but being new to hmail, I have not found it as yet. If you know of anything, please let me know.



Thanks.

[mattg]

Here is an example of additional data being added to the database using a script
http://www.hmailserver.com/forum/viewto ... 20&t=13890

You could modify this to achieve what you want (that I don't need).

[percepts]

Which recipient? There could be dozens in To:, dozens in Cc: and dozens in Bcc:.
I don't think the request has been thought through fully. Maybe its just so it ties in with some third party software.
A major design feature of hmail would seem to be minimal message data in DB. This request would seem to be at odds with that. Just my opnion from what I can see.

hmail performance options (message indexing) puts a to address in db table hm_message_metatdata. Use that. But it probably isn't populated until after mail delivery. You would need to check.

Also, the queue clears pretty darn quick unless its being hammered by automated sending so what's the point anyway.

[pjsmith]

Hi,

The requirement is to be able to say, quickly, from a remote server, what messages are waiting in queue for a specific domain, showing the message subject, to, from, etc. At the moment, we can do this 2 ways with the existing software (we are testing to see if we could replace this with hmail), query the database (very fast), loop through the messages in the per domain queue folders (slower, but every message is relevant).

As far as I can see, with hmail, the only way we can do this is to loop through every single email in the single queue folder checking the message to see if it is the domain we are looking for or not. Given there could be 10's of thousands of messages in the folder but only a thousand or so for the domain, this is a very slow way to find what the mails being searched for.

I'll look into adding data into a database via a script. That would solve many of the other things I am looking into also such as mail logging to database (we need to keep transaction logs and this is very high numbers of emails - too hard to search text logs).

Many thanks.

[percepts]

Seems to me that the stream of requests you are making are aimed at making hmail like your current software. I would suggest the simplest solution to that would be to use your current software.

[pjsmith]

Hi,

To some extent, yes, though I think hmail has a better core and likely more flexible for the future than the current solution. Assuming you are the code maintainer (or at least involved), you'll appreciate how much work goes into maintaining your own source on a project like this. Frankly, why do that if a better product (possibly hmail) already exists...

Like most large and complex pre-existing installs, changes in software don't necessarily mean you can rip out all the features users liked in the old software.

I think hmail though, given it's flexibility can be tailored by the user to emulate most systems of you are prepared to work at it. There are a few core things for us, isp type usage, that hmail just does not do that we need, nor I guess does it need to. I've been able to put in place a few of those thinks in just a few days, so it's going well as a test right now. The little I've learnt so far leads me to believe hmail can be extended with scripts, php code, etc to keep the existing bits we can't do without.

Thanks for the support.

[percepts]

Hi,

The requirement is to be able to say, quickly, from a remote server, what messages are waiting in queue for a specific domain, showing the message subject, to, from, etc. At the moment, we can do this 2 ways with the existing software (we are testing to see if we could replace this with hmail), query the database (very fast), loop through the messages in the per domain queue folders (slower, but every message is relevant).

As far as I can see, with hmail, the only way we can do this is to loop through every single email in the single queue folder checking the message to see if it is the domain we are looking for or not. Given there could be 10's of thousands of messages in the folder but only a thousand or so for the domain, this is a very slow way to find what the mails being searched for.

I'll look into adding data into a database via a script. That would solve many of the other things I am looking into also such as mail logging to database (we need to keep transaction logs and this is very high numbers of emails - too hard to search text logs).

Many thanks.

You are making a lot of assumptions. There isn't a per domain queue folder. There are only messages in queue identified I think by messagetype being = 1

changing table hm_messages layout is a core change and unsupported. But since hmail is opensource and now on github you are free to create your own fork and do as you wish with all the flexibility you can muster.

https://github.com/hMailServer/hMailServer

p.s. I am not a developer of this product. If you want developer opinions/suggestions then the IRC page would probably be most useful to you.

http://www.hmailserver.com/irc_fullscreen.php

[nico@acu.org]

This is almost a year later and I am sure you managed to do something with this; however, why couldn't you just join hm_message_metadata with hm_messages and pick up the metadata_to from there?
Nico

[martin]

Yeah, this should just be solved using a SQL JOIN. No reason to change the schema for this.