[dev] Fwd: IMP message header triggering spamassassin

[Kevin Myer]

Quoting Michael M Slusarz <slusarz at mail.curecanti.org>:

> Nope.  This has been covered many, many times before on the list.  This
> header conforms with the standards - a received header is added for
> every transport along the way.  The PHP/HTTP server is acting as a mail
> relay from the local computer - why should it be treated *any*
> differently than any other mail transport hop?  Answer: it shouldn't.

I'm just noting that IMP/PHP/HTTP as a client behaves differently, than 
oh, say,
just about any mail-generating client, in one big way.  The spam thing is a
total aside to what I see as something that warrants a slight change in the
MIME library.

The first trace hop from a traditional mail client is a:

Received: from $host blah for $recipient

The Horde MIME library generates a header:

Received: from $host blah for $user

Unless you're sending a message to yourself, $recipient != $user.

I don't disagree that the header should be there.  I think the current Horde
behavior violates the  intent of RFC 821/822.

4.1 SYNTAX
received    =  "Received"    ":"            ; one per relay
                       ["from" domain]           ; sending host
                       ["by"   domain]           ; receiving host
                       ["via"  atom]             ; physical path
                      *("with" atom)             ; link/mail protocol
                       ["id"   msg-id]           ; receiver msg id
                       ["for"  addr-spec]        ; initial for
                        ";"    date-time         ; time received

and 4.3.2 RECEIVED
     ...When the  sending  host  uses  a  destination
        address specification that the receiving host reinterprets, by
        expansion or transformation, the receiving host  may  wish  to
        record  the original specification, using the "for" parameter.
        For example, when a copy of mail is sent to the  member  of  a
        distribution  list,  this  parameter may be used to record the
        original address that was used to specify the list.

RFC 2821/2822 doesn't update that significantly, although it is more 
ambigious:

For = "FOR" FWS 1*( Path / Mailbox ) CFWS

Your message to dev at lists.horde.org was not originally destined to
slusarz at bigworm.curecanti.org but that's what the header of your reply 
says, as
read according to the specs in the RFC:

Received: from 165.127.12.75 ([165.127.12.75]) by bigworm.curecanti.org
	(Horde MIME library) with HTTP for <slusarz at bigworm.curecanti.org>;
	Tue, 03 May 2005 10:22:24 -0600

I have not and make no arguments about the goodness or badness of SA.  SA just
is - its how you configure it that makes it "good" or "bad", but as I said,
thats totally an aside.

I was assuming, perhaps wrongly, that the "for <$sender>" portion of the Horde
MIME library header was intended to be some sort of X-Originating-IP header
substitute, and if thats the case, that changes the meaning of the "for" to a
"from", which isn't the meaning that the Received: header should have for that
token.

Horde::MIME::addReceivedHeader needs to accept as an argument $recipient and
have $user replaced with $recipient, to conform to the RFCs.  Thats a more
concise way of saying all the above :)

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org