Re: Sender header?

[Amos Gouaux <amos+lists.ding@utdallas.edu>]

Frightening thread.  

Personally, what I'm most concerned about is the envelope sender.
If I set an identity in PINE, the "Sender:" will be
me@mymachine.domain, but the "From:" and the envelope sender
(eventually "Return-Path:") will be the identity address.  If the
envelope sender doesn't match the "From:" (before posting to a
list), then it's really hell to deal with.

Currently, to deal with this in gnus, I use the following (this was
done a while ago, so the comments might be way out of date now):

;;; Using smtpmail because it allows me to easily keep the "From:" address
;;; and envelope sender the same, just by setting `user-mail-address' via
;;; some posting styles (see below).  Why is this important?  Well, some
;;; MLMs are really anal about using the envelope sender rather than the
;;; "From:" address.  So this just makes sure I don't have too many headaches.
(load "smtpmail" nil t) ;;;; loading my hacked version.....
(add-hook
 'message-load-hook
 (function
  (lambda ()
    ;;; Envelope sender still a problem... try this...
    (add-to-list 'message-syntax-checks '(sender . disabled))
    (require 'smtpmail)
    (setq send-mail-function 'smtpmail-send-it)
    (setq message-send-mail-function 'smtpmail-send-it)
    (setq smtpmail-smtp-server "smtp.utdallas.edu"))))

I guess I also have to add that while the new RFCs do seem to
clarify some points, there still seems to be some room for
interpretation.  For example, take this portion from 2821:

B. Generating SMTP Commands from RFC 822 Headers

   2. The return address in the MAIL command SHOULD, if possible, be
      derived from the system's identity for the submitting (local)
      user, and the "From:" header field otherwise.  If there is a
      system identity available, it SHOULD also be copied to the Sender
      header field if it is different from the address in the From
      header field.  (Any Sender field that was already there SHOULD be
      removed.)

which seems to confirm what Rat has been saying.  HOWEVER, the very
next sentence reads:

      Systems may provide a way for submitters to override the
      envelope return address, but may want to restrict its use to 
      privileged users.  This will not prevent mail forgery, but may
      lessen its incidence; see section 7.1.

Well, this seems to weaken the SHOULDs above.  Section 7.1 then goes
on to say:

   Efforts to make it more difficult for users to set envelope return
   path and header "From" fields to point to valid addresses other than
   their own are largely misguided: they frustrate legitimate
   applications in which mail is sent by one user on behalf of another
   or in which error (or normal) replies should be directed to a special
   address.

Oh well, so much for that.  Not meaning to be a pain in the ass, but
I sure rely on such identities (with Cyrus shared folders) bloody
heavily........ 

-- 
Amos