I can appreciate the effort you've put in to maintaining the legacy of code while supporting the breadth of email technologies in Mercury. I'll keep an eye out for the support of various IMAP extensions in the future. Thanks again for putting forth the effort to maintain this type of technology. It's not too common these days to have the primary developer of a product dedicate the time to respond to queries like this.
Okay, I don't have a fantastic solution, but maybe you could run your pop3 server on a different port from the default port, so attackers that are just guessing you have pop3 because you SEND / ACCEPT mail will be thrown off the trail. Of course it will mean informing all of your users ... which might be a major headache!
*that's what I did when I was just starting and people were trying to connect to my pop3 and I didn't even have any users yet ! ! !, I changed port and now get no unwanted attention*
Anyone knows how bare LF messages received by the SMTP module are processed by Mercury/32?
-messages are accepted and LF converted to CR/LF pair
[/quote]
I would expect this to be the case almost everywhere in Mercury. The problem is that a message file can be processed so many times in the course of passing through the queue that there may be some places where it's not so - but as a general rule, this is what I would expect to happen. I code pretty defensively against bad line endings.
You're giving me nothing to work with - how about an example, or a more detailed description of what you're seeing? I'm not psychic.
That said, there are two general answers to this. The first is that if you can tell me specific places where you're having problems with truncation and can give me solid examples, I'll see what I can do to accommodate you... The second, however, is that if you are finding that some of your clients are sending mail with lines longer than 1000 characters, or messages that are not syntactically valid in terms of RFC2821/2822, then you should really be getting the *client* to get their programs fixed, not me. Just because I am approachable or available is not a sufficient reason to dump other developers' problems on me - problems should always be fixed at the source.
Basically you set up two local mailboxes, one for your wife and one for your self.
Point the alias you like to these mailboxes. (addr1@domain == mbox1, addr2@domain == mbox2)
For the generic address, set up a mailing list, use a real address as list name addr3@domain - then add the two alias addresses as subscribers to the list.
You need to run MercuryE and MercuryP and MercuryS.
The 32-bit version of malias.exe was unfortunately never included in the Mercury/32 installers, even though it was intended to be. Thanks for pointing this out, Chris! It's now available as a separate download from here:
Interestingly, I use the same copy of Pegasus to connect to an MS Exchange server, 2003 I think. Connecting to that using IMAP only seems to work if I use 'Via direct SSL connect'.
[/quote]
Yeah, tragic isn't it. Outlook only supports direct connect too, as far as I know. Trust Microsoft to be six years behind the times on standards compliance.
Thanx for the reference to ... it helps when you have a place to check your work. I seem to be running into issues with the SPF records and I had a Reverse DNS Lookup issue, but I'm not sure the DNS info has had enough time to propagate.
There was a time when Mercury would have accepted these addresses, in the spirit of "Be tolerant in what you accept and strict in what you send", but the advent of open relay testers and spambots meant that I had to change that policy to one of being much stricter about what I will and will not allow. There are also complications introduced by certain ESMTP extensions to the MAIL FROM: command that force me to be more stringent about syntax.
The only suggestion I can offer is the same as Thomas's - that you try entering the address in the old program with the < and > characters already in place. The address is still legal in all cases where a compliant RFC2822 parser would be reading it, and it will work around the problem. Of course, if the string is hardwired or there's some other reason why you can't change it, then I'm afraid you have a bit of a problem.
Today we received a fresh Beta where the licensing code is mainly being tested, besides some minor fixes since last beta.
Testing with us here at PraktIT, is a bit cautious: 1. Install in test-lab (which is our internal system) 2. Test all features that we use, settings etc. - report whatever we find. 3. If no serious issues arise with the beta, after about one week we: 4. Install the beta onto our production systems that has much heavier load.
During all the time, we watch carefully memory use, resource use, GDI-pointers, file handles, message error reports, statistics etc. as well as test the connectivities from various clients.
What kind of connection are you using to access your IMAP mailbox? My connection is 384 kbps so it takes a little while to download a 6 MB attachment to my local store and be able to access it.
[/quote]
Practically, I only access my IMAP mailbox from the home network (100 Mbit). I've set up my mail client to not download attachments until I open them. The problem doesn't exists if I access the mailbox with Pegasus Mail.
[quote user="roryk"]
As for the resources issues, are you seeing errors or performance issues related to the resource utilization?
[/quote]
No, I don't see errors. Everything works except a 100% CPU usage from mercury.exe in windows task manager (for a couple of seconds, depending on the size of the attachement). Strangely enough, this doesn't happen when I actually open the attachment (and download it from the server).
If you think that issue is solved in some beta version, could you give me link to that beta?
[/quote]
I've now looked back on the code I used to build v4.01c, and it's possible that I used the wrong base code set. It may be that the code I used to build v4.01c had an early prototype of the modified UTF-7 code, where it shouldn't have had anything at all. Unfortunately, the v4.01c build was done in a bit of a hurry (because it was addressing a reasonably serious security vulnerability), so I can't be totally sure about this.
Certainly the modifed UTF-7 code appears to be working fine in v4.5, at least based on reports from the test team.
As Peter has said, betas are currently not made available publicly, although I'm considering changing that: I may well go down a path where selected relatively stable betas will be made available to the public on the basis that they are undocumented and unsupported. Unfortunately, v4.5 is now so late along in the process that it's actually not easy for me to make a beta available to you, or I would consider doing so. Leave it with me and if I get to a point where I think there's something I can offer you, I'll get in touch.