Hi! And many thanks! Once again!
So, MercuryC.NLM work as should (~ designed) and problem lies in sender (mail-system)!
Great support! Also, our best to mr. Harris!
More thanks, Alar from Tartu Uni, Estonia.
PS! I got another such a sender and there was "Reply-To: <>". And, yes, it failed autoforwarding.

Hi!
We still use Mercury NLM, served us well! =)
We have on some mailboxes set forwarding and time-to-time see in Mercury.log error "Failed during autoforwarding.". Even is set deliver when autoforward e-mail is rejected and error is sent back. Any ideas?
More thanks, Alar.

> We still use Mercury NLM, served us well! =)

As do I here at home.  It's running behind a Mercury/32 gateway server though.  ;-)

> We have on some mailboxes set forwarding and time-to-time see in Mercury.log error "Failed during autoforwarding.". Even is set
> deliver when autoforward e-mail is rejected and error is sent back.

Not sure what you mean here.  It is getting delivered but the autoforwarding failed and the original sender gets an error message?  If so this is normal for a failure since an autoforward is a bounce so all of the original sender information is still used when doing a bounce.

Are you asking why the autoforwards are bouncing?

Hi and thanks!
Yes, we also use Mercury NLM after Mercury/32 gw! =)
Mercury/32 with ASSP - Netware with Mercury NLM and mailboxes on it. For some users is set autoforwarding via the same Mercury/32 to another server.
Sorry, I explained it bad. No, it is not delivered at all even is set to deliver even autoforwarding is set! Original sender is getting error!
Can't see why this happen.
More thanks, Alar.

Sorry. My interest is why Mercury can't autoforward it and deliver at all. Bounce during error ... that's probably ok. Is there a option to set for Mercury NLM for trying again after ... some problems, even I don't see any problems.
More thanks, Alar.

> Sorry. My interest is why Mercury can't autoforward it and deliver at all. Bounce during error ... that's probably ok. Is there a
> option to set for Mercury NLM for trying again after ... some problems, even I don't see any problems.

If it was a 400 series temporary error then MercuryC will requeue and try later.  If it was a 500 series fatal error it will never retry.

Hi and thanks!
Today it happen again and in log I see it does happen time-to-time, as I wrote. Probably it is, as You said, 500 error, because it was sent back almost at once. Yesterday evening from the same address (sender) this happen again. Original sender wrote that this seems to happen when she send a message from home, well, not sure using what.
Any ideas why Mercury/NLM could get this 500 error?
More thanks, Alar.

Here is one header did get bounced with error, do You see any ... odd's there. This message (ad) with this header did get error mentioned in subject. (Names/addresses is changed.)

Return-path: bouncer@miskit.ee
Received: from merc.kamiskit.ee (10.0.0.63) by info.kamiskit.ee (Mercury 1.48) with ESMTP;
15 Jun 10 12:44:25 +0300 (EET)
Received: from Spooler by merc.kamiskit.ee (Mercury/32 v4.52) ID MO002B06;
15 Jun 2010 12:44:25 +0300
Received: from spooler by kamiskit.ee (Mercury/32 v4.52); 15 Jun 2010 12:44:18 +0300
Received: from ASSP-nospam (127.0.0.1) by merc.kamiskit.ee (Mercury/32 v4.52) with ESMTP ID MG002B05;
15 Jun 2010 12:44:14 +0300
Received: from must.ut.ee ([193.40.51.251] helo=must.ut.ee) with
IPv4:25 by ASSP-nospam; 15 Jun 2010 12:44:14 +0300
Received: from carmen.it.ut.ee (carmen.it.ut.ee [193.40.51.234])
by must.ut.ee (8.13.8+Sun/8.13.8) with ESMTP id o5F9aicq013684
for <aniir@it.ut.ee>; Tue, 15 Jun 2010 12:36:44 +0300 (EEST)
X-AuditID: c12805ea-b7be5ae0000016cd-3b-4c1749ac25ac
Received: from t2mail5.trig.ee (t2mail5.trig.ee [212.17.5.22])
by carmen.it.ut.ee (Symantec Mail Security) with SMTP id 92.36.05837.CA9471C4; Tue, 15 Jun 2010 12:36:44 +0300 (EEST)
Received: by t2mail5.trig.ee (Postfix, from userid 0)
id 0A438478E9; Tue, 15 Jun 2010 12:36:44 +0300 (EEST)
From: =?UTF-8?b?TUFYSU1B?= info@maxa.ee
To: rii@ut.ee
Reply-to:
X-Customer-ID: 5332-66501608
Errors-to: bouncer@miskit.ee
Subject: =?UTF-8?b?VG9vcnN1aXRzdXZvcnN0IE1laWUgMTkwIGcgdmFpZCAxMy45MCBrcm9vbmkgICB0ZXN0?=
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_000_01C1C8EE.CC21BFA0"
Message-Id: 20100615093644.0A438478E9@t2mail5.tri.ee
Date: Tue, 15 Jun 2010 12:36:44 +0300 (EEST)
X-Brightmail-Tracker: AAAABhSiMgEUojIyFKI9/xSjEkUUoxJnFKMZsw==
X-Assp-Score: -1 (193.40.5 in griplist (0.23))
X-Assp-Score: 10 (Foreign Country EE - Department of Information
Technology Services)
X-Assp-Envelope-From: bouncer@miskit.ee
X-Assp-ID: ASSP-nospam (id-95054-01764)
X-Assp-Version: 1.6.1.2(1.0.01)

More thanks, Alar.

Today it happen again and in log I see it does happen time-to-time, as I

wrote. Probably it is, as You said, 500 error, because it was sent back

almost at once.

Yesterday evening from the same address (sender) this

happen again. Original sender wrote that this seems to happen when she

send a message from home, well, not sure using what.

If it the same sender the sender might be on a blacklist or there is something in the message itself that is considered spam.

Any ideas why

Mercury/NLM could get this 500 error?

Hi and thanks!
Well, sorry, can't follow You!
E-mail is sent and first server handling it is Mercury/32 with ASSP. Then it is sent to Netware server Merc/NLM. On this last one is no filtering, spam control etc., all this is done on Mercury/32. All Merc/NLM has to do is put into mailbox and - when applied - forward. And message is authentic, I mean OK. Error "Failed during autoforwarding." appear in mercury.log. In mercurys.log also isn't much about it, all as usual. Message is not put into user mailbox neither resent (copy, forwarded to another address)! Yes, problem appear with some addresses, but there is nothing to do with spam etc. Also, I see that for users where is set no forwarding, no problem getting e-mail's from the same address(es) bouncing ... "Failed during autoforwarding.". Strange, isn't it!?
Session log?
More thanks, Alar.

> Well, sorry, can't follow You!
>
> E-mail is sent and first server handling it is Mercury/32 with ASSP.
>
> Then it is sent to Netware server Merc/NLM. On this last one is no filtering, spam control etc., all this is done on Mercury/32.

Forwarded to MercuryS.NLM using MercuryE?  other?

> All Merc/NLM has to do is put into mailbox and - when applied - forward.

Forwarded via MercuryC.NLM via Mercury/32 MercuryS?  Some other server?  
What does the MercuryC log show?

> And message is authentic, I mean OK. Error "Failed during autoforwarding." appear in mercury.log. In mercurys.log also isn't
> much about it, all as usual. Message is not put into user mailbox neither resent (copy, forwarded to another address)!

Now the not being delivered is very strange unless there is something in the SMTP e-mail addresses that are invalid. This has nothing to do with the body of the actual message, this has to do with the SMTP MAIL FROM and RCPT TO addresses as received by MercuryS.NLM  from MercuryE.

> Yes, problem appear with some addresses, but there is nothing to do with spam etc.

Why do you say that?  The sending e-mail address may be on a blacklist that the autoforward receiving server is using to block the mail.  It might even be something in the ASSP headers that is triggering the bounce.

> Also, I see that for users where is set no forwarding, no problem getting e-mail's from the same address(es) bouncing ...
> "Failed during autoforwarding.". Strange, isn't it!?

No really, autoforwards can bounce for any number of reasons.  The non-delivery though is a problem since there autoforward and delivery are completely disconnected UNLESS there is a problem in the SMTP addresses.

> Session log?

MercuryE session log showing the delivery of the bouncing mail to MercuryS.nlm.

> More thanks, Alar.

Hi and thanks! And sorry for bother, I am here under some pressure, as You understand, e-mail's must get delivered! =)
(1) Forwarded from Mercury/32 to MercuryS.NLM using MercuryE.
(2) Right now I see entries from Mercury.INI and MercuryS.INI
E 20100616 0013 0    Mv.JuTu.MTK  Failed during autoforwarding.
This is only error in log so far I see. We haven't log on MercuryC.NLM as it wasn't there by default and ... I'd set log entry into Mercury.INI and later tonight will reload MercuryC on Netware server.
(3) Failed message header is above (in earlier posting), maybe there You see something ...?
Only "thing" I can see comparing other e-mail's I get is that in these two addresses bouncing forwarding so far I see
Reply-to: <empty>
Could this be a issue for MercuryC.NLM etc. during forwarding?
(4) No-no, this address we have last three problems is OK, I'm sure. This is why I noticed that, original sender get error back.
(5) Yes, for me is strange that users who don't have forwarding set they get this same message from same address, users who have forwarding set ... not!
(6) I'll turn on MercuryE session log.
More thanks, Alar.

> Hi and thanks! And sorry for bother, I am here under some pressure, as You understand, e-mail's must get delivered! =)
> (1) Forwarded from Mercury/32 to MercuryS.NLM using MercuryE.

Turn on session logging in MercuryE to verify the transfer.

> (2) Right now I see entries from Mercury.INI and MercuryS.INI
> E 20100616 0013 0    Mv.JuTu.MTK  Failed during autoforwarding.

In the INI files or the log files?    

> This is only error in log so far I see. We haven't log on MercuryC.NLM as it wasn't there by default and ... I'd set log entry into Mercury.INI and later tonight will reload MercuryC on Netware server.

> (3) Failed message header is above (in earlier posting), maybe there You see something ...?

There was nothing there that has the RCPT TO or MAIL FROM SMTP addresses so it was not very helpful.   There may have been a header that caused the receiving system to bounce it but that's not something that you control.

> Only "thing" I can see comparing other e-mail's I get is that in these two addresses bouncing forwarding so far I see
> Reply-to: <empty>
> Could this be a issue for MercuryC.NLM etc. during forwarding?

Yes, it's possible that this does cause a problem since MercuryC might be hanging on this field.  

> (4) No-no, this address we have last three problems is OK, I'm sure. This is why I noticed that, original sender get error back.

The address might be good for you but bad for the system receiving the autoforward.

> (5) Yes, for me is strange that users who don't have forwarding set they get this same message from same address, users who have forwarding set ... not!

The forwarding might be causing the problem.  You might turn on session logging in MercuryC.nlm to see exactly what is happening with the failure.

> (6) I'll turn on MercuryE session log.
> More thanks, Alar.

Hi and thanks again!
Well, will try to get some logs.
But question ahead. If this blank reply-to is the source of the problem, is MercuryC.NLM correct handling this that way? Also, please, could You point to some regulation(s) about e-mail header consistent etc.? I mean, probably this reply-to field must not be blank!? So far I can see this error with e-mail's coming from two addresses, one of these is correct address and sender, another one ... offering something, local (I mean, Estonian) spam(mer)!
More thanks, Alar.

> But question ahead. If this blank reply-to is the source of the problem, is MercuryC.NLM correct handling this that way? Also, please,
> could You point to some regulation(s) about e-mail header consistent etc.? I mean, probably this reply-to field must not be blank!? So far I
> can see this error with e-mail's coming from two addresses, one of these is correct address and sender, another one ... offering
> something, local (I mean, Estonian) spam(mer)!

I've always the reply-to: field should not be blank if present since most e-mail clients will use this when replying.  The RFC-5322 says it will have one or more addresses.

3.6.2.  Originator Fields

   The originator fields of a message consist of the from field, the
   sender field (when applicable), and optionally the reply-to field.
   The from field consists of the field name "From" and a comma-
   separated list of one or more mailbox specifications.  If the from
   field contains more than one mailbox specification in the mailbox-
   list, then the sender field, containing the field name "Sender" and a
   single mailbox specification, MUST appear in the message.  In either
   case, an optional reply-to field MAY also be included, which contains
   the field name "Reply-To" and a comma-separated list of one or more
   addresses.

BTW I sent a message to an auto forwarded Netware user with a blank Reply-to: address field and it failed during autoforwarding.