Pegasus Mail & Mercury

Hello from Australia 

I think I have a fairly simplistic Mercury setup, just using the MercuryC (SMTP Client) and MercuryD (POP3 Client) modules.  Therefore most of the work of the system is handled by my ISP.

As per this post's subject, the problem I have is I'm not recevied any failure notifications (presumably generated by my ISP) for email that has been mis-addressed.  I have received them in that past (possibly prior to upgrading to Mercury 4.52 but I can't be sure).

Just to confirm that I have the message path correct, Mecury sends messages to the ISP.  ISP sends message to recipient.  Recipient sends failure back to ISP.  Mercury received failure from ISP.  Right?

I rang the ISP and there isn't a problem at their end.  As a test, I logged into the server that Mercury checks via the ISP's Webmail service.  From there I sent a message to a bogus address and received a failure instantly, and when Mercury did it's next poll for new mail it received the failure notification as it would any normal email.

From that I get the impression that the ISP's mail server work fine, but for some reason it doesn't generate failutre notification for email it's receives via Mercury. If nothing else that confirms that I don't have any filters in Mercury that deletes failures instead of receiving them (right?).

I hope there's something simple that I'm missing.  Please let me know your thoughts.

Regards

Stuzz

Not sure what is happening with your v4.52 MercuryC setup but when I installed v4.52 using MercuryC to send the mail to a known bad address I got the following bounce.

 

Received: from spooler by Mercury.4.52 (Mercury/32 v4.52); 5 Mar 2008 11:18:39 -0800
X-Envelope-To: Electronic Postmaster <Admin@Mercury.4.52>
To: Electronic Postmaster <Admin@Mercury.4.52>
From: Electronic Postmaster <postmaster@Mercury.4.52>
Date: Wed, 5 Mar 2008 11:18:28 -0800
Subject: Postmaster Notify: Delivery Failure.
MIME-Version: 1.0
Content-type: multipart/mixed; boundary=27904.957754453

This message is in MIME format. If you are seeing this text,
then your mailer does not understand this format properly.

--27904.957754453
Content-type: Text/Plain; charset=US-ASCII
Content-Disposition: Inline
Content-Description: Reason for delivery failure.

The attached message has failed delivery and has been referred
to you as postmaster. The following error report or reports
were given to explain the problem:

   *** bad_address@tstephenson.com
   550 Address '<bad_address@tstephenson.com>' not known here.

--27904.957754453
Content-type: Message/RFC822

Received: from spooler by Mercury.4.52 (Mercury/32 v4.52); 5 Mar 2008 11:18:06 -0800
From: "E-Mail Administrator" <postmaster@Mercury.4.52>
To: bad_address@tstephenson.com
Subject: Test of mercuryC bounce
Date: Wed, 5 Mar 2008 11:17:46 -0800
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Mailer: Mercury/32 v4.52
Message-ID: <3915D6454CE0@Mercury.4.52>

This is a test of mail sent to a bad address.

--27904.957754453--
 

---

Thomas R. Stephenson
San Jose, California
Member of Pegasus Mail Support Team

stuzz78:

  

Just to confirm that I have the message path correct, Mecury sends messages to the ISP.  ISP sends message to recipient.  Recipient sends failure back to ISP.  Mercury received failure from ISP.  Right?

 

Maybe.  The last two steps, I think, are your problem.  What was the return address on the mail you sent out?  Assuming it left your queue (check the core process window to see they've been processed), the mail is out of your hands and the failure will be coming back from some other host - maybe your ISP, maybe a domain's MX.  The address to which that notice will be sent has to be valid.  If your ISP's mail account is the sender, it'll go into your ISP's POP3 box like you say where it will be picked up.  And since you've just told us that it works with webmail, something is obviously wrong with your outgoing job's return address.  What was it?  Check it first.

 

  

stuzz78:

  

  I rang the ISP and there isn't a problem at their end.  As a test, I logged into the server that Mercury checks via the ISP's Webmail service.  From there I sent a message to a bogus address and received a failure instantly, and when Mercury did it's next poll for new mail it received the failure notification as it would any normal email.

From that I get the impression that the ISP's mail server work fine, but for some reason it doesn't generate failutre notification for email it's receives via Mercury. If nothing else that confirms that I don't have any filters in Mercury that deletes failures instead of receiving them (right?).

 

There are a couple of other sneaky possibilities that might cause this.  But I'll bet the return address is the problem.  For instance, it could be that the webmail facility injects mail using the sendmail command and is therefore immune to SMTP-level rejection so that the ISP smarthost is forced to generate a DSN.  Check your queue and make sure it's empty before testing again to make sure that the job really got submitted.

 

Cheers,

Sabahattin

 

---

--
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme@yamta.org
http://sabahattin-gucukoglu.com/

Just to add to the possibles:

There's a big ISP in the UK (Plusnet) that will never send back DSNs for mail that is relayed through them, unless you host the domain with them.  (I guess it was originally put in place to deal with backscatter complaints.)

Some ISPs are like that.

Thankyou everyone for your suggestions.  I'm getting notifications now, so I guess I fixed the problem.  It seems it was due to my MercuryD setup regarding "Local User" and "Default User".

I had a user name in the Local User field and the Default User field was blank, so that all mail received goes to that one user, irrespective of who it was addressed to.  However, on reading the help regarding the Default User field I found:

If you leave this field blank, MercuryD will discard any messages for which it can find no local delivery addresses...

I believe this is where my messages were going.  Unless something else has changed without my knowledge.  All I did was move the username from the Local User field to the Default User field, and all seems well.

Thanks again

Regards, Stuzz