🚀 go-pugleaf

On Saturday, in article
     <838477611snz@tgold.dialup.access.net> tgold@panix.com
     "Anthony R. Gold" wrote:

AG> No sarcasm was intended, and I apologise if any slipped in 
AG> unintentionally, but indeed I do feel strongly about this.

Sorry, wrong diagnosis on my part.  But correct about the
strength of your feeling.  I will try to reassure you (that
our desires are very similar) in the following...

AG> > Personally I don't feel that strongly about the inconsistency, I
AG> > just felt a mail post-processor might be an interesting conjecture
AG> > and relatively easy to implement.  But do tell us WHY you would
AG> > like to opt out.
AG> 
AG> It is NOT inconsistent, it is essential to the integrity of smtp 
AG> which was designed to handle unique and irreplaceable data. The mail 
AG> must be DELIVERED before signaling acceptance of control and thereby 
AG> permitting the previous custodian of control up the chain to delete

I completely understand this, and thoroughly agree with the
principle of delivery that you're referring to.

Perhaps I misled you by raising this while talking about
'temp' files.  I would abhor any proposal to 'ack' the
client while mail could still be lost by a power-out.
That's not what I'm suggesting.  If you still think my
proposal compromises integrity, I'll be interested to know
why.

As for having an option, that's a complete non-starter,
that means fattening ka9q, not slimming it.

But I'm not going to get steamed up about this.  Now that I
know I can successfully receive a 900K mail, and that it
wasn't that one causing my problems earlier this week, I
find this discussion more academic.  Whilst IMO it might
have been nice if ka9q had worked this way from the outset,
I can imagine resistance to risking extra support calls from
non-techie ka9q users upgrading. (Is that an oxymoron?  Are
there non-techie ka9q users <g>).

Perhaps I find it easier to accept the concept of
post-processing mail offline because I already do precisely
that.  Instead of using the .txt files as they stand, with
PcElm or similar, I invoke mail2snz within demon.bat.
This happens automatically, even if I have a power-out.

So an extra post-processor isn't a big conceptual leap for
me.  The essence of what I'm asking is: "What's the
difference between 'ack'ing receipt of mail when it's safely
stored on your hard disk, or when it's safely stored on your
hard disk?".  <straight face, but a little twinkle around
the eyes, so you know I didn't mistype the question :-) >

AG> it. This also explains why mail is completely returned upon failure, 
AG> and not merely a return of a report of failure.

That's irrelevant, I think.  Even if it's true.  I've
never seen it stated as a principle, and I've certainly
had mail bounce where the report only included the
first few lines of my original (I agree that's inconvenient,
meant in some cases I had to go digging in my archive to
retrieve the whole original).  Of course, those partial
reports may have come from non-conforming systems. <shrug>

--
John Washington