6.0.0-beta1
▾
Tasks
New Task
Search
Photos
Wiki
▾
Tickets
New Ticket
Search
dev.horde.org
Toggle Alerts Log
Help
11/6/25
H
istory
A
ttachments
C
omment
W
atch
Download
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
N
ew Ticket
M
y Tickets
S
earch
Q
uery Builder
R
eports
Saved Queries
Open Bugs
Bugs waiting for Feedback
Open Bugs in Releases
Open Enhancements
Enhancements waiting for Feedback
Bugs with Patches
Enhancements with Patches
Release Showstoppers
Stalled Tickets
New Tickets
Horde 5 Showstoppers