Some time ago I added the ability for IMAP clients to fetch messages' GUIDs using FETCH X-GUID command. Because of a bug it wasn't working in 1.2.0 or 1.2.1, but I've fixed it now. But now I'm starting to wonder: With Maildirs the GUIDs are the maildir base filenames, which contain host names. Is it a bad idea to expose them to users?
On Thu, Jul 16, 2009 at 04:30:00PM -0400, Timo Sirainen wrote:
Some time ago I added the ability for IMAP clients to fetch messages' GUIDs using FETCH X-GUID command. Because of a bug it wasn't working in 1.2.0 or 1.2.1, but I've fixed it now. But now I'm starting to wonder: With Maildirs the GUIDs are the maildir base filenames, which contain host names. Is it a bad idea to expose them to users?
Why? Users can see hostnames in eg. Received headers as well?
Geert-- Geert Hendrickx -=- ghen@telenet.be -=- PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!
On Thu, 2009-07-16 at 22:57 +0200, Geert Hendrickx wrote:
On Thu, Jul 16, 2009 at 04:30:00PM -0400, Timo Sirainen wrote:
Some time ago I added the ability for IMAP clients to fetch messages' GUIDs using FETCH X-GUID command. Because of a bug it wasn't working in 1.2.0 or 1.2.1, but I've fixed it now. But now I'm starting to wonder: With Maildirs the GUIDs are the maildir base filenames, which contain host names. Is it a bad idea to expose them to users?
Why?
I don't know. That's why I'm asking. :)
Users can see hostnames in eg. Received headers as well?
The SMTP servers' headers, sure. That's a pretty known issue. And maybe some even filter out some Received headers before going outside.
With large installations with multiple servers that could allow user to see e.g. if they're on the same server as someone else they know, or when they get moved to a different servers, etc.. But is this a real issue? Maybe not.
Le 16 juil. 09 à 23:05, Timo Sirainen a écrit :
On Thu, 2009-07-16 at 22:57 +0200, Geert Hendrickx wrote:
On Thu, Jul 16, 2009 at 04:30:00PM -0400, Timo Sirainen wrote:
Some time ago I added the ability for IMAP clients to fetch
messages' GUIDs using FETCH X-GUID command. Because of a bug it wasn't
working in 1.2.0 or 1.2.1, but I've fixed it now. But now I'm starting to
wonder: With Maildirs the GUIDs are the maildir base filenames, which
contain host names. Is it a bad idea to expose them to users?Why?
I don't know. That's why I'm asking. :)
Users can see hostnames in eg. Received headers as well?
The SMTP servers' headers, sure. That's a pretty known issue. And
maybe some even filter out some Received headers before going outside.
What shouldn't be allowed wrt RFC rules, unless I'm wrong: at any
time, the user should be able to trace the path of a received message
(an SMTP server MUST add a Received header, never remove or modify
such a header).
With large installations with multiple servers that could allow user
to see e.g. if they're on the same server as someone else they know, or when they get moved to a different servers, etc.. But is this a real issue? Maybe not.
I tend to agree with the latter.
First, hiding the info would tend towards security through obscurity.
Second, it is very likely that the info would anyway be leaked through
some other parts of the transport layers.
Third, one may hope that the security of smtp/imap/pop softwares
doesn't depend on the availability of such info. ;-)
But it could be very likely that I just missed your concern, in which
case please don't hesitate to position back the thing!
Axel
On Fri, 2009-07-17 at 00:12 +0200, Axel Luttgens wrote:
With large installations with multiple servers that could allow user
to see e.g. if they're on the same server as someone else they know, or when they get moved to a different servers, etc.. But is this a real issue? Maybe not.I tend to agree with the latter. First, hiding the info would tend towards security through obscurity. Second, it is very likely that the info would anyway be leaked through
some other parts of the transport layers. Third, one may hope that the security of smtp/imap/pop softwares
doesn't depend on the availability of such info. ;-)
It's not really about the security, but more about exposing some information that maybe the IMAP service provider would have preferred if you didn't know about.
On Thu, Jul 16, 2009 at 11:19 PM, Timo Sirainentss@iki.fi wrote:
On Fri, 2009-07-17 at 00:12 +0200, Axel Luttgens wrote:
With large installations with multiple servers that could allow user to see e.g. if they're on the same server as someone else they know, or when they get moved to a different servers, etc.. But is this a real issue? Maybe not.
I tend to agree with the latter. First, hiding the info would tend towards security through obscurity. Second, it is very likely that the info would anyway be leaked through some other parts of the transport layers. Third, one may hope that the security of smtp/imap/pop softwares doesn't depend on the availability of such info. ;-)
It's not really about the security, but more about exposing some information that maybe the IMAP service provider would have preferred if you didn't know about.
If I may chip in my opinion:
Information disclosure *is* a security problem. And this trend is increasing as systems tend to become more secure and direct break ins are tougher and tougher. So attackers resort to weaker links - people.
When confronted with a choice of disclosing information or not (provided that the functionality level is the same, of course, and that the protocol standards are being followed) I see no reason to disclose it. It is just about following good practice.
At the end of the day, and in this case, the impact of disclosing this information is pretty close to 0.
Unfortunately I'm no longer a sysadmin and I don't know if "my" hosted multi-[virtual]-domain postfix/ldap/dovecot installations are still running, but I haven't yet found the reason to go back to other software.
Cheers, Pedro.
Axel Luttgens wrote:
Le 16 juil. 09 à 23:05, Timo Sirainen a écrit :
The SMTP servers' headers, sure. That's a pretty known issue. And maybe some even filter out some Received headers before going outside.
What shouldn't be allowed wrt RFC rules, unless I'm wrong: at any time, the user should be able to trace the path of a received message (an SMTP server MUST add a Received header, never remove or modify such a header).
Stripping "Received" headers at an outbound SMTP gateway to obscure internal server infrastructure is a common practice, and there is nothing wrong about it. It is of no concern to anybody which servers in a company LAN were involved before an email crosses over into the Internet, and if a mail administrator decides to deprive himself of debugging information, so be it. ;-)
Regarding Timo's question, I believe that disclosing host names to authenticated IMAP users is not a big security issue.
-R
Le 17 juil. 09 à 00:45, Ralph Seichter a écrit :
Axel Luttgens wrote:
[...] What shouldn't be allowed wrt RFC rules, unless I'm wrong: at any
time, the user should be able to trace the path of a received message (an
SMTP server MUST add a Received header, never remove or modify such a
header).Stripping "Received" headers at an outbound SMTP gateway to obscure internal server infrastructure is a common practice, and there is nothing wrong about it.
You're right, of course. I was too focused on "regular" headers,
without thinking about those headers that may be internally produced
by an infrastructure.
Thanks, Axel
Axel Luttgens schrieb:
Le 17 juil. 09 à 00:45, Ralph Seichter a écrit :
Axel Luttgens wrote:
[...] What shouldn't be allowed wrt RFC rules, unless I'm wrong: at any time, the user should be able to trace the path of a received message (an SMTP server MUST add a Received header, never remove or modify such a header).
Stripping "Received" headers at an outbound SMTP gateway to obscure internal server infrastructure is a common practice, and there is nothing wrong about it.
You're right, of course. I was too focused on "regular" headers, without thinking about those headers that may be internally produced by an infrastructure.
Thanks, Axel
if somebody likes to delete ip or hostname stuff in postfix you may use i.e
/^received:.*ip\.add\.re\.ss/ IGNORE
in header_checks
there are a few reasons sombody might hide i.e internal ips/hostnames
i.e i remember an antispamsolution ( which was teribble missconfigured ) of a big american university , that interpreted all dynamic ip ( the whole net of german telekom) in the header instead of the last mailrelay ip and therefore it leads to bouncing all mail delivered over the mailrelay
anyway hostnames are not secret, and manipulate headers is not recommended
-- Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 16 Jul 2009, Timo Sirainen wrote:
when they get moved to a different servers, etc.. But is this a real issue? Maybe not.
I agree to that it is no issue.
Maybe, deliver should get a new option, e.g.:
- -X fake_hostname
Bye.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSmmvjnWSIuGy1ktrAQLZnQf/Y+UacsKVhJmucrR01Ob63xfdqhPwflOe TVlO4BwP6Qq/d1G/CWLV7b/52gHtc/V1wejw+PA7qMgaCFDAro02ssgAzx42rMNI XO2v3GKDl+VpUirYuhy1ATA2pOOs4jXi3pC2RdN4CCISvq6fVtiKAjuWTLnKmtSY Oo63Ps2W/7uAmFUfK58Uy5YucHSRKfULY1kIpGJdmmhv+Va3Gp3gzhWFmhIK9tBB zYrkuj1NraBSOELdAFnVoXlyc2XpMtU61pW6XZ9UnVPZaW3d3060mBw2xv30dATa s26rOrnTOaM2aMZ6xxvpQRYHBQMhJM69fPQWsBwve9qyWC9uNg36TA== =a8zV -----END PGP SIGNATURE-----
On Qui, 2009-07-16 at 16:30 -0400, Timo Sirainen wrote:
Some time ago I added the ability for IMAP clients to fetch messages' GUIDs using FETCH X-GUID command. Because of a bug it wasn't working in 1.2.0 or 1.2.1, but I've fixed it now. But now I'm starting to wonder: With Maildirs the GUIDs are the maildir base filenames, which contain host names. Is it a bad idea to expose them to users?
Don't see why. Apart from guessing the number of incoming servers we have (we use the so inventive mailN host naming) and I cannot even see any harm in that.
-- Jose Celestino SAPO.pt::Systems http://www.sapo.pt --------------------------------------------------------------------- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
participants (8)
-
Axel Luttgens
-
Geert Hendrickx
-
Jose Celestino
-
Pedro Lourenco Venda
-
Ralph Seichter
-
Robert Schetterer
-
Steffen Kaiser
-
Timo Sirainen