From Wikitech
(Difference between revisions)
(some initial design decisions) |
(→Design decisions: more decisions) |
||
| Line 11: | Line 11: | ||
== Design decisions == | == Design decisions == | ||
| − | ; Black box mail system, no user shell logins : Few users would make good use of this anyway. Greatly simplifies network and host security, allows the use of some non-standardized extensions between software components for greater performance, interoperability and features because it doesn't have to support whatever shell users might install to access things directly. | + | ; Black box mail system, no user shell logins : Few users would make good use of this anyway. Greatly simplifies network and host security, allows the use of some (non-critical) non-standardized extensions between software components for greater performance, interoperability and features because it doesn't have to support whatever shell users might install to access things directly. |
; IMAP only, no POP3 : IMAP has good client support nowadays, and for a large part solves the problem of having multiple clients. Also backups can be done centrally on the server side, and multiple folders with server side mail filtering might be supported. | ; IMAP only, no POP3 : IMAP has good client support nowadays, and for a large part solves the problem of having multiple clients. Also backups can be done centrally on the server side, and multiple folders with server side mail filtering might be supported. | ||
; Support for mail submission : Through SMTP authentication we can allow our users to submit mails through the mail server, without them having to configure an outgoing mail server for whatever network they reside on. Can support multiple ports/protocols to evade firewalls. | ; Support for mail submission : Through SMTP authentication we can allow our users to submit mails through the mail server, without them having to configure an outgoing mail server for whatever network they reside on. Can support multiple ports/protocols to evade firewalls. | ||
; SSL/TLS access only, no plain-text : Although client support for this is not 100% yet, especially on mobile devices, the risks of using plain-text protocols is too high, especially with users visiting conferences and other locations with insecure wireless networks. | ; SSL/TLS access only, no plain-text : Although client support for this is not 100% yet, especially on mobile devices, the risks of using plain-text protocols is too high, especially with users visiting conferences and other locations with insecure wireless networks. | ||
| + | ; Quota support : Although we can set quotas widely especially for those who need it, quotas should be implemented to protect the system. | ||
| + | ; Web access : Some form of web-mail would be nice, although not critical at first and can be implemented at later stages. | ||
| − | === Software used === | + | === Software and formats used === |
; MTA: Exim : Great flexibility, very configurable, reliable, secure | ; MTA: Exim : Great flexibility, very configurable, reliable, secure | ||
| − | ; IMAP server: Dovecot : Fast, secure, flexible | + | ; IMAP server: Dovecot : Fast, secure, flexible |
| + | ; Maildir : Safe, convenient format, moderately good performance, good software support | ||
| + | ; Password database : To be determined. Important aspects: easy maintenance, good software support, replication support. Possible options: | ||
| + | * passwd-file | ||
| + | * sqlite | ||
== Old Wikimedia email setup== | == Old Wikimedia email setup== | ||
Revision as of 11:49, 21 April 2007
Contents |
New mailserver plans
- An IMAP/SSL server! Yay
- Two separate servers:
- One handling all incoming, external mail, and does spam filtering
- One containing all mail boxes (IMAP), sending out internal mail
- Alias files copied to secondary MXes
- Using cdb
- Exim! (sorry) and Dovecot
- Mailinglists without specific aliases, just by looking at the -l postfix or lists.wikimedia.org
Design decisions
- Black box mail system, no user shell logins
- Few users would make good use of this anyway. Greatly simplifies network and host security, allows the use of some (non-critical) non-standardized extensions between software components for greater performance, interoperability and features because it doesn't have to support whatever shell users might install to access things directly.
- IMAP only, no POP3
- IMAP has good client support nowadays, and for a large part solves the problem of having multiple clients. Also backups can be done centrally on the server side, and multiple folders with server side mail filtering might be supported.
- Support for mail submission
- Through SMTP authentication we can allow our users to submit mails through the mail server, without them having to configure an outgoing mail server for whatever network they reside on. Can support multiple ports/protocols to evade firewalls.
- SSL/TLS access only, no plain-text
- Although client support for this is not 100% yet, especially on mobile devices, the risks of using plain-text protocols is too high, especially with users visiting conferences and other locations with insecure wireless networks.
- Quota support
- Although we can set quotas widely especially for those who need it, quotas should be implemented to protect the system.
- Web access
- Some form of web-mail would be nice, although not critical at first and can be implemented at later stages.
Software and formats used
- MTA
- Exim : Great flexibility, very configurable, reliable, secure
- IMAP server
- Dovecot : Fast, secure, flexible
- Maildir
- Safe, convenient format, moderately good performance, good software support
- Password database
- To be determined. Important aspects: easy maintenance, good software support, replication support. Possible options:
- passwd-file
- sqlite
Old Wikimedia email setup
- postfix, mailman, OTRS, spamassassin on goeje
- mail.wikimedia.org <- service ip/name for mail
- secure.wikimedia.org <- service ip/name for OTRS
- ticket.wikimedia.org <- service name for OTRS, redirects to secure.wikimedia.org currently
- sendmail on most other machines (apaches)
- internally in pmtpa they forward to smtp.pmtpa.wmnet, which relays to the external world.
How to make an email alias
On goeje:
vi /etc/postfix/aliases newaliases postfix reload
It takes up to 15 minutes until the secondary MXes accept mail for new aliases.
