ietf-mxcomp
[Top] [All Lists]

Re: CSV (NBB, SPF incorporation of HELO check)

2004-06-20 18:18:22

"Matthew" == Matthew Elvey <matthew(_at_)elvey(_dot_)com> writes:
    >>  It's an interesting idea; do you know if an ID is forthcoming?

    Matthew> The latest I-D is dated May '04, and doesn't reflect this
    Matthew> "Unified SPF".  We'll see if it's in SenderID, which is
    Matthew> what the SPF - CID merger effort is being called, I
    Matthew> think.  This thread makes me think it will.

If the name SenderID refers to draft-ietf-marid-core (which was my
assumption) then it's clearly not in -00.  If it refers to something
else, then until and unless that proposal is submitted to this WG then
I would guess this is probably the wrong forum to discuss it further.

    >>  I'm dead against that.
    >> 
    Matthew> That was clear.

No doubt :-) Still, it's good to state one's position as precisely as
possible for the benefit of clarity of discussion...

Actually, on reflection I'd like to make one further point:

I strongly believe that this point shouldn't be glossed over by any
MARID standard.  You asked a couple of messages back what I think of
proposals that implicitly suggest blackholing messages.  I think
ambiguity like that would be the worst possible outcome for MARID.  If
MARID is going to fundamentally change this (or any other) long
established principle of Internet e-mail then it needs to be upfront
about it.

I'll go further and suggest that MARID needs to do one of the
following: either

1.  Make it clear that all mail that's not accepted MUST be rejected
    at SMTP time or bounced to the MAIL FROM where possible (as per
    existing RFCs); or

2.  Explicitly update RFC2821 6.1

Even a change from MUST to SHOULD (which would seem entirely
reasonable to me in the context of MARID) is a change to RFC2821 and
should be documented as such.

But having a MARID RFC that is inconsistent with RFC2821 (without
updating it) would seem be be unhelpful...  Having one that is
implicitly so, even more so...

    -roy


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