On Sun, 05 Oct 2014 19:18:33 -0400
Harry Putnam <rea...@newsguy.com> wrote:
Sorry, I missed this thread originally.
>
> (I'm not sure if this output means it worked or it failed. I can tell
> you that nothing is showing up at the other end)
>
> Can any of you experienced exim4 hands interpret this output?
> Did the Authentication work or fail?
The message was transmitted and accepted. The authentication must have
worked, it would have been checked during the SMTP conversation, not
afterwards.
>
> [NOTE: Just for the information, my lan is a fake one 2xd.{local.lan}
> was just invented right out of thin air some yrs ago]
> ------- ------- ---=--- ------- -------
>
> $ mailx -v -s "TEST $(dtf) $(hostname -f)" rea...@newsguy.com <
> txtmsg.txt
>
> LOG: MAIN
> <= ha...@2xd.local.lan U=harry P=local S=569
> $ delivering 1Xauru-0003TT-Fh
> R: smarthost for rea...@newsguy.com
> T: remote_smtp_smarthost for rea...@newsguy.com
> Transport port=25 replaced by host-specific port=587
> Connecting to mail.messagingengine.com [66.111.4.52]:587 ... connected
> SMTP<< 220 mail.messagingengine.com ESMTP ready
> SMTP>> EHLO 2xd
> SMTP<< 250-mail.messagingengine.com
> 250-PIPELINING
> 250-SIZE 71000000
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 STARTTLS
> SMTP>> STARTTLS
> SMTP<< 220 2.0.0 Start TLS
> SMTP>> EHLO 2xd
> SMTP<< 250-mail.messagingengine.com
> 250-PIPELINING
> 250-SIZE 71000000
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250-AUTH PLAIN LOGIN
> 250 AUTH=PLAIN LOGIN
> SMTP>> AUTH PLAIN ************************************
> SMTP<< 235 2.0.0 OK
> SMTP>> MAIL FROM:<ha...@2xd.local.lan> SIZE=1609
> SMTP>> AUTH=ha...@2xd.local.lan RCPT TO:<rea...@newsguy.com>
> SMTP>> DATA
> SMTP<< 250 2.1.0 Ok
> SMTP<< 250 2.1.5 Ok
> SMTP<< 354 End data with <CR><LF>.<CR><LF>
> SMTP>> writing message and terminating "."
> SMTP<< 250 2.0.0 Ok: queued as E25066800A8
> SMTP>> QUIT
> LOG: MAIN
> => rea...@newsguy.com R=smarthost T=remote_smtp_smarthost
> H=mail.messagingengine.com [66.111.4.52]
> X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256
> DN="C=AU,ST=Victoria,L=Melbourne,O=FastMail Pty
> Ltd,CN=*.messagingengine.com" A=plain C="250 2.0.0 Ok: queued as
> E25066800A8" LOG: MAIN Completed
>
>
You have a string of 2xx numbers, always a good sign. A 4xx is a
temporary failure, a 5xx a permanent one.
http://www.bc.edu/offices/help/comm-collab/email/smtp-codes.html
The transaction finishes when the sending server actually sends the
body of the email, and the receiving server responds with 'OK', and
issues a message ID string:
> SMTP<< 354 End data with <CR><LF>.<CR><LF>
> SMTP>> writing message and terminating "."
> SMTP<< 250 2.0.0 Ok: queued as E25066800A8
The LOG: MAIN lines are telling you what is being saved to
/var/log/exim4/mainlog: a very long line ending with the remote
server's message ID, then a line with just 'Completed'. Both of these
lines, along with the earlier log line starting '<= harry@...' will be
prefixed with the exim4 message ID, so that you can see that they belong
together: exim4 may be carrying out several transactions at the same
time, with interleaved log lines, this is how you sort them out.
Under normal circumstances, you don't need the verbose logging. The
normal exim4 logging in mainlog will show all transactions in and out,
including any that fail. In general, if you get a 'Completed' line, it
worked, if not, there will be a brief error message.
If you have a 'Completed' transaction, but the recipient isn't seeing
the mail, then theoretically you can contact the postmaster of the
receiving server quoting the message ID and ask what happened to it.
The fact that you have the ID means the receiving server accepted it,
and what happened after that should leave logs in the receiving system.
When email is silently dropped, it has almost certainly been identified
as spam, and the anti-spam software should keep logs of what was
dropped and why, and may even have kept the email in a quarantine
directory somewhere.
I say 'theoretically' as quite a lot of organisations no longer
maintain a 'postmaster' address as they are supposed to. In this case,
the receiving server is a smarthost for which you are presumably
paying, so somebody there has an obligation to tell you what happened
to the message. It may be that they relayed it successfully, and you
will then need the message ID they got from their recipient, and the
name of the server, to take the matter further. If your smarthost admin
says 'oh, we identified it as spam and dropped it' then you can ask
why this happened.
--
Joe
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141012203158.0a9a6...@jresid.jretrading.com
