On Jan 7, 2008 9:55 PM, Asheesh Laroia <asheesh@asheesh.org> wrote:

On Mon, 7 Jan 2008, Andrew Falanga wrote:

...

I have to admit that I'm not quite sure why no one has responded to me about this one. If I'm not providing enough information or incorrect information please tell me. It's quite important that this e-mail system be working.

Well, I can try to help. In general that's what we'll all do, but we have other things to do in our lives, too. (-:

Zeroth question: Why use virtual users rather than regular-old UNIX users? The regular way requires much less configuration, after all!

Well, that is actually how I got things working. Now that Christmas is past, the church staff is returning to work "full-throttle" and had to have e-mail services. (About three weeks ago, the windoze system they were running died.) As to why to use virtual users, we were wanting to go that route because one thought is to give e-mail accounts to church members who want them. I was thinking that a better way of doing that would be through virtual users.

...

I have created a system user ID called "vmail" which is referenced in my PostgreSQL database for UID/GID stuff. All virtual user home directories and INBOXes are made owner "vmail" and group is "users."

First question:

If you do 'su - vmail -s /bin/sh' you will get a shell running as user vmail. Run 'deliver' with the arguments it takes to deliver to a target user; does mail get delivered?

If not, we better fix that first!

Ok, I will try that ASAP. I don't think that I'll get to it tonight (in fact, I'm sorry for taking so long to respond to this but I couldn't take a free minute at work today to respond). Also, since they're working now, at least through POP, the pressure is off. However, in the near future, I need to get IMAP and SSL working.

...

Originally, I had my sendmail "/etc/mail/aliases" file setup to "map" all mail sent to these virtual users to the system user "vmail." However, none of the virtual users were getting any mail and vmail was just getting swamped. After doing more digging, I found that I just didn't understand the home directories and INBOX, mbox and such. That's what drove me to configuring what's in there now.

...

Now, following directions on this WIKI page: http://wiki.dovecot.org/LDA/Sendmail?highlight=%28deliver%29 I'm still unable to get the e-mail working for them. Continually, sendmail bails with errors saying it, "Can't create output." Because I am using *.mc files, I made a new *.m4 file as directed in /usr/share/sendmail/cf/mailer.

Can you turn up the verbosity from sendmail?

I haven't tried that one yet.

...

Dovecot does allow the virtual users to login. In fact, when I did, the first time, there appears a "mail" directory in their home directories after login. This would indicate to me that the login was successful. Further, I cut/pasted a message sent to one of the virtual users from the vmail INBOX (/var/mail/vmail) into the virtual user's INBOX (/var/mail/jdunkin). Then, logged in as this virtual user and ACTUALLY got the mail. I know this stuff works. What must be done to make sendmail do its thing for deliver?

So it sounds like Dovecot is fine and this is a sendmail question.

We can try to help, but I don't use Sendmail (I do use Dovecot...), so it's not clear that we'll be able to.

I agree with you. I only asked here because I was trying to use the dovecot deliver program, as specified in that wiki page, and I thought that since this applies to everyone using dovecot (mail delivery) you all might know how I need to fix this.

...

What is necessary to fix this situation?

Reply with answers to 0 and 1 and we'll see where we can go.

Andy

-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

On Wed, 9 Jan 2008 11:46:45 -0800 (PST) Asheesh Laroia <asheesh@asheesh.org> wrote:

[snip]

"One thought is to to give e-mail accounts to church members who want them" - that's easy, just run the system adduser command!

In my opinion, fiddling with virtual users is not usually worth the effort. (Now, if you have HUNDREDS OF THOUSANDS of users on one machine, then let's talk!)

Basically - the above is a reason to use 'adduser', not a reason to use virtual users! If I'm wrong, please clarify my understanding.

I really disagree. While I am not familiar with the OP's system, using virtual users with Postfix and Dovecot is really rather trivial once you understand the concept. I would never add a user to a system unless that user actually needed access to the system. It just makes security that much easier and safer. From what I gleam from the OP's post, he simply wants to give members of the group email access.

...

Ok, I will try that ASAP. I don't think that I'll get to it tonight (in fact, I'm sorry for taking so long to respond to this but I couldn't take a free minute at work today to respond). Also, since they're working now, at least through POP, the pressure is off. However, in the near future, I need to get IMAP and SSL working.

Dovecot IMAP just works (tm) if you use system users, for IMAP and POP3 SSL and everything else wonderful. Why fiddle with virtual users when real users are just as good and easier to set up?

Once the virtual framework is in place, adding new users is trivial. In fact, using something like PostfixAdmin can even simplify the entire process.

--

Gerard gerard@seibercom.net

From a certain point onward there is no longer any turning back. That is the point that must be reached.

F. Kafka

On Wed, 9 Jan 2008, Charles Marcus wrote:

On 1/9/2008, Asheesh Laroia (asheesh@asheesh.org) wrote:

...

Basically - the above is a reason to use 'adduser', not a reason to use virtual users! If I'm wrong, please clarify my understanding.

My understanding is using Virtual Users is inherently more secure, since the users do not have system accounts, much less shell accounts.

There should be a straightforward way to set their shell to something that prevents shell login but allows Dovecot login. Then they have their own separate security contexts (i.e., UID), so in the case that Dovecot goes horribly awry each user's data is isolated from the other's.

I believe /bin/false will work for this; since it is not listed in /etc/shells, shell login will fail even with e.g. ssh user@host /bin/sh, but PAM should authorize the user for Dovecot. I would double-check this before using it in production.

-- Asheesh.

-- Life is difficult because it is non-linear.

On Wed, 9 Jan 2008, Gerard wrote:

On Wed, 9 Jan 2008 12:17:22 -0800 (PST) Asheesh Laroia <asheesh@asheesh.org> wrote:

...

On Wed, 9 Jan 2008, Charles Marcus wrote:

...

On 1/9/2008, Asheesh Laroia (asheesh@asheesh.org) wrote:

...

Basically - the above is a reason to use 'adduser', not a reason to use virtual users! If I'm wrong, please clarify my understanding.

My understanding is using Virtual Users is inherently more secure, since the users do not have system accounts, much less shell accounts.

There should be a straightforward way to set their shell to something that prevents shell login but allows Dovecot login. Then they have their own separate security contexts (i.e., UID), so in the case that Dovecot goes horribly awry each user's data is isolated from the other's.

Whether a user is a virtual user or a regular user makes not difference. Their data is still isolated from each other.

Not in the way I was describing:

Let's say some person logs on to your Dovecot-based IMAP service and figures out how to take over Dovecot to read and modify arbitrary files on the system. (Timo, I hope this doesn't happen - but bear with me.) To be clear, Dovecot's imap handler runs as the UNIX UID associated with the user logging in, not root.

In the virtual user setup that the thread starter described, the user shares his UNIX UID with the other virtual users on the system. So he has UNIX permission to read and write other users' mail.

In my setup where you assign separate UIDs to each user, the attacking user can only read/modify the files that he has UNIX filesystem permission to read/modify. That would limit the attacker to only being able to destroy his own mail, unlike the virtual user setup.

Virtual users do not have all of their data jumbled together into one file, which seems to me anyway what you are referring to.

No, I meant filesystem-level permissions. Obviously no one is talking about different users having "all their data jumbled together into one file"; sorry if I wasn't clear.

A virtual user simply does not have a system account, and therefore cannot interact with the system directly.

This has the side-effect of not using UNIX UIDs to isolate the different users' data from each other.

Why give any user who does not require access to a system the possibility of doing so by making them regular users?

Because you can gain the benefit of UNIX filesystem permissions.

Besides, as I stated in a previous post, once in place, adding virtual users is trivial and far safer than adding regular shell accounts.

Imagine these two scenarios:

1. You add a UNIX UID to a system but configure the system to not give that user a login shell.

2. You do not add a new UNIX UID to a system.

The two have the same effect on shells - namely, that no one new can run a shell. That's what I'm saying.

...

I believe /bin/false will work for this; since it is not listed in /etc/shells, shell login will fail even with e.g. ssh user@host /bin/sh, but PAM should authorize the user for Dovecot. I would double-check this before using it in production.

I am not sure what you are trying to describe here. It appears that you are not either.

I am sure what I'm trying to describe here; it's scenario 1. It should be "trivial", just like adding new virtual users, and I believe the above is the way to do it, but again I would double-check because I haven't done this in a while and neglected to keep notes when I did it.

I hope that clears things up. If this is getting off-topic and boring let me know.

-- Asheesh.

-- Different all twisty a of in maze are you, passages little.

On Wed, 9 Jan 2008, Pascal Volk wrote:

Am 09.01.2008 21:43 schrieb Asheesh Laroia:

...

Not in the way I was describing:

Let's say some person logs on to your Dovecot-based IMAP service and figures out how to take over Dovecot to read and modify arbitrary files on the system. (Timo, I hope this doesn't happen - but bear with me.) To be clear, Dovecot's imap handler runs as the UNIX UID associated with the user logging in, not root.

In the virtual user setup that the thread starter described, the user shares his UNIX UID with the other virtual users on the system. So he has UNIX permission to read and write other users' mail.

This will be only the case, if you have a poor™ setup. If the setup is done right, each imap/pop user will have it's on UID. And therefor each imap/pop process will run with the UID from the user.

,--[ ps aux | grep imap | head -n 5 ]-- | 70001 5691 0.0 0.0 2676 1416 ? S 12:45 0:00 imap | 70002 5693 0.0 0.0 2600 1212 ? S 12:45 0:00 imap | 70014 5695 0.0 0.0 2676 1256 ? S 12:45 0:00 imap | 70013 5696 0.0 0.0 2420 1164 ? S 12:45 0:00 imap | 70000 5698 0.0 0.0 2564 1200 ? S 12:45 0:00 imap `--

...

In my setup where you assign separate UIDs to each user, the attacking user can only read/modify the files that he has UNIX filesystem permission to read/modify. That would limit the attacker to only being able to destroy his own mail, unlike the virtual user setup.

...

Virtual users do not have all of their data jumbled together into one file, which seems to me anyway what you are referring to.

No, I meant filesystem-level permissions. Obviously no one is talking about different users having "all their data jumbled together into one file"; sorry if I wasn't clear.

Filesystem-level permissions are also possible with virtual Users:

,--[ ls -l /srv/mail/1/70003 | tail -n 5 ]-- | drwx------ 3 70007 70003 4096 2007-12-31 17:48 70007 | drwx------ 3 70008 70003 4096 2007-10-16 23:07 70008 | drwx------ 3 70009 70003 4096 2007-10-16 23:08 70009 | drwx------ 3 70010 70003 4096 2007-10-16 23:08 70010 | drwx------ 3 70011 70003 4096 2007-12-31 18:19 70011 `--

As they say, I have been schooled. (-:

My apologies - I wasn't aware of these "virtual user with a UID" setups. I was only aware of the "virtual users all share a UID" setup like the thread starter described.

Can you provide a link to documentation on the system that you're describing?

-- Asheesh.

-- Chicken Little only has to be right once.

On Jan 9, 2008 3:24 PM, Pascal Volk <user+dovecot@localhost.localdomain.org> wrote:

Am 09.01.2008 22:51 schrieb Asheesh Laroia:

...

As they say, I have been schooled. (-:

My apologies - I wasn't aware of these "virtual user with a UID" setups. I was only aware of the "virtual users all share a UID" setup like the thread starter described.

What should I say? The Dovecot wiki <http://wiki.dovecot.org/> is very informative. :-)

Very informative yes, but at the same time it seems to make the same mistake all people make when writing documentation. There are many assumptions made that a lot of fundamental knowledge of how mail works is known to the reader. For example, the term "mbox" is simply used. It's not really described anywhere (admittedly, that I could find) what mbox is. It took much looking, and in fact one respondent to my question, a week ago, about what mbox and MAILDIR were, didn't respond with a dovecot wiki page but instead a wikipedia page. This really shouldn't be. This is only meant as constructive criticism, I'm not trying to be condemning here.

Andy

-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

Andrew Falanga, on 1/9/2008 6:02 PM, said the following:

...

What should I say? The Dovecot wiki <http://wiki.dovecot.org/> is very informative. :-)

Very informative yes, but at the same time it seems to make the same mistake all people make when writing documentation. There are many assumptions made that a lot of fundamental knowledge of how mail works is known to the reader. For example, the term "mbox" is simply used. It's not really described anywhere (admittedly, that I could find) what mbox is. It took much looking, and in fact one respondent to my question, a week ago, about what mbox and MAILDIR were, didn't respond with a dovecot wiki page but instead a wikipedia page. This really shouldn't be. This is only meant as constructive criticism, I'm not trying to be condemning here.

No offense, but that is just plain dumb. Have you ever heard of google? It took me all of 10 seconds to find more articles about these two formats than I could read in a week.

Anyone who is setting up a mail server that doesn't at least have a BASIC understanding of the BASIC things that mail servers deal with maybe shouldn't be administering a mail server? Or should at LEAST spend a few weeks LEARNING the basics on their own.

According to your argument, maybe I should complain that Timo didn't define the word 'is' on every page he wrote?

--

Best regards,

Charles

Andrew Falanga wrote:

[snip]

If it's expected that the reader knows what the difference between mbox and MAILDIR is, then a "disclaimer" or sorts should be given at least in the opening page of the wiki. Something like, "It's assumed that the reader has more than a basic understanding of how mail systems work . . ."

did you see http://wiki.dovecot.org/MailServerOverview ?

I agree and I did have more than a basic understanding. Prior to becoming a programmer, I spent 11 years as a network administrator and about 1.5 years of that time was administering e-mail. However, and very unfortunate for me, the extent of my experience working with e-mail for that time was all in Windoze and Exchange. Oh, also a package from IPSWITCH, can't recall now the name,

IMail?

but all of the work was done for me. One of the reasons I've come to resent the Windows world.

why? That's about all I like in windows... (I mean when the work I want is done for me, not the work someone else has decided to do for me ;-p)

but I agree that people who "grew in a windows universe" have a hard time getting behind the windows. not that they don't want to know, but they have no idea where to start. but I disgress...

The flip side is that how else does one gain the experience to do anything without being exposed to it? Very often I've noticed from people who know an attitude of, "Well, you shouldn't be doing this unless you have some idea of what you're doing." The problem is, without doing that thing, they can't have much of an idea of how to do it to begin with.

True, but you need to state this when you ask about something. The reason is that many people don't want to learn: they just want to fix something or know whether they took the right decision... so when they come and ask "I've heard about $foo. what is it and how to do me do?". Then "don't bother" is sometimes the right answer (which you can read it as "that's not very important. you can forget about it.").

also, some areas are more complex than it appears at start. email is one such domain. there are many protocols and standards (smtp, pop, imap, mime, dns, ... etc) and a lot of confusion (how many people do you know who can tell the difference between envelope senders and From headers?)

you are welcome to ask questions, but you need to show your motivation by doing your "home work". you need to look at few places such as wikipedia and google.

Of course, you'll meet what I call "angry" people in public forums (and in real life as well). They will insult you (litterally I mean) and treat you by many names that my mother forbid me to repeat. But up so far, I didn't see such individuals on the dovecot list. and if I can give you an advice: when you meet such people, either pass your way, or try to have fun.

and don't get mad at us. we are just robots (you know Eliza? if not, run Emacs and type "M-x doctor"). Whomever told you that we are real people sitting behind computers lied to you ;-p

-- mouss United Robots of Benetton

On Jan 10, 2008 9:03 AM, Scott Silva <ssilva@sgvwater.com> wrote:

on 1/9/2008 3:02 PM Andrew Falanga spake the following:

...

On Jan 9, 2008 3:24 PM, Pascal Volk < user+dovecot@localhost.localdomain.org> wrote:

...

Am 09.01.2008 22:51 schrieb Asheesh Laroia:

...

As they say, I have been schooled. (-:

My apologies - I wasn't aware of these "virtual user with a UID" setups. I was only aware of the "virtual users all share a UID" setup like the thread starter described. What should I say? The Dovecot wiki <http://wiki.dovecot.org/> is very informative. :-)

Very informative yes, but at the same time it seems to make the same mistake all people make when writing documentation. There are many assumptions made that a lot of fundamental knowledge of how mail works is known to the reader. For example, the term "mbox" is simply used. It's not really described anywhere (admittedly, that I could find) what mbox is. It took much looking, and in fact one respondent to my question, a week ago, about what mbox and MAILDIR were, didn't respond with a dovecot wiki page but instead a wikipedia page. This really shouldn't be. This is only meant as constructive criticism, I'm not trying to be condemning here.

Andy

Anybody setting up something like a mailserver should HAVE the basic knowledge of these things. If you don't know the basics of how e-mail works, you should have someone else set up your system. It is too easy to mis-configure a mail server and have an open relay or a botted system.

There were times I came pretty close to asking for that type of help. Coming into this, I knew of sendmails (or postfix's) role in the mail process, and I knew that POP and IMAP daemons were used by mail clients to actually retrieve mail from the server from a mail client. What I wasn't clear on was how the mail actually ended up into a persons "INBOX." This process was unknown to me. It was educational to me that it was sendmail that handles this. (I must admit, it should have been obvious to me.)

If the dovecot wiki isn't going to explain these things entirely, because it's not dovecot's responsibility to do so, that's fine. Shouldn't the wiki explain, however, that, "Knowledge of what mbox, INBOX, MAILDIR, etc., is assumed. If you don't understand these terms, see (some links)?"

In an ideal world, perhaps, no one would setup a mail server unless they knew how to. The trouble is, this position doesn't take into account that we *DON'T* live in an ideal world. In our world, to know how to do something means you've got to set it up. But to set it up, you've got to be familiar with it, but to be familiar with it, you've got to set it up.

Andy

-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

on 1/10/2008 10:37 AM Brian T Glenn spake the following:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Thu, Jan 10, 2008 at 10:26:05AM -0700, Andrew Falanga may have written:

...

In an ideal world, perhaps, no one would setup a mail server unless they knew how to. The trouble is, this position doesn't take into account that we *DON'T* live in an ideal world. In our world, to know how to do something means you've got to set it up. But to set it up, you've got to be familiar with it, but to be familiar with it, you've got to set it up.

I think that is what testing and lab enviroments are meant to accomplish. The Dovecot Wiki is for information about dovecot. It isn't for people to paste the results of Google searches you think would be helpful. Is it really that foreign of a concept to encounter a term you are not familiar with, copy it into your clipboard, and paste it into Google? I thought that was half of being successful at IT?

I had written something similar, but decided not to send it. My employer pays me fairly well for what I do, and they expect a certain amount of either knowledge, or willingness to obtain that knowledge. I don't expect to find that info in one book, or even 100 books, but it is there and most is free for the taking. But if you don't know how to do something, you either take the time to learn or pay someone else who did. No one is born with this stuff. There isn't a great cosmic knowledgebase that you can channel into to get this, you have to spend some time learning.

Knowledge is like a pyramid. You have to lay the base before you can add levels. And every level depends on the strength of the level below it. You can try to build one from the top, but it won't work very well.

-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!

On 1/10/2008, Andrew Falanga (af300wsm@gmail.com) wrote:

What I wasn't clear on was how the mail actually ended up into a persons "INBOX." This process was unknown to me. It was educational to me that it was sendmail that handles this.

Actually, it is the DELIVERY AGENT that is responsible for 'delivering' mail to the final resting place (Inbox). I have no clue about delivery agents with sendmail, but postfix can use a few different ones (its own standard LDA (Local Delivery Agent) and the VDA (Virtual...), and Maildrop, but I'm sure there are probably more.

If the dovecot wiki isn't going to explain these things entirely, because it's not dovecot's responsibility to do so, that's fine. Shouldn't the wiki explain, however, that, "Knowledge of what mbox, INBOX, MAILDIR, etc., is assumed. If you don't understand these terms, see (some links)?"

Again, this is ridiculous. Each persons level of knowledge is different. The author of a wiki like you describe would have to write to the lowest common denominator - which means he would be authoring a dictionary and a thesaurus all at the same time. Don't you see how ludicrous that is?

In our world, to know how to do something means you've got to set it up. But to set it up, you've got to be familiar with it, but to be familiar with it, you've got to set it up.

So go for it! You have a brain. You have a library somehwere close by. You have bookstores. You have fingers. You have a computer. You have an internet connection. You have google. You have amazon. Now go forth and USE THEM!

:)

--

Best regards,

Charles

on 1/10/2008 1:20 PM Evaggelos Balaskas spake the following:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I don't understand why people always want something more :D

Can you expand on that? ;-P

-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!

on 1/11/2008 10:43 AM Andrew Falanga spake the following:

Hi everybody,

There are a few things that I think I need to explain. Far too many people gave me feedback after my remarks about the dovecot wiki for me to answer all individually. At first, I must admit to some prideful need to lash back for not being understood. This however, would be totally inappropriate and completely worthless. Now, hopefully, I can articulate my thoughts without sounding prideful and egotistical (very hard to do without the added benefit of inflection when talking face to face).

My original statement that sparked this lengthy thread now was really born out of nothing more than my observation of documentation after working five years at HP as a programmer (not as an HP employee though). I have seen, even from my own efforts of writing more documentation than I care to admit to, that inevitably there are things that become so common place to the person writing the doc that they don't even realize they are fundamental to understanding how things work.

Unfortunately, I used as an example, mbox and MAILDIR to make my point. Perhaps this was a bad choice because I felt this same frustration in reading other areas of the wiki. It wasn't that the information was bad, or unusable. I just had questions about how it all fit together for dovecot, and couldn't find the answers on the dovecot site. I don't think it's unreasonable to ask that a particular software program explain how it's pieces fit together, or how it (the software program) is supposed to work with other pieces it makes use of but doesn't directly control.

Now, here comes the other problem. I was in a crunch. The church e-mail system had died, and a replacement was needed ASAP. Originally, I should have had more than adequate time to find my answers. Normally, I do spend much more time trying to find the answers myself. (At this point, I can only ask you to believe that.) I learned a painful lesson in this several years ago while learning OpenBSD. I learned that I really did expect folks to take me by the hand and walk me through. It's something that I've worked hard to overcome, and sometimes still struggle with.

I'm sorry that I reverted, to some degree, to this tendency with this whole dovecot endeavor.

I do have more than a rudimentary understanding of how mail works. After all, I didn't ask everyone to explain IMAP, POP or SMTP to me. Nor did I ask for an explanation for SSL/TLS or other things. Further, I didn't ask any questions here for how to make sendmail do SMTP authentication. Coming into this, I knew that SMTP was the MTA, things like sendmail and postfix did this, while other programs, e.g. dovecot; allow users to login and get mail from the server. An interesting thing for me to ask myself is, "Why did I look up postfix on google, but not mbox?" I didn't know what postfix was and did look that up on Google. When trying to get things working, I was assuming that mbox and maildir was something dovecot implemented itself, not a standard of sorts that dovecot implemented from a standards outline. That's why I thought it strange dovecot didn't define what they did. (Perhaps even why it didn't dawn on me to Google the term.) I must also mention that another respondent did give me a link in the dovecot wiki to an explanation of mbox and so on. I missed that one when doing my research.

In short, I'm sorry that I gave the impression that I assumed dovecot developers and documentation writers should explain every little detail to me. I do not think this, nor was I trying to persuade others that I did think this way. My remark about a disclaimer was taken to an extreme I did not intend. I do think disclaimers on every page is excessive is ridiculous.

In the future, I shall endeavor to look more heavily for the answers before posting, or at least before assuming that no one on this list is willing to help. Thank you to all for the help given.

Andy

Apologies back to you. You unfortunately seemed to look like the ever increasing group of people that have been hitting the lists (at least the 7 or 8 I read) asking very basic questions and wanting someone to give them a complete cover to cover install guide, write and test their config files, and be available for whatever problems that might come up( Maybe a little exaggerated, but it has seemed to get that bad some days). All the while they don't want or are unable to do the basic admin tasks. Sorry again to lump you into that group.

In a crunch like that, why not grab one of the pre-built gateway distros like clarkconnect or sme server. Sure they aren't perfect for everybody, but you can get them up and accepting mail in less than an hour or two. I always keep a cd or two of them for an emergency. I like clark connect, but its free version is limited to 10 e-mail accounts. The negative to me on sme server is it's use of qmail as MTA. But they are complete, and quick to set up.

-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!

On Fri, 2008-01-11 at 11:43 -0700, Andrew Falanga wrote:

Unfortunately, I used as an example, mbox and MAILDIR to make my point. Perhaps this was a bad choice because I felt this same frustration in reading other areas of the wiki. It wasn't that the information was bad, or unusable. I just had questions about how it all fit together for dovecot, and couldn't find the answers on the dovecot site. I don't think it's unreasonable to ask that a particular software program explain how it's pieces fit together, or how it (the software program) is supposed to work with other pieces it makes use of but doesn't directly control.

I think there are two problems with the wiki:

1. There's no clear beginning and ending as in a book. The mbox and maildir terms are explained in wiki, but you just didn't notice those pages. If it had been a book, they would have been in the first few chapters, and you probably would have noticed them.

2. Although there is http://wiki.dovecot.org/MailServerOverview it still doesn't explain everything. Also it could probably use a couple of headlines in the middle to make it easier to read. So explaining more about how things fit together would be useful, but I'm not sure where I should write about that or even what exactly I should write about.

Maybe a separate DovecotOverview page that tries to explain what parts Dovecot consists of and what different ways there are to set up a new mail server..

Pascal Volk wrote:

Am 09.01.2008 21:43 schrieb Asheesh Laroia:

...

Not in the way I was describing:

Let's say some person logs on to your Dovecot-based IMAP service and figures out how to take over Dovecot to read and modify arbitrary files on the system. (Timo, I hope this doesn't happen - but bear with me.) To be clear, Dovecot's imap handler runs as the UNIX UID associated with the user logging in, not root.

if there's a bug in dovecot that allows this, then there will also be bugs that give the whole server to the attacker...

...

In the virtual user setup that the thread starter described, the user shares his UNIX UID with the other virtual users on the system. So he has UNIX permission to read and write other users' mail.

This will be only the case, if you have a poor™ setup.

poor? come on!

If the setup is done right, each imap/pop user will have it's on UID. And therefor each imap/pop process will run with the UID from the user.

using different uids means that the delivery agent needs some privilege to write to the mailboxes. In general, this is achieved by making the MDA suid.

and since we are talking about possible bugs, what do you think are the consequences of potential bugs in the MDA if it is suid?

Note that using different uids with virtual users don't bring much. one needs to make sure there is no uid collision with unix users (which means you must make sure adduser doesn't create an account with a uid used by a virtual mailbox). the only thing it brings is that the uid has no "name" and can't login.

I have found that a single uid/gid have many benefits. for example, the same uid is used to retrain spamassassin.

Timo Sirainen wrote:

On Thu, 2008-01-10 at 09:32 +0100, mouss wrote:

...

Pascal Volk wrote:

...

Am 09.01.2008 21:43 schrieb Asheesh Laroia:

...

Not in the way I was describing:

Let's say some person logs on to your Dovecot-based IMAP service and figures out how to take over Dovecot to read and modify arbitrary files on the system. (Timo, I hope this doesn't happen - but bear with me.) To be clear, Dovecot's imap handler runs as the UNIX UID associated with the user logging in, not root. if there's a bug in dovecot that allows this, then there will also be bugs that give the whole server to the attacker...

Why? The mail handling code in Dovecot is the most complex one, so it's most likely to have bugs.

True. I was just trying to say that things aren't as simple as "using a single uid is bad". As usuaul, there are tradeoffs. and IMHO from a security perspective, the damages caused in the case of a single uid/gid are low compared to those (less probable but still) caused by the use of privileged programs.

with a single uid/gid, it is possible to run the whole server as that same user, chrooted in the mailstore base. Admittedly, the server has access to other people's mail. (A possible workaround would be to run privileged and once a user has authenticated, to chroot to the mailbox location. not sure this is "reasonable" though!).

...

...

If the setup is done right, each imap/pop user will have it's on UID. And therefor each imap/pop process will run with the UID from the user.

using different uids means that the delivery agent needs some privilege to write to the mailboxes. In general, this is achieved by making the MDA suid.

and since we are talking about possible bugs, what do you think are the consequences of potential bugs in the MDA if it is suid?

I do agree that setuid binaries are bad and hopefully one day Dovecot has LMTP server and there's no need for setuid-deliver.

but even then, it will need to run with privileges to be able to write to people's mailboxes. I however agree that the privileges can be droped before complex code is executed.

But even then the recommended way to set up setuid-deliver is to place it in a directory where only MTA can execute it, and again the (most complex) mail handling code is execute only after all the permissions have been dropped.

...

Note that using different uids with virtual users don't bring much. one needs to make sure there is no uid collision with unix users (which means you must make sure adduser doesn't create an account with a uid used by a virtual mailbox). the only thing it brings is that the uid has no "name" and can't login.

It's more complex to set up, but it also does limit the damage that security holes can do. Two of the four security holes found from Dovecot already were completely prevented if each user used their own UID.

Or if you're just arguing about multiple UIDs for virtual users vs. using system users (I just quickly scanned through this thread), then I don't see much of a difference. From Dovecot's point of view there's none.

in the last paragraph, I was comparing virtual users with different uids to unix users.

On Tue, 08 Jan 2008 06:52:53 -0500 Charles Marcus <CMarcus@Media-Brokers.com> wrote:

Andrew Falanga, on 1/7/2008 11:18 PM, said the following:

...

What must be done to make sendmail do its thing for deliver?

I don't think its because anyone is snubbing you... ;)

I think one of the reasons is not as many people use sendmail anymore

• I wouldn't have a clue... sorry...

I have to concur with that assessment. If you were to use Postfix, I believe you would get a lot better results. BTW, the stable release of Postfix 2.5 is scheduled for release at the end of this month according to what I have seen on the Postfix forum. I have used the beta versions and it works quite well.

Just my 2¢.

--

Gerard gerard@seibercom.net

Tip of the Day: Never fry bacon in the nude.

On Jan 8, 2008 6:01 AM, Peter Eriksson <peter@ifm.liu.se> wrote:

...

...

Andrew Falanga, on 1/7/2008 11:18 PM, said the following:

...

What must be done to make sendmail do its thing for deliver?

I use Dovecot in conjunction with Sendmail with Maildirs as the mail store and it works fine. We use "procmail" as the local delivery agent though.

Stuff in the sendmail config file:

   define(`PROCMAIL_MAILER_PATH', `/ifm/bin/procmail')
   FEATURE(local_procmail)

Users mail store is mounted as /home/$USER/Maildir and with an procmail config file (/etc/procmailrc) like this:

   # procmailrc
   PATH=/bin:/usr/bin:/usr/local/bin
   MAILDIR=$HOME/Maildir
   DEFAULT=$HOME/Maildir/

I should some day investigate on how to use Dovecots own local delivery agent...

• Peter

Peter,

You have no idea how much I appreciate this posting. I installed procmail last night, but couldn't find any reliable information on how to integrate it into my sendmail system. This is most helpful. Just out of curiosity, would you know how difficult it would be to configure for mbox? I noticed that this seems to be what FreeBSD defaults to and I'd like to minimize my own heartache when getting procmail setup.

Thanks again, Andy

-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

On Jan 10, 2008 4:55 AM, mouss <mlist.only@free.fr> wrote:

Andrew Falanga wrote:

...

You have no idea how much I appreciate this posting. I installed

procmail

...

last night, but couldn't find any reliable information on how to integrate it into my sendmail system. This is most helpful. Just out of curiosity, would you know how difficult it would be to configure for mbox? I noticed that this seems to be what FreeBSD defaults to and I'd like to minimize my own heartache when getting procmail setup.

a trailing slash means maildir ('/foo/bar/'). no trailing slash means mbox ('/foo/bar').

That said, FreeBSD or others don't care what format you use. the system will stay happy even if you use maildir :) so reconsider your position and take the time to check which format you should use. I say this because moving from one format to another will be harder once you have a lot of mail to convert (it's still feasible, but...).

I was afraid of this. I've never actually setup e-mail from this perspective before. There was quite a learning curve.

-- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?

At 6:52 AM -0500 1/8/08, Charles Marcus wrote:

Andrew Falanga, on 1/7/2008 11:18 PM, said the following:

...

What must be done to make sendmail do its thing for deliver?

I don't think its because anyone is snubbing you... ;)

I think one of the reasons is not as many people use sendmail anymore - I wouldn't have a clue... sorry...

I think it is more a matter of this sounding very much like strictly a Sendmail problem posed in the wrong forum for Sendmail problems, further weakened by the inclusion of no details about the specific nature of the problem or the existing configuration. A well-posed question (e.g. with log and config info) to a more suitable forum (e.g. comp.mail.sendmail) would almost surely get more response.

To some degree it probably also involves the fact that the Dovecot LDA is still something of a novelty, and it not as widely used as the traffic on this list might lead one to believe. The Dovecot LDA does not provide enough of a compelling feature set to overpower the inertia of sticking with the standard delivery agent(s). That's not specific to Sendmail.

-- Bill Cole
bill@scconsult.com

At 8:33 PM -0700 1/8/08, Andrew Falanga wrote:

On Jan 8, 2008 7:31 AM, Bill Cole <dovecot-20061108@billmail.scconsult.com> wrote:

...

At 6:52 AM -0500 1/8/08, Charles Marcus wrote:

...

Andrew Falanga, on 1/7/2008 11:18 PM, said the following:

...

What must be done to make sendmail do its thing for deliver?

I don't think its because anyone is snubbing you... ;)

I think one of the reasons is not as many people use sendmail anymore - I wouldn't have a clue... sorry...

I think it is more a matter of this sounding very much like strictly a Sendmail problem posed in the wrong forum for Sendmail problems, further weakened by the inclusion of no details about the specific nature of the problem or the existing configuration. A well-posed question (e.g. with log and config info) to a more suitable forum (e.g. comp.mail.sendmail) would almost surely get more response.

Ok, that's constructive. If I'm not posting enough data, please tell me. I'll get you what you need. I thought I was being quite verbose (please see some of the other posts too), but if the information isn't enough I need to know. Silence doesn't help anyone.

As I said: this looks like a Sendmail configuration and behavior problem, so your Sendmail config (probably just the mailer definition) and relevant log entries from Sendmail would be essential to know what is or is not happening. Configuration details and log entries are essential in any case, as are precise descriptions of *how* something fails instead of just a statement *that* it fails.

And also repeating: I don't think this is the best place for you to find answers for what looks likely to be a Sendmail configuration problem. As Charles' comment points up, there are not a lot of Sendmail admins on this list. I have been running Sendmail systems for well over a decade, and expect to do so for a little while to come yet, but I don't use Dovecot with Sendmail. On the Postfix+Dovecot system I run, I don't use the Dovecot LDA. I don't recall anyone discussing the use of the Dovecot LDA with Sendmail here. The best analog to this list for Sendmail problems is the Usenet newsgroup comp.mail.sendmail, and I expect that would be the best place for you to get help IF you provide the essential information about your problem.

...

To some degree it probably also involves the fact that the Dovecot LDA is still something of a novelty, and it not as widely used as the traffic on this list might lead one to believe. The Dovecot LDA does not provide enough of a compelling feature set to overpower the inertia of sticking with the standard delivery agent(s). That's not specific to Sendmail.

I didn't realize this. With the wiki page on how to set it up, I figured that I should be using this.

What you *should* be running is a local question: you have to answer it based on what you need. The Dovecot IMAP/POP server is very solid *without* the LDA component, and works reasonably well with mailboxes fed by MTA standard delivery agents.

Bill Cole bill@scconsult.com