omg , im sooooooo stupid .... sorry [:$]

looks like a mail account that i made for testing purposes and deleted short time later  . Im very sorry that ive wasted ur time with this [:'(]

Anyway .. thx 4 the help as i now understand much more of the functionality of mercury now [8-|] , if someone of u guys ever visit duesseldorf , Germany i invite u for a Drink

>> there is no attempt made to distinguish between local or external SMTP connections.

I always thought that the "intent" was to do just that, so maybe there should be a mechanism similar to that used by SpamHalter.

Thank you for your time.  I consider this resolved.  You guys do great work here!

[pi]

[quote user="ryanj"]

I can understand how and why the delivery confirmation works as it stands now, but I can't help but think that it's incorrect behavior.

[/quote]

It is really the FORWARDing mechanism that is at fault. Delivery to the maildrop should be the end of the SMTP journey for a message. The issue occurs when it is resent (original headers intact) with a new SMTP envelope, effectively a new message, that is also requesting delivery confirmation.

A 'copy' rule is probably a "more correct" method than the FORWARD file "hack".

I found it.  I normally use IMAP so it wasn't there.  Thanks.

[quote user="mdowlin"]I think I'll just have to get specific. Kansas State University has two domains, ksu.edu and k-state.edu and if you send an email to either domain it will get to the person. The problem is we have them in the lists as @ksu.edu right now, but I'd like the system to be able to see that if it comes from either domain to go ahead and let them send to the list. So people that choose to be @k-state can't send to the list right now. What I don't want is to put them in twice and get duplicates or have one silent or have to maintain 500 aliases. Hope that clears it up some, was trying to be generic. [/quote]

Aha, now I understand and  the only way you can get this to work is to have the users subscribe twice and have one set to no mail. 

This happens to me all the time on the PMail lists and I have 4-5 email addresses that are involved.  It's a bit of a pain to do at first but there are not that many lists and they do not change all that much.  That said, I generally subscribe to most lists with unique addresses and then always send to the list with that address. 

 

There is a separate log file for each module in Mercury. For the SMPT client you select the module you use from the configuration menu. There is a field called "General log file" that controls this. If it contains a fixed file name (like C:\MERCURY\Logs\MercuryE\smtp.log) it will add new lines forever to the same file. You can however use some special parameters to have it create a new file at set times. For instance:

C:\MERCURY\Logs\MercuryE\~y-~m.log           <--- a new file every month

C:\MERCURY\Logs\MercuryE\~y-~w.log           <-- a new file every week

C:\MERCURY\Logs\MercuryE\~y-~m-~d.log      <-- a new file every day

 

/Rolf 

[quote user="cynist"]All of my users connect using IMAP.  The IMAP4 server shows no connections but by the licensing statement at the bottom it shows three are connected.  What could these three mysterious connections be or how could I figure out?[/quote]

In the current incarnations of Mercury, user counting is done solely on mail delivered. So, each time a message is delivered to a user who has not received mail since the last time Mercury started up, the user count is incremented. Connections to a mailbox, whether by POP3 or IMAP, do not affect the active user count (although clearly if we ever move to stricter licensing requirements, they will have to do so).

With this definition in mind, all the diagnostic you're seeing means is that three discrete users have received new mail since the last time Mercury started up.

Cheers!

-- David --

Thanks for your help so far

I've check and re check my router but I will check again as I am no expert, 'll do some searching online and check with my ISP to see if they are blocking port 25.

This will most likely take more than a day but I'll let you know how i get on 

Again thanks

>> "specifying the shortcut to start minimised"

Holy cow!  Years of using Windows, and I never realized I could change that right in the shortcut!  After you mentioned it, I had to go look for it... and I consider myself an advanced user of Windows!  I'm so embarrassed!  I always glommed the proper command-line switch on the target-line.

Thanks for your help... and STILL learning something new every day.

[:)] 

 

Well if it is a static IP, you have to have proper reverse dns for most deliveries to work. If the reverse zone does not match your forward lookup zone many will consider your IP a dynamic one.

But yes - talk to them - they are people too.

Hi all

i just installed the new vesion of clamwall to 1.4 and upgrade to clamav 095a

 

all work fine!!

 

thanks a lot for this great support!!!

 

Victor

search mailixf and you find a few cgi tools

[quote user="bwhite"]Hi PaulW,  not sure how that would work in my situation in that we currently have a pop3 account that is our Domain Mailbox.  All mail sent to an address in our domain is collected there.  We then have mercury retreive the messages from that account to distribute to our internal users.[/quote]

That's a fairly standard setup, but has various drawbacks.

[quote]To use MercuryS we would have to have our Email host setup to periodically send all mail collected to our email server, right? [/quote]

No, that wouldn't gain you anything.  You must be the email host by changing the domain's mx record to point to your server.

[quote]With our ISP we have a problem with our "Static" IP addresses not being so Static, so that we be another problem.[/quote]

Ah, that would cause complications.

<title>blank_page</title><link href="/tiny_mce/jscripts/tiny_mce/themes/CommunityServer/css/editor_content.css" rel="stylesheet"><base href="http://community.pmail.com/forums/">

You really shouldn't have an AV solution that intercepts traffic at the tcp

level (most do unfortunately).

In a client this is perfectly normal, but in a mail-server you need a server

product, as the connection is supposed to be initiated from the other end (like

a magnet - opposite polarity) - the sockets are always open for new inbound

connections, and multiple connections has to be allowed.

For this very reason you should use an AV product that examines the content

for viral content after the content has been received.

I'm not familiar with Mercury on Netware or how different it is from Mercury/32 so YMMV.

You should turn on session logging for the SMTP client module to capture a session transcript of a message that causes the error (using a very small attachment is a good idea [:)]) and post it here.

 

> Today I saw again (it is still) that on some reason MercuryC
> (installed on NW 5.1) stuck on message delivery. I load another
> instance (as Mr. Stephenson suggested) and then e-mails get delivered
> again (beside this one which stuck with MercuryC 1-st instance). As I
> have Mercury/32 installed also (on WXP box with ASSP on front) I
> wonder is may be reasonable to load on this Mercury/32 box Novell
> Client and log into NW server and add to M/32 additional queue pointed
> to NW server Mercury smtpqueue directory? Is that OK? M/32 is probably
> newer and could handle messages in more ... efficient way!? Make this
> sense?

Can't hurt but the problem is that Mercury/32 MercuryC must be handling the mail exclusively and when using MercuryC the NLM version is more efficient.  There is no way that a single instance MercuryC of Mercury/32 is going to be more efficient than 5 instances of MercuryC.NLM handling the queue in a round robin fachion.  This is especially true if you are using multiple relay hosts but even if using a single relay host you will be using 5 paths instead of just one.  

RTFM [:D]

Have a look in the help file under "filters" and "policies".

How to employ these depends on the detail of what you are trying to achieve.

eGroupware is not a mail client.

Nope. Egroupware is a mail client! Maybe in some older versions it wasnt one but now it is (but its not so comfortable as an real mail-client is).

A 'smarthost' is an SMTP server that handles ALL outgoing mail for the eGroupware application, "there can be only one..."

Also Nope. I can use as many SMTP-servers (or smarthosts or however you like to call it) as I want to. The problem is the authentification. As i wrote some posts ago: When I configure mercury to relay only mails for my domain than I can send mails from egroupware regardless of which account I use (thats what I want) and all is working well. But I cannot use SMTP AUTH. My intention was to configure mercury to only relay for its own domain and to use SMTP AUTH, but if I enable SMTP AUTH all other opitons are greyed out and mercury relays all mails that are authenticated (equal for which domain).

 

Greetings thomas, that conf change corrected the problem.

 

 

[quote user="Thomas R. Stephenson"]This has been passed to David but the fix will not get into v4.72 since it's in the final release cycle.[/quote]

 

Gismo22, please read Thomas's answer above - the fix is NOT in the latest release. There wasn't enough time. I'm hoping for the NEXT release of Mercury. Thanks.