Same start as my last email.
Thanks John
Your comments are all very enlightening.
And i think I have to agree with all of them.
Your knowledge shines trough them all.
I can not wait to study your new 2821bis-draft
Is there a delay in this pipeline?
Not a significant one. The draft has been through a series of
nasty transformations of format, with attempts to track every
change in the text so it could be explained if anyone asked.
I'm now -- between interruptions, e.g., to try to explain why it
would not be a good idea to start putting a lot of largely
untested anti-spam theories into SMTP requirements -- checking
the post-able version, paragraph by paragraph, to try to make
sure nothing got lost. As soon as I've completed that process,
or conclude that the rest of it should be left to all of you,
the draft will be posted.
Note that any suggestions made now will be considered for -01
(presumably after IETF, given schedules and posting deadlines).
If I try putting more things in now, it just won't get up before
next Monday. So, if you, or others, want to send change
suggestions along, that is fine, but (i) don't expect to see
them reflected in this draft and (ii) assume that I will defer
anything that attempts to change the basic email model to
reflect a "killing spam is more important than interoperability
for normal messages" mentality for mailing list discussion. See
below for an explanation of part of this.
While I recently was studying the old RFC2821 I found a
strange MUST about relay-hosts.
...(snip)...
First, it isn't "strange". 2821 maintains a fairly strong
distinction between "relays" and other sorts of creatures.
Relays do not mess with message bodies and especially do not do
so without explicit permission from either the sender or
receiver. There are many reasons for this, but primary among
them are exactly that chain of responsibility and associated
questions of intent. To give a couple of handy examples from
the virus space...
... snip ...
Your reasoning is correct .
Another (textual) suggestion:
Split the old big RFC 2821 sections up in smaller ones.
(it makes discussion about them easier)
A bit of that has been done, and some artificially split
materials have been combined and condensed. Otherwise, see
comment above about changes for draft -00 and note that specific
suggestions (of the character of "split section 99.3 after the
second paragraph into 99.3.1 and 99.3.2") are far more helpful
than the general observation above.
I was just testing the water :)
Split up section 4.4
in a general, return-path header and a received header part.
Split up section 5
diferend sections for the different SMTP creatures
Also to benefit the discussion:
Make seperate sections for
Originator systems (is this not the same as an RFC 2476- MSA?)
Delivery systems
Relay systems
and
Gateway Systems
(as mentioned in section 2.3.8)
Specific suggestions welcome, but 2.3.8 is only two paragraphs
long. If you are suggesting a more extensive treatment, suggest
text and see if you can get agreement. Note in doing so that
this puppy is already over 80 pages long; few of us who need to
read these things would welcome a 100 page spec and I'd really
welcome identification of things than can come out instead of,
or in addition to, suggestions to put more things in.
It is just becaurse
Originator systems, Delivery systems,Relay systems and Gateway Systems
are different kids of creatures so it is usefull to know which rules (don't)
apply to which creature, in RFc 2821 it is all mashed together.
To scrap:
General
everything about originating systems could be removed. just a referal to RFC
2476 would do.
(Ps this is not a lot)
section 4.2.1
Is this section special to SMTP or is this section copied from another RFC?
If it is copied just a reference to there will do.
section 4.3.2
everything except the introduction.
regards,
john
Thanks again
Willemien