[courier-users] Re: reliable recipient-specific content filtering without bounces

> They sound reasonable, and I updated the master document.

Great! I agree there's no current need. But sometimes a few minutes
of work on a document can prevent future incompatibilities from ever
arising in the first place. When you can do that, it's a win.

I just looked at the new version of the draft. Actually I did not
intend for the "rationale" sections to become part of the draft:
they were just meant to be read by you, so you would understand the
thinking behind each of the rules I suggested, so you could make an
informed decision about which rules you'd want to adopt and whether
you'd want to modify them. You could just remove those "rationale"
sections. Or, if you really think it's better to have them in the
draft, that's fine with me too.

I did however notice one small goof: your text editor converted the
apostrophes to Unicode encoded with UTF-8, but your Apache sends the
document as 8859-1, so all the apostrophes look like line noise (at
least in my browser). Might be best to just re-save as plain ASCII.

P.S. I just noticed that section 8.1 still uses code #421 instead
of #450. Even though this does not currently cause interoperability
problems for Courier (as you mentioned a few days ago), I think the
use of #421 in the draft will probably confuse some people, especially
since your draft now has a datestamp that is later than RFC 2821's.
I can just imagine a thought balloon over a reader's head, saying:
"Huh? Why would you want to simulate a server shutdown?"

If you left the 421s there deliberately, because you didn't want the
draft to disagree with Courier's current behavior, I have a suggestion.
You could replace "a temporary 421 status code" with "a temporary
status code, such as 450." This would still be congruent with
Courier's current behavior, but would not confuse people, or cause
them to dismiss the draft as being incompatible with RFC 2821.

Oh, one more thing: the title of section 7.2 should probably be
"Incomplete replies and timeouts" instead of "Parsing incomplete
replies" because only the first sentence is about incomplete replies.

Thanks,





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/.../courier-users