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.
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.
As for the resources issues, are you seeing errors or performance issues related to the resource utilization?
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?
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.
> Did you use a relaying mail server or did you set up a completely new > for the domain? - I set up a full webserver and mail server (all on > the same box). And had the problem right away.
Completely new domain and Mercury/32 server. I go the domain from DynDNS.com and it used a fixed IP address so I was sending via MercuryE. There was no problem at all that I could see sending to the Yahoo addresses I have in my addressbooks. Of course, I have never had any problems sending to Yahoo.
> As for DKIM still being able to spam, and hence domains using DKIM are > marked as spam, should not really come as a surprise.
Agreed, I've read someplace that the spammers are some of the most compliant is the SMTP host out there.
> I'm merely refering to Yahoo policies as stated on their mail help. - > The place to find this spam identification is located in the header > information of the mails send. Even if a mail arrives in the normal > inbox, a previous whitelisting by the user will cause the mail to > arrive there and not end up in spam.
Yahoo does require that the domain have a valid PTR record but other than that I've not had any problems at all sending direct to Yahoo addresses.
How do you recommend that this be done when the mail is to a valid address? I guess you could remove the capability of maiser ever sending any respones to non-list members or moderated lists but that to me does more harm than good.
If the list is small and relatively fixed you can copy the list addresses to a dist. list and then do a list scan filter and delete any mail from a non-subscriber.
Personally, as recommended by David, I use POPFileD to catch the spam. This catches 99.87% of the spam and moves it to a spam user account so it very seldom gets to any of the mailing lists. ;-)
If you track a bounce and figure out who it was originally to, then do a search on that address via google or similar, and you'llmost likely find the info sitting in some web-page (mis-spelled, archived or active) - then you know for sure it wasn't a lapse of open relay.
Should make no difference where the mail comes from in MercuryS. Or do you mean POP3 download using MercuryD? Anyway, temporarily switch on session logging for the module in question to see all details of the transaction. (And remember to switch it off, it wastes a lot of disk space otherwise.)
I just had a problem with the outbound mail queue freezing. What happened is a spam message came in with an invalid email address going to an invalid email address ( to firstname.lastname@example.org) What happens is that a return notice keeps bouncing in the queue trying to send the non delivery receipt to an email address that doesn't exist internally. Is there anyway to prevent this from happening. I've had messages get stuck in the queue before, but this is the first time it actually hung processing.
Almost forgot. It is running on a Win2k server.
What I do is turn all mail being received for invalid local users in MercuryS. If mail is received via MercuryD leave the local user blank so that Mercury core delivers the mail and mail for all invalid users goes to the default user without a bounce. With this setup MercuryS rejects the message before it's received so no bounce message is generated. With mail received via MercuryD the default user processes it as desired.