[Top] [All Lists]

Re: RFC2821bis

2005-07-06 07:38:37

--On Wednesday, 06 July, 2005 13:56 +0100
willemien(_at_)amidatrust(_dot_)com wrote:

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.

RFC2821 section 3.7 last bit:

As discussed in section 2.4.1, a relay SMTP has no need to
inspect or act upon the headers or body of the message data
and MUST NOT do so except to add its own "Received:" header
(section 4.4) and, optionally, to attempt to detect looping in
the mail system (see section 6.2).
This MUST also implies that relay hosts that do inspect the
message data MUST NOT remove virusses and the likes from
emails it relays.

Please comment on this.

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...

        (i) There are people to whom one might reasonably want
        to send viruses, and who might want to receive them.
        Examples include anti-virus evaluators and researchers
        when a possibly-new virus is discovered.  Some
        semi-random relay intervening and destroying the virus
        would not be A Good Thing.  One could claim that such
        sites would choose their MX list and relays carefully so
        as to avoid virus-deleters, but there are some subtle
        edge cases, and 2821 tries to maintain a bright line.
        (ii) Other than actually running one in a clean room
        environment and seeing what it does (and maybe not
        then), no virus detection mechanism is 100%.  Like
        almost anything else, they involve the risk of letting
        some viruses through and of getting false positives.
        One really doesn't want a _relay_ intercepting one's
        mail, deciding there is a virus present, trashing the
        message and either sending a "well, you got a note, but
        it contained a virus, so we trashed it" message to the
        recipient or, given other discussions on this list,
        silently dropping the message as presumably hostile. 

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.

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
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.


<Prev in Thread] Current Thread [Next in Thread>