Not receiving error messages about a script...

[sheila]

Recently, I had a problem getting my installation of Ikonboard to work correctly during the registration process. (See this thread: http://www.aota.net/forums/showthread.php?s=&threadid=9310 )

I have it working now. So, that's great and been solved. But it somewhat bothers me that registration emails were not being delivered and I wasn't being notified of this. Had I received any error notification of this, I would have been aware of the problem much more quickly and fixed it much more quickly.

Here is a post I just made this morning at the IB forums at this URL http://forums.ikonboard.com/ikonboard.cgi?s=3bb5e7e74faeffff;act=ST;f=22;t=431
OK, this problem has been solved, so I thought I would post the concluding remarks here:

The problem was this: I had set the email address in the admincenter for outgoing administrator email to an email address whose domain is not hosted on my webhost. Their SMTP will only deliver outbound (non-local) mail for a SMTP sender whose address is with a domain that they host.

When I tested the registration, it appeared to work, since I (stupidly) only tested registering with email addys whose domain is hosted with this company. Those registration emails were addressed to a local recipient, so they were delivered. Thus, it looked to me like everything was fine, when in fact NO ONE was receiving the registration email.

I guess what bothers me the most about this, is that I received no error messages that the registration emails were not being delivered. I don't know if this is the "fault" of my webhost, or if this is the "fault" of Ikonboard. But it sure would have been nice to have been notified of this error so that I could have fixed it!

Also, it was not clear to me from the IB 2.1.19 admincenter interface, that the "outgoing email" for the board's administrator would be setting the SMTP envelope SENDER. If that had been more clear, I would have known not to use a foreign domain name, because I know my webhost's SMTP will only deliver mail for domains that they host. Should I have recognized this? Dunno.

Also, no one has still commented on the question I asked in the previous post:
Is there a debug mode for IB? Is it possible to set debug to log errors to some sort of error-log file? This would have been helpful if it were possible.


I guess I'm just curious whether there was any way the FutureQuest SMTP server could have notified me about this error? Or is that something that the IB authors would need to add to their scripts?

[Joe]

I think my question is related to Shiela's one here.

Am I correct in thinking that I won't have the kind of problems that Sheila encountered If I have an Ikonboard running for an IRM account and set my email notification from that IRM account (not the main account?)

I would want email notification going from notification@irmaccount.com and NOT notification@mainaccount.com

Should be OK? No?

Joe.

[Terra]

I guess I'm just curious whether there was any way the FutureQuest SMTP server could have notified me about this error?
I would assume IkonBoard is using a SMTP style connection to send the email...

Our SMTP server will see the email transaction as an unauthorized relay attempt and tell your email client (IkonBoard) to buzz off... Since there is no email that enters our mail system, there is no easy way to notify anyone... Why should it? The email client should have enough brains to properly handle any connection errors/problems instead of dropping it on the floor...

In conclusion, the burden of proper error reporting/notification is IkonBoard's fault due to the mishandling of the denied relay attempt... Our SMTP server did it's job by telling IkonBoard that it can't do that, whatever happens from there is IkonBoard's responsibility...

IOW: IkonBoard's SMTP client is brain damaged... ;)

--
Terra
--Tossing Qmail's SMTP server a cookie for doing the right thing--
FutureQuest

[Terra]

JB:

Yes, that should work unless you have the IRM account's MX record changed...

As always, test first before production deployment...

--
Terra
--If you only knew how much of my life goes to testing permutations--
FutureQuest

[Joe]

Terra,

Thanks. Definitely will test before deploying.

Sheila,

Do you want to post Terra's response on the ikonboard forums or shall i? :\

Joe.

[sheila]

JB, I'll notify those IB coder dudes.
Sheesh, you should see the response I got to the notification I reported above:
http://forums.ikonboard.com/ikonboard.cgi?s=3bb65e4425c6ffff;act=ST;f=22;t=431
and I quote:

As iB can not receive a mail it as no way it can know a mail as not been delived or even it is a valid mail address

I won't quote my reply here (a little long), you can follow the link above. But I basically said, "Are you telling me Python is better than Perl? Cause I can handle the error message in Python." and I quoted an interactive Python session for them, showing the error message provided by the SMTP server.

Terra, a question:
Yes, you are correct that IB is using SMTP protocol as I have it configured. There is also a sendmail option. Are you suggesting that if I used the sendmail option, it would basically pipe the mail to Qmail, so Qmail wouldn't do all the SMTP error checking provided by the SMTP protocol (in that case), and such a message would be able to get through by using the sendmail configuration?

(I have no plans to do that, mind you. I just changed the from: email addy. I'll stick with the SMTP protocol version.)

I'll point those IB coder dudes to this thread, for a bit more reading material.

[Bruce]

Originally posted by sheila:
Are you suggesting that if I used the sendmail option, it would basically pipe the mail to Qmail, so Qmail wouldn't do all the SMTP error checking provided by the SMTP protocol (in that case), and such a message would be able to get through by using the sendmail configuration? Using the sendmail interface when it is available is almost always the right thing to do, and certainly appears to be the right thing here.

[sheila]

Originally posted by Bruce:
Using the sendmail interface when it is available is almost always the right thing to do, and certainly appears to be the right thing here.
Hunh. That's funny, because it is counter to advice I've had from others in discussions I've had about this topic (for instance, with Barry Warsaw, author of Mailman, in comp.lang.python).

If one hands the mail off, via SMTP, to the localhost, and the SMTP server actually accepts the DATA and returns an OK, then from there on out the script need not deal with the mail delivery aspects (such as retrying delivery, returning the message to the person who originated it, and so on).

If one uses a sendmail type of way of piping the message from the script to the server, then one has to, essentially, code for all these other cases of what could happen if the mail is not ultimately successfully delivered. One has to build in functionality that is already in the SMTP server into ones script.

I can't imagine why one would want to do that? It seems to me it would be more efficient to hand the message off to the SMTP server, via SMTP protocol, and take advantage of the functionality already built in to the SMTP server???

[dank]

then one has to, essentially, code for all these other cases of what could happen if the mail is not ultimately successfully delivered.
I believe that's what trash bins are for. :)

Dan

[Bruce]

Originally posted by sheila:
If one uses a sendmail type of way of piping the message from the script to the server, then one has to, essentially, code for all these other cases of what could happen if the mail is not ultimately successfully delivered. What other cases? You open a pipe to sendmail, write the message into it, close the pipe, and check the result code from sendmail. If the sendmail interface (to qmail in this case) successfully stuffed the message into the queue, it will produce a zero (true) result. Anything else means it failed.

I can't imagine why one would want to do that? It seems to me it would be more efficient to hand the message off to the SMTP server, via SMTP protocol, and take advantage of the functionality already built in to the SMTP server??? Not entirely accurate. Sending via SMTP and receiving via SMTP are entirely different tasks. I have written a SMTP server that has NO SMTP receiver, designed for situations where the server never needs to receive mail (like a web server with no local mailboxes).

One reason to pipe the message to the sendmail interface is to avoid the SMTP protocol entirely, which is a good deal more complex to handle than just opening up a pipe.