> 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
>

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.

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.

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.

I hope that

is clear, many thanks in advance for any suggestions.

Thanks,

Tim

[quote user="oaneadp"]

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 ).

[/quote]  

Those two controls are distinct.  The former merely tells Mercury to advertise ESMTP AUTH and to accept authenticated users as permitted sources of mail destined for non-local addresses in spite of any configuration to the contrary (look at the excellent help page accessed from that dialog).  The latter is the "Master switch" for any kind of relaying.  If it's off (box not checked), the net's in trouble!  In particular, your use of authentication has bypassed the sender (that's the envelope sender - not in the headers) address check that "Normal" relaying controls imply.  You can confirm that you're an open relay by sending your mail from billg or whoever else you pick on from outside your domain to any nonlocal address and it will work even if you don't authenticate first.  And with "Normal" relaying controls on, you can still relay by spoofing any address in your own domain to anywhere without authentication.  The absolutely most safe way to operate Mercury as a closed relay for most users is simply to ensure that the "Only authenticated users may relay mail" checkbox is checked.  This simply guarantees that no amount of address forgery or no matter where the connection originates there will not be any relaying without authentication.  And since most clients will support SMTP auth, that just isn't a problem.

Besides, I think you're missing something here.  SMTP doesn't provide any protection against any kind of forgery.  It's trivial to do from any MTA and Mercury is no exception.  What you're asking for here is a feature that in essence doesn't allow mail to be sent outside when the sender's user part matches the actual user credential.  I can imagine doing that sort of thing with Sendmail and some stomach-knotting, mind-numbing rewriting rules, but for most sane mailers that just isn't an option.  It wouldn't be so bad if the trace (Received:) fields had some user accountability information in them, but Mercury doesn't add it (another feature for the implementer ...).

Cheers,

Sabahattin