SM wrote:
Hi Hector,
At 02:11 25-02-2008, Hector Santos wrote:
Or did the system, blame game work? I was able to show the big brand
name $$$$ AVS appliance vendor the "errors of their ways" using 2821
only and they made the change/fix.
The system blame game never works. :-) You took the decision to make a
change that fixes the problem. That's always the best alternative.
Ok, I think I failed to express the point. Maybe others who understood
can chime in.
The problem was resolved without us needing to make a change. The
vendor resolved the problem. It was never revealed how they did, only
to acknowledge it was a problem on their end. Whether it was an option
or a software change in this high-end proxy appliance software, it
wasn't reveal how they were going to address it. All I know it was fixed
within 24 hours.
What I was trying to point out was above and beyond the resolution that
was already found, we decided to add a change request to address any
future issues related to this where we might come across legacy
operation or current operation with an "run in legacy 821 mode" switch.
Who knows.
It goes to show, as with the other MX/CNAMES, that when these ambiguous
issues present themselves, regardless of what the specs may say,
solutions will be found to reduce future issues.
>> Don't you think this is important information to "keep" or bring back
>> in some form into 2821bis? It explains everything.
>
> It's good that we know about it to have a better grasp of the mail
> environment. The section I quoted talks about responses from
> improperly implemented servers. That was 13 years ago.
> It's high time that was fixed.
I agree, which is why we ask to talk to the vendor because the talk of
being a "big brand name", hence no way they had it wrong, was strange.
We told our customer that if we were dealing with a vendor that was a
legacy system and have no way to resolve it, we will provide the
immediate patch. But as it turned out, after pulling some teeth, the
vendor acknowledge the situation was on their end.
> I don't think it should be brought back into RFC 2821bis because:
>
> 1. There is already text to tell us what to do (refer to
> my previous message).
>
> 2. We cannot support improperly implemented servers forever.
>
> 3. We don't want the specifications to be longer than necessary.
SM, most professional and commercial systems does not have the luxury
to take such a hard stance and debate it with customers. It doesn't pay.
If its was a legacy system your customer was attempting to send mail to,
I believe it is for the new "Practice Codifying" specs to keep this
historical information intact so that developers who might come across
it will be able to understand and deal with it.
In short, if a new developer uses 2821bis to frame his new SMTP system,
it might use the RSET as part of the fall back without considering
interops issues for one simple reason only:
The historical and interops insights was removed.
I will venture very strongly that if a future developer had the simple
note available as I proposed for section 3.3, or the 13 year old RFC
1869 note carried over, he would seriously consider not using a RSET for
EHLO/HELO fallback logic requirements or making it operation on a per
host basis or something like that.
As it would be without any insights, he would find out the hard way.
Anyway, I am just expressing my opinion and this is my last input on the
subject. I must admit that there is a sense of inconsistent
considerations which is unfortunately based primarily on who is talking.
I could careless how it turns out, no, thats not true, I do care, but
it would be great to see some consistency here.
Thanks for your comments.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com