Re: need evangelists

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Daniel Quinlan writes:
>jm@jmason.org (Justin Mason) writes:
>
>> Hi all --
>> 
>> We need some evangelism for this proposal:
>> 
>>   http://wiki.spamassassin.org/w/EnvelopeSenderInReceived
>> 
>> Basically, it's a proposal to add "(envelope-from <en...@example.com>)"
>> to Received headers, to aid in accurate detection of the envelope data
>> in MDAs and MUAs (like where SpamAssassin runs in most cases).
>> 
>> Anyone on the relevant qmail/postfix/sendmail lists care to repost
>> it there?
>
>I don't see why the (comment) is needed for this.  It should just one of
>the the normal keyword=value pairs.

why:

1. We want adoption ASAP -- and whether it's a comment or not makes no
difference to us in terms of ease of parsing.   In fact, presenting
it as a comment is *easier* for us to parse, since it gives us a clearer
demarcation.

2. one MTA is already implementing it as a comment.  (qmail? exim? can't
remember)

3. a comment may receive less negative feedback from the MTA authors
than a full-fledged modification to the Received line format.

BTW didn't you look up the Received line fmt in RFC2822?  does it have
space for this?

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAKWxgQTcbUG5Y7woRAgbWAJwI2NVks4TMvhPAroAksaH4ZYXmKACgzLPX
4lgj+YIHvYBWxTT9nzI6OPY=
=Zvn9
-----END PGP SIGNATURE-----

Re: need evangelists

[Daniel Quinlan <qu...@pathname.com>]

Justin Mason <jm...@jmason.org> writes:

> 1. We want adoption ASAP -- and whether it's a comment or not makes no
> difference to us in terms of ease of parsing.   In fact, presenting
> it as a comment is *easier* for us to parse, since it gives us a clearer
> demarcation.

We could make the commenting optional, but require that it match \b for
parsing.

> 2. one MTA is already implementing it as a comment.  (qmail? exim?
> can't remember)

Bleh.  The reason I want to not make it a comment is that I think we
should publish a more complete Received: header specification and we'll
want to fix other stuff too.  Comments for everything added after RFC
2822 would be terrible and unnecessary.

> 3. a comment may receive less negative feedback from the MTA authors
> than a full-fledged modification to the Received line format.

Optional, again.

> BTW didn't you look up the Received line fmt in RFC2822?  does it have
> space for this?

Yeah, I did.

RFC 2821 and 2822 have sections on it.  2821 seems like it might not be
allowing additions, so a comment might be right.

Daniel

-- 
Daniel Quinlan                     anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/    and open source consulting