Thanks a lot, folks 

I will leave everything as it is.

Hi, Folks

I'd like some feedback if anyone has time, please. I'm going to be setting up Mercury for a small office - 3 to 5 users.

They presently use Outlook 2010 as their client. They connect each day to their webmail via IMAP. However, their webmail capacity has been reached and they are struggling between keeping essential and historical messages and deleting enough content that free space is created. They are fighting a losing battle.

This is part of a major IT overhaul for this office. I will be installing Mercury on a Windows 2008 R2 server, setting up POP3 access from Mercury to their webmail so that all mail is downloaded to the Windows server and removed from the webmail server. I will then point their Outlook installations at Mercury.

So far I have setup port fowarding on their office gateway router so that SMTP and IMAP are forwarded to the Windows server.

I will change their domain's DNS settings so that the MAIL record is associated with their static IP address so that the address is 'authorised' to send mail.

I have created firewall rules on the Windows Server that allow SMTP, IMAP and POP3 traffic. I will also create a rule specifically for Mercury when it is installed.

What I'd like feedback on is the following:

When I create the firewall rule for Mercury, is mercury.exe the only executable that needs to be allowed?

I am not going to be changing the MX records so the records point to their office IP address because I want to continue to take advantage of their webmail's spam filtering. I'm 99.9% sure that the MAIL record is the only record I need to change - are there any others that I might want to consider?

I've used Outlook in the past to point to Mercury within my own office, but that was v.2003, whereas these folks are using 2010 - again, I don't think there are any issues here, but am asking in case anyone has experienced any odd behaviour and would like to share it.

I intend to simply disconnect their IMAP accounts and keep them because they have setup a folder heirarchy on the webserver which will be lost once Mercury downloads and deletes the mail from the webserver.

Anything else you folks think I should be aware of? It's been a while since I set Mercury up and although I'm confident I can do it, I'd like to make sure I've covered everything as I don't have the luxury of working in my own office during off-peak hours. This has to be done while they are working so there is no room for error.

Many thanks!

There is an 'imapcopy' tool about somewhere that purports to transfer between imap servers, given both sets of auth info, although I recall having trouble with it and just using a mail client with both accounts attached and copying them over that way.

After that, grabbing the mail with MercD will only get what is in the inbox, not any

folders so they will still need to login either by imap or webmail to

check the spam folder.

FWIW, I think a Merc install with some SMTP transaction filtering, Spamcop lookups and a properly trained Spamhalter will beat the pants off any public webmail providers spam filtering.

As for DNS, I haven't had any issues with the reverse DNS not matching the smtp hostname, but would recommend setting an SPF record specifically allowing your ip (and optionally denying any others depending on usage).

[quote user="dilberts_left_nut"]

There is an 'imapcopy' tool about somewhere that purports to transfer between imap servers, given both sets of auth info, although I recall having trouble with it and just using a mail client with both accounts attached and copying them over that way.

After that, grabbing the mail with MercD will only get what is in the inbox, not any folders so they will still need to login either by imap or webmail to check the spam folder.

FWIW, I think a Merc install with some SMTP transaction filtering, Spamcop lookups and a properly trained Spamhalter will beat the pants off any public webmail providers spam filtering.

As for DNS, I haven't had any issues with the reverse DNS not matching the smtp hostname, but would recommend setting an SPF record specifically allowing your ip (and optionally denying any others depending on usage).

[/quote]

Thanks for replying.

I'm not worried about copying the folders as they will still exist as an 'archive' within the user's Outlook installation. The webmail server presently holds nearly 400MB of email messages for just one account and I will configure the POP3 client in Mercury to download that data tomorrow night before setting the staff up the following day.

I've installed Spamhalter with Mercury so I'll see how it goes. I really don't want to use this installation of Mercury as their domain email server because they won't be able to manage it. Mercury will simply download their email from the webserver and send email as required.

I had an issue with a recipient domain not accepting email from our sending domain when I initially setup Mercury at our office. It had done an rDNS check and of course our IP address was, at that time, associated with our ISP and not with the domain name we use to send email. After I added a PTR record for our mail.***.com sub-domain everything was fine. The DNS records for the domain of the organisation I am doing the work for has separate 'webmail' and 'mail' A records. I'll don't want them ringing me up complaining that their email is being refused :)

SPF records are a black art - I have very little experience with them, and the one time I have had to use a SPF record it was written out for me by Webroot's tech staff.

Fair enough.

Maybe using the webmail server as a smarthost could be an option.

Re: SPF - it's really not very difficult, just add a TXT record to the DNS.

MS has a SPF generator to walk you through creating the content for it here https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

Thanks a lot :)

I set up Mercury at their office yesterday and the first three messages they replied to failed because the IP was not linked to the mail A record. I configured their copies of Outlook to use the webmail server as the sending host instead of Mercury and it worked fine.

Although I've been managing a couple of Mercury installations for several years it's been a while since I set one up from scratch so I genuinely appreciate your help. Also, these people use Outlook 2010 - holy cow, talk about convoluted :) I spent more time fire-fighting Outlook's quirks than I did setting up the server. Still, everything is hunky dory now.

Cheers!

Another question, if I may.

As I said above their DNS records for the domain include A records for Mail and Webmail.

If I change the Mail record to point to their static IP address will this have any impact on the webmail server? I don't know how this works as I've never seen a Webmail record before. I assume that the Webmail A record is used just for sending mail via the webmail interface and that the Mail A record is used for sending mail from a different IP address.

I feel a bit stupid asking this as I know that our domains just use the Mail A record, but not having seen both types of record together before I don't want to break their email by misconfiguring it.

It's actually the MX record(s) that indicate the mail handlers for the domain. They should in turn contain A records, not IP addresses, though.

/Rolf 

[quote user="Greenman"]I configured their copies of Outlook to use the webmail server as the sending host instead of Mercury and it worked fine.[/quote]

I was meaning to use MercC to send outbound from mercury via the smarthost, rather than direct delivery with MercE.

That way all the mail passes through Mercury, which would be required for any meaningful logging or archiving purposes.

[quote user="Greenman"]If I change the Mail record to point to their static IP address will this have any impact on the webmail server? I don't know how this works as I've never seen a Webmail record before. I assume that the Webmail A record is used just for sending mail via the webmail interface and that the Mail A record is used for sending mail from a different IP address.[/quote]

Well that all depends on the MX record.

An A record simply ties a hostname to an IP address.

An MX record defines which hostname to deliver mail for the domain to. It doesn't have to be called "mail.domain.com", it could be anything (e.g. dirtyoldman.domain.com or just domain.com). What matters is that an SMTP server configured to accept mail for that domain is sitting at the IP address that the hostname resolves to.

Usually the A record like webmail.domain.com is only there for users to resolve the address of the webmail interface in their brwser and has nothing to do with sending or the mail system at all.

From what you have said, I am assuming that their hosting provider has an SMTP server that handles all mail for their domain, and also provides POP3 access as well as a webmail interface.

If you just change the "mail.domain.com" A record to point to your Mercury IP, foreign SMTP servers will attempt to deliver mail there as the MX record will still be pointing to that hostname, which now resolves to your Mercury.

If you want all inbound mail for the domain to arrive at the hoster's SMTP server then you need to have the MX record point to a hostname that resolves to their IP.

You can have your Merc IP address resolved by mail.domain.com and the MX record pointing to smarthost.hoster.com (or whatever other names it may go by), but then you are back to the original problem when sending - mail coming direct from mercury is not originating from the listed MX for the domain (not a technical problem, but a "reputational" one).

Assuming the hosters sever is reliable, I'd say leave the DNS as is and just point all the Outlooks back at mercury and use MercC to send outbound.