On Tue, Dec 03, 2002 at 08:53:39PM -0800,
Marc MERLIN <marc_news@???> is thought to have said:
> On Tue, Dec 03, 2002 at 11:36:19PM -0500, Tabor J. Wells wrote:
> > If a remote site then comes back to you and says "Hey where'd that
> > message go?" you still can debug it for as long as you keep your logs
> > around.
> >
> > What am I missing?
>
> They have the answer without Emailing me
> I may not answer them/get their mail/have kept my logs/whatever
Fair enough. But then I'm of the opinion that logs can be kept quite a long
time and the postmaster of a site should always respond to inquiries
directed to them. Besides, 90+ days of bzip2'd logs for even the busiest
mail servers isn't that difficult to store. I'm also just not sure any of the
above reasons are compelling enough to force an API change.
However, wouldn't they also have their answer if you rejected the mail
at the end of DATA rather than accept and then junk it? What does accepting
it and junking it gain you?
> Either way, I'm not forcing anyone to do this. I'm just saying that it can
> be useful, and that adding support for it is trivial.
I'm not saying you are. I just think an API change that breaks compatibility
of existing local_scan() functions in a point release isn't that good of
an idea. And I'm still not convinced it'd be useful in the first place.
Personally I think if the concern is about someone being able to get the
information about why the delivery wasn't completed on their own, then the
mail should be rejected and either the MUA will display an error or their
site's MTA will generate a bounce message for the sender.
If you want them to know about the failed delivery, throw an error. If you
don't, then let them come calling when they figure out it didn't go through.
It seems an odd thing to try and have it both ways in this case.
--
--------------------------------------------------------------------
Tabor J. Wells twells@???
Fsck It! Just another victim of the ambient morality
