Maillog explanation required

Question

I was wondering if anyone could help me read this maillog and tell me why emails to test-b made it through while emails to test-t did not. As you will see each email is also bcc'ed to test-s, and the one for test-b made it to test-s while the one intended for test-t did not make it anywhere.

Let me add I am not really a system admin but I have to 'fill in'. So any help will be appreciated.

Note: I have changed emails to protect privacy of owners :P.

Here is the log:

Dec  8 21:54:29 w3 sendmail[10083]: pB88sSlk010083: from=test1@example.com, size=1259, class=0, nrcpts=2, msgid=<201112080854.pB88sSlk010083@w3.printjob.com>, relay=daemon@localhost
Dec  8 21:54:29 w3 sendmail[10084]: pB88sT4P010084: from=<test1@example.com>, size=1415, class=0, nrcpts=2, msgid=<201112080854.pB88sSlk010083@w3.printjob.com>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Dec  8 21:54:29 w3 sendmail[10083]: pB88sSlk010083: to=test-s@example.com,test-b@example.com, ctladdr=test1@example.com (2/2), delay=00:00:01, xdelay=00:00:00, mailer=relay, pri=61259, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (pB88sT4P010084 Message accepted for delivery)
Dec  8 21:54:29 w3 sendmail[10087]: pB88sTwJ010087: from=test1@example.com, size=1129, class=0, nrcpts=2, msgid=<201112080854.pB88sTwJ010087@w3.printjob.com>, relay=daemon@localhost
Dec  8 21:54:29 w3 sendmail[10088]: pB88sTpu010088: from=<test1@example.com>, size=1306, class=0, nrcpts=2, msgid=<201112080854.pB88sTwJ010087@w3.printjob.com>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Dec  8 21:54:29 w3 sendmail[10087]: pB88sTwJ010087: to=test-s@example.com<test-s@example.com>,Tracey Joyce<test-t@example.com>, ctladdr=test1@example.com (2/2), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=61129, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (pB88sTpu010088 Message accepted for delivery)
Dec  8 21:54:30 w3 sendmail[10090]: pB88sTpu010088: to=<test-t@example.com>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=151306, relay=mxa.onenet.co.nz. [202.36.68.28], dsn=2.0.0, stat=Sent (B4ee0799f0000 Message accepted for delivery)
Dec  8 21:54:31 w3 sendmail[10086]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Dec  8 21:54:31 w3 sendmail[10090]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Dec  8 21:54:33 w3 sendmail[10086]: pB88sT4P010084: to=<test-s@example.com>, delay=00:00:04, xdelay=00:00:04, mailer=esmtp, pri=151415, relay=gmail-smtp-in.l.google.com. [74.125.91.26], dsn=2.0.0, stat=Sent (OK 1323334050 b15si1538496qcz.163)
Dec  8 21:54:33 w3 sendmail[10090]: pB88sTpu010088: to=<test-s@example.com>, delay=00:00:04, xdelay=00:00:03, mailer=esmtp, pri=151306, relay=gmail-smtp-in.l.google.com. [74.125.91.26], dsn=2.0.0, stat=Sent (OK 1323334050 s9si877612qcx.88)
Dec  8 21:54:35 w3 sendmail[10086]: STARTTLS=client, relay=aspmx.l.google.com., version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
Dec  8 21:54:37 w3 sendmail[10086]: pB88sT4P010084: to=<test-b@example.com>, delay=00:00:08, xdelay=00:00:04, mailer=esmtp, pri=151415, relay=aspmx.l.google.com. [74.125.91.27], dsn=2.0.0, stat=Sent (OK 1323334054 y4si1543502qcs.119)

Answer 1

The log line says this:

Dec  8 21:54:30 w3 sendmail[10090]: pB88sTpu010088: to=<test-t@example.com>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=151306, relay=mxa.onenet.co.nz. [202.36.68.28], dsn=2.0.0, stat=Sent (B4ee0799f0000 Message accepted for delivery)

Since the status is "stat=Sent (B4ee0799f0000 Message accepted for delivery)" to the recipient's mail server mxa.onenet.co.nz, it means that the problem is out of your hands. Your mail server successfully handed the message off to the recipient's mail server, and any problem it had will be at mxa.onenet.co.nz or afterwards.

In this case, the test-t recipient should contact the mxa.onenet.co.nz mail administrator. You can provide the admin with the relevant log entries for mxa.onenet.co.nz and he can go hunt down the problem on his end.