> Hello All,
>
>  
>
> I’m totally new to running my own MTA and Mercury is the first software
> I’ve tried of this nature, as such please excuse any mistakes.
>
> For the sake of the examples, we can pretend that Mercury has been
> setup to operate the acme.org domain. I have enabled MercuryS, MercuryP
> and MercuryE. Everything is configured such that remote internet users
> are forced to authenticate before they can relay mail which is great.
>
> I’ve been doing some testing, when “Authenticated SMTP connections may
> relay mail” is checked, the setting of “Do not permit SMTP relaying of
> non-local mail” seems to become irrelevant; because regardless of its
> state - as long as I authenticate whilst sending a mail, I can send
> make the “FROM:” header anything, for example bill.gates@microsoft.com
> and it will get sent. To me this seems like a bug but I’ve worked
> around it with an “Outgoing Filtering Rule” that basically says ( NOT
> HEADER contains “@acme.org” DELETE MESSAGE ).
>
> The net result is that 1. users must authenticate to send and 2. users
> cannot send email that does not originate from acme.org.
>
> The problem:
>
> Imagine two mailboxes, Clare and Bob. When Clare authenticates to send
> an email she can claim her email is originating from Bob or anything
> infact @acme.org.

Absolutely, it's always going to be like this as long as you are sending mail via SMTP.  There is nothing to authenticate the the person sending a message is actually the person in the MAIL FROM: address.  Of course, if the SMTP host authenticated the MAIL FROM: there is nothing to authenticate that the From: address was not spoofed.  Now is you were to turn on TSL via STARTTLS  then the whole process of sending works in a different manner.  The sender must provide a username and password to make the initial connection.  Clients like OE and Outlook can't use STARTTLS or TLS so you would have to run STunnel to allow these client to send via SSL.  Here's a bit on setting up STunnel.

Q: I need to use STunnel (http://www.stunnel.org) to access my corporate e-mail securely across the Internet from home. Please explain how can I do this?

A: In WinPMail, go to the Tools -> Internet Options... menu item, click on the Receiving (POP3) tab in the dialog and fill in the POP3 Host field as:
127.0.0.1
Then click on the Sending (SMTP) tab and fill in the SMTP Host field as:
127.0.0.1

Next, start up Windows Notepad and create a two-line Batch text file that starts STunnel. Below is an example of how the Batch file should look. You will need the change the path accordingly for where your copy of stunnel is located as well as the host names for your corporate POP3 and SMTP servers and the port numbers being used on each of those servers for STunnel:

    start /m C:\stunnel\stunnel-3.22.exe -c -d 110 -r pop.corp.com:995
    start /m C:\stunnel\stunnel-3.22.exe -c -d 25 -r smtp.corp.com:465

Save this as ST_PEG.BAT or similar (it must have a .BAT filename extension). Run this Batch file prior to running WinPMail in order to provide the STunnel redirection functionality.

For more information on setting up STunnel with Pegsasus Mail, look here: http://www.noderunner.net/~llin/old/pmail-ssl.html

MercuryC and MercuryD also work the same way.


>  
>
> So what I’m trying to establish is how I can work the following setup:
>
>  
>
> --  Users may only relay if the email is originating from
>     <their_username>@acme.org and they have authenticated themselves by
>     supplying a password.
>

You can't as it stands.  If you were using Pegasus Mail sending via the Mercury mail spool directory and forcing all mail through Mercury then the From: address will at least be automatically built from the users ID and or synonym but even this can be spoofed given that there are some people out there with some basic knowledge of the system.


>
>  
>
> I would like a setup where both users with (& without) accounts are not
> trusted.
>
>  
>
> To my mind the system should not implicitly grant trust to _anybody_ to
> be truthful about the origin address of an email relayed by Mercury. I
> need to try and find a way to impose more stringent controls on who can
> send emails and from what addresses.

Best of luck.   I've tried to do this for years and come to the conclusion that you cannot use technology to solve a social problem.  It's a losing battle, there are a lot of knowledgeable users out there and the basic mail system has a lot of holes that can be exploited.

>
> I hope that is clear, many thanks in advance for any suggestions.
>
> Thanks,
>
> Tim
>

Ok, I see. Perhaps this is the reason for the different behavior. We use the T-Bird-Version 2.0.0.12 at all 30 Clients. As far as I know, the 3.0 is not released for productive use yet.

Anyway, I agree, that T-Bird has this problems with any IMAP-server not allowing both folders and messages.I tested 6 of them so far. Although the problems look slightly different with each one of them, the problems exist all the time.

[quote user="dilberts_left_nut"]

Another option with filter rules is to use the "extract message to a file" action, then call the "run a program" on the extracted file (with a known filename), followed by a "wait for file" (I think, it's been a while since I looked that closely :)) then a "delete".

This may be a better method if you are only targeting selected mails.

[/quote]

I played with the new policy last night and while it worked it ran against every email vs targeted ones.  It also seemed to run slower (took a 10-15 seconds after receipt of the message before it triggered.  I'll try the filter you suggest above as an alternative (extract, run, wait, delete).  Thanks!

Thanks for your thoughts everyone.  I figued a solution would be something along the lines of putting the attachements in a folder which was polled in some way, I just wasn't sure how to do it.

I'll try out a few ways and let you know how it works out.

Thanks again.

Stuzz

[quote user="homeess"]

I am encountering an issue where authenticated users (local/remote) are being blocked from sending spam looking email. Is there a way to exclude authenticated users only?

[/quote]

In the CC setup on the first (general) tab is a field named 'apply this definition to'. You could set this to 'only mails originating from the internet'.
Be aware that, if you are using the MercuryD module, mails pulled by it from remote pop3 servers are also not checked against the CC definition then because Mercury has no way to determine if they are local or not.

Best regards

Nico

[quote user="houston"]

Yes you're right, outlook express sent e-mails properly. I guess I didn't bollux the syntax......

[/quote]

 

Sorry, I wasn't trying to be rude [:)]  , but using telnet for any more that basic testing is prone to typo's and errors, using a client generally removes this point of failure.

I still think you should look at your relaying controls urgently, as with these turned off, sure YOU can send mail, but so can EVERYONE else. 

 

[quote user="Thomas R. Stephenson"]Not sure but users are based on unique email addresses that are being received.  I suspect this will include mailing lists, postmaster, abuse, and other email address yuo may have.
[/quote]

Very close to bulls-eye Mr. Stephenson [H]
Here is a quote from some info-page here:
[quote]For licensing purposes, a "user" is considered to be either a single mailbox to which mail can be delivered directly by the Mercury server (i.e, an "end point"), or a single mailing list.[/quote]

So I asume this number will increase as Mercury learns about users and mailinglists as mail come and go, and finally saturate at the number of users and mailinglists.

Kai Atle

[quote user="jroger"]Thanks, that's interesting.  I tried creating roger.rowell.foo file and directory names in Windows XP and they seem to work fine. Is it time to rethink the use of the period?[/quote] Nope, since all of these names become directory names I'll bet there will be at least some delivery problems when long file names are used.  You of course can do whatever you want but I really recommend using only plain username.  You can have names longer than 8 characters but even there I would recommend using only ASCII charecters.

Thank you.

I'm running Mercury under the LocalSystem account and... meanwhile... I found a solution in the web... I just need to connect to the console session using remote desktop.
So, I need to start my remote desktop session with the "/console" parameter... start -> run -> mstsc /console

 

My only guess that there is something wrong with the address in the 'glue' headers. 

I was having a tough time with this type problem myself. My setup is as follows: Mercury/32 v4.52, SquirrelMail v1.5.1 (1.4.15 worked ok too) on IIS 5.0 [SquirrelMail is separate from my Mercury/32 server], PHP 4.3.4 and NetWare OES 6.5.6 storing messages. SquirrelMail is run from a virtualized directory of C:\MAIL and PHP is located in C:\PHP.

 

I found out the hard way that the PHP.INI must have fastcgi.impersonate = 1 and that the redirect.php from v1.4.15 of SquirrelMail make this work well. I even have the address_add plugin working (not under v1.4.15, though). I highly recommend using the autosubscribe and folder_sync plugins also. The documentation for this is very poor and that made for lots of trial and error to get this going...

 

HTH 

 

[quote user="Anthonyd"]

Hi, Can anyone tell me if there is a simple way to send a message to all my users in Mercury?

 

[/quote]

 A list of valid recipients can be obtained by simply listing the mail directories in the directory where they are kept.  From a command prompt you could, for instance, "cd\mercury\mail && dir/b/ad >rcptlist.txt".  Now, rcptlist.txt is a distribution list you can tell Pegasus Mail to mail to.

 

Cheers,

Sabahattin

 

[quote user="TonyRad"]It looks like after I closed out the problem accounts a bulk of the problems stopped. Now I have just a few that don't seem to want to send, I'm not seeing any error messages or anything though, I'm not sure what I should do about them?[/quote]  I've been looking at this one for some time now and I cannot figure out anything that could be causing the problem.  Does this problem still exist?

 

Thanks dilberts_left_nut.

I see what you mean. I have tried setting an outgoing rule to look for the offending text in the header and replace it but to no avail.

I should change the computer's name anyway so I guess I'll end up going down that route.

 

Cheers,

Reece

[quote user="jbrowne"]

Two questions regarding delivery confirmation:

 a)  Would allowing delivery confirmations to be returned to senders, am I saying 'yes' to receiving more spam?

[/quote]

 

No, but it probably is saying "Yes!" to the generation of more spam; unfortunately, though your autoresponder may be harmless, some people will find it annoying if they receive it unsolicited and will accordingly often report it as spam.  I should think carefully about whether or not you really need an autoresponder.  See this:

http://www.spamcop.net/fom-serve/cache/329.html

 

Mail is dead easy to forge.  A spammer just includes your autoresponder in his list and forges the sender to be some unfortunate somewhere and your helpful autoresponder will be sent to someone with no connection to your company.

 

The default (I.E. usual) behaviour of an RFC821-compliant mailer is only to report delivery failures.  If you don't accept mail for which you can't then accept responsibility (this is configurable in Mercury), you should have no reason for generating mail to innocent people.  Also, enabling Delivery Confirmation by itself isn't enough to cause a receipt to be generated; Mercury looks for a header to be present and mails the confirmation to the address in that header.  There is a more standard way to change conventional SMTP behaviour using the DSN extension and format - see RFC 891.  Mercury doesn't support that.  Delivery confirmation will only be generated on request, in any event.  So even if enabled, spammers have to knowingly abuse the feature, and most don't - yet.  I don't advise you to go ahead and provide an easy way for spammers to make you generate backscatter.

 

[quote user="jbrowne"]

b)  How possible would it be to use filters, daemons, to have automatic delivery confirmations sent back to people that email my company (even when they do not use the delivery confirmation option in their email client)?

And maybe have like an opt-in opt-out for those automatic delivery confirmations? (list of sender's email addresses that request them).

[/quote]

 

Yes, it should all be entirely possible using just rules and distribution lists.

 

Cheers,

Sabahattin

 

is posted here:

No, not possible.  Most changes are now written to mercury.ini immediately though.

 

Hi

Solved the problem, Mcafee was seeing Mercury as a mass mailer and had the port blocked.

Thanks for you help.

Regards

Simon 

 

 

 

 

The got MG* is an inbound job from MercuryS or MercuryD.  Could be a bounce message, could be spam but if it's not to a local user then it's going to be bounced.  Need to see the rest of those lines.

 

Maybe nothing, the host might be down.  Try to ping the host and then try telneting into ports 25 and 110.  If these are successful then checkout the firewall setting to ensure you are not blocking WinPMail.  I generally try running a session log when this happens to see exactly what is going on.