ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
>> <ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
>> I'm not sure how "fine" it is, Hector's and your (among others)
>> interpretations are clearly different.
>
> Hector appears to be mostly out on his own here. AFAICT SM, Pete, all three
> Johns, Glenn, Tony F, Robert, and myself are all in basic agreement as to what
> constitutes correct behavior.
My friend, it is well recognized of how the "Follow the chieftain
syndrome, the Consensus by Osmosis attitude has done such a tremendous
job thus far.
I've seen no evidence of that here. What I have seen is various people
performing their own independent analysis and coming to their own conclusions -
conclusions that seem to be in close alignment, your position excepted.
I will say, this approach is much better at getting
what you want than your broken usage.
Nonetheless, I've provided a CLEAR more common than not case of mail
delivery problem with this interpretation of yours.
Must have missed it. Or perhaps it's because you have failed ot make the case
you think you have.
Glenn at least acknowledge it.
Missed that as well.
You have not.
I, OTOH, have done so at least five times now.
Who's wrong?
I'm still convinced you are.
I will stick by my technical opinion, you are all wrong with this
erroneous interpretation. Glenn at the very least acknowledge the
possible lost of mail.
Haven't seen that either.
> On the contrary, Hector's interpretation causes lots of legitimate email to
> fail to be delivered in the VERY common case of pipellning to a single
> temporarily over quota recipient. This is hardly a minor matter.
PIPELINING is not a widely used or supported add-on as you think.
In other words, you're acknowledging that there's a problem with your
approach, and claiming that it is OK because you assert that pipelining
isn't widely implemented?
It's been a while since I ran the numbers, but the last time I did I found
support and use of pipelining to be quite widespread. But even if it wasn't,
that's really beside the point, because this problem exists without it.
Maybe thats the problem here. You can't get your command stacking,
your delivery status and DSN to work right,
All of this is working just fine for me, thank you.
so you need to change the
meaning of the BASIC SMTP specs to convince yourself you are in
compliance?
I need do nothing of the sort.
> I don't believe Hector has said how his MTA behaves,
Our software is designed to match the specs, and in regard to 250,
4yz, and 5yz. DATA 5yz does not mean RETRY. You can't say
"Yeah, But..."
You know Ned, you might think this is funny, but I am not even
convinced your MTA behaves in this ill manner. :-) You probably need
to check that out.
I already have. Our MTA behaves correctly. Apparently yours does not.
If your system is going to retry a 450/5yz set of
RCPT/DATA reply codes, then its a seriously broken system.
I disagree.
I just took a quick scan at Exim, and as far as I call tell in this
spigetti code, it only retries with
buffer[0] != '5' <---- NOT 5yz
RCPT or DATA results.
Please double check your code and double check to see if not some dumb
proprietary vendor software feature and/or operator PERL script
feature only.
There is no need for me to recheck anything. And since you have now
descended to insults, this will be my final message on this topic.
Ned