A good IMAP tutorial?
Hiawatha Bray
Outlook which worked flawlessly with POP. But IMAP is a different
story. I have sizable delays in getting my mail. I'm convinced I'm
doing something wrong. So I want to find a good guide to using IMAP
with Outlook. Where can I find such a thing? Thanks.
Klaatu
I would like to find a good guide to using IMAP, regardless of the client
used. I have searched all over the WWW, and in newsgroups, but still can't
find anything very useful.
But if you find anything, please let us know.
TIA
--
I intend to live forever......So far, so good.
Theodor Rash
> Greetings. I've just switched from POP to IMAP.
What does that exactly mean? What did you do?
> I use Microsoft Outlook
Bad idea
> which worked flawlessly with POP.
Sure?
> But IMAP is a different story. I have sizable delays in getting my mail.
> I'm convinced I'm doing something wrong.
Yes, using Outlook.
> So I want to find a good guide to using IMAP
> with Outlook. Where can I find such a thing? Thanks.
Every IMAP server, except those from Microsoft of course, tries to overcome
broken mail clients like Outlook as good as possible. They do not/can not
always succeed (and IMHO they shouldn't even try it).
Theo
Paul Rubin
> Every IMAP server, except those from Microsoft of course, tries to overcome
> broken mail clients like Outlook as good as possible. They do not/can not
> always succeed (and IMHO they shouldn't even try it).
Is there a document anywhere that explains Outlook's brokenness as
regards IMAP? There's an RFC about IMAP implementation hints that
basically says test with every client you possibly can, but doesn't
say anything specific about Outlook that I can remember. Thanks.
Mark Crispin
> Is there a document anywhere that explains Outlook's brokenness as
> regards IMAP? There's an RFC about IMAP implementation hints that
> basically says test with every client you possibly can, but doesn't
> say anything specific about Outlook that I can remember. Thanks.
Without getting into specifics, Outlook and Outlook Express suffer from
the all-too common affliction of treating IMAP as a fancy version of POP3.
They also assumes that it runs only on non-shared PCs that are used
exclusively by the human user, and that the human user wants everything
that the IMAP server holds to be copied to the PC
Outlook was designed to be used with Exchange; and its IMAP support was an
afterthought. It shows. Outlook Express is a completely different
program, and has its own nasty little surprises.
There are worse IMAP clients out there than either Outlook and OE... :-(
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
DaveT
to get into imap. If you're from a microsoft background you probably didn't
get that deep into imap at all.
Ray Charbonneau
hasn't turned up much in the way of documentation for using OL in a
non-Exchange environment.
Can you be more specific about the delays?
--
Ray Charbonneau
The MITRE Corporation
Check address before replying via email
"Hiawatha Bray" <wa...@monitortan.com> wrote in message
news:379dd397.03042...@posting.google.com...
Klaatu
> the imap book from oreilly for starters......I don't know how deep you
> want to get into imap. If you're from a microsoft background you
> probably didn't get that deep into imap at all.
I know I would like a tutorial that discusses the use of IMAP from the
client (any client) side, that is not too heavy on the technicalities. A
nice discussion of SIEVE would be nice too.
--
... A feather is erotic; a whole chicken is kinky!
Paul Rubin
> I know I would like a tutorial that discusses the use of IMAP from the
> client (any client) side, that is not too heavy on the technicalities.
I'd be interested to know what kinds of issues such a tutorial would
be expected to address. If it's aimed at users and it has to say more
than "find the dialog where you choose between POP3 and IMAP, and
click on IMAP", then something seems wrong. If it's aimed at
implementers, then I'd hope it would cover technicalities thoroughly.
If you want to look at a simple client side implementation,
Squirrelmail (www.squirrelmail.org) is written in PHP and is pretty
easy to understand. It only uses a small subset of IMAP client side
commands; however that's probably typical of IMAP clients.
Paul Rubin
> And if you want to get a much deeper understanding of IMAP and
> its capabilities, I recommend that you try out Mulberry. As far
> as I know there is no client that comes anywhere near Mulberry in
> IMAP abilities and ease of use (*), especially the upcoming
> version, which will support up to 8 user-defined keywords that
> are stored on the IMAP server.
But servers don't have to support more than the 5 standard keywords, I
thought?
> Another bit of advice about finding an IMAP client that will help
> you to grok IMAP: Avoid any client that was originally designed
> as a client for POP3 or MS Exchange (or whatever non-standard
> non-IMAP protocol you can think of). These programs are destined
> to never truly embrace the IMAP model and AFAICT this is one of
> the main reasons that users, such as my friend, are so confused
> about IMAP.
Actually, it's the badly designed and broken clients that interest me
the most, because I want to know what kinds of bizarreness server
implementations have to put up with. MS Outlook is obviously an
example; do you know about Mozilla/Netscape Communicator?
Thanks.
Nancy McGough
>
> Actually, it's the badly designed and broken clients that interest me
> the most, because I want to know what kinds of bizarreness server
> implementations have to put up with. MS Outlook is obviously an
> example; do you know about Mozilla/Netscape Communicator?
At the moment I use three IMAP clients pretty much every day:
Pine 4.55, Mulberry 3.03, and Mozilla 1.4a. The thing that drives
me nuts about Moz is that when I right click on a message and
choose "Copy To" it lists all my IMAP accounts and all the
mailboxes on those servers, but it does not give me the option --
*on the fly in the midst of a Copy To*-- to create a mailbox on
one of those IMAP servers. Does anyone know if there's a way to
do this in Moz? (Please don't tell me to go to the Server List
and choose "New Folder" -- that is a P.I.T.A. because I have
literally hundreds of mailboxes and dozens of IMAP and NNTP
servers in my Server List and it is truly a pain to scroll
through that list and find the IMAP server that I want to
target.)
Moz is my least favorite of the three IMAP clients that I use,
but I continue to use it because it is -- AFAIK -- the best free
GUI IMAP client and the one that I recommend to friends who want
a GUI and don't want to pay for Mulberry.
--
Nancy McGough
Infinite Ink Log and Discussion
<http://www.ii.com> <http://ii.deflexion.com>
--- Computing - Mathematics - Science - Philosophy ---
Paul Rubin
> Moz is my least favorite of the three IMAP clients that I use,
> but I continue to use it because it is -- AFAIK -- the best free
> GUI IMAP client and the one that I recommend to friends who want
> a GUI and don't want to pay for Mulberry.
I'm fairly happy with Squirrelmail. It doesn't require installing
anything on the user's computer. It has some security bugs that the
maintainers refuse to acknowledge, but are easy to patch.
ron nash
> I'm fairly happy with Squirrelmail. It doesn't require installing
> anything on the user's computer. It has some security bugs that the
> maintainers refuse to acknowledge, but are easy to patch.
Could you elaborate on the security bugs and patches for SquirrelMail?
--
_ ___,;;;/ | Ron Nash (nash...@sdsu.edu) San Diego State University
,;( )__, )~\| | remove shoes for mail
;; // '--; | Gin-N-Tonic endurance horse
' ;\ | | Luv on Fire trusty trail horse
Klaatu
> If you want to look at a simple client side implementation,
> Squirrelmail (www.squirrelmail.org) is written in PHP and is pretty
> easy to understand. It only uses a small subset of IMAP client side
> commands; however that's probably typical of IMAP clients.
You're kidding, right? Squirrelmail? You expect someone that wants a mail
client to access an IMAP server to install and configure Squirrelmail,
along with everything that it requires? It sounds like I would need to
install and implement a Web Server on my own machine, install and configure
PHP4, then install and configure Squirrelmail, all just to get an email
client? I don't think so...
Would you really expect a typical user to do all of that?
Thanks for the suggestion anyway.
--
When you're having a bad day and it seems like people are trying to piss
you off, remember, it takes 42 muscles to frown and only 4 to pull the
trigger of a decent sniper rifle.
Klaatu
> Nancy McGough <nm-reverse-...@ii.deflexion.com> writes:
>> And if you want to get a much deeper understanding of IMAP and
>> its capabilities, I recommend that you try out Mulberry. As far
>> as I know there is no client that comes anywhere near Mulberry in
>> IMAP abilities and ease of use (*), especially the upcoming
>> version, which will support up to 8 user-defined keywords that are
>> stored on the IMAP server.
> But servers don't have to support more than the 5 standard keywords, I
> thought?
See, that's just the sort of thing I want to see addressed in an IMAP
tutorial. What are keywords? What are they good for? How would I use
them? Before you mentioned them here, I didn't even know IMAP had this
thing called "keywords".
And hierarchies. WTF are they? And why can I create new ones? What good
do they do me? Why would I want to use them as opposed to just seeing all
of my folders?
I have and use Mulberry, but until recently was using it strictly with
POP3 accounts. Having just started using it with IMAP, I am running into
this new terminology and methodologies that are unfamiliar.
My IMAP provider supports SEIVE, so it looks like I can have the server
do a certain amount of filtering. A tutorial there would be handy as
well. Trying to find anything on the net detailing common terms and usage
of either IMAP or SEIVE is an effort in frustration.
--
"Things are more like they are now than they ever were before."
-- Dwight D. Eisenhower
Paul Rubin
> > If you want to look at a simple client side implementation,
> > Squirrelmail (www.squirrelmail.org) is written in PHP and is pretty
> > easy to understand. It only uses a small subset of IMAP client side
> > commands; however that's probably typical of IMAP clients.
>
> You're kidding, right? Squirrelmail? You expect someone that wants a mail
> client to access an IMAP server to install and configure Squirrelmail,
> along with everything that it requires? It sounds like I would need to
> install and implement a Web Server on my own machine, install and configure
> PHP4, then install and configure Squirrelmail, all just to get an email
> client? I don't think so...
>
> Would you really expect a typical user to do all of that?
No of course not. The suggestion of looking at squirrelmail was if
you wanted to see the internals of an implementation. Yes, if you
want to install squirrelmail you need to run a web server. That's
something an email user wouldn't normally do. But if you're trying to
provide email access to a bunch of users, one way to do it is run an
imap server and install imap clients on their computers. Another way
is install squirrelmail on your web server and let the users access it
with ordinary browsers. In many occasions, browsers can be simpler
for users to deal with than mail clients. Also, the most widespread
browsers all support SSL, while I don't think SSL (or TLS) is that
widely deployed yet in imap mail clients.
Sahil Tandon
[...]
>In many occasions, browsers can be simpler for users to deal with than mail
>clients.
Browsers aren't necessarily any simpler to use than several e-mail clients
available today -- it's mostly a matter of preference.
>Also, the most widespread browsers all support SSL, while I don't think SSL
>(or TLS) is that widely deployed yet in imap mail clients.
Where did you get that impression? The latest builds of many e-mail clients
currently support SSL.
Regards,
--
Sahil Tandon <sa...@brandeis.edu>
http://people.brandeis.edu/~sahil
Nancy McGough
>
> >Also, the most widespread browsers all support SSL, while I don't think SSL
> >(or TLS) is that widely deployed yet in imap mail clients.
>
> Where did you get that impression? The latest builds of many e-mail clients
> currently support SSL.
I'm also curious about this -- what IMAP clients do *not* support
IMAP over SSL? I'd like to add that info to my IMAP page and
steer people away from those clients.
Thanks,
Nancy
also trying to steer people away from email providers who don't
provide IMAP over SSL
Paul Rubin
> I'm also curious about this -- what IMAP clients do *not* support
> IMAP over SSL? I'd like to add that info to my IMAP page and
> steer people away from those clients.
I thought Netscape and/or IE only recently started supporting SSL.
Squirrelmail doesn't directly support SSL, though it's kind of a
special case.
Most everything I know about IMAP at the moment comes from the RFC. I
don't know much about specific clients yet. I'm probably going to
have to find out more. Sigh.
Villy Kruse
Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>Nancy McGough <nm-reverse-...@ii.deflexion.com> writes:
>> I'm also curious about this -- what IMAP clients do *not* support
>> IMAP over SSL? I'd like to add that info to my IMAP page and
>> steer people away from those clients.
>
>I thought Netscape and/or IE only recently started supporting SSL.
>
They supported SSL long before it was legal for WU imapd to be shipped
with SSL support. Both Microsoft and Netscap could afford the license
from RSA for SSL and had the required export license required by the US
government as well. They needed those licenses anyway to support SSL with
their respective browsers.
Villy
Paul Rubin
> Could you elaborate on the security bugs and patches for SquirrelMail?
Here are the ones I remember:
1) When a user composes a message, the browser's IP address is
included in a message header, a privacy breach. Removing it is
trivial but I was unable to convince the squirrelmail maintainers that
this was a bug. They seemed to think the squirrelmail application was
itself a mail server, which it is not. It's a mail client and it
talks to an imap server. It's a web application and a web client
talks to it, but the web client is not a mail client. The IP address
of the web server running squirrelmail should go in the message, but
the web browser's IP address should be considered private.
2) The MIME attachment separator is a pseudo-random string generated
from stuff including the browser's IP address, but the way that it's
generated allows figuring out the IP address even if the header
mentioned above is removed. Again there's a fairly simple patch for it.
3) The user's password (I may have this slightly wrong, it's been a
while) was encrypted and stored in browser cookie, but the encryption
function was no good. I sent in a patch and this time they
acknowledged the problem and thanked me for the patch, but the last
time I looked the patch hadn't been integrated.
4) The "compose message" screen sends the message headers (addressee,
subject, etc.) to the server with an HTTP GET request instead of a
POST. That means that a log of various headers including the subject
line for every outgoing message is preserved in the HTTP server log,
another privacy breach. Because of how that screen worked, patching
squirrelmail to use POST would have been a bit messy and I never got
around to it (instead I configured my httpd to not log those
requests). I don't remember what the response was when I reported
this but you get the general drift.
There were a couple of other things like this as well. Despite this I
think squirrelmail is a pretty good program; unfortunately, the
implementers at the time just weren't concerned enough about security,
sort of the same problem that a certain company in Redmond WA is
famous for.
This was all several releases ago and I haven't been using
squirrelmail recently. It's possible that the current releases have
these problems fixed. I probably want to start using it again, but
won't do so without first checking the code pretty carefully for these
kinds of bugs.
HTH
Ingo Pakleppa
> ron nash <nash...@sdsu.edu> writes:
>> Could you elaborate on the security bugs and patches for SquirrelMail?
>
> Here are the ones I remember:
>
> 1) When a user composes a message, the browser's IP address is
> included in a message header, a privacy breach. Removing it is
> trivial but I was unable to convince the squirrelmail maintainers that
> this was a bug. They seemed to think the squirrelmail application was
> itself a mail server, which it is not. It's a mail client and it
> talks to an imap server. It's a web application and a web client
> talks to it, but the web client is not a mail client. The IP address
> of the web server running squirrelmail should go in the message, but
> the web browser's IP address should be considered private.
I strongly disagree. Somebody who sends mail *should* be identifiable.
This is not a privacy breach. In fact, I would call for some better
identifiability (not w/ respect to Squirrelmail, but in general) to
prevent abuse (spam).
And, by the way, the browser's IP address is public information anyway.
> 2) The MIME attachment separator is a pseudo-random string generated
> from stuff including the browser's IP address, but the way that it's
> generated allows figuring out the IP address even if the header
> mentioned above is removed. Again there's a fairly simple patch for it.
See above.
> 4) The "compose message" screen sends the message headers (addressee,
> subject, etc.) to the server with an HTTP GET request instead of a
> POST. That means that a log of various headers including the subject
> line for every outgoing message is preserved in the HTTP server log,
> another privacy breach. Because of how that screen worked, patching
> squirrelmail to use POST would have been a bit messy and I never got
> around to it (instead I configured my httpd to not log those
> requests). I don't remember what the response was when I reported
> this but you get the general drift.
The same information is always available from the SMTP log. And with SMTP
traffic going unencrypted over the net, the only way to protect this kind
of information would be not to use email. So what's the point?
Paul Rubin
> I strongly disagree. Somebody who sends mail *should* be identifiable.
> This is not a privacy breach. In fact, I would call for some better
> identifiability (not w/ respect to Squirrelmail, but in general) to
> prevent abuse (spam).
There's some confusion going on here. Squirrelmail is not
Hotmail--most squirrelmail installations are on privately operated
servers which don't give accounts to random untraceable people such as
spammers. Since only someone with an account on the Squirrelmail
server can send mail, that person can be held responsible for abuses
without needing their IP address leaked.
In a Hotmail-like system where total randoms can create accounts with
no authentication and there's too much abuse to get a sysadmin to
intervene when it happens, there's a case to be made for including the
IP address even though it deliberately compromises privacy. However,
that should certainly not be the default setting. Hotmail is unusual
and exceptional.
> and, by the way, the browser's IP address is public information anyway.
That's complete nonsense. I have a browser up on my screen right now.
Can you tell me its IP address? (You can tell the address of the news
host I post through, but that's a server that I ssh into).
Squirrelmail should no more publish your browser IP address in your
email than your dialup ISP should publish your phone number in your IP
traffic.
Here is a concrete example of why including the IP address is bad,
starting with an actual testimonial from Squirrelmail's "feedback" page:
IPACT
Michael Huttinger
<huttinger[at]ipact.com>
We are an Industrial Process Automation company with many of our
employees on the road. I, being one of them, really wanted a nice way
to get to my mail back at the office without too much
hassle. SquirrelMail has saved the day! We are running SM on a linux
box with SSL to help provide a nice secure environment for our mail
needs. Easy to use and with new features being added every day makes
this a #1 choice. The plugin idea is great! I wrote the NewMail plugin
so I don't forget to check my mail :)
(http://www.squirrelmail.org/feedback.php?st=551)
The above is from some poor guy whose admin went out of his/her way to
set up SSL to keep their users' mail secure. Now the company staff is
travelling around using squirrelmail and including those browser IP
addresses. And presumably they're sending email to outside the
company, say to customers or to business-related mailing lists.
Say you're one of that IPACT's competitors, and you get an email from
an IPACT sales person, maybe through an industry mailing list or about
meeting up at an upcoming trade show. Or maybe it was simply
forwarded to you by one of your own customers, inviting you to match
an IPACT price quote. Anyway, you reverse-DNS the IPACT salesperson's
IP address and find that the message was entered at a Holiday Inn in
Armonk, NY (where IBM headquarters is). Guess what! You now know
that IPACT is trying to sell widgets to IBM! You quickly dispatch
your own sales team and grab the deal away. Or if it came from a
Motel Six in Redmond, WA, well, you get the idea.
If you own a business whose travelling staff uses Squirrelmail, do you
REALLY want the exact whereabouts of your sales force broadcast to
everyone who gets any email from them? If you say yes, you are crazy.
The IP address in the messages should always be the address of the
squirrelmail server sitting at IPACT headquarters. The exact location
of any salesperson at any moment should be treated as a business
secret. But IPACT's squirrelmail server is sending out the info right
now and its admins probably don't even know it! Meanwhile their VP of
Sales might be scratching his head right now, trying to figure out why
they keep losing all those deals despite taking their best
precautions.
> > 4) The "compose message" screen sends the message headers (addressee,
> > subject, etc.) to the server with an HTTP GET request instead of a
> > POST. That means that a log of various headers including the subject
> > line for every outgoing message is preserved in the HTTP server log,
>
> The same information is always available from the SMTP log. And with SMTP
> traffic going unencrypted over the net, the only way to protect this kind
> of information would be not to use email. So what's the point?
1) I don't believe SMTP logs typically record the message subject, but
rather just its timestamp. Of course some SMTP clients don't log anything.
2) SMTP (sometimes) supports traffic encryption via STARTTLS, just like IMAP.
3) The argument that unencrypted SMTP traffic is as bad as logging is
completely wrong. By your logic, since most POTS voice telephone
traffic is unencrypted, it's ok for phone companies to permanently
record every phone call you make because the only way to protect your
conversations is to not use telephones. In reality, recording
other people's phone calls is illegal unless there's a wiretap order
even if the phone calls are unencrypted. Once a conversation is over,
its contents should not be retained except possibly by the participants.
So, I hope you will think these things through a little more.
--Paul
Ingo Pakleppa
> "Ingo Pakleppa" <ingo-ne...@kkeane.com> writes:
>> I strongly disagree. Somebody who sends mail *should* be identifiable.
>> This is not a privacy breach. In fact, I would call for some better
>> identifiability (not w/ respect to Squirrelmail, but in general) to
>> prevent abuse (spam).
>
> There's some confusion going on here. Squirrelmail is not
> Hotmail--most squirrelmail installations are on privately operated
> servers which don't give accounts to random untraceable people such as
> spammers. Since only someone with an account on the Squirrelmail
> server can send mail, that person can be held responsible for abuses
> without needing their IP address leaked.
>
> In a Hotmail-like system where total randoms can create accounts with
> no authentication and there's too much abuse to get a sysadmin to
> intervene when it happens, there's a case to be made for including the
> IP address even though it deliberately compromises privacy. However,
> that should certainly not be the default setting. Hotmail is unusual
> and exceptional.
I don't think this is a valid argument. Squirrelmail CAN be used the way
you suggest, but just making the assumption that it will only be on
private networks is dangerous.
And, in any case, I don't see what privacy issues are affected by
disclosing your IP address.
>> and, by the way, the browser's IP address is public information anyway.
>
> That's complete nonsense. I have a browser up on my screen right now.
> Can you tell me its IP address? (You can tell the address of the news
> host I post through, but that's a server that I ssh into).
Of course not, because I'm not interacting with it. That's the difference.
> Squirrelmail should no more publish your browser IP address in your
> email than your dialup ISP should publish your phone number in your IP
> traffic.
>
> If you own a business whose travelling staff uses Squirrelmail, do you
> REALLY want the exact whereabouts of your sales force broadcast to
> everyone who gets any email from them? If you say yes, you are crazy.
Quite honestly, I am saying yes. If this really is your concern, then you
need to install a proxy server that talks to Squirrel Mail. That way, you
can secure the proxy server against somebody using it to spam, while still
provide the accountability of having the IP address in SM.
In reality, though, there are much better ways of tracking a person's
whereabouts than waiting for a random email to disclose where he has been
a few days ago. And what makes you think that the sales person doing a top
secret deal would even send an email to his worst competitor at the
critical time? Sure, it can happen, but waiting for that to happen would
be a pretty stupid move on the competitor's side. I would want a more
predictable way of spying.
By the way, if you use a traditional SMTP/IMAP client from the hotel, your
IP address would also be in the mail. In my mind, this is a good thing
because in the light of spam, the clear need for as much accountability as
we can get far outweighs such a doubtful claim to privacy.
>> > 4) The "compose message" screen sends the message headers (addressee,
>> > subject, etc.) to the server with an HTTP GET request instead of a
>> > POST. That means that a log of various headers including the subject
>> > line for every outgoing message is preserved in the HTTP server log,
>>
>> The same information is always available from the SMTP log. And with SMTP
>> traffic going unencrypted over the net, the only way to protect this kind
>> of information would be not to use email. So what's the point?
>
> 1) I don't believe SMTP logs typically record the message subject, but
> rather just its timestamp. Of course some SMTP clients don't log anything.
Clients yes. But sendmail (the server I am most familiar with), with
default settings, contains every single subject line, along with sender
and receiver and time stamp and some more information.
> 2) SMTP (sometimes) supports traffic encryption via STARTTLS, just like IMAP.
In theory. In practice, you only get encryption between the client and the
server if it is set up properly, almost never between servers unless you
have control of both ends of the connection.
> 3) The argument that unencrypted SMTP traffic is as bad as logging is
> completely wrong.
Actually, that's not my argument. My argument that unencrypted SMTP
traffic is much worse. The logs, on a properly secured system, are only
available to the sysadmin or other authorized people. SMTP traffic is
available to anybody on the way.
> By your logic, since most POTS voice telephone
> traffic is unencrypted, it's ok for phone companies to permanently
> record every phone call you make because the only way to protect your
> conversations is to not use telephones. In reality, recording
> other people's phone calls is illegal unless there's a wiretap order
> even if the phone calls are unencrypted. Once a conversation is over,
> its contents should not be retained except possibly by the participants.
SMTP is actually more akin to writing all your email on the back of
postcards. Your mail delivery person knows about every single postcard
that you receive, including content.
In any case, this is moot because your whole argument centered around
ILLEGAL activity. I could make the same point you make about POTS instead
about viewing sendmail log files.
> So, I hope you will think these things through a little more.
Or we agree to disagree...
Paul Rubin
> I don't think this is a valid argument. Squirrelmail CAN be used the way
> you suggest, but just making the assumption that it will only be on
> private networks is dangerous.
Using squirrelmail on private networks is surely far more common than
running public Hotmail-like services with it. And someone running a
public server who encounters spam problems (which they will
immediately) can start taking measures like including the IP address
once the problems start. It doesn't matter if they miss a few on the
first day.
This could even be a configuration option. But as it is now, the
setup system and the squirrelmail docs do nothing to make admins aware
of the issue.
> And, in any case, I don't see what privacy issues are affected by
> disclosing your IP address.
It reveals your location which you might consider private. Maybe YOU
don't consider your location private, but that's for you to decide,
not for the Squirrelmail implementers to decide. (Another example:
suppose you're on vacation and you send a work-related email to a boss
or customer who's a religious fundamentalist. If you chose to spend
your vacation in Las Vegas playing the slot machines, that's YOUR
business and it's completely legal, but revealing it to your boss
could get you in trouble. The Squirrelmail implementers should not
take it on themselves to interfere in workplace relations like that.)
> > That's complete nonsense. I have a browser up on my screen right now.
> > Can you tell me its IP address? (You can tell the address of the news
> > host I post through, but that's a server that I ssh into).
>
> Of course not, because I'm not interacting with it. That's the difference.
If I'm ssh'ing via a java ssh client running in the browser (which I
do sometimes), then you're interacting with the browser by reading
this post, to the exact same extent that you're interacting with a
browser used to send mail with squirrelmail. But you still don't see
the IP address.
> Quite honestly, I am saying yes. If this really is your concern, then you
> need to install a proxy server that talks to Squirrel Mail. That way, you
> can secure the proxy server against somebody using it to spam, while still
> provide the accountability of having the IP address in SM.
Why not just directly secure the squirrelmail server against somebody
using it to spam, instead of bothering with a proxy?
> In reality, though, there are much better ways of tracking a person's
> whereabouts than waiting for a random email to disclose where he has been
> a few days ago. And what makes you think that the sales person doing a top
> secret deal would even send an email to his worst competitor at the
> critical time? Sure, it can happen, but waiting for that to happen would
> be a pretty stupid move on the competitor's side. I would want a more
> predictable way of spying.
Sales people have to travel around and they have to attend to their
day to day email while they travel.
> By the way, if you use a traditional SMTP/IMAP client from the hotel, your
> IP address would also be in the mail.
Yes, that's a reason to use squirrelmail instead of a traditional
smtp/imap client, so the mail comes from the squirrelmail server and
NOT from the hotel. Except the squirrelmail code messes it up.
> In my mind, this is a good thing because in the light of spam, the
> clear need for as much accountability as we can get far outweighs
> such a doubtful claim to privacy.
Perhaps you should work for John Ashcroft :)
> Clients yes. But sendmail (the server I am most familiar with), with
> default settings, contains every single subject line, along with sender
> and receiver and time stamp and some more information.
I don't see any logs like that on my system, though I don't know much
about sendmail. However, email logs are typically better secured than
web logs. For example, where I used to work we sent our web logs to
an outside company for auditing (it was an e-commerce site). We didn't
do that with smtp logs.
> > 2) SMTP (sometimes) supports traffic encryption via STARTTLS, just like IMAP.
>
> In theory. In practice, you only get encryption between the client and the
> server if it is set up properly, almost never between servers unless you
> have control of both ends of the connection.
Some servers support starttls, though not as many as should.
> > 3) The argument that unencrypted SMTP traffic is as bad as logging is
> > completely wrong.
>
> Actually, that's not my argument. My argument that unencrypted SMTP
> traffic is much worse. The logs, on a properly secured system, are only
> available to the sysadmin or other authorized people. SMTP traffic is
> available to anybody on the way.
OK, I see what you mean. Still, SMTP traffic (like other IP traffic)
is normally not RECORDED. If someone is not actively looking at your
traffic the moment that you send it, they won't have a file kept
around where they can examine it at some arbitrary later date.
> SMTP is actually more akin to writing all your email on the back of
> postcards. Your mail delivery person knows about every single
> postcard that you receive, including content.
I don't believe that analogy, except to the same extent that your
phone company techs have access to your phone calls. Email is
supposed to be like phone calls and at least in the USA is given
similar legal protection (Electronic Communications Privacy Act).
Even if your mail carrier reads every one of your postcards before
delivering it, s/he would get probably in a lot of trouble if s/he
actually made and kept a permanent copy of each one. Once the
postcard is delivered, only the recipient is supposed to have it,
regardless of whether other people have seen it. Do you understand
the difference?
> In any case, this is moot because your whole argument centered around
> ILLEGAL activity.
You mean illegal wiretaps? I'm not sure what you're getting at here.
Certainly I think people usually want private communications for
reasons other than illegal activity.
> I could make the same point you make about POTS instead about
> viewing sendmail log files.
I don't think sendmail should log message contents, including the
subject line. And certainly, sendmail's installation docs should
explain to the sendmail admin exactly what is getting logged. But
squirrelmail's install docs don't say anything about message contents
getting logged. Most people just follow the installation instructions
without checking stuff very carefully, so they can be logging stuff
that they don't want to log. (That happened to me when I first
started using squirrelmail, before I noticed the bug).
> > So, I hope you will think these things through a little more.
>
> Or we agree to disagree...
Well, that's more or less what the squirrelmail maintainers said, but
both you and they are wrong ;-).
Paul Rubin
> For example, where I used to work we sent our web logs to
> an outside company for auditing (it was an e-commerce site).
[OT - Actually I think the above may be wrong, in case anyone is reading
this who cares about what that company was doing. The actual process
was more complicated, and the policy shifted a few times, but we may
have only sent out the results of log analysis that we did in-house.
Anyway, stuff like user login names didn't appear in the http logs.]