[REBOL] Re: Server error: tcp 553
From: gscottjones:mchsi at: 19-Apr-2003 5:45
From: "Jim Clatfelter"
> You seem to have received my email, since you quote
> it and say you tried the script. But I didn't get it back
> on my machine. And it doesn't appear on rebol-list
> http://www.escribe.com/internet/rebol/index.html
> archives. That's pretty strange.
Like a good magic trick, it is less strange once you know what happened.
That email you sent was sent directly to me instead of the list. I assumed
that had happened because you were changing clients as you were figuring out
this problem. If so, then it is very easy to accidently send it to the
wrong address. I probably should have explained this, but I didn't want to
draw light to that issue. Now look what I've done! :-)
> I tried your code but my mail still bounces.
My code snippet only got rid of the evidence that REBOL was sending the
email. So it seems as though that was not the issue. There still may be
some sort of authentication issue, a header mismatch or content encoding
issue.
I looked through pronet's support pages, and I do not see that
authentication is required before sending email. I am assuming that your
domain name on your email address is the same as that of the server (both
are pronet.net).
Inorder to separate whether your smtp server is choking on something REBOL
is doing versus your value-added client, I would next check by sending a
very basic message from the REBOL's command line.
send [personofmychoosing--theirdomain--com] "This is a test message"
If this message does not bounce, then it is likely something in your
program. If it does bounce, then, just to be compulsively sure, I would get
rid of the header line that identifies REBOL:
X-REBOL: "View 1.2.8.3.1 http://WWW.REBOL.COM"
as shown in the code sample yesterday. (BTW, as you probably already know,
there are of course other ways to do that.) If this message bounces, then
the problem gets *really* interesting, in my opinion, because it suggests at
least one of two possibilities: 1) REBOL's smtp scheme may have a bug, 2)
pronet's smtp server is non-standard, 3) pronet's smtp server screens for
the most common kind of clients before sending on email.
Given that your email to the list does not show a client type in the
headers, I do not think #3 is very likely, *unless* you are using pronet's
webmail interface (in which case they know you are validated). If you have
been using their web-based email to respond to the list, then, from REBOL
you may wish to send a spoofed head along with you email to see if they are
indeed screening for "bonified email clients (note that some localities may
have laws which prohibit header spoofing). One option would be to add the
following to the header:
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
Assuming that the above issue is not proving productive, I would next screen
the conversation between REBOL and your smtp server. The easiest way to do
this is to turn on tracing:
trace/net on
then resend your test message from the console:
send [personofmychoosing--theirdomain--com] "This is a test message"
This conversation will look something like this (email addresses obscured to
reduce spam harvesting):
Net-log: ["Opening" "tcp" "for" "smtp"]
Net-log: [none "220"]
Net-log: {220 sccmmhc01.mydomain.com - Maillennium ESMTP/MULTIBOX sccmmhc01
#3}
Net-log: [["HELO" system/network/host] "250"]
Net-log: "250 sccmmhc01.mydomain.com"
Net-log: "MAIL FROM: <[myname--mydomain--com]>"
Net-log: [none "250"]
Net-log: "250 ok"
Net-log: "RCPT TO: <[anothername--anotherdomain--com]>"
Net-log: [none "250"]
Net-log: "250 ok"
Net-log: ["DATA" "354"]
Net-log: "354 ok"
Net-log: [none "250"]
Net-log: "250 ok ; id=20030419102205mm1008qqooe"
Net-log: ["QUIT" "221"]
Net-log: "221 sccmmhc01.mydomain.com"
The bracketed responses are what REBOL is doing. The unbracketed responses
are what your smtp server is sending. If pronet's smtp server is
noncompliant, then one of these responses will look different. If you will
share that difference, then we will know what is going on. (BTW, given your
earlier messages, my assumption is that the message is not being accepted by
the server, instead of actually being accepted but then returned as
undeliverable.)
Let us know what you find when you have time.
--Scott Jones
