Anleitung-i2p-Susimail-sicheres-Email

1. Introduction

postman.i2p is a bundled collection of I2P enabled services allowing users to

1. create, manage and delete mail accounts and mailboxes
2. send e-mails to other I2p mail-users and the Internet
3. receive e-mails from other I2P mail-users and the Internet
4. receive a notification of new mail on IRC

The SMTP and POP3 services can be accessed by using properly configured normal MUA (Mail User Agents) or with the help of the so called susimail package. Your router software came with susimail. It is an anonymity and security-aware application which acts as a trusted SMTP and POP3 proxy on your I2P router.

(The security issues are discussed here)

The postman.i2p system offers content sanitisation and virus scanning on the server site.

2. Security Basics

The largest danger is that your mail client compromises your anonymity or privacy while composing/sending mail. Some mail clients add their own Received: header, including local network addresses and information indicating the software or the native language of the user. Some mail clients announce their local IP address as a HELO/EHLO host-name. Some clients don’t allow you to choose from multiple identities.

All those problems require our special attention. Since susimail works as a trusted SMTP and POP3 proxy, you’ll always be on the safe side when using it.

Although a normal MUA also has some advantages, it must be carefully configured and tested by experienced users: try to follow these steps:

1. Get a dedicated mail client for use with I2p mail only
2. Install and configure the system in a way that all configuration data and mail folders are stored on a safe and possibly encrypted partition.
3. Check the configuration. A few mail clients allow the specification of a dedicated HELO host-name to be used
4. Other MUA allow the creation of certain header lines to be prohibited (like Message-ID and Received).
5. Compose a mail and store it in the outgoing folder. Now have a close look at the mail source. Check for any lines relevant to anonymity. This is the way the mail will later be sent to the postman system.
6. Install and configure a PGP compatible software like OpenPGP, GNUPG or enigmail. Public keys of mail users are available from the postman.i2p public address book.

Those measures are nothing special but are suggested by common sense. The next chapter will show you more about the composition of a mail and what those fancy header lines do

3. Using the SMTP service

Check your router console next and click on the I2PTunnel Link at the. top of the console page. A default I2P installtion contains preconfigured tunnels for smtp.postman.i2p and pop.postman.i2p. If they’re missing you have to create them with the i2ptunnel application. Please read about the potential risks first before using this service.

Next step is to configure the SMTP server in your MUA:

1. SMTP host is localhost and the port of your smtp.postman.i2p client tunnel (127.0.0.1:7659 by default)
2. Don’t switch on TLS/SSL. Encryption is done by the I2P network.
3. Activate SMTP authentication (Use your mailbox user name and password)
4. Supported authentication mechanisms are PLAIN and LOGIN
5. You cannot fake your sender address, it must match your login

Pictures:

1. [1] Screenshot from I2PTunnel
2. [2] Screenshot from Mozilla Thunderbird SMTP Config

6. Using the POP3 Services

Check if the pop3 client tunnel is running. Before you start receiving mail you should consider the following:

1. Please read about the potential risks first before using normal mail clients for this service.
2. APOP authentication is not supported
3. Please do not store excessive amounts of mail – retrieve your mail and empty the mailbox please
4. Maximum allowed mailbox size is 50MB per account
5. SSL/TLS is not supported on the server-side. We rely on the I2P framework for secure communication

Now you’re able to configure an E-mail client and set the host:port of the I2P client tunnel as POP3 server. Please keep in mind that answering a mail from users of the mail.i2p mail-domain requires you to setup a tunnel to smtp.postman.i2p too.

Pictures:

1. [1] POP3 Configuration in Mozilla Tunderbird

7. Mail from/to the Internet

Since the end of October 2004 the proxy system for mail from and to the Internet has finally been on-line. It has taken quite a few measures and some nights of brainstorming, programming, adopting and configuring to make it fit. Postman wants to thank all those people that contributed their ideas and concepts, mainly: sugadude, jrandom, pipi, duck and mule. Special thanks to cervantes for providing backup mx facilities and helping to keep this service available on the Internet.

The following chapters aim to explain how sending mails to the Internet and receiving mails from the Internet is implemented, considering security and privacy concerns of I2P’s users as well as the administrative aspects of such a system. If you think we missed some very important issue in this concept, send a mail to <enkode>postman@mail.i2p</enkode> or join #mail.i2p on the I2PNet IRC Network.

1. Working with a pseudo-mailidentity

A pseudo-mailidentity is a system that tries to render any form of sender address forgery impossible. If a recipient receives a mail from a certain address, he can be sure that it was sent by Return-Path account. Within the postman.i2p system the identity is created by simple measures:

1. SMTP authentication is enforced.
2. The AUTH login name must match the sender address used in the mail.

Every user can only use his OWN address as the Return-Path for an email. The postman.i2p system requires you to authenticate yourself for every mail sent, it does not make a difference whether the recipient is a @mail.i2p user or an Internet destination. smtp.postman.i2p supports the PLAIN and LOGIN mechanism for authentication – all modern mail clients are capable of SMTP authentication.

While a sender can still forge the From: header address, he cannot change the Return-Path: line in the mail, since it’s inserted by the MTA.

2. Basics on forwarding mail to the Internet

Out-proxies and gateways to I2P services must be handled with care. Under all circumstances the anonymity of I2P service users must be guaranteed. Interacting with Internet communication partners has to be kept strictly separated from I2P internal communication. Content from the Internet needs to be sanitized before being offered to I2P users or clients. Content that is being sent to the Internet needs to be sanitized to protect I2P users/clients.

At the moment we’re using two mail exchanger systems which act as official MX servers for the domain i2pmail.org. Those servers both work as incoming and outgoing servers. smtp.postman.i2p and the out-proxy systems communicate solely by using I2P. The following happens when your mail is sent to the Internet:

I2P mail to the Internet: (assuming sender is <enkode>jondoe@mail.i2p</enkode>)

1. User connects to smtp.postman.i2p via I2P
2. User authenticates as John Doe (otherwise Relaying will not be allowed at all)
3. smtp.postman.i2p checks if the sender address matches the log-in account (jondoe==jondoe?)
4. smtp.postman.i2p checks the user’s recipient quota
5. smtp.postman.i2p sanitizes mail headers
6. smtp.postman.i2p accepts/queues the mail
7. smtp.postman.i2p rewrites the Return-Path and From: address of the mail to <enkode>jondoe@i2pmail.org</enkode>
8. smtp.postman.i2p connects to mx.i2pmail.org via I2P and relays the mail.
9. mx.i2pmail.org sanitizes mail headers
10. mx.i2pmail.org relays the mail to its Internet destination according to DNS/MX entries

Note:Please note that <enkode>user@mail.i2p</enkode> is always used as the sender address. When mail is forwarded to the Internet it will be mangled to: user@i2pmail.org. If you intend to receive mails from the Internet for your postman account, you should always give the “official” address and not the internal one.

3. Forwarding mail from the Internet

The official in/out-proxies do not carry any important data about I2P mail users at all. Mail is sanitized and forwarded to the smtp.postman.i2p system via I2P. If the machines are raided and confiscated no trace leading to the postman.i2p system can be found (No IPs, no account data). The queue file system for the mailer might contain a few still unsent mails. To protect those the complete queue file system, the I2P installation and all MTA related data reside on a crypto file system. In a nutshell:

1. The out-gateway does not host ANY mailboxes.
2. The out-gateway does not locally store any information about which accounts exist
3. The out-proxy does not know the IP of smtp.postman.i2p – it uses I2P to relay mail
4. The out-proxy can be sacrificed without exposing any sensitive information about I2P users.

Internet mail back to I2P (assuming recipient is <enkode>jondoe@i2pmail.org</enkode>)

1. The sender transmits the mail to his configured relay
2. The mail gets relayed to the Internet-gateway of the I2P mail service according to official MX records for the domain i2pmail.org
3. mx.i2pmail.org checks ACLs and eventually accepts the mail
4. mx.i2pmail.org sanitizes headers / queues the mail
5. mx.i2pmail.org rewrites the To: / envelope recipient addresses to @mail.i2p
6. mx.i2pmail.org contacts smtp.postman.i2p via I2P - mail gets forwarded.
7. smtp.postman.i2p sanitizes/removes headers
8. smtp.postman.i2p delivers the mail to the user’s mailbox

4. Configuration of delay for outgoing mails

While the smtp.postman.i2p mailer protects users by applying one last level of header sanitisation, the fact that an e-mail is being sent to the Internet alone carries some kind of information that can be used to lower the level of anonymity: an email sent to the Internet means that the sender is connected to I2P at this very moment. For this reason, a delay is being applied to outgoing mails. You can chose between the following:

1. 0-delay: the mail is forwarded immediately to the Internet
2. defer-delay: mail-forwarding is delayed for a certain amount of time (between 2000-4000 seconds) depending on the mail system’s queue runner
3. batch-delay: the mail is held until a cronjob at 0:00/12:00 UTC triggers the delivery

The Date: header line is always rewritten when mail is being delayed. Users can configure the delay in the [ Manage Account ] area.

Default is a defer-delay for all outgoing mail.