ietf-asrg
[Top] [All Lists]

Re: [Asrg] 0. General - anti-harvesting (was Inquiry about CallerID Verification)

2003-11-30 22:32:19
Exactly,  this is why is critical that before any proposals are worked on,
the RFC specifications must precisely be clear in its functional
specification at each and every interface point.  Once done, the proposals
is then easy to write to fit the new controlled specs.

I've seen this happen before and Yakov only needs to do is speak to Randy
Bush about the demise of the Fidonet Technical Specifications Committee
(FTSC) and the Fidonet Network itself (still present but not in the numbers
it use to be).

The interpretation of the specs, the insistence of FTSC administrators to
comply with legacy specifications,  their fear of losing control to militant
new groups,  help kill it.   The internet was coming and developers were
CRYING to get new internet ready specifications used by practically all the
vendors accepted by the committee.   However, to be compliant (hence get a
product code),  you had to support a legacy protocol called FTSC1 describing
the absolute minimum how a client and server handshakes to identify and
exchange data.   If your software didn't support FTSC1, the net coordinators
(ISP) would remove the node (mail server customer) from the membership list
(DNS).  This is akin to being removed your MX record removed from DNS for
not having a valid SMTP server.    When you joined the network, your host
(ISP) did FTSC1 compliance testing of your installation before issuing an
address (MX record) into the nodelist (DNS).

Now, in no way, am I advocating a strict administrated network like Fidonet
offered, but there were no security or access issues.   We can learn and
borrow quite a few ideas from it.    In a way, we are sort heading in the
same direction with SMTP with a "central authority" controlling your mail
server integration into the backbone.  It works, but do we really want this.
I don't think so.

Fix the SMTP specs people.  Everything else will follow. The specs are
great, flexible. We just need to leave no room for anonymous abuse.

---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com

----- Original Message ----- 
From: "Chris" <rebel(_at_)rebel(_dot_)com(_dot_)au>
To: <esr(_at_)thyrsus(_dot_)com>; "Yakov Shafranovich" 
<research(_at_)solidmatrix(_dot_)com>
Cc: "ASRG" <asrg(_at_)ietf(_dot_)org>; "Dave Crocker" 
<dcrocker(_at_)brandenburg(_dot_)com>
Sent: Sunday, November 30, 2003 11:35 PM
Subject: RE: [Asrg] 0. General - anti-harvesting (was Inquiry about CallerID
Verification)



Doesn't all this discussion prove that the interpretation of a protocol
can
vary?

Therefore any attempts to use a "feature" that is disputed will probably
end
up breaking some software

Regards
Chris



-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org 
[mailto:asrg-admin(_at_)ietf(_dot_)org]On Behalf Of Eric
S. Raymond
Sent: Monday, December 01, 2003 2:42 PM
To: Yakov Shafranovich
Cc: ASRG; Dave Crocker
Subject: Re: [Asrg] 0. General - anti-harvesting (was Inquiry about
CallerID Verification)


Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>:
Whether the RFCs require a valid return address, or not, in
spirit or in
letter of the law, is something Dave Crocker and Eric Raymond, and
others, who worked on the original 821 and 2821 RFCs can tell us. But
the fact today is that no one is expected to provide a valid address,
and any system relying on this, will fail in some cases unless the
existing RFCs are changed.

The spirit of the law, at least at the time I was involved with
RFC2822, was certainly that the return address was required to be
valid.  As for the letter...

Section 3.6.7 of RFC2822 says:

   The trace fields are a group of header fields consisting of an
   optional "Return-Path:" field, and one or more "Received:" fields.
   The "Return-Path:" header field contains a pair of angle brackets
   that enclose an optional addr-spec. [...]

The addr-spec is optional because it maty be omitted, as in daemon
bounces.  RFC2822 continues:

   A full discussion of the Internet mail use of trace fields is
   contained in [RFC2821].  For the purposes of this standard, the trace
   fields are strictly informational, and any formal interpretation of
   them is outside of the scope of this document.

Thus, RFC2822 does not mandate that the address be valid.  We are
referred to RFC 2821.  Section 4.1.1.4 reads:

   When the delivery SMTP server makes the "final delivery" of a
   message, it inserts a return-path line at the beginning of the mail
   data.  This use of return-path is required; mail systems MUST support
   it.  The return-path line preserves the information in the <reverse-
   path> from the MAIL command.  Here, final delivery means the message
   has left the SMTP environment.  Normally, this would mean it had been
   delivered to the destination user or an associated mail drop, but in
   some cases it may be further processed and transmitted by another
   mail system.

   It is possible for the mailbox in the return path to be different
   from the actual sender's mailbox, for example, if error responses are
   to be delivered to a special error handling mailbox rather than to
   the message sender.  When mailing lists are involved, this
   arrangement is common and useful as a means of directing errors to
   the list maintainer rather than the message originator.

I read this to mean that the Return-Path must, if present, be a
valid mailbox for a responsible person (note the MUST).
--
  <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



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