Tom,

 

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.

Regards,

Keith

[quote user="olic"]

Here is the lines sent by the old program which Mercury don't like :

MAIL 
RCPT TO:olivier@serv1.sim

[/quote]

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.

Cheers!

-- David --

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.

[quote user="roryk"]

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).
 

It could happen while I am connected via LAN (3Com gigabit switch) or remotely (3Com ADSL router), therefore I do not think it's a connection problem.

thanks, i had a bit of misconfiguration... in mind: following peter settings i was able to set the ML account, working now.

i already set up regular users for multi domains but ML confused me... now i got it 

let's see what the future will bring...

 
:)

 
Marco 

 

Probably the easiest option would be to static the local IP address.

I presume Mercury & apache are on the same machine. You could tell mercury to use localhost, but other pc's won't be able to talk to it.

 

Thank you for your help David.

[quote user="tokul"]

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.

Cheers!

-- David --

I sent a mail to fred from Mercury. ok.

 

Recieved the mail in TBird ok.

 

Somehow I don't think TBird is sending correctly or I have screwed somthing up I can't see, 

> 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.  ;-)

 

Just tried two messages I've seen this week.

1) Loooong header line (MS Outlook x-cr-hashedpuzzle:)

2) Long lines in an inline text attachment sent by Thunderbird 2.0.13. Format "flowed".

Both worked fine when downloaded from 4.72, not from 4.01b.

Guess I'll have to upgrade. 

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.

4.01b

 I managed to get it working, but it's a real kludge.

• I deleted myself, user "Pete" from Mercury
  
• I created a new user called mailbox which I now send with a reply-to of "pete@"
• I created a mailing list "Pete"
• I created a mailing list "Tmob" for my T-Mobile device with no welcome nor farewell file and made the mobile device address a moderator and active subscriber
  
• I created a mailing list "Cing" for my Cingular device with no welcome nor farewell file and made the mobile device address a moderator and active subscriber
• I subscribed mailbox, tmob, and cing to Pete

I can now do what I wanted. EMailing maiser@mydomain

add tmob any@email blah
mset any@email tmob nomail

will forward that address to the device, and

remove tmob any@email

will stop forwarding. (I replace "tmob" with "cing" to do the same from my cingular device). But like I said, it's kludgy.

We use port 110 on the local network and a random high port externally.

The internet gateway 'port forwards' this high external port to port 110 on the mail server so merc only needs to use one listening port. 

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.)

/Rolf 

[quote user="Slab"]

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 invalid2@mydomain.com)  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.

[/quote]

 

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.

 

 

The problem is less something specific to Mercury than a widespread problem in the way SSL is implemented generally. There are many different libraries and versions of libraries for doing SSL and not all of them interpret the specifications in the same way.

Now, with MercuryP, MercuryI, MercuryC and MercuryD, it's not too much of an issue, because they're only talking to a fairly limited range of implementations, so if there's a problem, it will become obvious at an early stage. Enabling SSL in MercuryS, though, exposes you to every implementation in Christendom, with all their vagaries and differences. For this reason, I generally do not recommend enabling SSL in the SMTP server - and will not be recommending it until the industry settles down considerably in this area.

Cheers!

-- David --

It's all sorted [:D]

Turns out that it was just the password stuff in Mercury that had become corrupted - new password setting - job done.

Can't believe I have spent 5 days driving myself (and everyone else) mad over this.

Thanks again and hopefully back to another happy and trouble free five years of Mercury & Pegasus.
Oh! and once you sort out the licensing stuff - 5 mailboxes here please

Lynn