[Top] [All Lists]

Re: Using RSET with the EHLO/HELO fallback logic

2008-02-25 08:48:53

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.


Hector Santos, CTO