----- Original Message -----
From: Tac/Smokescreen Action Network <[EMAIL PROTECTED]>
To: inFusion Support List <[EMAIL PROTECTED]>
Sent: Thursday, July 13, 2000 7:44 AM
Subject: [iMS] handling bad email
> Congrats on getting 1.3 out the door! <brief pause>
>
It was a long time coming but we were finally satisfied with the quality and
feature set.
As far as the list server stuff...
There is no such thing as a software package that has every feature that
anyone could want. That being the case, we are always looking for feedback
from our users and have a very good track record of implementing feature
requests (and all upgrades have been free, to boot).
Anyway, I think that we need to look at how other list servers process
bounces and perhaps incorporate that into the CFML code as well as looking
into providing better info on returned mail from the POST Server.
For the CFML Code we need to have mail bounce to a specific address for the
list mail. There are many servers out there that will accept mail for users
that do not exist or have full mailboxes and then bounce the mail later on.
What I mean is, for example, the iMS POST Server sends the mail to
domain.com and then domain.com sends back a 250 code which means that the
mail was received successfully. So, as far as the iMS server is concerned,
the mail was sent successfully. However, somtime later, the remote mail
server sends back an error mail that says that the recipient is unknown or
the recipient has a full mailbox. In this case you want the remote mail
server to send the mail back to a specific address so that you can take the
appropriate action. To do this you should use some or all of these list
server headers:
Errors-to: <address to bounce mail to>
Return-path: <address to bounce mail to>
Also, you may want to insert an additional header that shows you who the
intended recipient was. For example:
X-ListRecipient: <recipient ID number>
X-List: <list ID number>
Then, create an address to receive the bounced mail and take the appropriate
action. You could also make the bounce address unique for each recipient
which may make things easier. For example, you prepend each list
recipient's bounce address with "bounce-" plus their ID number. So, a
bounced mail might go to [EMAIL PROTECTED] and then you can pull the
user ID from the address.
The second thing is the mail server itself. I'll look into providing more
detailed information on delivery failures. Also, I think we discussed having
additional information available to the reportpoststatus template (all the
e-mail headers) so that will be done for a subsequent point release.
Please give me some comments about this....
Thanks,
Howie
> Now, on to 1.4. I'm still convinced that better error handling is
critical
> to, and consistent with building a "fashion-your-own" mail server.
Although
> I'm very actively using the ReportPostStatus to see what mail has gone out
> (I've written an integrated visual monitor that Howie will problem post to
a
> User-Supplied Addons Section), I can't tell anything about the failed
> messages without reading the logs.
>
> I'm setting ERRORSTO="<listname>-errors.<userid>@smokescreen.org", but the
> error that comes back to that address is usually very terse. Again, I
have
> to go to the logs to get more info. I also set <insetheader
> Errors-To="#listname#-errors.<:userid:>@smokescreen.org">, which I
> understand handles different errors that the ERRORSTO attribute of the
> iMSMail tag.
>
> I'd like to know the sender, receiver and as much detail as possible when
an
> error happens (or when any mail is received, for that matter, so I can
> report to list administrators the status of their message via a web page.)
>
> Below is typical of what one of my list administrators will send me:
>
> ---
> > Tac, I'm getting a zillion more bounce messages tonight after posting a
> > doc...
> > 70 so far...
> ---
>
> I'm keeping track of, in a primitive way, e-mail addresses on a list that
> have failed (although I can't specifically say if the e-mail addresses
> failed because of a message sent from that list). But I have no details
as
> to why, so I can't look at these 70 messages and tell her what might be
> wrong (e.g. @aol or @yahoo is down, a government domain changed its name,
> etc.) It's a painful process to tell someone else to open up each error
> message (I send the errors back to the list administrators) and ask them
to
> open the attachment which may or may not contain some useful info.
>
> Anyway, let's get some discussion going about how to handle errors, as I'm
> sure others have issues as well, and Howie is very committed to making
sure
> that design decisions benefit the largest group possible.
>
> Tac
>
========================================================================
This list server is Powered by iMS
'The Swiss Army Knife of Mail Servers'
--------------------------------------
To leave this list please complete the form at
http://www.CoolFusion.com/iMS.htm
List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
========================================================================
