Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders thatare not compatible with RFC 2822

From: "Jim Lyon" <[email-masked]>
Date: Mon, 13 Sep 2004 11:21:15 -0700

On Monday, September 13, 2004, at 10:52 AM, Paul Iadonisi wrote:

-- Jim Lyon
   mailto:[email-masked]
   tel:+1-425-706-0867

Internet commerce will never really take off until you can buy something
online without getting spammed by the vendor.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Paul Iadonisi
Sent: Monday, September 13, 2004 10:52 AM
To: [email-masked]
Subject: RE: TECH-ERROR: SenderID sets recomendation for forwarders
thatare not compatible with RFC 2822
> It [Resent-From] is not for 'manually or automatically'
> re-inserted messages, but only manually, given that the
> automatic re-insertion is excluded from using Resent-*
> fields according to the above line I've quoted from
> section 3.6.6 of RFC2822.

I think the bright-line test to decide whether Resent-From is
appropriate is:

    Is the action occurring at the desire of the mailbox owner, or is
    it occurring at the desire of the mail infrastructure owner?

Otherwise, using the reading that you propose yields an absurd and
unimplementable result:

    If my MUA has a "Resend" command, and I manually execute it, there
    should be a "Resent-From".  But if an automated script executes my
    MUA's "Resend" command, there shouldn't be a "Resent-From".  This
    appears nonsensical on its face, so an alternate interpretation is
    required.  (It also begs the question of whether my secretary
pressing
    the button constitutes "manual" or "automatic", when he's doing so
    under my standing orders with no discretion.)

You need to read specs like a lawyer, not like a programmer.
(Programmer: if the spec says "jump", I'll jump and damn the
consequences.  Lawyer: if the spec says "jump" and that's either
ambiguous or nonsensical, I'll look beyond the words to the intended
meaning.)  Admittedly, the best specs are ones that yield the same
result to both programmers and lawyers.

-- Jim Lyon

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 13 Sep 2004 13:20:44 -0700 (PDT)

> result to both programmers and lawyers.

As much as I'd want to be able to read some documents like a laywer, I'm 
not one and can not easily do it.

I believe and many others would probably confirm that IETF documents are 
foremost intended to be read and interpreted by engineers and programmers
and that likely scenario is that lawyer would not be able to understand
complexities and technical details of many of the IETF protocols as he/she
would not qualified unless he/she isa also engineer or programmer (such a
person is for example Karl Auerbach and I actually dont even know any other
lawyer who is also network engineer geek).

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: Paul Iadonisi <[email-masked]>
Date: Mon, 13 Sep 2004 16:30:36 -0400

On Mon, 2004-09-13 at 14:21, Jim Lyon wrote:

[snip]

> Otherwise, using the reading that you propose yields an absurd and

  The reading I propose does not *at all* yield an 'absurd and
unimplementable result'.  That you have the nerve to call it absurd
amazes me, given that it seems to be a *widely* accepted (though
obviously not by you) reading of it.  And the simple fact that it HAS
been implemented this way for quite some time is extremely clear
evidence that it is absolutely implementable.

[snip]

> You need to read specs like a lawyer, not like a programmer.

  I take exception to you telling me that I should read it like a
lawyer.  Lawyers don't have to implement these specs, so they are not
written with lawyers in mind.  And they shouldn't be.  Please read Anne
Mitchell's (she's a lawyer...oh, the irony ;-)) latest post to this list
for a good summary of my views on this (I'd provide a link, but it
hasn't shown up in the archives yet).  It's her post with the subject
'Re: What the lawyers and suits think'.
--
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets