17/12/12 03:09:16 (10 years ago)

improve definition of the From header field; partly addresses #419

1 edited


  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2052 r2054  
    23272327  <x:anchor-alias value="mailbox"/>
    2329    The "From" header field, if given, &SHOULD; contain an Internet
    2330    e-mail address for the human user who controls the requesting user
    2331    agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
     2329   The "From" header field contains an Internet email address for a human
     2330   user who controls the requesting user agent. The address ought to be
     2331   machine-usable, as defined by "mailbox"
    23322332   in <xref x:sec="3.4" x:fmt="of" target="RFC5322"/>:
    2346    This header field &MAY; be used for logging purposes and as a means for
    2347    identifying the source of invalid or unwanted requests. It &SHOULD-NOT;
    2348    be used as an insecure form of access protection. The interpretation
    2349    of this field is that the request is being performed on behalf of the
    2350    person given, who accepts responsibility for the method performed. In
    2351    particular, robot agents &SHOULD; include this header field so that the
     2346   The From header field is rarely sent by non-robotic user agents.
     2347   A user agent &SHOULD-NOT; send a From header field without explicit
     2348   configuration by the user, since that might conflict with the user's
     2349   privacy interests or their site's security policy.
     2352   Robotic user agents &SHOULD; send a valid From header field so that the
    23522353   person responsible for running the robot can be contacted if problems
    2353    occur on the receiving end.
    2354 </t>
    2355 <t>
    2356    The Internet e-mail address in this field &MAY; be separate from the
    2357    Internet host which issued the request. For example, when a request
    2358    is passed through a proxy the original issuer's address &SHOULD; be
    2359    used.
    2360 </t>
    2361 <t>
    2362    The client &SHOULD-NOT;  send the From header field without the user's
    2363    approval, as it might conflict with the user's privacy interests or
    2364    their site's security policy. It is strongly recommended that the
    2365    user be able to disable, enable, and modify the value of this field
    2366    at any time prior to a request.
     2354   occur on servers, such as if the robot is sending excessive, unwanted,
     2355   or invalid requests.
     2358   Servers &SHOULD-NOT; use the From header field for access control or
     2359   authentication, since most recipients will assume that the field value is
     2360   public information.
Note: See TracChangeset for help on using the changeset viewer.