wiki.antiguru.de

User Tools

Site Tools

You are here: start » info » mail
info:mail

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
info:mail [2015/01/23 17:01] – implemented hartmutinfo:mail [2024/02/20 11:46] (current) – [Address Mapping] hartmut
Line 9: Line 9:
 The domain of the incoming address must be one of the domains listed in ''main.cf'' property ''virtual_alias_domains''. User aliases can be defined in ''/etc/aliases''. The domain of the incoming address must be one of the domains listed in ''main.cf'' property ''virtual_alias_domains''. User aliases can be defined in ''/etc/aliases''.
  
-After editing the file, run the following commands:+If you changed the aliases, run 
 +  # postalias /etc/aliases 
 +After editing the ''virtual'' file, run the following:
   # postmap /etc/postfix/virtual   # postmap /etc/postfix/virtual
 +
 +After that,
   # postfix reload   # postfix reload
  
Line 24: Line 28:
  
 To add custom sieve scripts, I recommend installing the [[http://sieve.mozdev.org/|Thunderbird Sieve]] extension. It allows the creation and syntax checking of sieve scripts directly on the server. On Debian, it is available as ''xul-ext-sieve'' package. To add custom sieve scripts, I recommend installing the [[http://sieve.mozdev.org/|Thunderbird Sieve]] extension. It allows the creation and syntax checking of sieve scripts directly on the server. On Debian, it is available as ''xul-ext-sieve'' package.
 +
 +Important: sieve scripts will only work when formatted with DOS-type CRLF linebreaks. The above extension takes care of that.
 +
 +If you set up a new user, do not forget that dovecot looks for a .dovecot.sieve script in that user's home directory (which may be also a symlink to an include script in a sieve folder).
  
 For specific information about managing sieve on antiguru.de look at [[moritz:antiguru.de|moritz:antiguru.de]]. For specific information about managing sieve on antiguru.de look at [[moritz:antiguru.de|moritz:antiguru.de]].
  
-===== Mail aggregation aka unified inbox (proposal) =====+===== Mail aggregation aka unified inbox ===== 
 + 
 +Objective: collect email messages from several legacy freemail inboxes, pass them through a reliable virus and spam filter, and dispatch them to the IMAP inbox on the server. 
 + 
 +Benefits: reliable and controllable spam filtering, POP3 inboxes made accessible via IMAP 
 + 
 +Drawback: on clients that can't be configured otherwise, answering mails received that way will result in the answers carrying your IMAP inbox address as sender. 
 + 
 +===User Agents=== 
 +Icedove/Thunderbird and Claws Mail work without problems with the setup described. Both clients support the creation of folders and will also check for mail delivered into subfolders by the sieve scripts. 
 + 
 +Take care when creating new folders: If you don't create them as subfolders to the mailbox root, but instead as subfolders to INBOX, it may happen that you end up with an INBOX folder on the server, containing nothing but the aforementioned subfolder. This is because in this here setup, the INBOX is no folder, but only exists virtually. So: never create subfolders to INBOX, and you won't run into difficulties (like clients not even seeing these folders). 
 + 
 +When it comes to **mobile user agents**, the picture changes: The stock email app for Android Lollipop, called 'GMail', does perform rather poorly with this setup. Subfolders show up in the folder tree of the account and after they've been opened as recent labels (what seems to be Googlish for folders), too. But to see mail filed into these folders, you have to open them, they don't seem to get refreshed otherwise. Also, the overall layout of the app is very untidy and it is simply hard to use. 
 + 
 +There are a lot of mail user agents or clients for Android, but most of them are either still a whole lot more ugly than GMail, or do not offer more functionality, or are infested with ads, or have to be paid before testing, or a combination of the above. In the jolly old times of WebOS, we had one email app which did its job greatly; now we have hundreds and all do their job poorly, or so it seems. 
 + 
 +By 'doing its job' I mean: the email client should at least take note of mails appearing in subfolders, and possibly offer a unified inbox, a virtual folder where all unread mail is presented in a bundle. It should not pester you with advertisements and, if to be paid, at least be free to try out. 
 + 
 +After testing dozens of email clients, I can conclude that I found only one that matched these criteria, and even to some extent surpassed them. It is called Aquamail[[https://play.google.com/store/apps/details?id=org.kman.AquaMail&hl=en|Play Store Link]], and it offers all the quoted features (you can even control which folders to use for the virtual inbox and which folders not to scan for new mail). The paid version even seems to allow to send mail from different sender addresses, which would perfectly fit our setup, but which remains hitherto untested. The app offers a clean design, tons of options (too many, indeed, for the menus, so that another layer of menus had to be hidden behind long presses on, e.g., folders, which I had some trouble to deduce at first), a nice widget which is a) resizable and b) updates after you read/deleted a mail from the folder it shows (both being features Google seems to be unable to accomplish), and it does not use ads to get on your nerve, but decorates outgoing mails with a promotional signature (promised to disappear in the unlocked version). 
 + 
 +So far, testing Aquamail has shown very positive results. I'll keep you updated. 
 + 
 +==== TLDR; ==== 
 + 
 +Now that the system wide setup is  working, it is simple to add a service that is polling an external inbox into your user's IMAP inbox here. Just create a file called .fetchmailrc in your user directory and adjust the  
 +permissions so that fetchmail is going to accept them. 
 +<code> 
 +  $ touch ~/.fetchmailrc 
 +  $ chmod 0600 /etc/fetchmailrc 
 +</code> 
 +Then, edit this file to match your credentials for the inbox you want to poll: 
 +<code> 
 +#log to system log - enable after verifying your setup 
 +#set syslog 
 +poll pop.gmx.net protocol pop3: 
 + username "XXXXXX" password "..........", is someuser here smtphost localhost/2345 
 +  # use secure connection relying on CA certificates 
 +  ssl 
 +  # do not delete from server (for testing) 
 +  keep 
 +  # get all messages, not just the ones that arrived after the last poll (use this after commenting out keep) 
 +  #fetchall 
 +</code> 
 +Now, run fetchmail verbosely: 
 + 
 +  $ fetchmail -v 
 + 
 +and check the output. If all is well, change the .fetchmailrc to delete messages from the remote inbox and log to system log, and add it to your crontab, so that it will be executed regularly by the system. 
 + 
 + 
 +  $ crontab -e 
 +   
 +Add a line like this to your crontab: 
 +<code> 
 +*/5 * * * * /usr/bin/fetchmail &> /dev/null 
 +</code> 
 +(this will poll every 5 minutes). Then, save and exit the editor. Now, the fetchmail job will run unattended as set in the crontab. 
 + 
 +Once this works, one could filter mail using the sieve method described above. 
 + 
 + 
 +==== For the administrator ==== 
 + 
 +To fine-tune the setup, there are some things to be taken into account: 
 +  * spam scores: In /etc/amavis/50-user, we define numerical spam score levels. The sa_tag2_level_deflt variable lets the spam filter decide if a mail is to be considered SPAMMY. This variable is set to 4.51 on our server at the time of writing, which may have to be adjusted after a test period. 
 +  * spam from the inboxes polled by fetchmail will be silently deleted when the score of sa_kill_level_deflt (now 20) is reached. You might want to review the logs for some time to look for false-positives being discarded. 
 +  * on the server, the rewriting of the subject lines of messages considered spam has been disabled. This makes it easier to deal with false positives. Just move them out of the spam folder. 
 +  * learning: do not delete true spam messages. After collecting lots of them, they should be used to train the spam filter. 
 +  * Ports: now, all clients submitting messages on port 465 (smtps) are considered local. Check if this is a valid assumption. If not, modify the system to accept these submissions on port 587 (submission). See below. 
 + 
 +==== Setup details  ====
  
-The setup described does now fulfill the expectations. Amavisd does now scan and decorate mails from fetchmail. But it has not yet been implemented on the 'real' server.+The setup described does now fulfill the expectations. Amavisd does now scan and decorate mails from fetchmail.
  
 After lots of trials which didn't work, I decided to move away from the production server. After lots of trials which didn't work, I decided to move away from the production server.
Line 95: Line 174:
 # the MX record (or backup mailers) should point to this IP address # the MX record (or backup mailers) should point to this IP address
 # set to your external IP address # set to your external IP address
-# this does not work when you want to run this service chrooted, see below+# this does not work when you want to run this service chrooted
 #192.168.100.233:smtp inet  n  -  n  -  -  smtpd #192.168.100.233:smtp inet  n  -  n  -  -  smtpd
 #  -o content_filter=amavisfeed:[127.0.0.1]:10040 #  -o content_filter=amavisfeed:[127.0.0.1]:10040
Line 130: Line 209:
 <code> <code>
 # regular incoming mail, originating from anywhere (usually from outside) # regular incoming mail, originating from anywhere (usually from outside)
 +# this works chrooted if you've set a content filter in main.cf
 +# like so:  content_filter = amavisfeed:[127.0.0.1]:10040
 +# (this name must match the one given above).
 # the MX record (or backup mailers) should point to this IP address # the MX record (or backup mailers) should point to this IP address
 # set to your external IP address # set to your external IP address
Line 135: Line 217:
 </code> </code>
 Of course, you'll have to enter the external IP address of your mail server (MX record) here. Of course, you'll have to enter the external IP address of your mail server (MX record) here.
-This will run the smtp service that can be reaches from outside in a chroot environment.+This will run the smtp service that can be reached from outside in a chroot environment. 
 + 
 +For roaming users reaching the server via smtps, we add a content filter to map them to our local port for amavisd: 
 +<code> 
 +smtps     inet  n       -       -       -       -       smtpd 
 +  -o smtpd_tls_wrappermode=yes 
 +  -o smtpd_sasl_auth_enable=yes 
 +  -o smtpd_client_restrictions=permit_sasl_authenticated,reject 
 +  -o milter_macro_daemon_name=ORIGINATING 
 +  -o content_filter=amavisfeed:[127.0.0.1]:10042 
 +</code> 
 +(just the last line was added!). 
 + 
 +===Still problematic=== 
 + 
 +But this assumes that only roaming clients will connect to the smtps port, which possibly is false. 
 + 
 +So, I think it would actually be preferable to separate the roaming user service from the other smtp(s) services. That's where the port used for mail submission comes in (port 587), it is in postfix' master.cf. 
 +We'll have to take care that the chroot works for this too, and move the content flter for port 10042 to this service in master.cf.  And we'll need to open it in the firewall. Then, we'll have to change the port for the roaming smtp clients accordingly, so that the new submission path will be used.  
  
 Finally, look for a line like this and comment it out as shown. Finally, look for a line like this and comment it out as shown.
Line 146: Line 247:
  
    * listen on the external IP address as smtp server and hand over mail from there to amavis at port 10040    * listen on the external IP address as smtp server and hand over mail from there to amavis at port 10040
 +   * listen on the smtps port and hand over email messages received there to amavis at port 10042
    * listen on the local loopback email address at port 2345 as smtp server and hand over mail from there to amavis at port 10041    * listen on the local loopback email address at port 2345 as smtp server and hand over mail from there to amavis at port 10041
    * listen on the local loopback email address as smtp server and hand over mail from there to amavis at port 10042    * listen on the local loopback email address as smtp server and hand over mail from there to amavis at port 10042
Line 188: Line 290:
 # regular incoming mail, originating from anywhere (usually from outside) # regular incoming mail, originating from anywhere (usually from outside)
 $policy_bank{'EXT'} = { $policy_bank{'EXT'} = {
-  originating => 1, 
 }; };
  
Line 203: Line 304:
  
 # mail locally submitted on the host on which MTA runs # mail locally submitted on the host on which MTA runs
 +# or submitted via the smtps port by roaming users
 $policy_bank{'INT-HOST'} = { $policy_bank{'INT-HOST'} = {
 +  originating => 1,
     # NOTE: this is just an example; ignoring internally generated spam     # NOTE: this is just an example; ignoring internally generated spam
     # may not be such a good idea, consider zombified infected local PCs     # may not be such a good idea, consider zombified infected local PCs
info/mail.1422032493.txt.gz · Last modified: 2015/01/23 17:01 by hartmut
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki