[quote user="Thomas R. Stephenson"]

Use an AND filter with the address/domain of the requester and the Spamhalter header with an action delete (or move to a spam user).  Looks something like this in the riles.mer

If expression headers matches "X-SPAMWALL: SPAM detected!"  LogicalAnd ""

If header "CT" contains "domain.com" Move "@c:\\pmail\\mail\\spamaccount"

but the backup server handles mail for some other domains ... would that not forward ALL incoming mail to the remote server?

 

Hi, two weeks ago I've subscribed to a service that sends an e-mail at

2 a.m.   The default exit / restart also happens to be at 2 a.m.  It

turns out that when exit / restart happens it doesn't wait for

everything to be idle, but instead just does its thing, and anything in

progress will be lost.  I know that since I have POPFile and all the

service e-mails got as far as POPFile, but not into Mercury.  I've now

moved the reload time to 2:15 and they're now progressing all the way

to the client.  But what might be lost at 2:15?

Nothing will be lost, they'll be resent.  The SMTP protocol is designed to handle breaks in communication between the sender and the receiver.   If a SMTP connection is lost in the middle of a transaction, the sender is required by the RFC to requeue the mail to be sent later.  Now if the service does not resend a message  that fails to complete then you have to talk to them about their bug in their service.

I only have logging on as I was trying to find out why certain emails were not being received.

Now that's sorted logging will be turned off.

From David Harris:

It's stored as part of the encoded string in MercuryD.dat. There's
basically no way of getting at it outside the program's UI at this point.

 

aaaaaaaaaahhhhhhhhhhhhhhhh! damn! I've seen that so many times, but have never had to use it.

Many thanks.

[quote user="tomt"]My greeting.mer contains:

220-mail.domain.co.uk Mercury/32 v4.52 ESMTP server ready.
220-Use of this server for unauthorised relaying of mail is forbidden.
220 Unsolicited Commercial E-mail ("spam") is NOT WELCOME HERE.

Is this format wrong ??[/quote]

It isn't the format specified in greeting.txt because you have added response codes and the initial line. Here's a relevant section:

"We recommend the following text as a starting point:

--------- cut here --------------
Use of this server for unauthorised relaying of mail is forbidden.
Unsolicited Commercial E-mail ("spam") is NOT WELCOME HERE.
--------- cut here --------------

MercuryS automatically adds the SMTP response codes and continuation
characters correctly."

Try telnetting into your server to see what response you get.

That said, the client may not be able to handle multi-line responses anyway, even if they are formatted correctly.

 

Now you see the problems you have when you are trying to use a single-user protocol (POP3) to handle multiple users.  If you have an enlightened ISP, when they put the mail into the POP3 mailbox they will also add a special header passing the original SMTP RCPT TO: address the the message.  If so, MercuryD can (and should) be told what the header is and to use this header for delivery instead of the addresses in the RFC 2822 message body.  From the MercuryD help:

 

Checking for special headers in messages

By default, MercuryD goes through the standard headers in incoming mail looking for local addresses: the fields it examines are: "To", "Cc", "BCC" and "Received". MercuryD also records the Message-ID of every message it processes and usually will not attempt to deliver the same message twice.

Unfortunately, not all ISPs use POP3 mailbox schemes that will work with this approach: some use a non-standard header to record the address of the person for whom the message was actually intended - for example, "X-Deliver-To" is one that is seen from time to time. If your ISP uses a non-standard header to record the delivery envelope address, you can tell MercuryD about it using the Headers control: type in the name of the header Mercury should examine for local addresses (so, from our example above, you would type in X-Deliver-To). The field is not case-sensitive (so, X-Deliver-To and X-DELIVER-TO are treated as identical) and you can add the colon separator at the end of the name or not as you wish. If your ISP uses more than one special header to identify the local addressee, you can enter multiple header names in this field, separated by semi-colon characters (";"). You must not type any spaces in this field.

If you check the control labeled "Check only in these headers" then MercuryD will no longer examine the standard To, Cc, Bcc and Received headers for local addresses and will not discard duplicate messages. Use this control only if you are sure that your ISP always adds the header to your mail.

Your ISP will usually be able to tell you if they use a special header to identify the envelope address in your messages.

 

 

I've done some tests with Server 2008 and the upcoming Mercury 4.61 and didn't notice any issues with Loader/Mercury/S/P/E/Imap. Though from experience web site configuration takes some getting used to.

Ok, I got it. I had a misconfiguration of the local domains in the core modul. Now everything works fine. Thank you!

> Hi there,
>
>  I have mercury running on my local webserver. Now I want to configure
> mercury that it sends all the emails received to another smtp server
> in my network (e.g. smtp.mydomain.org). Mercury should not make any mx
> lookups itself, only forward it.

Mercury/32 currently does not provide MX services.  David's looking into this for a future enhancement but until that happens here's a work around.   

1.    Create a domain account for the domain you want forwarded. For example I forward the domain novell-tstephenson.com so I have a domains list setting of

DM=novell: novelltstephenson.com

2.    Create a program to get the CNM files in the user NOVELL directory and convert them to 101 "glue" header queue files that change the address to the IP address of the receiving SMTP host.  I did this in BASIC but you could use anything you happen to have and are familiar with to do the same thing.


REM This program was developed to send mail from a "domain" account to a different
REM server via SMTP.  It takes the CNM RFC 2822 message body, extracts the SMTP addresses
REM and then saves it as a 101 file.  The CNM import file is a directory listing
REM of the CNM files in the "domain" user account.

CLS
REM Set the path to the domain mailbox and the new domain name.
PATHSPEC$ = "c:\pmail\mail\novell\"
Domain$ = "@[192.168.1.3]"

REM Read in the CNM files
OPEN PATHSPEC$ + "files.txt" FOR INPUT AS #1
       
WHILE NOT EOF(1)
        REM Read the CNM directory listing
        LINE INPUT #1, Line$
        REM Check to see if this is a CNM file else skip it.  The CNM file is always 8.3.
        IF RIGHT$(Line$, 3) = "CNM" THEN File$ = RIGHT$(Line$, 12) ELSE GOTO SKIP
    
        REM Read the CNM file
        OPEN PATHSPEC$ + File$ FOR INPUT AS #2
       
        REM Get the MAIL FROM: and RCPT TO: addresses for the glue headers.
        REM I'm using the Sender: for the MAIL FROM: address. It may be blank
        REM for locally delivered mail but a blank MAIL FROM: works for me.
        WHILE NOT EOF(2)
            LINE INPUT #2, Line$
            IF LEFT$(Line$, 14) = "X-Envelope-To:" THEN RCPTTO$ = MID$(Line$, 16, LEN(Line$))
            IF LEFT$(Line$, 7) = "Sender:" THEN MAILFROM$ = MID$(Line$, 9, LEN(Line$))
        WEND
        REM Close the CNM file.
        CLOSE #2

        REM Change the domain name to the new domain in the RCPT TO: address.
        FOR I = 1 TO 100
            IF MID$(RCPTTO$, I, 1) = "@" THEN RCPT2$ = MID$(RCPTTO$, 1, I - 1) + Domain$
        NEXT I

        REM If the SMTP address was in brackets add the trailing bracket.
    IF LEFT$(RCPT2$, 1) = "<" THEN RCPT2$ = RCPT2$ + ">"

        REM Write the 101 file in Glue header format.
        OPEN PATHSPEC$ + File$ FOR INPUT AS #2
        OPEN PATHSPEC$ + LEFT$(File$, 8) + ".101" FOR OUTPUT AS #3
        REM Write the MAIL FROM:, RCPT TO: and blank line.
        PRINT #3, "$$ " + MAILFROM$
        PRINT #3, RCPT2$
        PRINT #3, ""
        REM Write the rest of the RFC 2822 body to the 101 file.
        WHILE NOT EOF(2)
            LINE INPUT #2, Line$
            PRINT #3, Line$
        WEND
        REM Close the CNM and 101 Files.      
        CLOSE 2
        CLOSE 3
        REM Delete the CNM file
        KILL PATHSPEC$ + File$
SKIP:
WEND
CLOSE
SYSTEM
END

4.    Create a BATCH file to process the CNM files.  I got the program wait.com off the web someplace.  Works fine.

ECHO OFF
:LOOP
CD c:\pmail\mail\novell
dir c:\pmail\mail\novell\*.cnm > c:\pmail\mail\novell\files.txt
REM CALL c:\qb45\qb /RUN c:\pmail\mail\novell\MX.BAS
call c:\pmail\mail\novell\mx.exe
move *.101 c:\mercury\queue
DEL c:\pmail\mail\novell\files.txt
call c:\pmail\mail\novell\wait -m 5
GOTO LOOP

5.    Load the batch file at startup.  I use NT Wrapper Pro to run it as a service  at startup.

Now mail for domain novell-tstephenson.com is received by tstephenson.com and moved to the Novell user new mail directory.  The bat file runs the program very 5 minutes and makes a list of all the CNM to files.txt.  The BAS file is run and reads the files.txt file to get all of the CNM files and adds the "glue" headers to the original CNM file and saves it as a 101 file.  The bat file moves the 101 files to the queue and loops.

This works for me to forward all mail from the outside world with the domain novell-tstephenson.com to the Mercury NLM server running on my Novell system. 

So, this PTR,reversed record can also be at my ISP and not needed at

my domain name hoster (budgetwebhosting.nl) because the spreading is

better than stuck in one place. Am i right or totally wrong?

Not totally wrong, not totally right.

1.    The PTR record is not required by the SMTP/ESMTP RFCs at all. There is no MUST requirement that the rDNS show anything.

2.    Many SMTP hosts though will not accept a connection that does not have a PTR record since a valid SMTP server SHOULD have one and it should point to a vaild host name. 

3.    A very limited number of SMTP hosts wil  not accept the mail from hosts where this PTR does not match the connecting EHLO/HELO srting.  I've never run into one of these but some have reported this as a problem.

So, I believe you are are properly setup and should have no problems delivering the mail.

 

I believe this message is hardcoded in the program. If you want a message in the system log window at program start you could write a small resident daemon with a startup function that has a logstring command. See daemon.txt in the Mercury\Resource directory for more information.

/Rolf 

hmm.. I double check to make sure

Thanks :) 

Thanks, it looks pretty simple when viewed like this. Unfortunately my head is averse to logic [:P] and trying to concoct this stuff leaves me in a gibbering heap.

What does the E stand for in FRE? Should it be FRS?

 

Edit 2:

It's OK, just discovered what it is.

Thanks again for the help *thumbs-up*

Ahh - thanks. Problem is, without going through the entire help system, users will not know this, nor other details which appear in the Help, but not in the manual.

Again, thankyou - looks like this is the perfect solution for me now. [H]

Hi Peter,

Thanks for your reply, and sorry for my late response.

I agree that these issues are not impairing the real functionality of Mercury/32 in any way, but it would be nice when the change of development environment would cure them.

If I can help in any way by testing something, just let me know.

Regards, Ed

[quote user="tomt"]

It turns out the filter was fine !
The user was still CC'ing the other 2 users..

[/quote]
That was exactly what the filter I've suggested was meant to avoid :)

Best regards,

Nico

problem solved thanks. just checking back, we had changed the username & Password many times and was sure it was right, when we turned on logging we found the local pasword set as the POP3 Password, this was definatly not the case when i looked at it friday but it may have been the case in the begining the person who set up the email may have entered it first time around.

 is there any chance of it getting locked up with the wrong password - either way the logging allowed me to view and check that it has been fixed.

thankyou for all your time

Mattr88