Steve, > > One thing that you might want to do is change the use of X-Headers to > > attributes, since this will go into v2.2+. Attributes are > > available for > > both v2.2 and HEAD. I would only use X-Headers for something > > you want the > > MUA to see. > > Yes, I thought about this. My concern with such an approach is that as > attributes require a database, file based systems will not then be able to > use fetchmail. While fetchmail is not an essential James > component, deciding > that any James component (in the Phoenix sense) need not support > file based > systems is more of a strategic decision than I alone should be taking. > > Hmmm. Maybe a <UseAttributes>true</UseAttributes> flag would do it. >
No, mail attributes are available also for file based repositories in James: moreover, they are immediately fully available from the moment you start using v2.2.0a9, if using file based repositories, while instead you need to do some work to activate it if using DB repositories (better, to achieve persistance). As written in this list under "Mail Attributes support added", amended by "Mail attributes: backward and forward compatibility": ... Such support is immediately available just by restarting the server if James uses file based repositories for inbox and spools, *even if there are messages in the queues*. For db based repositories instead the following steps must be done, depending on the following three situations: 1) No "inbox" and no "spool" tables exist (no db repositories yet): just look for the string "attributes support" in james/apps/james/conf/sqlResources.xml, uncomment/comment the sql statements as described there and restart the server. 2) Both "inbox" and "spool" tables exist, but there are NO "old" messages to keep residing in the repositories: do the comment/uncomment as said in (1) above, and either drop the tables form the db and restart the server (if you haven't done any customisation) or add the "message_attributes" column to both tables with *not null* and restart the server. 3) Both "inbox" and "spool" tables exist, but there ARE "old" messages to keep residing in the repositories: do the comment/uncomment as said in (1) above, and add the "message_attributes" column to both tables with *null* and restart the server. ... So it would be safe to follow Noel's suggestion for fetchmail. Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
