I am using the same IP for my http server and Mercury 32 mail server.

However, I am using comcast's smtp to relay the mail (smtp.comcast.net,

port 587) if that even matters for the MX.

It does not matter how you are sending.  A MX record is not really required, the RFC says to send to the A record if there is no MX record.  That said, there are some strange mail servers out there and so I would recommend that you enter the GoDaddy domain as the MX record domain so those that require a MX record will be happy.  Now if you do have an off-site MX host for your domain then you should also enter this MX host as a higher numbers secondary MX host.

FWIW, it would have been very helpful if you had not munged up the real data so we could provide real answers.  This is not a security issue, these data go out with every message you send.

 

Thanks again Nico, for clearing this up.

I will keep the config as it is now (never fix it if it aint broken ;-).

I have another (performance) issue with your CamAV implementation, but this does not have anything to do with Mercury32 (I think), so I will contact you directly through your web site.

Regards,

Ed

it's true :( anyway both (1 and 2)  don't leave a copy on the server and directly forward the message to the destination server... it not good enough :(

 

i'm working now with the 3......

What I want to do is to be able

to use/see my emails where ever I am in the world be it on multiple

machines within my network, connected to the internet remotely (where I

would like to be able to download new emails and manage emails) and

also when not connected to the internet read a local copy on my laptop

and when reconnected to the internet or internal to my network update

the central database with my changes I made to the local copy whilst

offline.

 Mercury/32 can provide access to your mail stored on the Mercury/32 server either via IMAP4 or POP3.  Outlook can cache the IMAP4 mail folder for processing offline.  Mercury/32 will not automatically change anything that you have done offline but that might be a function of Outlook, I really do not use Outlook all that much.

FWIW, I have both PMail & Mercury/32 IMAP4 and Squirrelmail access to my system when on travel and I copy my current mailbox to my laptop when  going on the road. when using a slow or costly connection I generally get the mail via POP3 (MercuryD) and send via the SMTP client (MercuryC).  This means I am only on-line for a few minutes for mail processing.

I have also installed Mercury/32 on the laptop so I can send/receive my mail from my home system bypassing all port blocks.  Work I have done on the laptop is sent to a transfer folder and moved back to the main system when connected to the lan. 

[quote user="Vincent Fatica"]

When Mercury processes an email with "CC: mailing_list" the persons on "mailing_list" receive an email with "mailing_list" in the "To:" header and containing no "CC:" header.  Is there any way to keep Mercury from doing this so CC recipients can readily see to whom the email was send and that they were cc'd?  A test shows "header stripping" does not affect this.  Thanks.[/quote]

Does version 4.7 do that also?

 

Sorry I should have replied earlier.

Rebooting the server fixed it !!

Thanks

Thanks everyone for your help it is working now :-)

Especially Mr Stephenson you are a legend - Thanks.

I'm pleased to say that (possibly in response to my concerns) Lonely Cat Games, the vendors of Profimail, have published version 3.14c as a beta - this has the option to use STARTTLS on an IMAP connection and it works with Mercury. I can recommend it to any wanting to connect a Symbian smartphone to a Mercury server over IMAP.

 

As Thomas says you will need to make sure that the webmail gets a copy of the messages if you want to be able to read the mail there as well.

/Rolf 

[quote user="matthewsdowns"]It seems like my ISP (Verizon) has blocked the ability to open port 25 in my residential use?  Is there a work-around using a different port or something else I can do?[/quote]

Checkout the services provided by DynDNS.  They provide services for both inbound and outbound mail on non-standard ports for a pretty reasonable annual fee.  https://www.dyndns.com/services/

 

Thanks....That was exactly what I was looking for!  I remember turning on logging, but never turned it off, so this should fix it.

 

RonC

[quote user="Ashley"]

Hi

Interesting this, when i set up Mercury, it says there MUST be an entry for the machine itself, (no domain), however this results in receiving email for anything at "ipaddress", is there a way to stop this, so it only receives email for domains the server controls?
[/quote]

I presume you mean something like this?

[Domains]
server: [123.123.123.123]

server: yourdomain.com

 

It's good practice, but I don't know if it is required by RFC's (I am no expert). I would be surprised if many servers supported that now. Also, I have never seen it used by any incoming mail.[quote]

However will this kill the "postmaster" function account?[/quote]

No. The postmaster account is postmaster@<internet name for this system in Core Config>
[quote]Will i have to create a rule that only says to process emails to specific domains (will still kill the postmaster account i think?)

[/quote]

As long as your (anti-)relaying settings are correct it should only accept mail for the domains listed in the [Local Domains] section.

Assuming i do this, this means this is acting as a total mail server,

with a POP mailbox for each domain, that said could i then use

WSMTPEX.EXE to then look for the files and forward those to the "real"

server behind the firewall, this would negate the need to use POP by

the real server to pull the emails....

Yes, WSMTPEX can be used to send all mail in a mailbox to the second SMTP host on any port. 

Having said that, would

WSMTPEX.EXE use MercuryE to send the emails out as a process, and if so

how long will it try before it fails (and i assume means the mail sits

in the "badmail" folder?

WSMTPex sends mail with it's own built-in mailer but the receiving domain is specifed using the [<IP address>], i.e. user@[192.168.1.4].

I may need to "re-think" this as i dont

want 2 mail "servers" running, just means bumping mail to each stop

while it waits for collection.....

If you are just using the second one as a backup MX host this will work pretty well using the POP3 pull.

If you have set Mercury to handle the mail for a domain (qasti.com) by putting it in the 'local domains' section of the core module, then incoming mail to that domain will always be allowed.

Relaying only refers to mail to a non-local domain, and from your description that is not the case here.

 
  

Ive found the same problem, it was quicker (and safer i thought) to just resend the same mail, no good if the mail isnt from you though...

Searching for TheThousand@pmail on Bing produces 9 results. Google produces 5.

Is anyone promoting this? If you guys are serious about generating sustainable support for this product then advertising this far and wide is essential. There are obviously a lot of people/companies willing to contribute but they will not do so if they know nothing about this.

[quote user="Deagol"] In order to be able to connect to an administrative share like C$ you need to be an administrator on the box you are connecting to. Regular users by default can't connect to a system via administrative shares. The only 'backdoor' in this case would be the users who do have administrative rights to the mail server. A problem could arise if you decide to create another share through which the Mercury environment *is*  accessible to users. The Mercury system can be secured by setting the correct NTFS permissions.

I am running  a Mercury 4.62 system to which users connect using a web interface (so no direct pmail integration). Mercury is running as a service in the context of a specific service account.. Only this service account, a specifically appointed Mercury mail administrator and the system account are granted access to the Mercury files and directories. This setup works fine and will deny users, if they somehow manage to get access to the mailserver (i.e. access through another share) from browsing through the mail system and from reading mail from other users.[/quote]

This is the same approach we use. An AD-user called mailserver1...n is assigned the login right and is the sole reader/writer of the Mercury directories on the local drive (RAID-5), as well as the windows service account. The setup makes the Mail Servers fairly "isolated". We've also removed the windows file-sharing protocol from these servers as well as netbios. The main MTA's (all running Mercury) has since Y2K never been infected or caused any trouble, as well as being extremely stable.

Ah.... MercuryC, I just missed it because I had the other smtp module loaded.  Thanks for the tip!

It most certainly does as the centralized processes like filtering now can run concurrently. You need to change the counterlogic to minimize open file conflicts.

Try comparing all headers (not just From and To) in one of these messages with a similar message that behaves normally and see if you can find any differences.

/Rolf