Maybe I found where is the problem.

Here is the QCF/QDF of a test message in the queue folder of the first instance:

[quote]

ST: R 000000000000 00 000001 000000 000000

FR: <pinco.palla@pec.it>

DF: MG000022.QDF

FL: 65536      

OS: 120112111502

BA: <myhouse@blabla.it>

ES: R 120112111502

RI: 000.000.000.000 000.000.000.000 000.000.000.000 000.000.000.000

DI: --------.---

EA:

Return-path: <pinco.palla@pec.it>

Received: from ugenerico2 (192.168.1.8) by palla09.local (Mercury/32 v4.72) with ESMTP ID MG000022;

   12 Jan 2012 11:15:02 +0100

From: "Pinco Palla" <pinco.palla@pec.it>

To: <myhouse@blabla.it>

Subject: prova 12genn h.11.14

Date: Thu, 12 Jan 2012 11:15:02 +0100

Message-ID: <00f201ccd113$0c3d9cd0$24b8d670$@palla@pec.it>

MIME-Version: 1.0

Content-Type: multipart/alternative;

    boundary="----=_NextPart_000_00F3_01CCD11B.6E0204D0"

X-Mailer: Microsoft Office Outlook 12.0

Thread-Index: AczREwwXeQjdos+cQ1+Jps9WknKHzw==

Content-Language: it

...cut......cut......cut...

[/quote]

As already seen, this message is moved by an outgoing rule to the

PEC-out mailbox, and sits there waiting to be picked up by Wsmtpex; the

following is the Header of the message found in the CNM file in the

PEC-out folder

[quote]

Received: from spooler by palla09.local (Mercury/32 v4.72); 12 Jan 2012 11:17:50 +0100

Received: from ugenerico2 (192.168.1.8) by palla09.local (Mercury/32 v4.72) with ESMTP ID MG000022;

   12 Jan 2012 11:15:02 +0100

From: "Pinco Palla" <pinco.palla@pec.it>

To: <myhouse@blabla.it>

Subject: prova 12genn h.11.14

Date: Thu, 12 Jan 2012 11:15:02 +0100

Message-ID: <00f201ccd113$0c3d9cd0$24b8d670$@palla@pec.it>

MIME-Version: 1.0

Content-Type: multipart/alternative;

    boundary="----=_NextPart_000_00F3_01CCD11B.6E0204D0"

X-Mailer: Microsoft Office Outlook 12.0

Thread-Index: AczREwwXeQjdos+cQ1+Jps9WknKHzw==

Content-Language: it

...cut......cut......cut...

[/quote]

We can see that the "Return-path: <pinco.palla@pec.it>" line disappeared.

Now, as stated in the wsmtpex.txt file

[quote]

WSMTPEx looks into .CNM file and search for header 'Return-Path' for

SMTP envelope MAIL FROM address. Uses "<>" if none is found.

[/quote]

So, I was thinking that this may lead to the QCF with the empty "FR: <>" field in the queue of the second instance (and to the subsequet problems).

May this be so?

I'm wondering what to do... Any idea?

Best regards

Filippo

Hello (and happy new year).

I would need some help in mail forwarding between instances of Mercury, running on the same machines.
As stated in a previous post
[quote]
At office we have M/32 which sends mail relaing on our ISP (say, at smtp.antani.it).
We also have another ISP, providing us with certified mail; to send certified mail we must relay on the special smtp server provided by the ISP (say, at smtp.pec.it).

Now, as in M/32 you can configure only one external smtp to relay on, I was thinking about the possibility of installing a second copy of M/32 in another Directory of our server (W2008), whit its own queues, mailboxes, users, ecc., so on the same machine would run 2 separate instances of M/32.
[/quote]

The suggestion was
[quote]
Non Problema as long as you are not running against the same queue.  You can have the first server forward all outbound to the domain smtp.pec.it to the second instance of Mercury.  In this case this the second instance will connect via MercuryC to the proper host.
[/quote]

Now I made the following setup
Mercury main server:
- created a dummy user named PEC-out
- created the following outgoing filter rule: if "FROM:" field of any outgoing msg contains "@pec.it", then MOVE the message to the user PEC-out
WSMTPEx looks in the PEC-out mailbox, and forwards the mail it founds in it to the seconds instance of M32 on port 8025 (both M32 are run on the same machine).
M32 second instance gets the mail via MercuryS and sends out via MercuryC that relays on smtp.pec.it


The problem: the mail received by the final recipient is not certified: it's a plain mail.

I suspect that there is something wrong in the forwarding of the mail, but I cannot imagine what.
Here is the plot of the QCF/QDF files

QCF/QDF in first m-32 instance (=before forwarding)
[quote]
ST: R 000000000000 00 000001 000000 000000
FR: <pinco.palla@pec.it>
DF: MG000059.QDF
FL: 65536      
OS: 120104154221
BA: <myhouse@blabla.it>
ES: R 120104154221
RI: 000.000.000.000 000.000.000.000 000.000.000.000 000.000.000.000
DI: --------.---
EA:

Return-path: <pinco.palla@pec.it>
Received: from ugenerico2 (192.168.1.8) by palla09.local (Mercury/32 v4.72) with ESMTP ID MG000059;
   4 Jan 2012 15:42:21 +0100
From: "Pinco Palla" <pinco.palla@pec.it>
To: <myhouse@blabla.it>
Subject: prova pec
Date: Wed, 4 Jan 2012 15:42:20 +0100
Message-ID: <011501cccaef$108be5a0$31a3b0e0$@palla@pec.it>
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----=_NextPart_000_0116_01CCCAF7.72504DA0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AczK7xBqxe3JNvvSRl2gzvAyebxuUQ==
Content-Language: it

This is a multi-part message in MIME format.
[/quote]

QCF/QDF in SECOND m-32 instance (=AFTER forwarding, and before the sending via MercuryC)
[quote]
ST: R 120104160935 01 000001 000000 000000
FR: <>
DF: MO000002.QDF
FL: 0          
OS: 120104153932
BA: myhouse@blabla.it
ES: R 120104153932
RI: 000.000.000.000 000.000.000.000 000.000.000.000 000.000.000.000
DI: --------.---
EA:

Received: from spooler by palla09.local (Mercury/32 v4.72); 4 Jan 2012 15:39:32 +0100
Received: from J-Mailer (192.168.1.2) by palla09.local (Mercury/32 v4.72) ID MG000001;
   4 Jan 2012 15:38:04 +0100
Received: from spooler by palla09.local (Mercury/32 v4.72); 4 Jan 2012 15:37:34 +0100
Received: from ugenerico2 (192.168.1.8) by palla09.local (Mercury/32 v4.72) with ESMTP ID MG000057;
   4 Jan 2012 15:37:18 +0100
From: "Pinco Palla" <pinco.palla@pec.it>
To: <myhouse@blabla.it>
Subject: prova pec
Date: Wed, 4 Jan 2012 15:37:17 +0100
Message-ID: <010701cccaee$5bf609e0$13e21da0$@palla@pec.it>
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----=_NextPart_000_0108_01CCCAF6.BDBA71E0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AczK7luulxMEygP5TRGlH0VEwjFtQQ==
Content-Language: it

This is a multi-part message in MIME format.
[/quote]


By the way, if I configure Outlook to send mail directly to MercuryS on the second instance of M32, it works like a charm, so the problem is not in the interaction between m32 and the certified mail server. Here is the plot of the queue
[quote]
ST: R 000000000000 00 000001 000000 000000
FR: <pinco.palla@pec.it>
DF: MG000001.QDF
FL: 65536      
OS: 120104175019
BA: <myhouse@blabla.it>
ES: R 120104175019
RI: 000.000.000.000 000.000.000.000 000.000.000.000 000.000.000.000
DI: --------.---
EA:

Return-path: <pinco.palla@pec.it>
Received: from ugenerico2 (192.168.1.8) by palla09.local (Mercury/32 v4.72) with ESMTP ID MG000001;
   4 Jan 2012 17:50:19 +0100
From: "Pinco Palla" <pinco.palla@pec.it>
To: <myhouse@blabla.it>
Subject: prova 3
Date: Wed, 4 Jan 2012 17:50:19 +0100
Message-ID: <01a101cccb00$f121e270$d365a750$@palla@pec.it>
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----=_NextPart_000_01A2_01CCCB09.52E64A70"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AczLAPD791P/psbOTZKAFHOX0vvAaQ==
Content-Language: it

This is a multi-part message in MIME format.
[/quote]

Best regards

Filippo

You seem to lose MAIL FROM in the SMTP envelope when forwarding to the second instance of Mercury. What exactly are the requirements for the certified mail service provided by smtp.pec.it?

/Rolf 

In the weekend I will read the tech manual of the service, and translate it (it's in italian).

Best regards.

Filippo

I found the timeto translate: here it is:

(...cut...)
(Upon receiving the original message) in transmission, the ISP prepares the transport envelope: this envelope consists in a message generated by the ISP access point, and contains the original message and the certification data.
The transport envelope inherits from the original message the following headers:
- Received
- To
- Cc
- Return-Path
- Message-ID
- X-Riferimento-Message-ID
- X-TipoRicevuta

Inside the transport envelope there is, in attachment, the whole original unmodified message, in a format that complains with RFC 2822, with its headers, body and attachments. Inside the same transport envelope ther is also an XML attachment that contains the certification data (already presents in the body of the envelope) and additional informations about the kind of the message and the sort of the receipt requested.

When the ISP access point receives the message, the system grants the formal correctness of the message, by checking that:
- in the message a "From" field with an email address compliant with RFC 2822 exists;
- in the message a "To" field with one or more email addresses compliant with RFC 2822 exists;
- the sender email address in the reverse-path coincides with the data in the "From" field;
- the recipient email addresses in the forward-path coincide with the data in the "To" and "C" fields.
[...cut...]

Best Regards

Filippo

So the problem is presumably that the SMTP envelope is expected to contain Return-Path (= MAIL FROM), which was <> in your example. I afraid I haven't been using WSMTPEx myself so I'm not sure how this can be fixed.

/Rolf 

> So the problem is presumably that the SMTP envelope is expected to

contain Return-Path (= MAIL FROM), which was <> in
> your example. I

afraid I haven't been using WSMTPEx myself so I'm not sure how this can be fixed.

I really do not understand this since I am using WSMTPEX  to forward mail from a Mercury/32 gateway server to other domains using the same IP address.  The actual e-mail headers just get a couple of extra lines showing the transfer but the original MAIL FROM and SENDER headers are not changed.

Now if they are forwarding the message that is being delivered to an account then the server is going to generate a new set of MAIL FROM and RCPT TO  addresses using the <> for the MAIL FROM.  Maybe I'm missing something here.

I will try to add an always-trigger rules to insert a field in every message.

Best regards

Filippo

The headers in the message itself are probably OK, the problem is that WSMTPEX appears to use <> instead of the real sender as MAIL FROM in the SMTP envelope.

/Rolf 

Excuse me Mr. Stephenson, which version of wsmtpex are you using?

best regards

Filippo

[quote user="Rolf Lindby"]

The headers in the message itself are probably OK, the problem is that WSMTPEX appears to use <> instead of the real sender as MAIL FROM in the SMTP envelope.

/Rolf 

[/quote]

You are right: I paused the core in 2nd instance; then I opened the QCF file in the queue, and manually changed the line "FR: <>" to "FR: <pinco.palla@pec.it>"; saved the file, unpaused the core, and all worked well; so the problem is that empty FR field. I don't know what to think; I post here my wsmtpex.ini, in case I made some error:

[quote]

# Configuration file for WSMTPEx
# At the begining, it is recomended to use program menu Option for configuration.
# When you change this file, WSMTPEx will automatically update its
# config in next cycle time.

#  You can rename this tool, but name of following section must remain [WSMTPEx]
[WSMTPEx]
Version=0.26
# Mail header in which target address is searche for
#   if not defined, X-Envelope-To: is used
XToHeader=To:
#  Number of seconds to delay between searches for emails
LoopDelay=30
#  Folder, under which is most of user's mailboxes
UserFolder=C:\MERCURY\MAIL\
Domains=1
LogName=C:\MERCURY-PEC\LOGS\WSMTPEX\wsmtpex.log
MailBoxes=1
Badmails=C:\MERCURY-PEC\MAIL\WSMTPEx-badmail\

# Domains must be numbered from 1 to Domains
[Domains]
# Users email address domain part
Domain1=pec.it
# where to send all mail for domain (if port is not specified, default 25 is used)
SMTPServer1=192.168.1.2:8025

# Users must be numbered from 1 to MailBoxes
# User parameters are:  "name";"folder";"domain"
[Mailboxes]
# "normal" user.
# Mail found in folder "<UserFolder>\regdir" will be sent to <regular@Domain1>
Mailbox1=DM:pinco.palla;PEC-out;1
[/quote]