This is base64 encoded except the password is encoded in MD5.  You can easily get the username though.

11:42:45.438: >> AUTH CRAM-MD5<cr><lf>
11:42:45.438: << 334 PC0yNzE0Mzg1OC4zNDZAZGF2aWRoYXRoYXdheS5jby51az4=<cr><lf>

<-27143858.346@davidhathaway.co.uk>

11:42:46.938: >> amFtZXNoQGRodGwuY28udWsgYmUxMWQ1ZjViZTM3ZjE0Yzk2NGFhYTk4YjU1ZjY0YzU=<cr><lf>

jamesh@dhtl.co.uk be11d5f5be37f14c964aaa98b55f64c5

You might try using a simple username rather than the full SMTP address here.  That said, this may be one of those servers that advertise CRAM-MD5 but then do not implement it.  Upgrade to PB1 and you can tell PMail not to use this protocol. From v4.5x help.

 Do not use CRAM-MD5 authentication even if it is advertised  This one's a bit technical, so please bear with us... The process of logging into the SMTP server to authenticate your identity can take a variety of forms: the server "advertises" the forms it understands, and Pegasus Mail looks through that list, choosing the most secure form it recognizes. Some forms are very "weak", in that they either transmit your credentials as clear text or in a form that can be easily broken, while other forms are "strong", in the sense that it is very difficult to work out your credentials simply by observing the exchange of data between the two programs. Unfortunately, one of the strongest forms of authentication, called CRAM-MD5, is commonly misconfigured on SMTP servers, even at quite reputable ISPs - the server will advertise that it supports it, but will actually fail any attempt to use it. Getting the ISP to realize that they are at fault is a lost cause in most cases - it's almost always easier simply to check this control, which tells Pegasus Mail never to use CRAM-MD5 for this server. You should be aware that you reduce the security of your connection by checking this control: CRAM-MD5 is the only commonly-used authentication form that offers reasonable security, and by disabling it, you force Pegasus Mail to use less secure methods... But sometimes you may decide that being able to send mail is more important than being able to do it securely. The choice is yours.

What was the error message(s)?   Did they just get sent with no errors?  In any case, turn on session logging in MercuryC and then send a mail message to these addresses.  At least this will verify that it got to the relay host without problems.

Maybe the relay host is being blocked by some blacklists. You have a fixed IP address.  Is the ISP blocking port 25 outbound?  If not then try sending via MercuryE direct to the receiving hosts. maybe the relay host is being blocked by some blacklists.

 

Thanks, Thomas. I must have misunderstood the Help info on how to use a normal delivery in a filter - I thought I had to use MOVE or COPY to obtain delivery?

However, I can now scrap this attempt - the vendor of Profimail, the mail client I wanted to use but was having SSL issues with, has now published a beta update which uses TLS and works with Mercury. I am not sure whether or not this was written in response to me reporting my problems to them via their forum, but it's either impressive service or impressive co-incidence.

Thank you for all your help with this

 Chris

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.