[quote user="Greenman"]<p><span style="font-size: 10pt;">Messages identified as spam are often simply dumped without notification.</span><span style="font-size: 10pt;"> </span></p><p>[/quote]</p><p>Thanks for the input folks, but it looks like Greenman is on the money.</p><p>I took my problem to another forum where reps from the ISP contribute and got a bite.  At the end of my log is: <span style="font-family: 'Open Sans', Verdana, 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14.6000003814697px; background-color: rgb(204, 201, 197);">14:25:07.920: >> 250 ok: Message 330362388 accepted<cr><lf></span><span style="font-size: 10pt;"> , and at some point in their log is </span><span style="font-family: 'Open Sans', Verdana, 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14.6000003814697px; background-color: rgb(204, 201, 197);">Thu Apr 30 12:24:57 2015 Info: MID 330362388 using engine: CASE spam positive</span></p><p>I'm now in email communication with an actual person at the ISP and he's currently looking into it, and theorised that "image in signature is a common culprit" which my emails have.  The timing of the spam identification would indicate something within the DATA section of the email too, since my message hadn't even completed sending when it was tripped.</p><p>I'll let you know the result, but in any case it's nice to know I'm not crazy.</p>

<p>For the last few weeks (or month) sending emails from Pegasus via MercuryC often results in the intended recipient simply not receiving it.  However, sometimes they do.  There is no bounce back message to say something has gone wrong, and all the logs I'm aware of within Mercury suggests that everything has occurred as it should.</p><p>For example here's part of a MercuryC session log of a message that DID get to the <receivingemailaddress>:</p><p>17:37:53.951: --- 29 Apr 2015, 17:37:53.951 ---</p><p>17:37:53.951: Connect to '<mailserver>', timeout 30 seconds.</p><p>17:37:54.951: >> 220 icp-osb-irony-out7.iinet.net.au ESMTP<cr><lf></p><p>17:37:54.951: << EHLO <domainname><cr><lf></p><p>17:37:55.045: >> 250-icp-osb-irony-out7.iinet.net.au<cr><lf></p><p>17:37:55.045: >> 250-8BITMIME<cr><lf></p><p>17:37:55.045: >> 250-SIZE 31457280<cr><lf></p><p>17:37:55.045: >> 250-STARTTLS<cr><lf></p><p>17:37:55.045: >> 250-AUTH PLAIN LOGIN<cr><lf></p><p>17:37:55.045: >> 250 AUTH=PLAIN LOGIN<cr><lf></p><p>17:37:55.045: << MAIL FROM:<sendingemailaddress> SIZE=60431<cr><lf></p><p>17:37:55.139: >> 250 sender <sendingemailaddress> ok<cr><lf></p><p>17:37:55.139: << RCPT TO:<receiving<span style="font-size: 13.3333330154419px;">emailaddress</span>><cr><lf></p><p>17:37:55.217: >> 250 recipient <receivingemailaddress> ok<cr><lf></p><p>17:37:55.311: << DATA<cr><lf></p><p>17:37:55.405: >> 354 go ahead<cr><lf></p><p>17:37:55.405: << Received: from Spooler by <domainname> (Mercury/32 v4.80.119) ID MO000005;<cr><lf>  29 Apr 2015 17:37:55 +1000<cr><lf></p><p>17:37:55.405: << Received: from spooler by <domainname> (Mercury/32 v4.80.119); 29 Apr 2015 17:37:48 +1000<cr><lf> </p><p><snipped rest of DATA section> </p><p>17:37:56.780: << --Message-Boundary-14164--<cr><lf></p><p>17:37:56.780: << .<cr><lf></p><p>17:37:57.014: >> 250 ok:  Message 625066933 accepted<cr><lf></p><p>17:37:57.014: << QUIT<cr><lf></p><p>17:37:57.139: >> 221 icp-osb-irony-out7.iinet.net.au<cr><lf></p><p>17:37:57.139: --- Connection closed normally at 29 Apr 2015, 17:37:57.139. --- </p><p> </p><p>And here's another message sent at a different time to the same <span style="font-size: 13.3333330154419px;"><receivingemailaddress> which has NOT been received:</span></p><p>08:17:22.498: --- 30 Apr 2015, 8:17:22.498 ---</p><p>08:17:22.701: Connect to '<mailserver>', timeout 30 seconds.</p><p>08:17:23.701: >> 220 icp-osb-irony-out7.iinet.net.au ESMTP<cr><lf></p><p>08:17:23.701: << EHLO <domainname><cr><lf></p><p>08:17:23.780: >> 250-icp-osb-irony-out7.iinet.net.au<cr><lf></p><p>08:17:23.780: >> 250-8BITMIME<cr><lf></p><p>08:17:23.780: >> 250-SIZE 31457280<cr><lf></p><p>08:17:23.780: >> 250-STARTTLS<cr><lf></p><p>08:17:23.780: >> 250-AUTH PLAIN LOGIN<cr><lf></p><p>08:17:23.780: >> 250 AUTH=PLAIN LOGIN<cr><lf></p><p>08:17:23.811: << MAIL FROM:<span style="font-size: 13.3333330154419px;"><sendingemailaddress></span> SIZE=60424<cr><lf></p><p>08:17:24.467: >> 250 sender <span style="font-size: 13.3333330154419px;"><sendingemailaddress></span> ok<cr><lf></p><p>08:17:24.467: << RCPT TO:<span style="font-size: 13.3333330154419px;"><receiving</span><span style="font-size: 13.3333330154419px;">emailaddress</span><span style="font-size: 13.3333330154419px;">></span><cr><lf></p><p>08:17:24.561: >> 250 recipient <span style="font-size: 13.3333330154419px;"><receiving</span><span style="font-size: 13.3333330154419px;">emailaddress</span><span style="font-size: 13.3333330154419px;">></span> ok<cr><lf></p><p>08:17:24.561: << DATA<cr><lf></p><p>08:17:24.639: >> 354 go ahead<cr><lf></p><p>08:17:24.639: << Received: from Spooler by <domainname> (Mercury/32 v4.80.119) ID MO00001E;<cr><lf>  30 Apr 2015 08:17:24 +1000<cr><lf></p><p>08:17:24.639: << Received: from spooler by <domainname> (Mercury/32 v4.80.119); 30 Apr 2015 08:17:01 +1000<cr><lf> </p><p><span style="font-size: 13.3333330154419px;"><snipped rest of DATA section> </span> </p><p>08:17:26.076: << --Message-Boundary-25279--<cr><lf></p><p>08:17:26.076: << .<cr><lf></p><p>08:17:26.311: >> 250 ok:  Message 625289068 accepted<cr><lf></p><p>08:17:26.311: << QUIT<cr><lf></p><p>08:17:26.389: >> 221 icp-osb-irony-out7.iinet.net.au<cr><lf></p><p>08:17:26.405: --- Connection closed normally at 30 Apr 2015, 8:17:26.405. --- </p><p> </p><p>According to my logic, if <span style="font-size: 13.3333330154419px;">icp-osb-irony-out7.iinet.net.au is sending messages back to Mercury saying everything is OK (as it did in both examples), then both messages should have made it to their destination, and the error would lie with </span><span style="font-size: 13.3333330154419px;">icp-osb-irony-out7.iinet.net.au itself (note, the number after 'out' in the server can vary, but the same 'sometimes' sending occurs).  I contacted the ISP about this, and their current position is, if their Webmail system works for our account without issue (which it seems to) then the issue would be with the sending client rather than their servers.</span></p><p><span style="font-size: 13.3333330154419px;"></span><span style="font-size: 10pt;">Mercury 4.74 was installed here for several years, and the above logs are from Mercury 4.80 since I upgraded to it only yesterday with a vain hope that it would help.</span></p><p>I'm quite in a pickle and welcome any advice. </p>

<p>Well, the SMTP server at icp-osb-irony-out7.iinet.net.au has confirmed receipt of both messages. There is no way for you (or Mercury) to know what happened after that point. The most common reason these days for messages not arriving to the destination is of course spam filtering somewhere in the transfer chain or in the receiving email client.</p><p> </p>

[quote user="Rolf Lindby"]<p>The most common reason these days for messages not arriving to the destination is of course spam filtering somewhere in the transfer chain or in the receiving email client.</p><p> <span style="font-size: 10pt;">[/quote]</span></p><p>Yep.  And back a month or 2 ago, some of the iinet.net.au servers were on server blacklists and we were receiving return emails to say that our emails had been rejected.  But as I mentioned, I am currently receiving no notification of any kind that message aren't getting to their destination.</p><p>After my original post I tried MercuryE for the first time, which as I understand, completely bypasses intermediate servers and connects direct to the server of the intended receiver.  I sent an email to my private email address and received it straight away.  Unfortunately, all other servers rejected the messages as spam since my IP address (as allocated by my ISP) is on a PBL at spamhaus.org.  According to the entry in the list: </p><p><span style="color: rgb(51, 51, 51); font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11px; line-height: 18px;">"It is the policy of <ISP> that unauthenticated email sent from this IP address should be sent out only via the designated outbound mail server allocated to <ISP> customers."</span></p><p>In theory, I can change my current internet plan to a business plan to get an IP address that would allow such method of sending emails, but of course I shouldn't have to do that.</p><p>So, if MercuryC sends an email to the ISP's servers and the server confirms it's received the message but the messages doesn't get to it's destination.  And, MercuryE can send emails bypassing the ISPs server, and they get to their destination (as long as that destination doesn't use the specific spam block list), is there any doubt that it's the ISP's servers which are causing the problem?  Is there anything else that Mercury could possibly be doing (filters, policies etc.) that wouldn't show up on a session log which could cause an intermittent issue?</p><p> </p>

<P>If Mercury was responsible you'd see a 'message killed by filtering rule' notification in the Mercury Core Process window when the message was sent. Any other delivery failures would be received by the sender and would be sent either by Mercury or the ISP's mail server or the receiving domain's mail server.</P> <P>Messages identified as spam are often simply dumped without notification. </P> <P>To make sure you need to send a message to the same destination via MercuryC and via your ISP. You need to do this several times. If you get consistent results as described above then your ISP will have to check their settings and discover if your messages are being identified as spam. If they are the ISP should be able to adjust their settings or add your user@domain list of addresses to an allow list.</P> <P mce_keep="true"> </P>

<p>As we see in the log that messages have been received by your ISP's server we know that Mercury hasn't blocked anything. We still don't know if it's your ISP or something at the destination that prevents delivery though. I would probably try sending a test message to for instance a Gmail account that I can access to see what happens.</p><p> </p>