[Tickets #13041] Re: Posibillity to diabled the Received from ... (Horde Framework) with HTTP header line injection to the e-Mail header lines.

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13041
------------------------------------------------------------------------------
  Ticket             | 13041
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Posibillity to diabled the Received from ... (Horde
                     | Framework) with HTTP header line injection to the
                     | e-Mail header lines.
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Enhancement
  State              | Rejected
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2014-03-18 15:48) wrote:

>>> is there a possibility, or could this be realized, to diabled the
>>> Received from ... (Horde Framework) with HTTP ... header line
>>> injection to the e-Mail header lines.
>>
>> This is a terrible idea.  It is explicitly prohibited against RFCs.
>
> Maybe the is a missunderstanding or my first desciption of my problem
> was not so good.
>
> I don't want to disable ALL Recived: from lines, only the first line  
> which insert
> the Horde Framework HTTP header line from the client/Desktop PC.
>
> In Roundcube or in LotusNotes you can configure this, to hide the  
> client/Desktop PC
> Received: from line!

This is explicitly against the RFC.  **ALL** hops have to be accounted  
for.  Webmail is a mail user agent ... skipping the MUA -> HTTP server  
step (which is really acting as a mail server in this instance) is  
probably the most important step in the whole process!

> I remember, that the Received: from line for the sender MTA must be  
> in the header lines,
> but not from which client/Desktop PC the e-Mail was sent to the first MTA.

Why not?  That's where the potential abuse (the purpose behind  
Received) is initiated.  It's the most important information in there.

>>> This could be good for security reason, because sometime I use a
>>> browser at a place, and I don't want to get lines like the following
>>> in my e-Mail-Header:
>>
>> If you are worried about privacy, then don't send e-mail messages.
>
> If you worried to die while you cross the street, did you stop walking?

I don't know what this means.

>> Otherwise, if you remove those headers, it becomes a security issue
>> from the *recipient's* side, since they can no longer effectively
>> track the message in the case of abuse.  So these headers are for the
>> benefit of the recipient, not the sender.  You start removing
>> tracking headers and you become at risk of being put on various RBLs,
>> for example.
>
> No I think that the sender MTA must be reachable for abuse, note the  
> client/desktop PC!

#1: you absolutely cannot assume the sending MTA is going to help you,  
or that they will archive this information (they almost certainly will  
not).

#2: RFC 5321:

7.6. Information Disclosure in Trace Fields

    In some circumstances, such as when mail originates from within a LAN
    whose hosts are not directly on the public Internet, trace
    ("Received") header fields produced in conformance with this
    specification may disclose host names and similar information that
    would not normally be available.  This ordinarily does not pose a
    problem, but sites with special concerns about name disclosure should
    be aware of it.

> With postfix header_checks, I realized "header stripping" for that  
> line, but I think when
> Roundcube and other client software/webmailer could do this, why not  
> Horde too?

They are simply wrong.  Just because "XYZ" does something doesn't make  
it right.