Date: 19 May 1998 10:54:00 +0200
From: kaih@khms.westfalen.de (Kai Henningsen)
To: drums@cs.utk.edu
Message-ID: <6u8I4iwmw-B@khms.westfalen.de>
In-Reply-To: <m34synx6vd.fsf@windlord.Stanford.EDU>
Subject: Re: State of 821bis and RSET inconsistency
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Organization: Organisation? Me?! Are you kidding?
References: <m34synx6vd.fsf@windlord.Stanford.EDU>
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.

rra@stanford.edu (Russ Allbery)  wrote on 18.05.98 in <m34synx6vd.fsf@windlord.Stanford.EDU>:

> The only purpose I can see for rejecting parameters to DATA is if we
> intend to use that as an extension mechanism down the road.  Given the

I think what we should do is make very clear what the legal form is, and  
in each case where a system doesn't follow it _allow_ the other system to  
handle this as an error - but also allow it to find some way to fix this  
up. And we should not specify how to do this.

This way, the choice is up to the implementer, but people can always point  
to the rfc and say "you are clearly wrong in generating this junk".

Now, the above is meant for situations like parameters for DATA or RSET -  
that is, situations where a reaction in some way is necessary. Where it is  
possible to simply ignore the issue (like errors in the header of a mail  
message that the MTA is just relaying), there is value in saying "don't  
try to fix this - either pass it on, or reject it".

MfG Kai