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

* Your Email Address
* Spam protection	Enter the letters below: \ /.__.. .._..___. >< [__]\| \| \| _/ / \\| \|\|/\\|_\|_./__.
Comment	>>>> 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.
Attachment
Watch this ticket

Saved Queries