Rich Kulawiec wrote:
> On Tue, May 12, 1998 at 01:07:21AM +0000, Peter J. Schoenster wrote:
> > On 11 May 98 at 19:49, Jack Killpatrick wrote:
> >
> > > I would like to have a way to check the emails that have been sent
> > > via sendmail against the ones in the database so I can spot any
> > > errors that may have occurred in the sendmail process. For example,
> > > let's say sendmail fails for some reason (some loose and crazy
> > > process that stymies the system so that sendmail is rendered
> > > useless, while perl and msql continue to function). I'd like to
> > > compare a record of sent mail to the records in the database, using
> > > the index as a key. Then I could spot any submissions that were not
> > > sent out by sendmail.
> >
> > Umm.. not sure if I really understand but that hasn't stopped me
> > before.
> >
> > When you open sendmail do you not do this:
> >
> > open sendmail || do something else
>
> You're correct, and you're not correct.
>
> What you propose will tell you if sendmail returns a non-zero exit
> code immediately, but that isn't what you really need to know: you
> need to know if the mail actually got delivered. And there's no
> way to know that at the time you submit mail to sendmail's queue,
> because sendmail itself doesn't know if the mail's deliverable (except
> in truly pathological cases, e.g. malformed addresses).
>
> In other words, just because sendmail accepts a message for delivery
> on your local host doesn't mean that it will be successful. There can
> be transient failures (DNS timeouts, loss of connectivity to the
> remote host), permanent failures (unknown host, unknown user) and about
> a zillion other things that can go wrong.
>
> My solution would be to use the -f flag to set the return adddress, e.g.
>
> "|/usr/lib/sendmail -oi [EMAIL PROTECTED] someuser@somewhere"
>
> as well as burying the true recipient in an X-header, e.g.
>
> X-Really-Really-To: someuser@somewhere
>
> and then have mail coming back to "bounces" piped into a perl script
> that extracts the X-Really-Really-To field and marks it as "not
> delivered" in your database or wherever it needs to be noted.
Yes, that would work for checking the mail _if_ it was in fact sent out.
What I really need to do is find out if sendmail even sent the mail out. I
need to know what email send was being attempted when sendmail did not
respond.
This is a little more on my scenario: I am using a virtual server at
iServer. They limit the amount of processes that you can run at one time.
Last week, one day, I was writing some crappy code and maxed out my process
limit. So, when my scripts tried to use sendmail it didn't work. My client
called and said, hey, we haven't had any emails today, is there something
wrong with the system. I found a zillion processes, killed them and then
sendmail started working again. They then asked me what emails they had not
received. I looked in my database and gave them copies of the last records
in the table, but told them that I didn't know when sendmail stopped being
usable, so they'd have to check the database info against the emails they
already received to see what they hadn't received. It was kind of a hassle.
In the first place, I wasn't aware of the problem, in the second place I
didn't have an easy way of tracking the unsent emails. Note that these
weren't even emails drifting around in cyberspace; they never even got
created.
So, I'm looking for a way to be able to know whether an email was created
and sent or not. Let's say sendmail doesn't even start up, and thus can't
return an exit code, I need to know what email send (ideally, identified by
the 'index' variable in my table) was being attempted at that time.
Could my script just look for _no_ exit code coming from sendmail, write an
error to the user in html and write a record to my database detailing the
non-send? Seems like that could work. Hmmm. At that point the user on the
web would get an error notice, but not me (I don't plan on sitting at the
console). I could ask the web user to call Customer Service at my client and
notify them of the error, then Customer Service could call me. Hmmm, that
might work. Any thoughts?
TIA,
Jack
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
