> -----Original Message-----
> From: Howie Hamlin [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 05, 2002 4:23 PM
> To: inFusion Support List
> Subject: Re: [iMS] POST return-path mangling
>
>
>
> ----- Original Message -----
> From: "Raven R. Cecil" <[EMAIL PROTECTED]>
> To: "inFusion Support List" <[EMAIL PROTECTED]>
> Sent: Friday, April 05, 2002 5:10 PM
> Subject: RE: [iMS] POST return-path mangling
>
>
> >
> >
> > Okay, let me clarify this so I do not get confused. The
> server does not
> > parse failto, warnto, reply-to, or return-path when
> returning mail, correct?
> > Does the server parse tokens in the smtpfrom address before
> returning a
> > message?
> >
>
> When the server sends a failure message it is informational
> and the server actually makes a new mail and control file when it does
> this. None of the original tokens are preserved in the new
> control file. I would not rule out enhancing the functionality in a
> future release but, for now, this is the way that it works.
>
> The server would either have to preserve the tokens in the
> new control file or parse the tokens in the original mail
> when sending an
> error notification but it does not do this now.
>
> > Also, despite these issues we are discussing, the server
> was definitely
> > parsing our tokens as we have over 100,000 bounces recorded
> using IDs from
> > return-path address using QTokens. I am not sure what
> happened here, but
> > there is obviously something occurring which did not occur
> previously.
> >
>
> That functionality has not changed. It could be that at one
> time you were looping over the cfx and creating the header in that way
> and now you are using QTokens.
I was wrong. The previous mailings which I mentioned were mostly temporary
failures, and we were not using Smart Delivery. The failure messages were
generated outside the iMS server, and thus contained the correctly parsed
headers, because the message was parsed when originally delivered by the
POST server. This explains why it seemed the tokens were not being parsed in
the logs, because the more recent messages were permanent failures, which
the POST server generated by itself, and thus did not parse the header
tokens.
I would love to see the functionality you mentioned added to a later version
of iMS.
Thanks once again for your assistance and direction, Howie.
Regards,
Raven
>
> Regards,
>
> Howie
>
>
> >
> > Regards,
> >
> > Raven
> >
> >
> > >
> > > > Also, you said reply-to in your message, but I was
> > > > referring to return-path in my original message, was that
> > > just a typo?
> > >
> > > Yes.
> > >
> > > > Lastly, your original suggestion to us was to remove the
> > > reportpoststatus
> > > > template and use a bounce processor account, because of the
> > > extra overhead
> > > > involved on the server, so has this extra overhead been
> > > resolved in some
> > > > way?
> > > >
> > >
> > > The overhead I mentioned is only associated with the server
> > > calling ColdFusion templates. The iMS server has very
> little overhead
> > > in calling ColdFusion. The more ColdFusion templates you
> > > use, the more overhead. This is why we allow you to disable
> > > ReportPostStatus if you don't need it.
> > >
> > > Regards,
> > >
> > > Howie
> > >
> > >
> > > >
> > > > Regards,
> > > >
> > > > Raven
> > >
> > >
==^=======================================================
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/iMSSupport.cfm
Need an iMS Developer license? Sign up for a free license here:
http://www.coolfusion.com/iMSDevelopers.cfm
List archives: http://www.mail-archive.com/infusion-email%40eoscape.com/
Note: You are subscribed as [email protected]
==^=======================================================
