Hi Folks, I'm hoping someone with the expertise can help me!
In connection with trying to diagnose email delivery problems to a particular domain, I'd like to know the answer to the following.
My email procedure is: 1. Compose the email "off-line" in my MUA (XFMail) 2. "Send" it -- so it goes in the outbox 3. Really send it (batch send) -- XFMail hands the outbox over to sendmail which then does SMTP with the mail server of my ISP (Zen).
Up to this point, there is no problem; and receipt of a "check" Bcc: sent to me on an external email account via the ISP verifies that the ISP accepted the mail for delivery. And of course I usually have no problems with delivery of emails to their destinations by the ISP. Except for this one domain.
Now the question. When my sendamil is doing its SMTP with Zen's mail server, the first substantive request it will make is
mail from: <whatever.my.sendmail.uses>
After the mail has been received by the ISP, the ISP's mail servers will try to initiate connections with the destination domain's mail server. Again, once a connnection is established, the first substantive request it will make will be of the form:
mail from: <whatever.my.ISP.uses>
My question is: What (if any) is the relationship between
<whatever.my.sendmail.uses>
and
<whatever.my.ISP.uses>
??
Does <whatever.my.ISP.uses> take the email address from the "From:" header in the email? From the "envelope-from"? Or does it uses its own version, as in (e.g.):
mailer-daemon@zen.co.uk
Or what?
One aspect of the background to this question is that, when I try myself to do a (test) manual SMTP dialogue with one of the remote domains mail servers, while I may well get through and successfully send the mail, on many other occasions I will get a response to "mail from:" on the lines of
mail from: Ted.Harding@manchester.ac.uk 451 4.3.2 Please try again later
which will be repeated indefinitely if I keep trying. So I'm wondering if it may be a negative response to the email address used in the "mail from:" request, or has some other reason. Since I don't know whether Zen's mail server would use the same (or similar) email address in its own "mail from:" request, I can't (as yet) link the delivery failures I get with my own SMTP dialogue with the delivery failures when Zen tries to forward my emails to the destination domain.
[And, by the way, how should I interpret the error message 451 4.3.2 Please try again later ??]
With thanks, Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) ted.harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 15-Nov-07 Time: 11:36:23 ------------------------------ XFMail ------------------------------
On 15/11/2007, Ted Harding ted.harding@nessie.mcc.ac.uk wrote:
My question is: What (if any) is the relationship between
<whatever.my.sendmail.uses>
and
<whatever.my.ISP.uses>
??
Does <whatever.my.ISP.uses> take the email address from the "From:" header in the email? From the "envelope-from"? Or does it uses its own version, as in (e.g.):
It should use the envelope-from.
One aspect of the background to this question is that, when I try myself to do a (test) manual SMTP dialogue with one of the remote domains mail servers, while I may well get through and successfully send the mail, on many other occasions I will get a response to "mail from:" on the lines of
mail from: Ted.Harding@manchester.ac.uk 451 4.3.2 Please try again later
which will be repeated indefinitely if I keep trying. So I'm wondering if it may be a negative response to the email address used in the "mail from:" request, or has some other reason.
When receiving the temporary rejection you are supposed to retry later. This is normally because of something like too much load on the server or a (temporarily) full disk.
It could also be that the mail server may have greylisting of some sort. Basically this is a scheme where the first time you connect to send email the server tells you to try again later. When you retry (with the same from and from the same server) it lets the mail through. The thinking is that spam sending mail bots won't bother with the retry and will just fail. The problem is that some legitimate servers do the same.
If you google for greylisting you can find the gory details.
[And, by the way, how should I interpret the error message 451 4.3.2 Please try again later ??]
It basically means that the server can't accept email now but that it should be able to at some point so you should try sending it again later (e.g. re-queue it for delivery).
JD
Thanks, John. Some comments interspersed below.
On 15-Nov-07 13:46:14, Jon Dye wrote:
On 15/11/2007, Ted Harding ted.harding@nessie.mcc.ac.uk wrote:
My question is: What (if any) is the relationship between
<whatever.my.sendmail.uses>
and
<whatever.my.ISP.uses>
??
Does <whatever.my.ISP.uses> take the email address from the "From:" header in the email? From the "envelope-from"? Or does it uses its own version, as in (e.g.):
It should use the envelope-from.
That could be useful! How definitive is that?
One aspect of the background to this question is that, when I try myself to do a (test) manual SMTP dialogue with one of the remote domains mail servers, while I may well get through and successfully send the mail, on many other occasions I will get a response to "mail from:" on the lines of
mail from: Ted.Harding@manchester.ac.uk 451 4.3.2 Please try again later
which will be repeated indefinitely if I keep trying. So I'm wondering if it may be a negative response to the email address used in the "mail from:" request, or has some other reason.
When receiving the temporary rejection you are supposed to retry later. This is normally because of something like too much load on the server or a (temporarily) full disk.
I understand that. However, at times I've retried every 5 minutes or so for up to 10 times, always with the same result. (I use manual telnet to port 25 on the remote server, then doing the EHLO ... / mail from: ... / rcpt to: ... [if I get that far] / ... manually).
It could also be that the mail server may have greylisting of some sort. Basically this is a scheme where the first time you connect to send email the server tells you to try again later. When you retry (with the same from and from the same server) it lets the mail through. The thinking is that spam sending mail bots won't bother with the retry and will just fail. The problem is that some legitimate servers do the same.
Yes,I know about grey-listing (which is probably in place at the far end). It seems to me, though, that the above failure of re-tries possibly rules out grey-listing, since it should respond positively to the next try or two.
[And, by the way, how should I interpret the error message 451 4.3.2 Please try again later ??]
It basically means that the server can't accept email now but that it should be able to at some point so you should try sending it again later (e.g. re-queue it for delivery).
Yes, 451 is supposed to indicate
451 Requested action aborted: error in processing
If I'm not mistaken (though I could be ... ) the "4.3.2" is an instance of the RFC 3463 status nessages class:
X.3.2 System not accepting network messages
The host on which the mailbox is resident is not accepting messages. Examples of such conditions include an immanent shutdown, excessive load, or system maintenance. This is useful for both permanent and persistent transient errors.
which, I guess, could also be valid for a grey-listing refusal.
Hmmm ... Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) ted.harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 15-Nov-07 Time: 14:17:26 ------------------------------ XFMail ------------------------------
Thanks to everyone who responded to my query. The responses helped to clarify various things for me. Unfortunatley it seems that I can't extract sufficiently specific information to point to a particular problem.
I'd like to ask another question:
Is there a way (apart from starting up my own manual SMTP session) of testing the responsiveness of a remote mail server? I'd want to do this from a UK-located source.
I found such a service at
which actually probes the MX host for a given domain, and returns some performance indicators, but I think this operates from the US.
To be specific: I want to check whether there are general problems connecting to otago.ac.nz, and I suspect there may be internet connection difficulties between the UK and New Zealand. I think connections from the US are probably better.
I want to delegate this to another agent, to eliminate the possibility that there may be s problem arising from my own IP/domain.
With thanks, Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@manchester.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 15-Nov-07 Time: 19:47:33 ------------------------------ XFMail ------------------------------
-
Jon Dye -
ted.harding＠nessie.mcc.ac.uk