(Does eventum-users need to set a Reply-To: header or is Thunderbird
just refusing to respond to the list? Sorry for the double-up Joao.)
Joao Prado Maia wrote:
> Great question, and I assume that the difference is that "IMAP" will use
> TLS if the server broadcasts that as available, and "IMAP, no TLS"
> forces the IMAP extension not to try to use TLS.
I would buy that, but there is also a "POP, no TLS" option and I wasn't
aware POP had a mechanism for opportunistic upgrades (not that it's an
area I've looked at this millenium). Perhaps it's just for code
orthogonality; I should read the source but alas have an appointment and
must go. I'll try to remember to do it later.
>>And, while I'm at it, wouldn't it be neat if, in conjunction
>>servers, one could specify an alternate folder for "Leave Copy of
>>Messages on Server?"
> I guess. Is this something you need?
I'm not sure. I am thinking that it might be a performance win for
people who want to leave the messages on the server, because the
scanning code would have a smaller corpus to consider on each check. If
you're doing your scan every minute, that's potentially significant.
Might also be a plus if you want the ability to coexist with Eventum, or
be able to respond to current messages about your Eventum's database
server being down ( ;-) ) without wading through two years of
Only other benefit I can think of would be that a person could clear the
"saved" mailbox with impunity, whereas you might get contention issues
on the INBOX.
> Yes, because the cron jobs usually require a bunch of Eventum classes
> that wouldn't be available if they were running from another server. But
> I guess if you copy the Eventum directory to some other server, and
> change the configuration file to point to the real MySQL server, then it
> should work fine.
That would also work, but I solved this with wget. I sent that rather
ugly, hackish patch to eventum-devel.
> The easiest thing to do here is simply to create a "test" project,
> create all of your tickets in there, and when you are ready to move on,
> just create the project that you are really going to use, and then
> delete the test one.
Well I was testing with real data, so I will do the exact opposite...
create a "hidden" project and move all the tickets I want to suppress
into it (probably via command line SQL). Thanks for the idea, that's