Re: [Dovecot] Are host names a secret?
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
Re: [Dovecot] Are host names a secret?
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. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Are host names a secret?
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
Re: [Dovecot] Problems with Expire Plugin
On Fri, 2009-07-17 at 00:07 +0200, Robert Schetterer wrote: > Timo Sirainen schrieb: > > I'm getting tired of explaining again and again how expire plugin is > > supposed to work, so I added now Example #1 timeline and Example #2 > > timeline to http://wiki.dovecot.org/Plugins/Expire which tell exactly > > what is supposed to happen with a couple of examples. Do they finally > > help understanding how exactly things are supposed to work? > > Hi Timo, your examples are well to understand, > i ve tested the mysql setup also using ... --test > everything looks fine and works as it should but > mails dont get deleted, Then everything doesn't look fine and work.. What exactly do you have in the database and what exactly does --test say? > Anyway the time should be set more shortly for testing > waiting 1 day minimum isnt really fun You could try it in a test machine and just use "date --set". That's how I made the wiki examples. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Problems with Expire Plugin
Timo Sirainen schrieb: > I'm getting tired of explaining again and again how expire plugin is > supposed to work, so I added now Example #1 timeline and Example #2 > timeline to http://wiki.dovecot.org/Plugins/Expire which tell exactly > what is supposed to happen with a couple of examples. Do they finally > help understanding how exactly things are supposed to work? Hi Timo, your examples are well to understand, i ve tested the mysql setup also using ... --test everything looks fine and works as it should but mails dont get deleted, i am testing this with 1.2.1 since a few days, any hint what to search for in the logs to find out whats going wrong ? Anyway the time should be set more shortly for testing waiting 1 day minimum isnt really fun > > Unfortunately X-SAVEDATE doesn't work with current 1.2 versions, because > of a bug. If you want to look at them, you can apply this patch to > v1.2.1: http://hg.dovecot.org/dovecot-1.2/rev/f353c5b71097 > > On Fri, 2009-07-10 at 10:58 -0500, Jose Luis Marin Perez wrote: >> Dear Timo, >> >> As I understand with regard to Expire plugin is marking the folder will >> be deleted in a certain amount of days and that the deletion is >> performed by expire-tool >> >> Expire plugin works correctly, and >> I can check on the database folder has been marked, the problem is with >> expire-tool as it does the deletion. >> >> This is intended to expire Expire Plugin-tool? >> >> Please require your help to solve this problem. >> >> I apologize for my low level of knowledge about these issues, but what >> interests me is to learn. >> >> Thanks >> >> Jose Luis >> >>> From: jolumape...@hotmail.com >>> To: t...@iki.fi >>> Date: Thu, 9 Jul 2009 14:18:28 -0500 >>> CC: dovecot@dovecot.org >>> Subject: Re: [Dovecot] Problems with Expire Plugin >>> >>> >>> Dear Timo >>> >>> I have set up crontab to run the tool expires at midnight >>> >>> When running with the --test option: >>> >>> Info: User lookup failed: jma...@sistemasunidos.com >>> Info: jma...@sistemasunidos.com/INBOX.Papelera: no messages left >>> >>> When running without the --test option: >>> >>> Does not leave any message and there are no data in the table expires of >>> Mysql >>> >>> I reviewed the Trash folder and still holds the emails. >>> >>> >>> It should be noted that for purposes of the test today I sent two >>> emails and copied to the Papelera folder so that after executing the >>> end-tool should be removed >>> >>> Thanks >>> >>> Jose Luis >>> Subject: Re: [Dovecot] Problems with Expire Plugin From: t...@iki.fi To: jolumape...@hotmail.com CC: dovecot@dovecot.org Date: Thu, 9 Jul 2009 14:57:19 -0400 On Thu, 2009-07-09 at 12:12 -0500, Jose Luis Marin Perez wrote: > Now my problem is with expire-tool because it is not deleting the > emails in the folder that has been marked by Expire Plugin. Did you read how exactly it works? http://wiki.dovecot.org/Plugins/Expire > This is the command that I run through crontab: > > /usr/local/sbin/dovecot --exec-mail ext > /usr/local/libexec/dovecot/expire-tool Giving --test parameter shows what it's really doing. > | jma...@sistemasunidos.com/INBOX.Papelera | 1247162400 | 1247162400 = Thu Jul 9 18:00:00 UTC 2009 So it should have started checking and expunging oldest message(s) from this mailbox about an hour ago (as of when I'm writing this mail). >>> _ >>> News, entertainment and everything you care about at Live.com. Get it now! >>> http://www.live.com/getstarted.aspx >> _ >> Explore the seven wonders of the world >> http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Are host names a secret?
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. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Are host names a secret?
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 -=- g...@telenet.be -=- PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages! pgpkoCQJN7dXO.pgp Description: PGP signature
[Dovecot] Are host names a secret?
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? signature.asc Description: This is a digitally signed message part
[Dovecot] Problem with virtual mailboxes (was Sylpheed-claws and virtual mailboxes)
Turns out that both mulberry (linux+win xp) and kmail (1.11.2) do fail
to recognize the virtual mailbox too.
thomas
On Thu, 16 Jul 2009 11:00 +0200, "Thomas Berker" wrote:
> Hi!
> Has someone encountered the following problem? What am I doing wrong or
> does someone know a workaround?
>
> Dovecot 1.2.1 on Debian unstable, two namespaces:
>
> namespace private {
>prefix =
>location = maildir:~/res/Maildir:LAYOUT=fs
>inbox = yes
>list = yes
> }
>
> namespace private {
>prefix = gtd/
>separator = /
>list = yes
>location = virtual:~/res/Maildir/gtd:LAYOUT=fs:INBOX=~/res/Maildir/gtd
> }
>
> The problem:
> cur, tmp, new maildir folders get created within the folder gtd when it
> is opened by Sylpheed-claws (3.7.1). Subfolders in gtd holding the
> dovecot-virtual files are not recognised as mail folders at all, they
> show up but do nothing.
>
> Other clients (I have tested thunderbird, evolution) work as expected:
> they show the folder gtd and the sub-folders perform searches.
>
> Thanks in advance,
> tb
>
--
Thomas Berker, NTNU, Trondheim, Norway
Fax: +47-735-91327
Office phone: +47-735-51031
Mobile phone: +47-92434811
Re: [Dovecot] user unknown with deliver
On 16.07.2009 16:35, Nikolay Shopik wrote:
I'm getting user unknown when trying to deliver to Sent folder messages.
My master.cf part is:
copy2sent unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d
${sasl_username} -m Sent
But it still won't work. I'm running 1.0.15
pluto postfix/pipe[30934]: 7470890C4DA: to=,
relay=copy2sent, delay=0.03, delays=0.02/0/0/0.01, dsn=5.1.1,
status=bounced (user unknown)
Find root cause, problem was in proxy_filter (amavisd-new), which
injected between smtp and deliver.
Re: [Dovecot] user unknown with deliver
On 16.07.2009 18:11, Rainer Frey wrote:
Are the failing users actually authenticated, or maybe permitted by
mynetworks? in this case ${sasl_username} would be empty.
Other thought: how is the transport used? Perhaps postfix needs a valid
recipient map for the delivery to this transport.
They are because I seen such records when user sends an email
sasl_method=CRAM-MD5, sasl_username=sho...@inblock.ru
Transport is simple file:
bcc.inblock.ru copy2sent
I'm doing blind carbon copy to b...@bcc.inblock.ru, this is how copy2sent
invoked.
Probably you are right, will go ahead and ask in postfix mailing list.
Re: [Dovecot] user unknown with deliver
On 7/16/2009, Nikolay Shopik (sho...@inblock.ru) wrote:
> dovecot unix - n n - - pipe
> flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d
> ${recipient}
> dov_loc unix - n n - - pipe
> flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -m Pub/${mailbox}
> copy2sent unix - n n - - pipe
> flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${sender} -m
> Sent
So how does copy2sent get invoked?
And what is dov_loc for?
Sorry if I'm asking stupid questions... I want to understand this...
--
Best regards,
Charles
Re: [Dovecot] E-Mail Encryption
Some companies and governments in the United States at least have very strict policy requirements regarding various aspects of security and encryption. Transit encryption (ssl/tls from MTA to MTA) and local encryption of messages sometimes is a requirement if you want to be able to bid on government contracts. https://www.bidsync.com/DPX?ac=view&auc=158380 This example is not for hosting mail but for an anti-spam/anti-virus service (they refer to it as email hygiene) that required message encryption on the transit MTA servers disk as well as tls/ssl for MTA to MTA encryption. So this example does not apply directly to Dovecot but it does show there are needs for this level of encryption in general for various customers. -Original Message- From: dovecot-bounces+jkrejci=usinternet@dovecot.org [mailto:dovecot-bounces+jkrejci=usinternet@dovecot.org] On Behalf Of Tom Hendrikx Sent: Thursday, July 16, 2009 2:47 AM To: Thomas Cc: dovecot@dovecot.org Subject: Re: [Dovecot] E-Mail Encryption Thomas schreef: > Arkadiusz Miskiewicz wrote: >> On Wednesday 15 of July 2009, Patrick Domack wrote: >>> The only benefit this would being, is email being saved on the server >>> would be encrypted. Otherwise it offers no protection. >>> >>> I guess if you paranoid that the system admin might read your emails, >>> but then, he can just as easily read them as they come in or out of >>> the system. >> >> Actually such encryption is interesting as a protection in case when >> someone steals server hardware/disks. > > It could be a feature. Why not. > But I'd say that's might be a better idea to encrypt the filesystem. > But... why not if you have time to code it :) > > Cheers, > Thomas When you have to worry about unauthorized persons having physical access to your hardware, you're solving the wrong problem. Encryption would add only false security because the person could also pop some sniffer device onto your NIC connection that reads wire traffic... The "de/encryption in deliver" concept is interesting, but imho not much use in real life. hard disk encryptoin would be much easier though (i.e. off-the-shelve). But I think these tin foil hat ideas get a little off-topic:) -- Tom
Re: [Dovecot] user unknown with deliver
Charles Marcus wrote:
On 7/16/2009 9:38 AM, Nikolay Shopik wrote:
I'm using GMAIL style saving sent items automatically, so email don't
send twice to server. First when sending via smtp, second when MUA
saving it to IMAP sent folder.
Hmmm... interesting idea...
Are you having trouble with a working config after an upgrade? Or are
you still in the process of trying to get it to work?
Well its working if email address and authentication name are same and I
use such command line:
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${sender}
-m Sent
I can't say its Dovecot problem, I'm just curious if that problem of
Dovecot or I should post this to Postfix mailing list.
Care to share your configs (bothe dovecot and postfix sides) to make
this work after *sending* an email? Since LDA is generally not invoked
for sending/outbound, I'm curious how you invoke it?
Nothing fancy.
# 1.0.15: /etc/dovecot/dovecot.conf
log_path: /var/log/dovecot.log
protocols: imap
ssl_ca_file: /etc/postfix/ca.crt
ssl_cert_file: /etc/postfix/chained.pem
ssl_key_file: /etc/postfix/mail.inblock.ru.key
login_dir: /var/run/dovecot/login
login_executable: /usr/lib/dovecot/imap-login
login_greeting_capability: yes
mail_location: maildir:/var/mail/store/%u
dotlock_use_excl: yes
maildir_copy_with_hardlinks: yes
namespace:
type: public
separator: /
prefix: Pub/
location: maildir:/var/mail/public
namespace:
type: private
separator: /
inbox: yes
auth default:
mechanisms: PLAIN CRAM-MD5
passdb:
driver: passwd-file
args: /etc/dovecot/passwd
userdb:
driver: static
args: uid=vmail gid=vmail home=/var/mail/store/%u
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 438
user: root
group: root
postfix master.cf
smtp inet n - - - - smtpd
submission inet n - - - - smtpd
# -o smtpd_enforce_tls=yes
# -o smtpd_sasl_auth_enable=yes
-o sender_bcc_maps=hash:/etc/postfix/sender_bcc
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
#smtps inet n - - - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
# -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#628 inet n - - - - qmqpd
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f
${sender} -d ${recipient}
dov_loc unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -m
Pub/${mailbox}
copy2sent unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d
${sender} -m Sent
pickupfifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - - 300 1 oqmgr
tlsmgrunix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounceunix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verifyunix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
smtp unix - - - - - smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix - - - - - smtp
-o smtp_fallback_relay=
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - - - - lmtp
anvil unix - - - - 1 anvil
scacheunix - - - - 1 scache
postfix main.cf - is kinda huge share only dovecot related part
transport_maps = hash:/etc/postfix/transport
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_authenticated_header = yes
dovecot_destination_recipient_limit = 1
virtual_transport = dovecot
virtual_mailbox_domains = inblock.ru
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
#copy2sent
sender_bcc_maps = hash:/etc/postfix/sender_bcc
Re: [Dovecot] user unknown with deliver
On Thursday 16 July 2009 15:38:25 Nikolay Shopik wrote:
> Charles Marcus wrote:
> > On 7/16/2009 9:16 AM, Nikolay Shopik wrote:
> >> I'm using GMAIL style saving sent items automatically, so email don't
> >> send twice to server. First when sending via smtp, second when MUA
> >> saving it to IMAP sent folder.
> >
> > Hmmm... interesting idea...
> >
> > Are you having trouble with a working config after an upgrade? Or are
> > you still in the process of trying to get it to work?
>
> Well its working if email address and authentication name are same and I
> use such command line:
> flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${sender}
> -m Sent
Are the failing users actually authenticated, or maybe permitted by
mynetworks? in this case ${sasl_username} would be empty.
Other thought: how is the transport used? Perhaps postfix needs a valid
recipient map for the delivery to this transport.
> I can't say its Dovecot problem, I'm just curious if that problem of
> Dovecot or I should post this to Postfix mailing list.
I guess it needs to be fixed in postfix configuration.
Rainer
Re: [Dovecot] user unknown with deliver
On 7/16/2009 9:38 AM, Nikolay Shopik wrote:
>>> I'm using GMAIL style saving sent items automatically, so email don't
>>> send twice to server. First when sending via smtp, second when MUA
>>> saving it to IMAP sent folder.
>> Hmmm... interesting idea...
>>
>> Are you having trouble with a working config after an upgrade? Or are
>> you still in the process of trying to get it to work?
> Well its working if email address and authentication name are same and I
> use such command line:
> flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${sender}
> -m Sent
>
> I can't say its Dovecot problem, I'm just curious if that problem of
> Dovecot or I should post this to Postfix mailing list.
Care to share your configs (bothe dovecot and postfix sides) to make
this work after *sending* an email? Since LDA is generally not invoked
for sending/outbound, I'm curious how you invoke it?
--
Best regards,
Charles
Re: [Dovecot] user unknown with deliver
Charles Marcus wrote:
On 7/16/2009 9:16 AM, Nikolay Shopik wrote:
I'm getting user unknown when trying to deliver to Sent folder messages.
? Why are you delivering to Sent folder?
It is the responsibility of the mail Client - not Deliver - to place a
copy of sent messages in the Sent folder.
I'm using GMAIL style saving sent items automatically, so email don't
send twice to server. First when sending via smtp, second when MUA
saving it to IMAP sent folder.
Hmmm... interesting idea...
Are you having trouble with a working config after an upgrade? Or are
you still in the process of trying to get it to work?
Well its working if email address and authentication name are same and I
use such command line:
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${sender}
-m Sent
I can't say its Dovecot problem, I'm just curious if that problem of
Dovecot or I should post this to Postfix mailing list.
Re: [Dovecot] user unknown with deliver
On 7/16/2009 9:16 AM, Nikolay Shopik wrote: >>> I'm getting user unknown when trying to deliver to Sent folder messages. >> ? Why are you delivering to Sent folder? >> >> It is the responsibility of the mail Client - not Deliver - to place a >> copy of sent messages in the Sent folder. > I'm using GMAIL style saving sent items automatically, so email don't > send twice to server. First when sending via smtp, second when MUA > saving it to IMAP sent folder. Hmmm... interesting idea... Are you having trouble with a working config after an upgrade? Or are you still in the process of trying to get it to work? -- Best regards, Charles
Re: [Dovecot] user unknown with deliver
Charles Marcus wrote: On 7/16/2009 8:35 AM, Nikolay Shopik wrote: I'm getting user unknown when trying to deliver to Sent folder messages. ? Why are you delivering to Sent folder? It is the responsibility of the mail Client - not Deliver - to place a copy of sent messages in the Sent folder. I'm using GMAIL style saving sent items automatically, so email don't send twice to server. First when sending via smtp, second when MUA saving it to IMAP sent folder.
[Dovecot] Sylpheed-claws and virtual mailboxes
Hi!
Has someone encountered the following problem? What am I doing wrong or
does someone know a workaround?
Dovecot 1.2.1 on Debian unstable, two namespaces:
namespace private {
prefix =
location = maildir:~/res/Maildir:LAYOUT=fs
inbox = yes
list = yes
}
namespace private {
prefix = gtd/
separator = /
list = yes
location = virtual:~/res/Maildir/gtd:LAYOUT=fs:INBOX=~/res/Maildir/gtd
}
The problem:
cur, tmp, new maildir folders get created within the folder gtd when it
is opened by Sylpheed-claws (3.7.1). Subfolders in gtd holding the
dovecot-virtual files are not recognised as mail folders at all, they
show up but do nothing.
Other clients (I have tested thunderbird, evolution) work as expected:
they show the folder gtd and the sub-folders perform searches.
Thanks in advance,
tb
Re: [Dovecot] user unknown with deliver
On 7/16/2009 8:35 AM, Nikolay Shopik wrote: > I'm getting user unknown when trying to deliver to Sent folder messages. ? Why are you delivering to Sent folder? It is the responsibility of the mail Client - not Deliver - to place a copy of sent messages in the Sent folder. -- Best regards, Charles
[Dovecot] user unknown with deliver
I'm getting user unknown when trying to deliver to Sent folder messages.
My master.cf part is:
copy2sent unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d
${sasl_username} -m Sent
But it still won't work. I'm running 1.0.15
pluto postfix/pipe[30934]: 7470890C4DA: to=,
relay=copy2sent, delay=0.03, delays=0.02/0/0/0.01, dsn=5.1.1,
status=bounced (user unknown)
Re: [Dovecot] E-Mail Encryption
On Thu, 16 Jul 2009, Tom Hendrikx wrote: Thomas schreef: Arkadiusz Miskiewicz wrote: On Wednesday 15 of July 2009, Patrick Domack wrote: The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection. Actually such encryption is interesting as a protection in case when someone steals server hardware/disks. It could be a feature. Why not. But I'd say that's might be a better idea to encrypt the filesystem. But... why not if you have time to code it :) If someone manages to steal hardware, there nothing would stop such person from simply starting the system. And since system will rather start up automatically, the disk(s) would be decrypted. Correct me if I'm wrong. When you have to worry about unauthorized persons having physical access to your hardware, you're solving the wrong problem. Encryption would add only false security because the person could also pop some sniffer device onto your NIC connection that reads wire traffic... But it would be a great option for maintaining a mail system for any corporation - usually management-level users are paranoid about someone reading their emails... The only problem is, that in such situation passwords should not be stored in plaintext... The "de/encryption in deliver" concept is interesting, but imho not much use in real life. hard disk encryptoin would be much easier though (i.e. off-the-shelve). But I think these tin foil hat ideas get a little off-topic:) As I say - hard disk encryption does not solve problem when someone steals the hardware, does not help when your clients are paranoid :) Best regards, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.
Re: [Dovecot] E-Mail Encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 16, 2009 at 12:51:32AM -0700, Seth Mattinen wrote: [...] > Encrypting with a public key is completely reasonable, but for proper > security, the decryption should only take place on the client's trusted > workstation with their private key. Hear, hear! Let me state it again: nothing is gained with server-side *de*cryption which can't be achieved more easily with disk encryption. Werver-side encryption is another thing... Yes, Seth, I'm just paraphrasing you, but this is so important (and often forgotten) that it cannot be over-emphasised. And the infrastructure for that is already there: gpg-encrypt every mail on delivery with the users public key. The user's MUA should take care of the rest. Alas, (server-side) full text search goes out of the window with that (unless there is a clever scheme to do some indexing without giving away too much info, but there I reached the limit of my knowledge :) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKXvyMBcgs9XrR2kYRAijYAJ4nIteX/70MmvpEIeHILbqNictHjACeLAv+ xzTTkbTbhGUdG9HYDItXioI= =JstP -END PGP SIGNATURE-
Re: [Dovecot] E-Mail Encryption
On Thu, Jul 16, 2009 at 09:06:19AM +0200, Arkadiusz Miskiewicz (ar...@maven.pl) wrote: > On Wednesday 15 of July 2009, Patrick Domack wrote: > > The only benefit this would being, is email being saved on the server > > would be encrypted. Otherwise it offers no protection. > > > > I guess if you paranoid that the system admin might read your emails, > > but then, he can just as easily read them as they come in or out of > > the system. > > Actually such encryption is interesting as a protection in case when someone > steals server hardware/disks. Or when the regular, trustworthy sysadmin is temporarily replaced by a crook or is blackmailed or is overridden by a pointy-haired boss. Indeed it might be valuable protection for the sysadmin who doesn't want to compromise other people's mail: no need to refuse orders when you *can't* read them. (New mails can of course still be intercepted as noted, but that doesn't mean protecting old stuff isn't useful.) Anyway, this can be done with procmail as well, but a dovecot plugin might be more convenient. -- Tapani Tarvainen
Re: [Dovecot] E-Mail Encryption
Tom Hendrikx wrote: > Thomas schreef: >> Arkadiusz Miskiewicz wrote: >>> On Wednesday 15 of July 2009, Patrick Domack wrote: The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection. I guess if you paranoid that the system admin might read your emails, but then, he can just as easily read them as they come in or out of the system. >>> Actually such encryption is interesting as a protection in case when >>> someone steals server hardware/disks. >> It could be a feature. Why not. >> But I'd say that's might be a better idea to encrypt the filesystem. >> But... why not if you have time to code it :) >> >> Cheers, >> Thomas > > When you have to worry about unauthorized persons having physical access > to your hardware, you're solving the wrong problem. Encryption would add > only false security because the person could also pop some sniffer > device onto your NIC connection that reads wire traffic... > > The "de/encryption in deliver" concept is interesting, but imho not much > use in real life. hard disk encryptoin would be much easier though (i.e. > off-the-shelve). But I think these tin foil hat ideas get a little > off-topic:) > Encrypting with a public key is completely reasonable, but for proper security, the decryption should only take place on the client's trusted workstation with their private key. ~Seth
Re: [Dovecot] E-Mail Encryption
Thomas schreef: > Arkadiusz Miskiewicz wrote: >> On Wednesday 15 of July 2009, Patrick Domack wrote: >>> The only benefit this would being, is email being saved on the server >>> would be encrypted. Otherwise it offers no protection. >>> >>> I guess if you paranoid that the system admin might read your emails, >>> but then, he can just as easily read them as they come in or out of >>> the system. >> >> Actually such encryption is interesting as a protection in case when >> someone steals server hardware/disks. > > It could be a feature. Why not. > But I'd say that's might be a better idea to encrypt the filesystem. > But... why not if you have time to code it :) > > Cheers, > Thomas When you have to worry about unauthorized persons having physical access to your hardware, you're solving the wrong problem. Encryption would add only false security because the person could also pop some sniffer device onto your NIC connection that reads wire traffic... The "de/encryption in deliver" concept is interesting, but imho not much use in real life. hard disk encryptoin would be much easier though (i.e. off-the-shelve). But I think these tin foil hat ideas get a little off-topic:) -- Tom signature.asc Description: OpenPGP digital signature
Re: [Dovecot] E-Mail Encryption
Arkadiusz Miskiewicz wrote: On Wednesday 15 of July 2009, Patrick Domack wrote: The only benefit this would being, is email being saved on the server would be encrypted. Otherwise it offers no protection. I guess if you paranoid that the system admin might read your emails, but then, he can just as easily read them as they come in or out of the system. Actually such encryption is interesting as a protection in case when someone steals server hardware/disks. It could be a feature. Why not. But I'd say that's might be a better idea to encrypt the filesystem. But... why not if you have time to code it :) Cheers, Thomas
Re: [Dovecot] E-Mail Encryption
On Wednesday 15 of July 2009, Patrick Domack wrote: > The only benefit this would being, is email being saved on the server > would be encrypted. Otherwise it offers no protection. > > I guess if you paranoid that the system admin might read your emails, > but then, he can just as easily read them as they come in or out of > the system. Actually such encryption is interesting as a protection in case when someone steals server hardware/disks. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/
