alle E-mail via IMAP op home server

[Rukapul]

Ik ben bezig thuis de mail de centraliseren op de Debian home server. Het doel is om in plaats van met terminal server te connecten naar de vaste PC om met de diverse laptops, webmail en smartphones bij de mail te kunnen.

De situatie tot zover:
• dovecot geinstalleerd
• fetchmail geinstalleerd
• procmail geinstalleerd
• squirrelmail geinstalleerd

De basis werkt, maar misschien dat iemand al commentaar heeft op het bovenstaande?

Er zijn nog een aantal openstaande issues:
• hoe mail van een bepaald account in een bepaalde folder van een user binnen te laten komen? De match moet hard op het account plaatsvinden en niet op een matching rule op het To or From field, etc., die fout kan lopen. Fetchmail en procmail moeten hier samenwerken, maar hoe?
• is er een (webbased) frontend om serverside rules aan te maken ter vervanging van de rules die nu in de client staan zoals het verplaatsen naar folders? Op zich valt er met matching rules in procmailrc wel wat op te vangen, maar dat is iets minder geschikt voor de WaF

[blaataaps]

Ik zou getmail en maildrop gebruiken ipv fetchmail en procmail.
Ik weet niet precies hoe de users gescheiden zijn, maar als iedereen z'n aparte getmail heeft zie ik niet hoe ze bij de verkeerde user kunnen komen? En anders is er nog de delivered-to header of iets dergelijks.

Dovecot ondersteunt het sieve-protocol voor remote instellen van sorteerregels, zonder ftp/shell-toegang, met plugins voor de meeste gangbare (web)mailclients.

[ Voor 6% gewijzigd door blaataaps op 13-11-2009 23:01 ]

[Rukapul]

blaataaps schreef op vrijdag 13 november 2009 @ 23:01:
Ik zou getmail en maildrop gebruiken ipv fetchmail en procmail.

Ga ik uitzoeken.

Ik weet niet precies hoe de users gescheiden zijn, maar als iedereen z'n aparte getmail heeft zie ik niet hoe ze bij de verkeerde user kunnen komen? En anders is er nog de delivered-to header of iets dergelijks.

Verkeerde users is het punt niet. Het gaat om mailinglists die een aparte 'inbox' folder moeten hebben, terwijl de normale mail van dezelfde user in de echte mailbox terecht komt

Een header die het account identificeert is ook prima inderaad.

Dovecot ondersteunt het sieve-protocol voor remote instellen van sorteerregels, zonder ftp/shell-toegang, met plugins voor de meeste gangbare (web)mailclients.

Ga ik ook uitzoeken

[Boudewijn]

blaataaps schreef op vrijdag 13 november 2009 @ 23:01:
Ik zou getmail en maildrop gebruiken ipv fetchmail en procmail.

Waarom dat?

[blaataaps]

Rukapul schreef op vrijdag 13 november 2009 @ 23:24:
[...]


Verkeerde users is het punt niet. Het gaat om mailinglists die een aparte 'inbox' folder moeten hebben, terwijl de normale mail van dezelfde user in de echte mailbox terecht komt

Een header die het account identificeert is ook prima inderaad.

Mailinglists hebben vaak ook een List-id header.

Boudewijn schreef op vrijdag 13 november 2009 @ 23:57:
[...]

Waarom dat?

Omdat die een leesbare config hebben, en m'n mail niet kwijtmaken

[vanaalten]

Wat betreft smartphones (je noemt alleen het merk/type niet...):
Ik gebruik ook Dovecot, eigenlijk een beetje de standaard installatie, en heb sinds gisteren Profimail op mijn telefoon geinstalleerd. Lijkt perfect te werken: je kan twee access punten instellen, dus in mijn geval m'n wifi-netwerk en T-mobile data. Profimail & Dovecot ondersteunen IMAP-idle, dus heb ik daarmee push-e-mail op m'n Nokia E52.

IMAP gebruik ik secure (IMAPs, poort 993) via SSL/TLS; SMTP via poort 25 en TLS. Volgens mij heb ik het allemaal daarmee goed beveiligd, maar het voelde wel onplezierig aan om die poorten op de router & server open te zetten.

[Rukapul]

blaataaps schreef op zaterdag 14 november 2009 @ 09:22:
[...]

Mailinglists hebben vaak ook een List-id header.

Nadeel daarvan is dat je blijft configureren voor elke individuele mailinglist.

getmail en maildrop draaien inmiddels in rudimentaire vorm, maar nog niet helemaal ideaal.

Ik heb flink wat mailinglist subscription die mail afleveren aan <naam>@mijndomein.com. In het control panel van DirectAdmin heb ik ooit eens de moeite genomen om die te forwarden naar [e-mail]. Wat ik nu wil is dat mail op [e-mail] wordt afgeleverd in een aparte maildir folder. Echter, door de forwards kan getmail geen eenduidige Delivered-To header maken.

Oplossing die ik nu zie is het gebruiken van meerdere configuratiefiles per account (zoals hieronder), maar liever zou ik zelf een header invoegen in getmail (/fetchmail) per account en maildrop daarop laten filteren.

maildroprc:

SHELL="/bin/bash"
SENDMAIL="/usr/sbin/sendmail -oi -t"
logfile "/var/log/maildrop.log"

DEFAULT="$HOME/.Maildir/"

.mailfilter:

DEFAULT = "$DEFAULT/.lists.INBOX"

Omdat die een leesbare config hebben, en m'n mail niet kwijtmaken

getmail is dan wel leesbaar, maar vereist een configuratiebestand per account wat fetchmail niet nodig heeft

[ Voor 7% gewijzigd door Rukapul op 15-11-2009 14:57 ]

[blaataaps]

Rukapul schreef op zondag 15 november 2009 @ 14:51:
[...]

Nadeel daarvan is dat je blijft configureren voor elke individuele mailinglist.

getmail en maildrop draaien inmiddels in rudimentaire vorm, maar nog niet helemaal ideaal.

Ik heb flink wat mailinglist subscription die mail afleveren aan <naam>@mijndomein.com. In het control panel van DirectAdmin heb ik ooit eens de moeite genomen om die te forwarden naar [e-mail]. Wat ik nu wil is dat mail op [e-mail] wordt afgeleverd in een aparte maildir folder. Echter, door de forwards kan getmail geen eenduidige Delivered-To header maken.

Is er ook geen x-original-to of iets dergelijks?

Oplossing die ik nu zie is het gebruiken van meerdere configuratiefiles per account (zoals hieronder), maar liever zou ik zelf een header invoegen in getmail (/fetchmail) per account en maildrop daarop laten filteren.


getmail is dan wel leesbaar, maar vereist een configuratiebestand per account wat fetchmail niet nodig heeft

Klopt, ik heb inderdaad ook 1 .getmail-directory met een bestandje voor elke directory. Het punt van de leesbaarheid gaat ook vooral op voor procmail versus maildrop voor mij

[Rukapul]

blaataaps schreef op zondag 15 november 2009 @ 15:31:
[...]
Is er ook geen x-original-to of iets dergelijks?

Nope, maar uiteindelijk was de oplossing heel simpel: dedicated maildroprc/mailfilter per getmailrc

Klopt, ik heb inderdaad ook 1 .getmail-directory met een bestandje voor elke directory. Het punt van de leesbaarheid gaat ook vooral op voor procmail versus maildrop voor mij

Mee eens. Qua config is het bij mij nu ook heel overzichtelijk: 3x getmailrc, 2x maildroprc

vanaalten schreef op zaterdag 14 november 2009 @ 12:05:
Wat betreft smartphones (je noemt alleen het merk/type niet...):
Ik gebruik ook Dovecot, eigenlijk een beetje de standaard installatie, en heb sinds gisteren Profimail op mijn telefoon geinstalleerd. Lijkt perfect te werken: je kan twee access punten instellen, dus in mijn geval m'n wifi-netwerk en T-mobile data. Profimail & Dovecot ondersteunen IMAP-idle, dus heb ik daarmee push-e-mail op m'n Nokia E52.

Er komt een HTC Hero aan te hangen, maar dat zou geen probleem moeten vormen.

IMAP gebruik ik secure (IMAPs, poort 993) via SSL/TLS; SMTP via poort 25 en TLS. Volgens mij heb ik het allemaal daarmee goed beveiligd, maar het voelde wel onplezierig aan om die poorten op de router & server open te zetten.

Het is zeker ook niet mijn favoriete setup. Dovecot accepteert inmiddels alleen nog maar IMAP over SSL. Moet nog even de settings in om uit te vinden waarom TLS niet werkt. (Kan ook een quirk van Thunderbird zijn.)

SMTP houd ik extern. Hoe minder externe services hoe beter. Om diezelfde reden zal ik webmail waarschijnlijk ook extern draaien gezien de gemiddelde brakheid ervan.

Ik zit nu nog met het puntje dat ik Dovecot wil forceren slechts een lijst met vooraf gedefinieerde users (uit /etc/passwd) te authenticeren. De documentatie zegt wel hoe je users uit kunt sluiten gegeven een policy dat alle users toestaan, maar ik wil het precies andersom: 'deny all' except 'user1', 'user2'.

Daarna de passwords nog even hardenen, de logging afregelen, en dan zijn we bijna klaar

[vanaalten]

Rukapul schreef op dinsdag 17 november 2009 @ 20:33:
[...]

Het is zeker ook niet mijn favoriete setup. Dovecot accepteert inmiddels alleen nog maar IMAP over SSL. Moet nog even de settings in om uit te vinden waarom TLS niet werkt. (Kan ook een quirk van Thunderbird zijn.)

Ik vind het allemaal behoorlijk verwarrend:
De TLS Wikipedia pagina is vrij uitgebreid en geeft mij het idee dat ik liever TLS dan SSL gebruik.
De Mozilla Knowledge Base heeft echter ook een stuk over Thunderbird en TLS - en dat verteld dat het allemaal niets uitmaakt - sterker, SSL lijkt zelfs de voorkeur te hebben.

Wat echter weer vreemd is:

If you select "TLS" Thunderbird will make a TCP/IP connection to the mail server and send a command to ask what capabilities the mail server has. If it says it supports STARTTLS Thunderbird will change the connection to a TLS connection.

... Nou rapporteert Dovecot bij mij dat 'ie STARTTLS doet - dus waarom werkt Thunderbird dan niet met TLS? (ongeacht of je liever SSL hebt)

[Boudewijn]

Het voordeel van TLS is dat je het opdezelfde poort aan kunt bieden als SSL.

[Rukapul]

@vanaalten: het is voor een groot deel een semantische discussie. SSL 3.1 == TLS 1.0

[DeTeraarist]

Ik heb het idee dat Thunderbird zich niet aan de regels houdt. Het was de enige client die niet op m'n dovecot server in kon loggen. M'n LG Viewty kon met de standaard mail client inloggen, PopPeeper kon inloggen en zelfs Windows Live Mail deed niet moeilijk.
Krijg je nog een foutmelding van Thunderbird?
Ik zag net dit voorbij komen: klik

[vanaalten]

@Boudewijn: Ik krijg juist de indruk dat TLS op 143 zit en bedoeld is voor niet-encrypte verbindingen die je na onderling afspreken 'upgrade', terwijl SSL op 993 zit en meteen encrypted is.

@Rukapul: Ah, gedoe met versienummers om het nog waziger te maken... Geen idee of Dovecot SSL3.1 of lager gebruikt - zal er eens naar zoeken. Overigens zag ik in m'n logfiles bij SSL gebruik (poort 993) overal Dovecot iets met TLS rapporteren. Dus lijkt wel gewoon met TLS te werken.

Gisteravond toch nog wat aan het proberen geweest, wat Dovecot configs aangepast en uiteindelijk had ik zowel TLS poort 143 als SSL via 993 werkend met Thunderbird. Wat uiteindelijk de wijzigingen waren: POP3 en POP3S als service uitgeschakeld (gebruikte ik toch al niet) en plaintext authorization disabled. Sowieso geen slechte wijzigingen, ook al blijf ik uiteindelijk SSL-via-993 gebruiken. Ook maar gelijk wat poorten extra dichtgezet. Kan geen kwaad om een topic als deze te gebruiken om de beveiliging weer eens aan te scherpen.

[Rukapul]

Rukapul schreef op dinsdag 17 november 2009 @ 20:33:
Ik zit nu nog met het puntje dat ik Dovecot wil forceren slechts een lijst met vooraf gedefinieerde users (uit /etc/passwd) te authenticeren. De documentatie zegt wel hoe je users uit kunt sluiten gegeven een policy dat alle users toestaan, maar ik wil het precies andersom: 'deny all' except 'user1', 'user2'.

Iemand?

De rest werkt inmiddels al een aantal dagen naar volle tevredenheid

[Rukapul]

Oplossing gevonden. Voor de archieven:

In /etc/dovecot.conf voeg args entry toe:

passdb pam {
args = dovecot
}

In /etc/pam.d/dovecot voeg auth required regel toe:

#%PAM-1.0

@include common-auth
@include common-account
@include common-session

# allow IMAP access only for users in /etc/imapusers file
auth required pam_listfile.so item=user sense=allow file=/etc/imapusers onerr=fail

met tenslotte een lijst met usernames in /etc/imapusers

[vanaalten]

Rukapul schreef op woensdag 25 november 2009 @ 19:58:
In /etc/dovecot.conf voeg args entry toe:

Zou niet nodig moeten zijn, die args entry is al de default (volgens de documentatie).

[...]

In /etc/pam.d/dovecot voeg auth required regel toe:

[...]

met tenslotte een lijst met usernames in /etc/imapusers

Toch even nieuwsgierig waarom je dit eigenlijk wilde: heb je meerdere gebruikers en wil je sommige geen IMAP toegang bieden? Of heeft het qua security nog zinnige voordelen?
Ik heb op mijn systeem behalve wat systeemaccounts exact 1 gebruiker en die heeft IMAP toegang nodig, dus vraag ik mij af of bovenstaande voor mij zinnig zou zijn.

[Rukapul]

vanaalten schreef op donderdag 26 november 2009 @ 11:44:
[...]

Zou niet nodig moeten zijn, die args entry is al de default (volgens de documentatie).

Zou kunnen, maar bij mij werkte het pas nadat ik de wijziging had doorgevoerd (afaik).

Toch even nieuwsgierig waarom je dit eigenlijk wilde: heb je meerdere gebruikers en wil je sommige geen IMAP toegang bieden? Of heeft het qua security nog zinnige voordelen?
Ik heb op mijn systeem behalve wat systeemaccounts exact 1 gebruiker en die heeft IMAP toegang nodig, dus vraag ik mij af of bovenstaande voor mij zinnig zou zijn.

Hoofdreden is dat ik externe toegang tot het systeem zo krap mogelijk wil maken binnen de mogelijkheden van een standaard configuratie: zo min mogelijk services, zo min mogelijk accounts, etc. Dit minimaliseert de mogelijkheden van een aanvaller.

Tevens wil ik voorkomen dat er in de loop van de tijd bijeffecten ontstaan of dat instellingen uit het verleden als pure interne machine interfereren. Het is geen productiemachine waar alles netjes volgens vaste processen wordt afgehandeld, maar bovenal een hobby en zelfs experimentele machine. In combinatie met het feit dat mensen fouten maken geef ik de voorkeur aan een wat robustere opstelling m.b.t. externe toegang.

En om het heel concreet te illustreren: in de standaard dovecot installatie bleek de mailbox van het rootaccount standaard benaderbaar...

[Tomsworld]

Ik heb een gelijkaardige setup, ik ga nog eens grondig dit topic doorlezen om er tips uit te halen. Alleen draait er hier Ubunutu Jeos als vm met dovecoat / getmail etc, die haalt een 10 tal pop boxen leeg en zet dat dmv procmail op de goede plaatsen. Er draait ook nog een postfix als authed relay server naar mijn isp relay, misschien deliver ik later de mail ipv hem op te halen.

Op 3 pc's lees ik met thunderbird, 2 intern, 1 extern. Daarnaast draait er op mijn home vm nog een roundcube webmail. Volgende uitdaging wordt het dns verhaal regelen zodat mijn htc magic zowel van binnenuit als van buitenaf kan connecteren.

[vanaalten]

Rukapul schreef op vrijdag 27 november 2009 @ 12:16:
[...]

Hoofdreden is dat ik externe toegang tot het systeem zo krap mogelijk wil maken binnen de mogelijkheden van een standaard configuratie: zo min mogelijk services, zo min mogelijk accounts, etc. Dit minimaliseert de mogelijkheden van een aanvaller.

Maar is het niet zo dat je voorheen een username & password moest doorgeven waarna er een 'OK' kwam, en nu al na de username een reject volgt? Anders gezegd, is er nu niet een makkelijke manier van username-guessing?
Hiervoor wist een hacker niet welke usernames er waren en wat het password was. Nu kan je misschien eerst de username gokken en daarna het password?

[Rukapul]

Ten eerste: een typische service geeft geen feedback puur op eventuele user input. IMAP (RFC 3501) kent daarnaast een LOGIN commando dat direct de combi username en password als parameters heeft (ipv POP3 dat het in twee commando's doet).

Ten tweede: het is een beetje schijnveiligheid. username guessing puur en alleen om daarna bruteforce passwords te kraken is enigszins suf omdat puur op de sterkte van het wachtwoord vertrouwd moet kunnen worden.

Tomsworld schreef op vrijdag 27 november 2009 @ 12:39:
Volgende uitdaging wordt het dns verhaal regelen zodat mijn htc magic zowel van binnenuit als van buitenaf kan connecteren.

Dat hoeft niet zo'n uitdaging te vormen. Ik heb hier op de router eenvoudig een entry toegevoegd in hostsfile zodat het externe adres resolved naar een intern IP.

Mocht dat geen optie zijn dan kun je ook nog een local loopback maken, maar dat is wat ranziger.

[ Voor 42% gewijzigd door Rukapul op 27-11-2009 21:47 ]