On 08/17/2014 05:55 PM, Anton Aylward wrote:

On 08/17/2014 04:11 PM, James Knott wrote:

...

...

Here is my dovecot.conf:

## Dovecot configuration file

# If you're in a hurry, see http://wiki2.dovecot.org/QuickConfiguration *** WARNING JIM ROBERTSON ***

Wrong wrong wrong wrong wrong wrong

Look: at the top of http://wiki2.dovecot.org/QuickConfiguration it says quite clearly

This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.

So if you are running v2 then there isn't a sinvle config file any more. As it says, try running

doveconf -n | Head -n 1

I deleted that line in dovecot.conf and changed 10-mail.conf according to what you said. Now I can't see anything. BTW, I know you said you weren't interested, but this computer was running dovecot on a fresh install of 13.1 for a few months. It's just this last week that I've had problems. Why the difference? Here's the 10-mail.conf file: ## ## Mailbox locations and namespaces ## # Location for users' mailboxes. The default is empty, which means that Dovecot # tries to find the mailboxes automatically. This won't work if the user # doesn't yet have any mail, so you should explicitly tell Dovecot the full # location. # # If you're using mbox, giving a path to the INBOX file (eg. /var/mail/%u) # isn't enough. You'll also need to tell Dovecot where the other mailboxes are # kept. This is called the "root mail directory", and it must be the first # path given in the mail_location setting. # # There are a few special variables you can use, eg.: # # %u - username # %n - user part in user@domain, same as %u if there's no domain # %d - domain part in user@domain, empty if there's no domain # %h - home directory # # See doc/wiki/Variables.txt for full list. Some examples: # # mail_location = maildir:~/Maildir # mail_location = mbox:~/mail:INBOX=/var/mail/%u # mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n # # # #mail_location = mail_location = mbox:~/mail:INBOX=/var/mail/%u # If you need to set multiple mailbox locations or want to change default # namespace settings, you can do it by defining namespace sections. # # You can have private, shared and public namespaces. Private namespaces # are for user's personal mails. Shared namespaces are for accessing other # users' mailboxes that have been shared. Public namespaces are for shared # mailboxes that are managed by sysadmin. If you create any shared or public # namespaces you'll typically want to enable ACL plugin also, otherwise all # users can access all the shared mailboxes, assuming they have permissions # on filesystem level to do so. namespace inbox { # Namespace type: private, shared or public #type = private # Hierarchy separator to use. You should use the same separator for all # namespaces or some clients get confused. '/' is usually a good one. # The default however depends on the underlying mail storage format. #separator = # Prefix required to access this namespace. This needs to be different for # all namespaces. For example "Public/". #prefix = # Physical location of the mailbox. This is in same format as # mail_location, which is also the default for it. #location = # There can be only one INBOX, and this setting defines which namespace # has it. inbox = yes # If namespace is hidden, it's not advertised to clients via NAMESPACE # extension. You'll most likely also want to set list=no. This is mostly # useful when converting from another server with different namespaces which # you want to deprecate but still keep working. For example you can create # hidden namespaces with prefixes "~/mail/", "~%u/mail/" and "mail/". #hidden = no # Show the mailboxes under this namespace with LIST command. This makes the # namespace visible for clients that don't support NAMESPACE extension. # "children" value lists child mailboxes, but hides the namespace prefix. #list = yes list = no # Namespace handles its own subscriptions. If set to "no", the parent # namespace handles them (empty prefix should always have this as "yes") #subscriptions = yes } # Example shared namespace configuration #namespace { #type = shared #separator = / # Mailboxes are visible under "shared/user@domain/" # %%n, %%d and %%u are expanded to the destination user. #prefix = shared/%%u/ # Mail location for other users' mailboxes. Note that %variables and ~/ # expands to the logged in user's data. %%n, %%d, %%u and %%h expand to the # destination user's data. #location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u # Use the default namespace for saving subscriptions. #subscriptions = no # List the shared/ namespace only if there are visible shared mailboxes. #list = children #} # Should shared INBOX be visible as "shared/user" or "shared/user/INBOX"? #mail_shared_explicit_inbox = yes # System user and group used to access mails. If you use multiple, userdb # can override these by returning uid or gid fields. You can use either numbers # or names. #mail_uid = #mail_gid = # Group to enable temporarily for privileged operations. Currently this is # used only with INBOX when either its initial creation or dotlocking fails. # Typically this is set to "mail" to give access to /var/mail. #mail_privileged_group = # Grant access to these supplementary groups for mail processes. Typically # these are used to set up access to shared mailboxes. Note that it may be # dangerous to set these if users can create symlinks (e.g. if "mail" group is # set here, ln -s /var/mail ~/mail/var could allow a user to delete others' # mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading it). #mail_access_groups = # Allow full filesystem access to clients. There's no access checks other than # what the operating system does for the active UID/GID. It works with both # maildir and mboxes, allowing you to prefix mailboxes names with eg. /path/ # or ~user/. #mail_full_filesystem_access = no ## ## Mail processes ## # Don't use mmap() at all. This is required if you store indexes to shared # filesystems (NFS or clustered filesystem). #mmap_disable = no # Rely on O_EXCL to work when creating dotlock files. NFS supports O_EXCL # since version 3, so this should be safe to use nowadays by default. #dotlock_use_excl = yes # When to use fsync() or fdatasync() calls: # optimized (default): Whenever necessary to avoid losing important data # always: Useful with e.g. NFS when write()s are delayed # never: Never use it (best performance, but crashes can lose data) #mail_fsync = optimized # Mail storage exists in NFS. Set this to yes to make Dovecot flush NFS caches # whenever needed. If you're using only a single mail server this isn't needed. #mail_nfs_storage = no # Mail index files also exist in NFS. Setting this to yes requires # mmap_disable=yes and fsync_disable=no. #mail_nfs_index = no # Locking method for index files. Alternatives are fcntl, flock and dotlock. # Dotlocking uses some tricks which may create more disk I/O than other locking # methods. NFS users: flock doesn't work, remember to change mmap_disable. #lock_method = fcntl # Directory in which LDA/LMTP temporarily stores incoming mails >128 kB. #mail_temp_dir = /tmp # Valid UID range for users, defaults to 500 and above. This is mostly # to make sure that users can't log in as daemons or other system users. # Note that denying root logins is hardcoded to dovecot binary and can't # be done even if first_valid_uid is set to 0. #first_valid_uid = 500 #last_valid_uid = 0 # Valid GID range for users, defaults to non-root/wheel. Users having # non-valid GID as primary group ID aren't allowed to log in. If user # belongs to supplementary groups with non-valid GIDs, those groups are # not set. #first_valid_gid = 1 #last_valid_gid = 0 # Maximum allowed length for mail keyword name. It's only forced when trying # to create new keywords. #mail_max_keyword_length = 50 # ':' separated list of directories under which chrooting is allowed for mail # processes (ie. /var/mail will allow chrooting to /var/mail/foo/bar too). # This setting doesn't affect login_chroot, mail_chroot or auth chroot # settings. If this setting is empty, "/./" in home dirs are ignored. # WARNING: Never add directories here which local users can modify, that # may lead to root exploit. Usually this should be done only if you don't # allow shell access for users. #valid_chroot_dirs = # Default chroot directory for mail processes. This can be overridden for # specific users in user database by giving /./ in user's home directory # (eg. /home/./user chroots into /home). Note that usually there is no real # need to do chrooting, Dovecot doesn't allow users to access files outside # their mail directory anyway. If your home directories are prefixed with # the chroot directory, append "/." to mail_chroot. #mail_chroot = # UNIX socket path to master authentication server to find users. # This is used by imap (for shared users) and lda. #auth_socket_path = /var/run/dovecot/auth-userdb # Directory where to look up mail plugins. mail_plugin_dir = /usr/lib64/dovecot/modules # Space separated list of plugins to load for all services. Plugins specific to # IMAP, LDA, etc. are added to this list in their own .conf files. #mail_plugins = ## ## Mailbox handling optimizations ## # The minimum number of mails in a mailbox before updates are done to cache # file. This allows optimizing Dovecot's behavior to do less disk writes at # the cost of more disk reads. #mail_cache_min_mail_count = 0 # When IDLE command is running, mailbox is checked once in a while to see if # there are any new mails or other changes. This setting defines the minimum # time to wait between those checks. Dovecot can also use dnotify, inotify and # kqueue to find out immediately when changes occur. #mailbox_idle_check_interval = 30 secs # Save mails with CR+LF instead of plain LF. This makes sending those mails # take less CPU, especially with sendfile() syscall with Linux and FreeBSD. # But it also creates a bit more disk I/O which may just make it slower. # Also note that if other software reads the mboxes/maildirs, they may handle # the extra CRs wrong and cause problems. #mail_save_crlf = no # Max number of mails to keep open and prefetch to memory. This only works with # some mailbox formats and/or operating systems. #mail_prefetch_count = 0 # How often to scan for stale temporary files and delete them (0 = never). # These should exist only after Dovecot dies in the middle of saving mails. #mail_temp_scan_interval = 1w ## ## Maildir-specific settings ## # By default LIST command returns all entries in maildir beginning with a dot. # Enabling this option makes Dovecot return only entries which are directories. # This is done by stat()ing each entry, so it causes more disk I/O. # (For systems setting struct dirent->d_type, this check is free and it's # done always regardless of this setting) #maildir_stat_dirs = no # When copying a message, do it with hard links whenever possible. This makes # the performance much better, and it's unlikely to have any side effects. #maildir_copy_with_hardlinks = yes # Assume Dovecot is the only MUA accessing Maildir: Scan cur/ directory only # when its mtime changes unexpectedly or when we can't find the mail otherwise. #maildir_very_dirty_syncs = no # If enabled, Dovecot doesn't use the S=<size> in the Maildir filenames for # getting the mail's physical size, except when recalculating Maildir++ quota. # This can be useful in systems where a lot of the Maildir filenames have a # broken size. The performance hit for enabling this is very small. #maildir_broken_filename_sizes = no ## ## mbox-specific settings ## # Which locking methods to use for locking mbox. There are four available: # dotlock: Create <mailbox>.lock file. This is the oldest and most NFS-safe # solution. If you want to use /var/mail/ like directory, the users # will need write access to that directory. # dotlock_try: Same as dotlock, but if it fails because of permissions or # because there isn't enough disk space, just skip it. # fcntl : Use this if possible. Works with NFS too if lockd is used. # flock : May not exist in all systems. Doesn't work with NFS. # lockf : May not exist in all systems. Doesn't work with NFS. # # You can use multiple locking methods; if you do the order they're declared # in is important to avoid deadlocks if other MTAs/MUAs are using multiple # locking methods as well. Some operating systems don't allow using some of # them simultaneously. #mbox_read_locks = fcntl #mbox_write_locks = dotlock fcntl # Maximum time to wait for lock (all of them) before aborting. #mbox_lock_timeout = 5 mins # If dotlock exists but the mailbox isn't modified in any way, override the # lock file after this much time. #mbox_dotlock_change_timeout = 2 mins # When mbox changes unexpectedly we have to fully read it to find out what # changed. If the mbox is large this can take a long time. Since the change # is usually just a newly appended mail, it'd be faster to simply read the # new mails. If this setting is enabled, Dovecot does this but still safely # fallbacks to re-reading the whole mbox file whenever something in mbox isn't # how it's expected to be. The only real downside to this setting is that if # some other MUA changes message flags, Dovecot doesn't notice it immediately. # Note that a full sync is done with SELECT, EXAMINE, EXPUNGE and CHECK # commands. #mbox_dirty_syncs = yes # Like mbox_dirty_syncs, but don't do full syncs even with SELECT, EXAMINE, # EXPUNGE or CHECK commands. If this is set, mbox_dirty_syncs is ignored. #mbox_very_dirty_syncs = no # Delay writing mbox headers until doing a full write sync (EXPUNGE and CHECK # commands and when closing the mailbox). This is especially useful for POP3 # where clients often delete all mails. The downside is that our changes # aren't immediately visible to other MUAs. #mbox_lazy_writes = yes # If mbox size is smaller than this (e.g. 100k), don't write index files. # If an index file already exists it's still read, just not updated. #mbox_min_index_size = 0 # Mail header selection algorithm to use for MD5 POP3 UIDLs when # pop3_uidl_format=%m. For backwards compatibility we use apop3d inspired # algorithm, but it fails if the first Received: header isn't unique in all # mails. An alternative algorithm is "all" that selects all headers. #mbox_md5 = apop3d ## ## mdbox-specific settings ## # Maximum dbox file size until it's rotated. #mdbox_rotate_size = 2M # Maximum dbox file age until it's rotated. Typically in days. Day begins # from midnight, so 1d = today, 2d = yesterday, etc. 0 = check disabled. #mdbox_rotate_interval = 0 # When creating new mdbox files, immediately preallocate their size to # mdbox_rotate_size. This setting currently works only in Linux with some # filesystems (ext4, xfs). #mdbox_preallocate_space = no ## ## Mail attachments ## # sdbox and mdbox support saving mail attachments to external files, which # also allows single instance storage for them. Other backends don't support # this for now. # WARNING: This feature hasn't been tested much yet. Use at your own risk. # Directory root where to store mail attachments. Disabled, if empty. #mail_attachment_dir = # Attachments smaller than this aren't saved externally. It's also possible to # write a plugin to disable saving specific attachments externally. #mail_attachment_min_size = 128k # Filesystem backend to use for saving attachments: # posix : No SiS done by Dovecot (but this might help FS's own deduplication) # sis posix : SiS with immediate byte-by-byte comparison during saving # sis-queue posix : SiS with delayed comparison and deduplication #mail_attachment_fs = sis posix # Hash format to use in attachment filenames. You can add any text and # variables: %{md4}, %{md5}, %{sha1}, %{sha256}, %{sha512}, %{size}. # Variables can be truncated, e.g. %{sha256:80} returns only first 80 bits #mail_attachment_hash = %{sha1} -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-08-17 22:11, James Knott wrote:

On 08/17/2014 03:57 PM, James Knott wrote:

...

All this past week, I have been trying to get dovecot to work properly. For some reason, it now wants to use the users home directory, instead of ~/mail. Dovecot.conf has the line mail_location = mbox:/mail.

Should be "~/mail"

Here is my dovecot.conf:

...

# A config file can also tried to be included without giving an error if # it's not found: !include_try local.conf mail_location = mbox:~/mail:INBOX=/var/mail/%u

You should now not edit dovecot.conf, but local.conf. So you should look at both files, and also at "conf.d/0-mail.conf" Or better, the output of "doveconf". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 08/17/2014 04:55 PM, Lew Wolfgang wrote:

I think you forgot the "~" in front of mail. Should be:

mail_location = mbox:~/mail:INBOX=/var/mail/%u

No, the ~ is in there and always has been. Here's the line as it currently is: mail_location = mbox:~/mail:INBOX=/var/mail/%u I had even tried copying the file from the old system, but same thing. So, I doubt it's the dovecot.conf file that's doing this. According to everything I've seen, it's correct. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/17/2014 05:58 PM, James Knott wrote:

On 08/17/2014 05:31 PM, Anton Aylward wrote:

...

On 08/17/2014 03:57 PM, James Knott wrote:

...

All this past week, I have been trying to get dovecot to work properly. Rather than just that one line, can you pelase show us the output of dovecot -n

# 2.1.17: /etc/dovecot/dovecot.conf

GOOD! So do it the v2 way!

mail_location = mbox:~/mail:INBOX=/var/mail/%u

This is WRONG. It should be in a namespace not 'raw' like this[1]

namespace inbox {

This seems to be your default and is maildir format NOTE: it says "inbox".

inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } protocols = imap lmtp ssl = no userdb { driver = passwd }

The docc in the wiki2 also says <quote> By default the mail_location setting is empty, which means that Dovecot attempts to locate automatically where your mails are. </quote> So why not simply remove it and see what happens. [1] Yes I know the docc talks about 'overrides' but obviously this isn't working for you, whereas I've had no problems with a 'pure' namespace approach. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

Unless I'm seriously mistaken, I was using V2 when I first installed 13.1 on this system a few months ago. It worked fine by using the dovecot.conf from my previous system.

Um... isn't that sorta what I said? Baka. -------- Original Message -------- Subject: Re: Why is dovecot using user home directory? Date: Sun, 17 Aug 2014 15:28:57 -0700 References: <53F10938.2050201@rogers.com> <53F11F4B.2080309@antonaylward.com> <53F125A2.8090103@rogers.com> Linda Walsh wrote:

I remember having a problem with those namespace things....

I tossed them and looked at what changed between 1 and 2 and brought over my v1 config file.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/18/2014 01:45 PM, Patrick Shanahan wrote:

Please be sure to leave the rest of the world unknowing of your solution!

It was essentially trial & error, going through what I found on line, with what I read here and just trying to figure things out. I suppose I could provide the conf.d files though. It was a real pain trying to wade through all the info to work things out.

...

...

Now to get fetchmail going and all is well! (Yeah, right!) If you have problems with fetchmail, sarcasm will not help. Basic reading and rithmitic will help.

No, I won't have problems with fetchmail. I just have to start it. At the moment, I have it disabled while I worked through the dovecot issues, in order to protect my new email. I've been doing all my email, over the past week, using POP on my notebook computer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 08/18/2014 01:53 PM, James Knott wrote:

...

No, I won't have problems with fetchmail. I just have to start it. At the moment, I have it disabled while I worked through the dovecot issues, in order to protect my new email. I've been doing all my email, over the past week, using POP on my notebook computer.

Looks like I spoke too soon. Fetchmail is pulling in the mail and I can read it with the mail command when logged in as the user, but it's not appearing in my dovecot server.

uh, yeah. I got that working too. Too bad you're ignoring what I have to offer. I think this is called reaping what you sow... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 08/18/2014 09:10 PM, Linda Walsh wrote:

...

James Knott wrote:

...

On 08/18/2014 01:53 PM, James Knott wrote:

...

No, I won't have problems with fetchmail. I just have to start it. At the moment, I have it disabled while I worked through the dovecot issues, in order to protect my new email. I've been doing all my email, over the past week, using POP on my notebook computer.

Looks like I spoke too soon. Fetchmail is pulling in the mail and I can read it with the mail command when logged in as the user, but it's not appearing in my dovecot server.

uh, yeah. I got that working too.

Too bad you're ignoring what I have to offer. I think this is called reaping what you sow...

I saw what you brought over from v1. Is that now your v2 config?

What's really amazing is that something that's worked so well for years, including on this same computer running 13.1, things would just blow up like this. I have maintained that set up through a few versions of suse, including fresh installs and moving to a new mom board. Yet, I just try to reinstall on an existing system and BLAM!!!

Same happened to me... I think it was the namespace stuff. What I posted here was exactly what I have now, as output by the "-n"... I could post the config files if wanted. My fetchmail script delivers my email through sendmail which delivers things to a perl script that does my filtering into "/var/spool/mail/$user" for my Inbox, and into ~/mail/foldername for everything else (list mail)...my "Inbox" seems to be virtually mapped to the system mail spool dir. Everything else is under ~/mail -- about 70 lists in all. I tell Tbird on each folder's properties that can get incoming email to "Check this folder for new messages".... I make sure to use standard mbox locking: { # lock routine returns lock handle needed by unlock sub mbox_lock ($) { my $lh; my $lname = $_[0] . ".lock"; # no timeout -- wait forever # this is not a great dea, but works 99.999999% of the time; we should # return a temporary failure... sleep 1 while !sysopen($lh, "$lname", 0 | &O_CREAT | &O_EXCL, 0444); my $lck = {'LNAME' => $lname, 'LH' => $lh}; return $lck; } sub mbox_unlock ($) { my $lck = $_[0]; my ($lh, $lname) = ($lck->{LH}, $lck->{LNAME}); close $lh || syslog("warn|mail", "closing lockfile $lname: $!"); return unlink $lname; } } -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 08/18/2014 11:06 PM, Linda Walsh wrote:

...

I could post the config files if wanted.

Sure. That would be appreciated.

According to rpm, the only file I've changed of interest here is dovecot.conf:

rpm -V dovecot21 SM5....T. c /etc/dovecot/dovecot.conf .M....... /etc/init.d/dovecot .M...U... /usr/share/doc/packages/dovecot .M...U... d /usr/share/doc/packages/dovecot/AUTHORS .M...U... d /usr/share/doc/packages/dovecot/COPYING rpm -qi shows version 2.1.17, rel 2.1.2, dist 13.1

So for dovecot.conf (the only conf file that is different): ----------------------------(comments show age of earlier configs).... # 2.0.13: dovecot.conf.rpmsave # OS: Linux 2.6.38.3-T610-Vanilla x86_64 openSUSE 11.4 (x86_64) listen = 192.168.4.1 192.168.3.1 127.0.0.1 ssl_cert =

James Knott wrote:

On 08/19/2014 05:24 PM, Linda Walsh wrote:

...

That's it. As near as I can tell, none of the files in /etc/dovecot/conf.d are actually used (which was intentional)... The previous dovecot.conf was 619 bytes -- That grew to ~ 4000+ in 2.x and had all those includes....

I combined what I wanted and ended up with the 1871 byte file above. Hope this helps..

Thanks. I'll have to look into it. Does this also get the mail from the user to dovecot? That's what I'm stuck on right now.

??? dovecot doesn't handle my outgoing email -- just IMAP. I use fetchmail to pull it in from the remote server -- that delivers it to 'sendmail'... which does it's normal thing (incoming in /var/spool/mail). In my home dir I have a ".forward" file that forwards my incoming email to my "procmail" equivalent (the perl script that calls spamassassin). But it just diverts some of the email into folders under ~/mail The post-filter stuff that gets through ends up in /var/spool/mail (which is where fetchmail seems to think it's inbox is). I'm using classic 'mbox' format -- makes searching and organization a bit easier for me... My perl script drops a summary of the incoming in mail/.log that looks like: 20140701:031807 (Tue) OpenSuSE mail (Re: [opensuse] Firefox Location-Aware Browsing ?)[CLEANED] received (john layt <>) (9.19sec processing) 20140701:032216 (Tue) OpenSuSE mail ( Re: [opensuse] Firefox Location-Aware Browsing ?)[CLEANED] received (per jessen <>) (9.32sec processing) 20140701:033029 (Tue) Firebug mail ([firebug] Re: Missing files on script tab with Firefox 30 + Firebug 2.0)[CLEANED] received () (7.96sec processing) 20140701:033036 (Tue) SpamAssassin mail (Changes in Spamhaus DBL DNSBL return codes) received (axb <>) (9.00sec processing)... 20140819:144406 (Tue) SPAM tagged mail , Supposedly to localaddress , thru localalias: mail (***SPAM*** Perfect solution: Up to 25pounds OFF!) received (daily health tip <>) (8.08sec processing) --- 95% of the processing time is really waiting on network responses. Fortunately, when email comes in, a different copy of the script gets invoked for each message... so if fetchmail has been inactive for some reason, it will pull down hundreds of messages that it tries to process mostly in parallel...(as most of it is waiting)... Yeah, as Anton says, I could short-circuit the path, but that can create problems if I try to integrate other standard tools in to replace something in my "supply chain"... I suppose eventually, I'll have my email delivered by systemd? *cough*.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 06:43 PM, James Knott wrote:

Would it be possible to do similar with a symlink from the file in /var/spool/mail to some directory under ~/mail?

Don't do that! Set up a namespace. And make sure you are aware of setting it to mbox format and not maildir format! Please also see http://wiki2.dovecot.org/Plugins/Snarf whcih maps the var/spool to the ~/mail Since you are mixing maildir amdn mbox, please pay attention to what's in http://wiki2.dovecot.org/Namespaces -- I tell you that as long as I can conceive something better than myself I cannot be easy unless I am striving to bring it in to existence or clearing the way for it. -- George Bernard Shaw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 08:09 PM, Carlos E. R. wrote:

[big snip]

Normally, that means that the new email would end on:

/var/spool/mail/james

So that's the place that dovecot and others call "INBOX", and it is in mbox format (unix default).

Its the place that ... well no. IF and only if there have been no 'overrides', that is the dovecot is just as 'blank' as you said the postfix was, defaults all the way down the line, then dovecot _searches_ likely locations. If mail_location is unset, Dovecot tries to detect where your mail is stored by looking at ~/Maildir, ~/mail, /var/spool/mail/ and /var/mail/ directories

Now, your dovecot has this configuration, as you posted recently:

location = maildir:~/Mail/INBOX:LAYOUT=fs

Which is an 'override' and not the default null.

which I understand means that it expects the INBOX to be the Maildir directory "/home/james/mail/INBOX" - but that is not where the system is placing email.

It is where the system is placing it on my setuo BECAUSE that's how I have the procmail set up to deliver it. If James has a non default procmail then your suppositions are off.

I think you need something like:

mail_location = INBOX=/var/mail/%u

NO! James has the "location" defined _within_ a namespace. That's different, though with the same sytax as,a mail_location. Do not play loose and free by mixing both. It will only get dovecot confused and THAT kind of thing might be wht James is in the mess he's in. The default unless you override is that in 10-mail and 15-mailboxes the default, unless you override it' is for the inbox namespace, the one that James has enclosing the "location=" above, is to be a maildir. Default ==> maildir.

In order to verify, you have to look at the logs.

In order to verify this you can simply do a telnet into the dovecot server. In order to do debugging & logging http://wiki2.dovecot.org/TestInstallation#Check_that_it_finds_INBOX -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 09:19 PM, Carlos E. R. wrote:

On 2014-08-20 02:57, Anton Aylward wrote:

...

On 08/19/2014 08:09 PM, Carlos E. R. wrote:

...

...

which I understand means that it expects the INBOX to be the Maildir directory "/home/james/mail/INBOX" - but that is not where the system is placing email.

It is where the system is placing it on my setuo

But not on his.

It looks like James copy/pasted some of my config ...

...

BECAUSE that's how I have the procmail set up to deliver it.

If James has a non default procmail then your suppositions are off.

But he has not.

He has not said he has, and we have asked about it several times.

... some of your config ideas ...

...

The default unless you override is that in 10-mail and 15-mailboxes the

You should not edit either of those files, but only the "local.conf" file. And you can also add to existing or new namespaces in there, if you wish.

I do wish and I have. but that's all beside the point other than to illustrate how flexible and capable namespaces re for getting anything from anywhere in any format.

...

default, unless you override it' is for the inbox namespace, the one that James has enclosing the "location=" above, is to be a maildir.

Default ==> maildir.

The default for dovecot should be "dbox".

.. and some of what Lynn has suggested, but I don't know if that has cropped up. Please don't confuse him further. I think the problem James has is that he has taken our advice. All of our advice. And put it in some kind of blender. And the results are inconsistent with other bits like postfix and fetchmail and procmail. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 08/19/2014 05:32 PM, James Knott wrote:

...

Thanks. I'll have to look into it. Does this also get the mail from the user to dovecot? That's what I'm stuck on right now.

I think your problem is one of some parts are talking mbox and others are talking maildir.

---- If you noticed, I'm only using mbox... If you somehow tried to cast your Inbox as a maildir format, I can't see how that would work with most Local delivery agents. Would it try to create a maildir in /var/spool/<user>/{m1,m2,m3}. James Knott wrote:

With my previous set up, fetchmail brought the mail to the user and dovecot managed to pick it up there. I didn't have to do anything else with sendmail, procmail etc. When dovecot was working in the wrong directory, that was still happening. Now that I've got it out of the user's directory, dovecot no longer does that.

--- You got "it" out? it=dovecot or fetchmail? Looking at your previous 'fetchmailrc', fetchmail delivered it to the your local MTA which was likely configured to just "work" in this case, out of the box. The man page for fetchmail says it is only configured to fetch to the system-mail destination for a user (though it can be used in a multi-user mode that would enable the email going into separate, username-based locations. I.e. somewhere, it seems you have added something... If you were using procmail before, it is quite possibly that procmail's setup installed a ".forward" file in your home directory. (do you have one? contents something like "|procmail blahblahblah". You only need procmail if you are sorting it into mailboxes. If you don't use procmail, I would guess everything would end up in your "Inbox" in /var/spool/mail/<user>.

Don't you just *LOVE* the way people "improve" things?

---- You know me, cutting edge only! But in this case, it's likely due to systemd (seriously!) Whatever MTA you used to use wasn't properly setup to accept email from fetchmail with the move to systemd, whereas before, it was and either procmail or sendmail were configured to run at startup (is 'it', (likely procmail) started and configured to be start at boot time That may be another issue... In which case, intermixing mbox and maildir probably wouldn't be an issue (i.e. this is a reason FOR using a standard MTA -- to get such interoperability).

...

I use fetchmail to pull it in from the remote server -- that delivers it to 'sendmail'... which does it's normal thing (incoming in /var/spool/mail).

In my home dir I have a ".forward" file that forwards my incoming email to my "procmail" equivalent (the perl script that calls spamassassin).

But it just diverts some of the email into folders under ~/mail

Would it be possible to do similar with a symlink from the file in /var/spool/mail to some directory under ~/mail?

--- You really don't want to do that. There be dragons, there! Check out your previous setup (if you can)... I'll bet something else was configured by default on your old system that isn't configured now. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-08-20 02:00, Anton Aylward wrote:

On 08/19/2014 07:41 PM, Linda Walsh wrote:

Go back and read what James said he's using:

location = maildir:~/Mail/INBOX:LAYOUT=f ^^^^^^^^^^^^^^^^^^^^

Now I have the same, and I also have, as I've previously posted here, my promail set up so that it default delivers to

MAILDIR=/$HOME/Mail/ DEFAULT="$MAILDIR/INBOX/"

But his is not. He does not explicitly set a delivery method in fetchmail, so that means it just handles over to the local mail transfer agent, be it postfix, sendmail, qmail, whatever. And that ends delivering email as an mbox file under /var/spool/mail/. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-20 03:05, Anton Aylward wrote:

Unless he wants to make his dot-procmailrc work like mine, perhaps his best tactic is to delete *all* customization from the dovecot config, not just the customization of the namespace but remove all mail_location and remove local.conf and let dovecot do its smart thing.

Yes, I agree with that. Start with a clean slate. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-20 03:37, Linda Walsh wrote:

Carlos E. R. wrote:

The only place that cannot (AFAIK) be in maildir format is the INBOX.

No, it can also be in maildir, modern tools support it. That is, postfix supports it :-p I have a pair of test users with a maildir system INBOX, dated 2006... last time I tried.

The standard in mail is mbox and utils will look for that in /var/spool/mail.

True.

Now dovecot, can be configured differently -- but he needs to have Inbox in mbox.

Not "need" but indeed easier. Fewer configs to change if he sticks to defaults. :-)

He should have an MTA configed -- this business of trying to use fetchmail as an MTA is likely to cause problems.

I agree.

He said his other stuff was working (in /home/mail), so they only thing he did was break his inbox by changing it to maildir which isn't part of the email standard.

I agree.

So at this point, I would now guess that hist Inbox is in /var/spool/mail/<user> and that's the only thing he needs to fix... James?

Right, but dovecot has been told to expect a maildir inbox on "~/Mail/INBOX". And the system is placing an mbox in "/var/spool/mail/<user>". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-20 04:02, Linda Walsh wrote:

Carlos E. R. wrote:

Well, if his postfix is configured for maildir format in /var/spool/mail, but it isn't sendmail compliant.

Wait. Postfix can use maildir, but it is not the default. So I doubt he has the spool in maildir. It is done by the Local Delivery Agent used by postfix. * The local(8) delivery agent understands UNIX-style mailboxes, qmail- compatible maildir files, Sendmail-style system-wide aliases(5) databases, and Sendmail-style per-user .forward files. Multiple local delivery agents can be run in parallel, but parallel delivery to the same user is usually limited. The local(8) delivery agent has hooks for alternative forms of local delivery: you can configure it to deliver to mailbox files in user home directories, you can configure it to delegate mailbox delivery to an external command such as procmail, or you can delegate delivery to a different Postfix delivery agent. (/usr/share/doc/packages/postfix-doc/README_FILES/OVERVIEW)

Also fetchmail can't store directly in that format as well as most clients that can't read it except through IMAP. (http://en.wikipedia.org/wiki/Maildir)

No, fetchmail handles mail over to something else, be it the local MTA, be it procmail. It is that other component which does the filing. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-20 05:41, Anton Aylward wrote:

On 08/19/2014 10:02 PM, Linda Walsh wrote:

...

Well, if his postfix is configured for maildir format in /var/spool/mail, but it isn't sendmail compliant. Also fetchmail can't store directly in that format as well as most clients that can't read it except through IMAP. (http://en.wikipedia.org/wiki/Maildir)

Linda, the whole point of the shift to ~/Mail in the last century was to allow the expansion that came with maildir which isn't possible with /var/spool/mail/user.

There are many programs that can not read Maildir, notably Thunderbird. Pine could do it with a patch, that nowdays is part of the core (on Alpine). So for many years it could not. SpammAssassin sa-learn does not even mention maildir in the manual. Often the implementation of maildir used by one program is not compatible with the one used by another program, so that you can not, say, tell Kmail to just use a ~/Mail folder previously used by... dunno, evolution. On the other hand, an mbox file used by Thunderbird can be used by Pine or others (like sa-learn, procmail, etc), seamlessly. In that sense, mbox is a standard, and maildir is not. ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 08/20/2014 07:18 AM, Carlos E. R. wrote:

SpammAssassin sa-learn does not even mention maildir in the manual.

That doesn't mean it can't handle it. Go Google. This guide shows how to set up spamassassin for maildir http://help.directadmin.com/item.php?id=358 You mistake is in seeing that sa-learn has the "-mbox" option. What you miss is that if that is not used then the default is maildir. -- "Politics is the art of appearing candid and completely open, while concealing as much as possible." -- Brian Herbert, -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 08/19/2014 09:37 PM, Linda Walsh wrote:

...

The only place that cannot (AFAIK) be in maildir format is the INBOX.

I'm sorry, Linda, that is not the case. My INBOX *is* in maildir format.

And it is in /var/spool/mail??? Does it create a subdir there and put messages in that? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/20/2014 04:00 AM, Per Jessen wrote:

Linda Walsh wrote:

...

Anton Aylward wrote:

...

On 08/19/2014 09:37 PM, Linda Walsh wrote:

...

The only place that cannot (AFAIK) be in maildir format is the INBOX.

I'm sorry, Linda, that is not the case. My INBOX *is* in maildir format.

And it is in /var/spool/mail??? Does it create a subdir there and put messages in that?

I have INBOX'es in maildir format in e.g. /var/spool/mail/<domain>/<user>/{cur,new,etc.}

works just fine.

Just so long as you are completely consistent and all the MDA, readers etc are configured for that. -- Bullet proof vest vendors do not need to demonstrate that naked people are vulnerable to gunfire. Similarly, a security consultant does not need to demonstrate an actual vulnerability in order to claim there is a valid risk. The lack of a live exploit does not mean there is no risk. -- Crispin Cowan, 23 Aug 2002 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/21/2014 02:59 AM, Per Jessen wrote:

Anton Aylward wrote:

...

On 08/20/2014 04:00 AM, Per Jessen wrote:

...

Linda Walsh wrote:

...

Anton Aylward wrote:

...

On 08/19/2014 09:37 PM, Linda Walsh wrote:

...

The only place that cannot (AFAIK) be in maildir format is the INBOX.

I'm sorry, Linda, that is not the case. My INBOX *is* in maildir format.

And it is in /var/spool/mail??? Does it create a subdir there and put messages in that?

I have INBOX'es in maildir format in e.g. /var/spool/mail/<domain>/<user>/{cur,new,etc.}

works just fine.

Just so long as you are completely consistent and all the MDA, readers etc are configured for that.

There is only one software dealing with it, and that's dovecot. Period.

"Dealing with it"? "Dealing" means what? As I see it sendmail/postfix deals with it; procmail deals with it; spamassassin deals with it; and if you are using Thunderbird to read files rather than a server like dovecot, then Thunderbird deals with it. Excusing the last, they all have to have a consistent view of things. If the MTA/MDA is delivering up the mail in mbox style then dovecot need to access that in mbox style. Similarly with maildir. Now I admit that the way my procmail works I serve the INBOX as maidir and stuff that goes straight to the archives as mbox. But then again I have dovecot configured so that it deals with the INBOX as maidir and ARCHIVES as mbox by means of namespaces. Its all completely consistent. The only thing that stops me letting Thundebird read all this, and yes late-model Thunderbird *can* handle both mbox and maildir, is that Thunderbird is on my workstation and not the mail server. So no, I don't think that "there's only *ONE* software dealing with it". Perhaps, if you don't take the point I'm trying to make here, you'd care to explain the "only one". -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/21/2014 11:18 AM, Per Jessen wrote:

I don't see it like that :-) After receiving and filtering with Spamassassin, postfix delivers incoming mails to dovecot, dovecot (optionally) stores them in the maildir after they've been filtered by sieve, then updates the index. To read them, each client has to use IMAP. (clients include TB, roundcube, smartphones, outlook etc).

And *I* don't see it like *that* :-) I see it as fetchmail -> procmail -+-> spamassassin -+-> procmail -> INBOX | | | +-> SpamBox +-> lists, ARCHIVES or possibly Postfix -> Dot-Forward -> procmail -> (as above) So that dovecot is only concerned with the READING and not with the delivery. Strictly speaking its not the dovecot server that you are talking about but an axillary program.

...

The only thing that stops me letting Thundebird read all this, and yes late-model Thunderbird *can* handle both mbox and maildir, is that Thunderbird is on my workstation and not the mail server.

IMAP? Why are you running dovecot if it isn't as an IMAP server?

Did you not see my emphasis, the highlighted "*can*"? The point I was trying to make is that there are many things that can access the maildir. *CAN* *CAN* Not that I do, but that if it wasn't on a separate server box I *COULD*. The point being that Dovecot is not the *ONLY* software.

See above. Really, in my setup the only software that accesses/deals/fiddles with the maildir is dovecot.

Right. Please don't fall into the absolutist "my way is the only way because its the correct way" that Linda so often communicates. Your way is not my way. Your way is interesting and I may try it out some time. I'm prone to experiment[1]. That we can implement it all these different ways is great and typical of UNIX/Linus and probably what scares off a lot of smaller minded types who are sued to the vendor (being Microsoft in many cases) telling them how it should be. The old "You don't get fired for buying.." syndrome, letting the vendor rep make all the decisions about what hardware and software and configuration. Yes, UNIX/Linux is real scary! And guess what? My system might be different next month. Well not next month, I have surgery lined up, but I might do a massive reconfig over the new years, depending on what Santa brings. Thank you for explaining. Good to know. I'll bookmark this. [1] I haven't figured out Linda's booting without initrd, but then I reboot so rarely its not a serious concern. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/20/2014 03:13 AM, Linda Walsh wrote:

Anton Aylward wrote:

...

On 08/19/2014 09:37 PM, Linda Walsh wrote:

...

The only place that cannot (AFAIK) be in maildir format is the INBOX.

I'm sorry, Linda, that is not the case. My INBOX *is* in maildir format.

And it is in /var/spool/mail??? Does it create a subdir there and put messages in that?

No. Why are you hung up on this? The shift to putting user's email in ~/Mail or ~/Maildir came about a long long time ago and that's where maildir mail lived. When you let go of the obsession with mbox and the obsession with packing everything in a single file, which dates back to the early days of UNIX when there was a tight limit on the number of open files because kernel tables were a fixed size determined at kernel compile time, and all the hassle that goes with the mbox format. The mbox format has locking issues: in effect you are trying to edit the middle of a on open file (e.g tagging or making as read), deleting a chunk out of the middle when you garbage a message, while another process is trying to insert another message into the file. With maildir that's not a problem. The mbox format is an emergent property of the days when UNIX was resource limited in quite a number of ways. Linda you know full well that the archaic (I recall it from V6 and V7 systems in the late 1970s) /var/spool style is tied inexorably to mbox, so what you're really doing here is trying to say Maildir is stupid because it can't use /var/spool/mail in a way that's compatible with mbox. Which is true but like saying that cars are stupid because you don't steer them with reins and you don't use spurs to make them go faster. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-08-20 05:29, Anton Aylward wrote:

On 08/19/2014 09:37 PM, Linda Walsh wrote:

...

Carlos E. R. wrote:

Right. Fetchmail *has* to hand of to something. Carlos seems to think that in the absence of a "mda" directive it hands off to sendmail/postfix. THIS IS NOT SO!

The docco says that in the absence of a mda directive, fetchmail sends to port 25 of the machine that fetchmail is running on.

And port 25, in a default configured openSUSE machine nowdays, is handled by postfix. Previously it was sendmail. Other distributions might use different things, but I don't care about them. And people may install a different MTA. That's is my meaning of "fetchmail handing over to sendmail/postfix". Not that fetchmail calls any of those programs: it does not know the name of the MTA nor cares (well, it may know, but for simplicity we'll assume it doesn't).

There is then th hope that this is properly configured to recognise the address/domain as local and will effect local delivery. This in turn _might_ end up having a .forward being used rather than delivery to the local /var/spool/mail.

In this situation I believe fetchmail doesn't forward to a user@host.domain, just to a "user", so there is no chance of sending outside by mistake. Of course, if there is a ".forward" file, that is not handled by fetchmail.

Hopefully that .forward invokes a procmail and the procmailrc has suitable defaults.

I don't remember who handles .forward files, but I think it is postfix. Normally postfix invokes procmail directly, not via .forward.

But all this is dependent on how the sendmail/postfix is configured. Any 'errors' there, any unexpected processing based on what's in the email envelope & headers and its lost.

Nay, I've never seen that. :-) And I have been using this same method for decades, even as a Linux novice. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Have you tried logging in to the server using telnet as per http://wiki2.dovecot.org/MissingMailboxes and http://wiki2.dovecot.org/TestInstallation#Check_that_it_finds_INBOX Try those and report back what happens -- "Nothing is more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things." -- Machiavelli -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-08-18 21:38, James Knott wrote:

On 08/18/2014 01:53 PM, James Knott wrote:

...

No, I won't have problems with fetchmail. I just have to start it. At the moment, I have it disabled while I worked through the dovecot issues, in order to protect my new email. I've been doing all my email, over the past week, using POP on my notebook computer.

Looks like I spoke too soon. Fetchmail is pulling in the mail and I can read it with the mail command when logged in as the user, but it's not appearing in my dovecot server.

The dovecot 2 supplied by openSUSE is designed so that you do not touch any of the supplied configuration files, but instead edit only "/etc/dovecot/local.conf". This way you keep the distributiohn files intact, and carry over a single file with your own modifications, that should be few. Dovecot 2 config also uses something called "namespaces", so you have to be careful with that. A setting might not apply globally. And in order to find out the actual configuration it is using, you run "doveconf -N". So you could post the output you get now and we have a look ;-) Also, we have to consider how you have fetchmail set... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-19 03:40, James Knott wrote:

On 08/18/2014 09:34 PM, Carlos E. R. wrote:

...

The dovecot 2 supplied by openSUSE is designed so that you do not touch any of the supplied configuration files, but instead edit only "/etc/dovecot/local.conf". This way you keep the distributiohn files intact, and carry over a single file with your own modifications, that should be few.

I don't see that file.

No, you create it, of course.

...

Dovecot 2 config also uses something called "namespaces", so you have to be careful with that. A setting might not apply globally.

And in order to find out the actual configuration it is using, you run "doveconf -N".

# 2.1.17: /etc/dovecot/dovecot.conf # OS: Linux 3.11.10-21-desktop x86_64 openSUSE 13.1 (x86_64) mail_privileged_group = mail

I don't have that one. But I have: auth_mechanisms = plain default_vsz_limit = 256 M listen = *, :: mail_debug = yes mail_location = mbox:~/Mail:INBOX=/var/mail/%u mail_plugin_dir = /usr/lib64/dovecot/modules mail_plugins = " fts fts_lucene"

namespace inbox { hidden = no inbox = yes list = yes location = maildir:~/Mail/INBOX:LAYOUT=fs mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = }

Ah, you have changed the location _inside_ the inbox namespace, so that it only applies to "inbox". What I have is, I believe the openSUSE default: namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = }

passdb { driver = pam } plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } service imap-login { inet_listener imaps { port = 993 ssl = yes } } ssl_cert =

The rest I have similar, with non important differences: passdb { driver = pam } plugin { fts = lucene fts_lucene = whitespace_chars=@. sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } service imap { vsz_limit = 512 M } ssl = yes ssl_cert =

...

So you could post the output you get now and we have a look ;-)

Also, we have to consider how you have fetchmail set...

# Configuration created Sun May 21 12:58:54 2006 by fetchmailconf 1.52 $Revision: 4636 $ set postmaster "james.knott" set bouncemail set no spambounce set properties "" set daemon 120 poll pop proto pop3 via pop.broadband.rogers.com user "********" pass "#########" ssl nokeep

As you can see, I've been using this configuration for a while.

Mmm. I think that email there is handled over to the local smtp server, with the same "user" (I'm unsure of that detail, as I set it explicitly). And it would probably end in /var/spool/mail/username (username = **** above, I think). If you also use procmail, or some other delivery agent, it could end anywhere instead. Ah, wait. Is that fetchmail run by root, or by some local user? In the second case, that's the user it could be sent to finally. But I think that your dovecot will not look at /var/spool/mail/username, so that it will not see new email... Your dovecot expects email to enter on "~/Mail/INBOX" instead, in maildir format (which by default postfix doesn't). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 08/18/2014 10:18 PM, Carlos E. R. wrote:

Ah, you have changed the location _inside_ the inbox namespace, so that it only applies to "inbox".

DO NOT BE MISLED! The name of the _namespace_ is "inbox" Think back to the White Knight's song. Its name is "inbox" but what it is called (see "prefix =") is "" I have one whose name is 'ARCHIVE' but is called "ARCHIVE" And just to confuse matters further, the data for this resides in "~/Mail/ARCHIVE" But those are three quite arbitrary strings and need not be in any way related. One is a name, anther is a label and the third is an address. IYR, things like this occur quite often in computing and all to often in C programming. Beginners are wanted away from using such things in C programming. Perhaps because I read Carroll as a child these things do not confuse me. For very long. As long as I concentrate. Hard. And don't get distracted. The point is that you are SUPPOSED to set the location _inside_ the namespace definition. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \h immortality for me." -- E.W. Dijkstra -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 07:28 AM, Carlos E. R. wrote:

On 2014-08-19 06:57, Anton Aylward wrote:

...

On 08/18/2014 10:18 PM, Carlos E. R. wrote:

...

Ah, you have changed the location _inside_ the inbox namespace, so that it only applies to "inbox".

DO NOT BE MISLED!

The name of the _namespace_ is "inbox"

Think back to the White Knight's song.

What's that? :-???

See chapter 8 of "Alice Through the Looking Glass". The name of the song is called 'Haddocks' Eyes'. That is what the name is called. The name really is 'The Aged Aged Man'. The song is called `Ways And Means': but that's only what it's called, you know. The song really is `A-sitting On A Gate': and the tune's my own invention. As I said, none of this is strange to C programmers. Heck, they might even autoincrement it!

...

But those are three quite arbitrary strings and need not be in any way related. One is a name, anther is a label and the third is an address.

Ah, ok....

...

The point is that you are SUPPOSED to set the location _inside_ the namespace definition.

But the dovecot people don't.

What 'dovecot people'? And it WORKS. The verb is always stringer than the noun.

They configure it here: /etc/dovecot/conf.d/10-mail.conf, outside of any namespace. They say:

# Location for users' mailboxes. The default is empty, which means that Dovecot

Yes, and I tried that originally and found, as James is finding, that it didn't work. The VERB and the noun. I'm mixing both maildir and mbox; I'm using fetchmail from a number of sites. In fact I'm doing this all without Postfix as I described in an earlier posting. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

Ah, wait. Is that fetchmail run by root, or by some local user? In the second case, that's the user it could be sent to finally.

But I think that your dovecot will not look at /var/spool/mail/username, so that it will not see new email... Your dovecot expects email to enter on "~/Mail/INBOX" instead, in maildir format (which by default postfix doesn't).

My dovecot uses /var/spool/mail/<user>... It *calls* it "INBOX", but it is located in spool. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 07:30 AM, Carlos E. R. wrote:

On 2014-08-19 11:51, Linda Walsh wrote:

...

It *calls* it "INBOX", but it is located in spool.

Because, I understand, INBOX is a special name in "imap" standard.

No its not because of that, its that the "tune is my own invention" part. The name 'inbox' of a namespace is there in 10-mail.conf, but you can change that. I *CHOSE* the name to which my fetchmail/procmail delivered incoming mail that was not put elsewhere by procmail (spam for example) to be INBOX and to be located in /home/anton/Mail. I chose that because once I lost my mailbox in an upgrade when I forget to tell the installer not to reformat /var. OUCH OUCH OUCH. So now my mail lives under /home. It also get backed up as part of /home which is a bit more aggressive than /var. I realise that the examples in, for example, RFC 5162, make use of C: A04 SELECT INBOX but that's beside the point. Right now I've just done a C: A27 SELECT OpenSuseForum I could have my fetchmail/procmail deliver new mail to ~/Mail/Fitzgibbon]1] and have "My Inbox" appear as the name at the top of the listing when I open Thunderbird, and when I click on "My Inbox" Thunderbird sends A01 SELECT Fitzgibbon to the IMAP server. [1] English humour: http://en.wikipedia.org/wiki/White_Knight_Fitzgibbon -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-08-19 23:41, James Knott wrote:

On 08/19/2014 08:07 AM, Anton Aylward wrote:

...

OUCH OUCH OUCH.

So now my mail lives under /home. It also get backed up as part of /home which is a bit more aggressive than /var.

I had always made a habit of backing up /var/spool/mail, but currently it's in it's own partition, separate from /var. I suppose I could have used a symlink to somewhere under /home, but this way works too.

If you are using maildir, you could consider making that partition a reiserfs one. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 08/19/2014 06:00 PM, Carlos E. R. wrote:

If you are using maildir, you could consider making that partition a reiserfs one. I haven't used reiserfs for a few years. All my partitions are ext4 now. What benefit would reiserfs have? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 06:00 PM, Carlos E. R. wrote:

On 2014-08-19 23:41, James Knott wrote:

...

On 08/19/2014 08:07 AM, Anton Aylward wrote:

...

OUCH OUCH OUCH.

So now my mail lives under /home. It also get backed up as part of /home which is a bit more aggressive than /var.

I had always made a habit of backing up /var/spool/mail, but currently it's in it's own partition, separate from /var. I suppose I could have used a symlink to somewhere under /home, but this way works too.

If you are using maildir, you could consider making that partition a reiserfs one.

I do :-) -- The bitterness of poor quality lingers long after the sweetness of meeting schedules is forgotten. --Kathleen Byle, Sandia National Laboratories -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/18/2014 09:40 PM, James Knott wrote:

On 08/18/2014 09:34 PM, Carlos E. R. wrote:

...

The dovecot 2 supplied by openSUSE is designed so that you do not touch any of the supplied configuration files, but instead edit only "/etc/dovecot/local.conf". This way you keep the distributiohn files intact, and carry over a single file with your own modifications, that should be few.

I don't see that file.

...

Dovecot 2 config also uses something called "namespaces", so you have to be careful with that. A setting might not apply globally.

And in order to find out the actual configuration it is using, you run "doveconf -N".

# 2.1.17: /etc/dovecot/dovecot.conf # OS: Linux 3.11.10-21-desktop x86_64 openSUSE 13.1 (x86_64) mail_privileged_group = mail managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave namespace inbox {

* THIS * is the definition for the inbox

hidden = no inbox = yes list = yes location = maildir:~/Mail/INBOX:LAYOUT=fs

* THIS * is the location of the inbxi and it is a maildir not a mbox

mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } [snip]

...

Also, we have to consider how you have fetchmail set...

# Configuration created Sun May 21 12:58:54 2006 by fetchmailconf 1.52 $Revision: 4636 $ set postmaster "james.knott" set bouncemail set no spambounce set properties "" set daemon 120 poll pop proto pop3 via pop.broadband.rogers.com user "james.knott" pass "#########" ssl nokeep

As you can see, I've been using this configuration for a while.

And where is that delivering to and is it delivering in maildir mode or mbox mode? I am quite explicit about it in my fetchmail, # Rogers accounts # poll pop.mail.yahoo.com with proto POP3 # user 'Anton.Aylward@rogers.com' there with password 'xxxxxx' is 'anton' here options ssl no rewrite # mda "/usr/bin/procmail -f %F -d %T"; My procmail is doing spamassassin checking among many other things and unless other things are triggered it goes into the INBOX. My INBOX is a Maildir just as is specified in James listing aboe The relevant line from my .procmailrc are MAILDIR=/$HOME/Mail/ DEFAULT="$MAILDIR/INBOX/" # Thee trailing / makes it a maildir LOGFILE=/dev/null # LOGFILE=$HOME/procmail.log # For Troubleshooting: # VERBOSE=yes # LOGABSTRACT=all As you can see, I once had to do detailed debugging! I have a LOT of processing in my procmail scripts. This means that I am not dependent on the rules in Thunderbird for sorting to folders etc. If I change mail readers or read via my phone or tablet the stuff is still sorted. Procmail is wonderful! And yes, procmail can deliver to both maildir and mbox. My point here is that the listing James gives show quite clearly he has a *maildir* setup so he should be storing the mail he fetches in a maildir format. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19 Aug 2014, cpchan@bell.net wrote:

Here is where we differ. I prefer using dovecot for final deliver. Here is the relevant lines from my .procmailrc:

Forgot to add, if you do decide to change to using dovecot-lda, you will be interest in the dovecot directives "lda_mailbox_autocreate" and "lda_mailbox_autosubscribe". For example, I have: ,---- | lda_mailbox_autocreate = yes | lda_mailbox_autosubscribe = yes `---- Charles -- "Whip me. Beat me. Make me maintain AIX." (By Stephan Zielinski)

On 19 Aug 2014, robin.listas@telefonica.net wrote: Hi Carlos:

I would have to replace the last line with:

| $DELIVER -m lists/os-en

Yes.

or...?

Would it end in the same mailbox format, in my case mbox?

It will deliver to what ever mailbox format you setup your Dovecot to use. However, I don't use mbox, so you should run a test to test the procmail recipe first. If the message could not be saved to the mailbox for any reason, it is delivered to INBOX instead. You will not loose any mail. Charles -- "Never make any mistaeks." (Anonymous, in a mail discussion about to a kernel bug report.)

On 19 Aug 2014, robin.listas@telefonica.net wrote: Hi Carlos:

It is not working here... the problem is AppArmour, profiles have to be adjusted.

Hum, it works fine here as you can see from my procmail.log for your message: ,----[ Excerpt from procmail.log ] | procmail: Skipped "News_Letters" | procmail: Skipped """ | From opensuse+bounces-162799-cpchan=bell.net@opensuse.org Tue Aug 19 12:46:36 2014 | Subject: Re: [opensuse] Why is dovecot using user home directory? | Folder: /usr/lib/dovecot/dovecot-lda -m OpenSuSE 8384 `---- Can you see if your apparmor profile is the same as mine? # ------------------------------------------------------------------ # # Copyright (C) 2013 Christian Boltz # # This program is free software; you can redistribute it and/or # modify it under the terms of version 2 of the GNU General Public # License published by the Free Software Foundation. # # ------------------------------------------------------------------ # vim: ft=apparmor #include #include /usr/lib/dovecot/dovecot-lda { #include #include capability setgid, capability setuid, @{DOVECOT_MAILSTORE}/ rw, @{DOVECOT_MAILSTORE}/** rwkl, /etc/dovecot/** r, /proc/*/mounts r, /{var/,}run/dovecot/mounts r, /usr/bin/doveconf mrix, /usr/lib/dovecot/dovecot-lda mrix, # Site-specific additions and overrides. See local/README for details. #include } Charles -- "Are [Linux users] lemmings collectively jumping off of the cliff of reliable, well-engineered commercial software?" (By Matt Welsh)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2014-08-19 at 22:15 +0200, Carlos E. R. wrote:

/home1/cer/Mail/** rwk,

...

@{DOVECOT_MAILSTORE}/ rw, @{DOVECOT_MAILSTORE}/** rwlk,

It has to be /home1/cer/Mail/** rwlk, or I get this error: <2.3> 2014-08-20 02:23:24 Telcontar dovecot - - - lda(cer): Error: link(/home/cer/Mail/_Lists/.imap/y_gml_os-unifd/dovecot.index.log, /home/cer/Mail/_Lists/.imap/y_gml_os-unifd/dovecot.index.log.2) failed: Permission denied aa-logprof doesn't catch that one. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlPz+NAACgkQtTMYHG2NR9VQqACfbX7ZnANxf/R/ir6Y1Og/gZ2v qugAnRyJaQDswVs5p3QCW0iSmiIMNaNk =MdMR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2014-08-20 at 12:05 +0200, Carlos E. R. wrote:

On Tuesday, 2014-08-19 at 13:50 +0200, Carlos E. R. wrote:

...

On 2014-08-19 07:52, Charles Philip Chan wrote:

...

This is very interesting!

I'm seeing one issue with the lock file.

This way it works: :0f * ^X-Mailinglist: opensuse-es | /usr/bin/formail -bfi 'Reply-To: "oS-es" ' :0 aw: y_gml_os-unifd.lock # $HOME/Mail/_Lists/y_gml_os-unifd | $DELIVER -m _Lists/y_gml_os-unifd :0f * ^X-Mailinglist: opensuse | /usr/bin/formail -bfi 'Reply-To: "OS-en" ' :0 aw: y_gml_os-unifd.lock | $DELIVER -m _Lists/y_gml_os-unifd And the log shows it: procmail: [13582] Wed Aug 20 13:24:37 2014 procmail: Locking "y_gml_os-unifd.lock" procmail: Executing "/usr/lib/dovecot/dovecot-lda,-m,_Lists/y_gml_os-unifd" procmail: [13582] Wed Aug 20 13:24:38 2014 procmail: Assigning "LASTFOLDER=/usr/lib/dovecot/dovecot-lda -m _Lists/y_gml_os-unifd" procmail: Unlocking "y_gml_os-unifd.lock" procmail: Notified comsat: "cer@:/usr/lib/dovecot/dovecot-lda -m _Lists/y_gml_os-unifd" - From opensuse-factory+bounces-55636-robin.listas=gmail.com@opensuse.org Wed Aug 20 13:24:28 2014 Subject: Re: [opensuse-factory] wicked wicked, again Folder: /usr/lib/dovecot/dovecot-lda -m _Lists/y_gml_os-unifd 5975 procmail: [13603] Wed Aug 20 13:24:39 2014 procmail: Locking "y_gml_os-unifd.lock" procmail: Executing "/usr/lib/dovecot/dovecot-lda,-m,_Lists/y_gml_os-unifd" procmail: Assigning "LASTFOLDER=/usr/lib/dovecot/dovecot-lda -m _Lists/y_gml_os-unifd" procmail: Unlocking "y_gml_os-unifd.lock" procmail: Notified comsat: "cer@:/usr/lib/dovecot/dovecot-lda -m _Lists/y_gml_os-unifd" - From opensuse+bounces-162861-robin.listas=gmail.com@opensuse.org Wed Aug 20 13:24:29 2014 Subject: Re: [opensuse] Re: Why is dovecot using user home directory? Folder: /usr/lib/dovecot/dovecot-lda -m _Lists/y_gml_os-unifd 8183 which I understand is the correct flow. Of course, it is a nuisance having to specify a different lock file on each rule, and the same lock file for those rules writing to the same folder... Pity that procmail can't call dovecot-lda without a pipe, or some other automatic method to determine the destination folder and thus better create the correct lock file automatically. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlP0iTkACgkQtTMYHG2NR9WdWACgheYmO41Qm+insd1vPU1DA+vv xaUAn0ly9rFrDg8u3G6QvsiAAz0u/yTN =cp8b -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 01:52 AM, Charles Philip Chan wrote:

The advantages of using dovecot-lda is:

,---- | * Mailbox indexing during mail delivery, providing faster mailbox access later | | * Quota enforcing by the quota plugin | | * Sieve language support by the Pigeonhole sieve plugin `----

Thank you Charles, I'll look into adopting this. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [08-19-14 08:31]: [...]

Yes, you can do it explicitly in fetchmail, but you can let fetchmail simply handle over the email to the system MTA (postfix), which explicitly finally handles it over to the LDA, typically procmail.

It is explicitly set, but in a different config file :-)

as in (excerpt from .fetchmailrc): mda '/usr/lib/sendmail -i -oem -f %F %T' which then hands off to local procmail -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Anton Aylward [08-19-14 09:22]: [...]

1. Yes, but it might not. What it does depends on how sendmail/postfix has been configured. Perhaps, just perhaps, you've tried setting up spam/av checking and got it wrong under some fringe condition. Perhaps you've got some alias you weren't aware of. Perhaps there's some other fringe error. After all, Postfix is very very complex!

2. The spam/av processing can be done within procmail so why not eliminate the sendmail/postfix step and have fetchmail hand off to local procmail directly?

What this boils down to is this:

Do you have a good reason to apply the processing that can *only* be carried out by sendmail/procmail in this path?

I poured over this and could not find any.

Please note: I'm not saying "Postfix is not needed" in any universal sense. I said "in this path".

I have postfix and by fetchmail handing to postfix I get *all* mail logged in /var/log/mail, ie: not just fetchmail's and procmail's logs. It was a *conscious* decision :^). -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-08-19 16:46, Anton Aylward wrote:

On 08/19/2014 09:51 AM, Patrick Shanahan wrote:

...

I have postfix and by fetchmail handing to postfix I get *all* mail logged in /var/log/mail, ie: not just fetchmail's and procmail's logs.

It was a *conscious* decision :^).

Same here. And other reasons, like learning to use postfix, which I use for sending, too, and to add other things like amavis.

might contain. My POV is 'why keep logs unless you are inspecting them?'.

Because when there is a problem, and they come, eventually, I want to find out why, later. I also keep procmail logs... ...which are parsed by an application I wrote which then displays how many new posts I have, and on which folders. It doesn't waste any of my time to just "have logs". Just some disk space. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 08/19/2014 12:29 PM, Anton Aylward wrote:

Rogrs is my cable ISP provider. They supply the model and give out a DHCP address. Yes I know out things like DynDNS. They also perform scans and if they find a listening SMTP or http server they send a notice asking you to remove it OR ELSE YOUR SERVICE WILL BE TERMINATED ! ! !

The Rogers host name is static, so long as you don't change hardware. So, I use an alias on the DNS server I use. The only ports I have open are ssh & imaps. Also, I don't know how much scanning they do on my tunneled IPv6 addresses (I've only got 2^72 of them). Several years ago, someone from Rogers mentioned they generally don't go after people with servers, but retain the right to, for those who run popular public servers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 01:17 PM, Anton Aylward wrote:

...

...

The Rogers host name is static, so long as you don't change hardware. Mine has changed with a period of around 6 months over the last few years. YMMV.

Your IP address may change occasionally, but your host name shouldn't, unless you change your modem or router. The host name contains the MAC address for both devices.

...

...

So, I use an alias on the DNS server I use. The only ports I have open are ssh & imaps. Also, I don't know how much scanning they do on my tunneled IPv6 addresses (I've only got 2^72 of them).

Several years ago, someone from Rogers mentioned they generally don't go after people with servers, but retain the right to, for those who run popular public servers. I have had such notice and know a few others who have. Mine was for SMTP, other were for http, none of who said they had much traffic. I once worked in another part of Rogers and did ask they said yes it was policy and yes they did scan. Until about 5 years ago I ran a port watcher since my NATing f/w was a Linux box (its now a NETGEAR switch) and I saw a scan every five or six weeks. Maybe things have changed since then.

I don't know anything about the IPV6 situation.

With IPv4, they have only 1 or 2 addresses to scan. As I mentioned, I have 2^72 possible IPv6 addresses. Those addresses would take a bit longer to scan, assuming they even knew what IPv6 subnet I have. To determine that, they'd have to do deep packet inspection of the tunnel packets. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19 Aug 2014, opensuse@antonaylward.com wrote:

Yes, did all that. But like James, Rogers imposes a restriction. I can't run a server, web or SMTP. Rogrs is my cable ISP provider. They supply the model and give out a DHCP address. Yes I know out things like DynDNS. They also perform scans and if they find a listening SMTP or http server they send a notice asking you to remove it OR ELSE YOUR SERVICE WILL BE TERMINATED ! ! !

Wow, I am glad that I am not with Rogers- I am with Bell (Fibe 25). Tech support sucks, but at least I can run my servers. Charles -- Linux is obsolete (Andrew Tanenbaum)

On 08/19/2014 12:29 PM, Anton Aylward wrote:

Instead of beating around the bush, lets have a good look at logs, ok? :-)

Assuming that logging, adequate in detail, has been enabled. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 09:22 PM, Carlos E. R. wrote:

On 2014-08-20 02:40, Anton Aylward wrote:

...

On 08/19/2014 12:29 PM, Anton Aylward wrote:

...

Instead of beating around the bush, lets have a good look at logs, ok? :-)

Assuming that logging, adequate in detail, has been enabled.

Which I explained on another post how to do.

And I've explained in detail to James how to get fetchmail working with Rogers, the ISP we both use, and have sent him my configs. But the result? I suspect there has been some 'cherry-picking'[1] going on as I've already mentioned. So yes, lets see the logs and yes lets hope that they are detailed enough. Note: I think the second definition below, the 'incomplete evidence' is very pertinent here. I've asked for these logs, for the result of telnet sessions and more. [1] http://www.urbandictionary.com/define.php?term=cherry%20picker http://en.wikipedia.org/wiki/Cherry_picking_%28fallacy%29 -- The radical of one century is the conservative of the next. The radical invents the views. When he has worn them out, the conservative adopts them. --Mark Twain -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Let me repeat: if its local, as it is with the single use systems James and I are dealing with, then there is no need for the complex and powerful capability of Postfix to be between a fetchmail for local deliver and a procmail that does filtering of local delivery.

---- I agree.... I never moved away from sendmail, myself... ;-) Only hiccup I had was in some upgrade my access rules got thrashed and someone found a way to route emails through my server...Seems the upgrade didn't move forward old values... Oh yeah, and recently there was a bad thing about ntpd being used to flood people because you can have ntpd remotely dump a log of everyone who has contacted it in some previous period of time... That was just a matter of restricting some remote administrative queries that should have shipped that way, but who would'a' thought of using ntpd for DoS's? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/19/2014 05:59 PM, Carlos E. R. wrote:

On 2014-08-19 23:36, Linda Walsh wrote:

...

Anton Aylward wrote:

...

Let me repeat: if its local, as it is with the single use systems James and I are dealing with, then there is no need for the complex and powerful capability of Postfix to be between a fetchmail for local deliver and a procmail that does filtering of local delivery.

---- I agree.... I never moved away from sendmail, myself... ;-)

What? I find sendmail even more complex than postfix.

The issue with sendmail isn't that its complex so much as that its arcane and obscure. But if you are using fetchmail/procmail for incoming email there is no need for either. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-08-20 01:52, Linda Walsh wrote:

Anton Aylward wrote:

...

On 08/19/2014 05:59 PM, Carlos E. R. wrote:

...

On 2014-08-19 23:36, Linda Walsh wrote:

...

Anton Aylward wrote:

...

there is no need for the complex and powerful capability of Postfix to be between a fetchmail for local deliver and a procmail that does filtering of local delivery.

---

I agree.... I never moved away from sendmail, myself... ;-) What? I find sendmail even more complex than postfix.-- Sigh... even a dry smile isn't caught these days... oh well... I mean, um, what are you talking about complex, it's as clear as M4 macro language! Er.... um....

Ah, ok! M4! Yes, clear as mud, yes, LOL!

...

But if you are using fetchmail/procmail for incoming email there is no need for either.

---

Depends on your need. If you use both maildir and mbox, using a standard delivery system might be a good idea. I'm thinking an MTA was configured on his old system (suse used to be good about those things), but now I bet it's broken due to recent system startup changes... If that's the case, maybe finding what was there before, and putting it back might be the shortest route to solving the problem...

Nay, the MTA is not broken on systemd systems. It works out of the box, as always. Maybe, just maybe, you have to just run YaST mail module just once, in simple mode, accepting defaults (and not configuring fetchmail in there). But this has been the same for decades. Instead of beating around the bush, lets have a good look at logs, ok? :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-20 03:47, Linda Walsh wrote:

Carlos E. R. wrote:

...

Nay, the MTA is not broken on systemd systems. It works out of the box, as always. Maybe, just maybe, you have to just run YaST mail module just once, in simple mode, accepting defaults (and not configuring fetchmail in there). But this has been the same for decades.

I agree, I spoke too soon on that because he already said he WAS getting his email except for his INBOX. Given that, I think the problem is in him trying to use maildir format for his inbox. That's non-standard and likely to cause problems. I am all but certain sendmail doesn't support that and think it would be unlikely for postfix to support that for '/V/S/M'...

Different format and different place. Both problems.

But he hasn't answered back for a while, so maybe he succumbed to sleep? Saw his 1st email this morning at 7am -- hadn't even been to sleep yet. (I don't sleep regular hours and sometimes not at all... really helps my concentration....NOT).

I know that feeling O:-)

...

Instead of beating around the bush, lets have a good look at logs, ok? :-)

Logs? he's on systemd -- aren't the logs in binary somewhere -- if they aren't cleared? I.e. some systemd proponents thought logging wasn't that necessary and that they could be tossed each boot for most users...so he may have to go generate some before we can read them.

But openSUSE folks filter down some of those things, and thus we still have traditional syslog by default :-)

Anyway, have to wait for him to respond (poor him, he has larry, curly and moe performing surgery on his email...!)...

:-)) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-20 13:05, Per Jessen wrote:

Carlos E. R. wrote:

...

But openSUSE folks filter down some of those things, and thus we still have traditional syslog by default :-)

We do? ISTR having to select it explicitly every time.

Not me. You have to select a syslog manually on 13.1 on install? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-20 13:40, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2014-08-20 13:05, Per Jessen wrote:

...

Carlos E. R. wrote:

...

But openSUSE folks filter down some of those things, and thus we still have traditional syslog by default :-)

We do? ISTR having to select it explicitly every time.

Not me. You have to select a syslog manually on 13.1 on install?

Yep, I'm pretty certain - at least with minimal server/text-mode install.

AH! Minimal install. I refuse to ever install the "minimal" pattern, because it is exceedingly minimal for a server: there are crucial components missing for a server. You have to manually add a lot. Minimal pattern should be a different pattern than a text-server pattern. I install at least the minimal X pattern, and I prefer the XFCE pattern. I also refuse to accept that a Linux server has to be text only - even if I have it boot in text mode by default, I can login in graphical mode when I want. Of course, I don't use headless servers, that might be a difference. But even in that case, I'd probably use the same graphical pattern, to make sure I can login remotely with graphical tools (like yast in QT flavour). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 08/19/2014 09:47 PM, Linda Walsh wrote:

Carlos E. R. wrote:

...

Nay, the MTA is not broken on systemd systems. It works out of the box, as always. Maybe, just maybe, you have to just run YaST mail module just once, in simple mode, accepting defaults (and not configuring fetchmail in there). But this has been the same for decades.

I agree, I spoke too soon on that because he already said he WAS getting his email except for his INBOX. Given that, I think the problem is in him trying to use maildir format for his inbox. That's non-standard and likely to cause problems.

Will you please stop propagating this nonsense that maildir is non standard. Its a reliable standard that has been in use for getting on for 40 years, it long pre-dates Linux, long pre-dates UNIX on PCS. It history goes back to the MH messaging system and was based on the idea that the shell/text tools make more sense when email is in a one-message-per-file format. If that 'stinks' of CLI-ness, then yes, and it tells you how old this is.

I am all but certain sendmail doesn't support that and think it would be unlikely for postfix to support that for '/V/S/M'...

And that too is misinformation as a light browse of the Postfix documentation shows. For example, this shows how to set Postfix to use a maildir in the user's home directory: http://www.postfix.org/postconf.5.html#home_mailbox Googling for 'sendmail + maildir" produces plenty of how-to pages. So you assertions are misinformation. None of this is difficult, it is just that it requires *all* the config files to say the same thing. http://www.ioncannon.net/system-administration/97/using-fetchmail-and-procma... http://pbraun.nethence.com/unix/mail/sendmail_procmail_dovecot.html Part of the fallacy you are promulgating is false because: ** It's not actually sendmail that saves the messages on final delivery, but the local mail delivery process that sendmail hands the message off to. ** Sendmail and postfix both honour the .forward, so the moment ether of them deliver to the user whatever is in the dot-forward takes over. That is probably procmail. Anyway, it constitutes a local delivery agent.

...

Instead of beating around the bush, lets have a good look at logs, ok? :-)

Logs? he's on systemd -- aren't the logs in binary somewhere -- if they aren't cleared? I.e. some systemd proponents thought logging wasn't that necessary and that they could be tossed each boot for most users...so he may have to go generate some before we can read them.

Once again, Linda, you are spreading misinformation. Logs are whatever you want them to be; systemd only logs what systemd does. Your oft-stated anti-systemd prejudices are showing and have no relevance here so please put them back in the box. As Carlos and I have made very clear in this thread, all these components can log directly to a file or to syslog. The point is that you need to enable that and to make sure the logging level is, as I keep pointing out, adequate. Setting it to "error" is of no use when you want "debug". Please, Linda, stop spreading misinformation. Most of your assertions about what these things cannot do is easy disproved by a few seconds with google. Many of us get annoyed when we are told that things we've been doing for years and years with not problems are 'impossible'. Back to my point about the verb and the noun. -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/20/2014 04:57 PM, Linda Walsh wrote:

Anton Aylward wrote: snippage 8< >8.

...

Will you please stop propagating this nonsense that maildir is non standard. Its a reliable standard that has been in use for getting on for 40 years, it long pre-dates Linux, long pre-dates UNIX on PCS.

----- 40 years? Not really

From my recall maildir came into being with djb's qmail in the late 90's / early 2000s There were similar mailbox formats before that, but not maildir as described here: http://www.qmail.org/qmail-manual-html/man5/maildir.html and until then, sendmail and mbox WERE the standard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2014-08-20 at 16:57 -0700, Linda Walsh wrote:

It might come down to usage, but putting each message in a separate file generally will waste space, time, resources... human time and cpu time...

As everything in engineering, things have different sides. Things have both advantages and disadvantages. Yes, maildir is slower on some operations, like searches, or anything that requiries reading or writing a whole folder. On the other hand, it is faster at deleting emails, or adding them. Specially deleting an email: in mbox, it means copying the file, and skipping one chunk - or marking some chunks as deleted, and do the actual deletion when the folder is compacted (in thunderbird you do this operation explictly; if you don't, folders grow huge). Then mbox is faster in normal operation (reading, browsing), it is more compact. But a file corruption could destroy the whole folder (never happened to me). However, being a plain text file, it can be probably reconstructed. On maildir, a file corruption damages a single email. Then there are more advanced, newer formats: for instance, you can combine both methods, and have a bunch of posts in the same file up to some acceptable limit, and then switch to another file. For instance, Pine and uw-imap has one such format, called "mix" (http://en.wikipedia.org/wiki/MIX_%28Email%29). And dovecot has "mdbox" (I believe MIX is better). And all are mutually incompatible, not suported by other components :-( I knew this since years, but you have a very nice summary here: http://wiki2.dovecot.org/MailboxFormat Maildir is widely suported, yes. But mbox is still the only one universally supported format.

Here is the result of putting 238940 in a folder. Each of them are 1k long -- an average email message. I am using a larger number than one would normally have in a folder to allow comparison of methodology, not that email clients using email would have this many messages in 1 folder.

If you run the comparison on reiserfs, the figures are not that different.

That it takes almost 4x the space is bad enough, but that it 200-300 times slower is the real bear.

Some operations are faster - like deleting. Compacting is not needed. Ah, but you forget the huge number of inodes used :-p - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlP1VoQACgkQtTMYHG2NR9XTlQCeNuapl+OcmvpsVvHtTW2p6o4i tpoAnRswRLfa8puOjjAozx7E/glGfsWL =FqoC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-08-21 14:02, Anton Aylward wrote:

On 08/20/2014 10:16 PM, Carlos E. R. wrote:

...

Ah, but you forget the huge number of inodes used :-P

Not an issue with the b-tree-like FS such as ReiserFS, XFS and BtrFS.

Yes, it is is an issue on btrfs, as I demonstrated it with a test that I published here. The filesystem crashes completely if you create "too many" small files, and speed diminishes hugely before that. There is an unsolved bugzilla on it. XFS adjusts the equivalent of inodes dynamically, it adapts, but nevertheless, it has a limit. The recommendation is to tune the filesytem, on creation time, for many small files. ext2/3/4 has a fixed number of inodes, but it can also be tuned for a large number of small files. Reiserfs is the only filesystem that has no issues with the situation, and is way faster than the rest (in this situation). But development is stuck, and it scales badly (only one thread is used for all the reiserfs partitions you have, regardless of the number of cores you have). It is possible that it disappears from the distribution not far in the future - in 13.1 you can not create a reiserfs in YaST, for instance, support has already been removed there.

Nor is the 'growth' of the size of the directory & compacting it nor, if you set up the options to start with, sorting huge directories.

It is an issue in the sense that it impacts performance a lot. You only need to run tests on large mail folders using several formats, and compare. Some workloads run faster on maildir, and some on mbox. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-08-21 15:31, Anton Aylward wrote:

On 08/21/2014 08:33 AM, Carlos E. R. wrote:

...

Yes, it is is an issue on btrfs, as I demonstrated it with a test that I published here. The filesystem crashes completely if you create "too many" small files, and speed diminishes hugely before that. There is an unsolved bugzilla on it.

Date on that? Details?

Date: Mon, 21 Oct 2013 00:52:15 +0200 (CEST) From: Carlos E. R. <> To: OS-fctry Subject: [opensuse-factory] [13.1 RC1] I managed to destroy a btrfs - anyone wants to investigate it? https://bugzilla.novell.com/show_bug.cgi?id=846807 Reported 2013-10-21, last activity 2013-10-22

...

XFS adjusts the equivalent of inodes dynamically, it adapts, but nevertheless, it has a limit. The recommendation is to tune the filesytem, on creation time, for many small files.

ext2/3/4 has a fixed number of inodes, but it can also be tuned for a large number of small files.

Reiserfs is the only filesystem that has no issues with the situation, and is way faster than the rest (in this situation). But development is stuck, and it scales badly (only one thread is used for all the reiserfs partitions you have, regardless of the number of cores you have). It is possible that it disappears from the distribution not far in the future - in 13.1 you can not create a reiserfs in YaST, for instance, support has already been removed there.

Have a look at this post: Date: Tue, 6 May 2014 16:11:12 +0200 (CEST) From: Carlos E. R. <> To: OS-EN Subject: [opensuse] Total system crash when test writing to reiserfs partition. Basically, it happens when writing many files with dd and "conv=fdatasync" to a reiserfs partition. https://bugzilla.novell.com/show_bug.cgi?id=879778

That's a good summary. Many feel that BtrFS is going to replace ReiseFS and give their rationalization, but as you point out its not quite there yet. The standardizing/default of BtrFS and the removal or ReiserFS are premature, and I say that as someone who supports BtrFS.

Well, I wanted precisely to test if btrfs could replace reiserfs in that exact task, millions of small files in a single directory (if it works in a single directory, it will work also on many directories: a single one is more stress). And it failed. And no, I'm not happy with it.

My own experimentation shows that BtrFS works best on huge file systems that have no physical partitioning. That is no separate /home/ usr, /var and so on. It optimizes and balances the whole damn lot.

Yes, that's a design point. But it goes against my ingrained practices of decades: having several smaller partitions, so that a problem in one can not affect others.

I suspect, or is that fear, that the optimization of BtrFS will eventually do this:

Oh look! That sector of that file and this sector of this other file are the same byte-for-byte so lets link then both to single copy and tag it for COW.

Maybe. Interesting idea.

And so all of the /usr/bin and /usr/lib will be optimized to hell.

What I want is compression, and that part is not stable yet. And I also want CRC of data on the metadata, and verified. XFS is working on this idea, I think.

No, really, with all of a 4T drive as a single BtrFS what's the odds that there are two files with a sector the same? I run FSLint and I find I have quite a number of duplicate files at the size&md5 level and sometimes even the name is the same or similar. LOTS of them. More than the space wasted by maidir messages not filling all of 4K partitions, which is a non issue on my ReiserFS where INBOX lives because of the way, as you say, Carlos, that ReiserFS deals with inodes and how it packs small chunks. Aren't Btrree's wonderful?

Sometimes the way BtrFS is developing scares me.

Yes... kind of, yes.... That reminds me. One project I have on very backstage-low-priority is something to generate checksums of files on given paths, then locate files with the the same checksums, and offer to rename them the same way. I need that in order to sync several copies of the same files on different disks, so that the name match and are easier to locate (the files are very big, perhaps a terabyte or two in total, so copying them from place to place, although works, is slow and a pain).

...

...

Nor is the 'growth' of the size of the directory & compacting it nor, if you set up the options to start with, sorting huge directories.

The problem with ext-series is that you have to know about it at Mkfs time. Yast and Installer aren't great about advising you on this issue and the values in mke2fs.conf are someone else's idea of what you should use; not as flexible as ReiserFS.

True.

...

It is an issue in the sense that it impacts performance a lot. You only need to run tests on large mail folders using several formats, and compare. Some workloads run faster on maildir, and some on mbox.

"Context is Everything". Which is why I use both maildir and mbox .... in different contexts.

:-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Carlos E. R. wrote:

Yes, maildir is slower on some operations, like searches, or anything that requiries reading or writing a whole folder. On the other hand, it is faster at deleting emails, or adding them. Specially deleting an email: in mbox, it means copying the file, and skipping one chunk - or marking some chunks as deleted, and do the actual deletion when the folder is compacted (in thunderbird you do this operation explictly; if you don't, folders grow huge).

You *can* do them explicitly ... or you can set to happen automatically when it will save more than "xx"%. Also an index is sometimes stored in the first message that remains fixed in size and allows for marking messages deleted w/o rewriting the whole mess. Another issue I worry about on files -- ACL's. Linux doesn't do ACL's as well as NTFS. Anything with a default ACL, creates an extra data segment to access if the ACL doesn't fit in the inode (which is likely for any but the simplest of ACLs).

Then mbox is faster in normal operation (reading, browsing), it is more compact. But a file corruption could destroy the whole folder (never happened to me). However, being a plain text file, it can be probably reconstructed. On maildir, a file corruption damages a single email.

Not relevant. I have daily backups and snapshots (both -- serving different needs).

Then there are more advanced, newer formats: for instance, you can combine both methods, and have a bunch of posts in the same file up to some acceptable limit, and then switch to another file. For instance, Pine and uw-imap has one such format, called "mix" (http://en.wikipedia.org/wiki/MIX_%28Email%29). And dovecot has "mdbox" (I believe MIX is better).

---- Yeah, I could see some use for that in some cases, but on my system, optimal io-xfer unit is calced to be 12*64k or 768k, but I also know that I get my fastest disk-io if I do r/w of 32-64MB in 1 call. My fastest Network IO is close to that... about 8-16MB. Using 8MB iosizes: --- R:512+0 records in 512+0 records out 4294967296 bytes (4.0GB) copied, 6.27631 s, 652.6MB/s W:512+0 records in 512+0 records out 4294967296 bytes (4.0GB) copied, 6.29395 s, 650.8MB/s -------------- Not always that fast, but that's ball park top speed for sequential I/O. disk max sequential is about 2x that. So I know with great certainty that I can read and write an entire mbox-file in less time than it would take just read a fraction of them if they were in separate files.

Ah, but you forget the huge number of inodes used :-p

--- Not when each has an ACL on them as well...I tried to make sure that on my new disk, I created inodes at 256 bytes instead of the default 128 bytes so most of my ACL's will fit in the inode. Also given the minimum 4096-byte phys-i/o size using smaller files doesn't make much sense. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 08/20/2014 06:42 AM, Anton Aylward wrote:

Will you please stop propagating this nonsense that maildir is non standard. Its a reliable standard that has been in use for getting on for 40 years, it long pre-dates Linux, long pre-dates UNIX on PCS. It history goes back to the MH messaging system and was based on the idea that the shell/text tools make more sense when email is in a one-message-per-file format. If that 'stinks' of CLI-ness, then yes, and it tells you how old this is.

Point of order: maildir is less than 19-years old. It was invented by Dan Bernstein for use in his qmail MTA, which started in Dec 1995, as per a quick google search. Regarding usability, I prefer mbox because of its reliability and ease of access with standard text tools. Locking hasn't been an issue for me, as long as I don't mount via NFS. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

And in order to find out the actual configuration it is using, you run "doveconf -N".

dovecot -N dovecot: invalid option -- 'N' Usage: dovecot [-F] [-c <config file>] [-p] [-n] [-a] [--help] [--version] [--build-options] [reload] [stop]

He already posted the output of dovecot -n, perhaps that is what you mean? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2014-08-19 11:54, Linda Walsh wrote:

...

Carlos E. R. wrote:

...

He already posted the output of

dovecot -n, perhaps that is what you mean?

But that was before the latest changes. Better see a recent output. And I prefer -N, more context.

And it is "doveconf -N", not "dovecot -N"

doveconf -N >/tmp/one dovecot -n >/tmp/two

diff /tmp/one /tmp/two 10d9 < auth_worker_max_count = 30 18d16 < mail_fsync = optimized 21d18 < mbox_dirty_syncs = yes

Yep -- 3 more lines!... I wondered where those were in the other output... remember'd them being in the configure, but didn't remember what they were called. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org