Anleitung-i2p-Susimail-sicheres-Email

Aus Freiheit statt Angst!

Wechseln zu: Navigation, Suche

good job man

It's serious

interesting site man

Inhaltsverzeichnis

4. Comparing MUAs

The following table compares a number of well known mail clients in terms of anonymity and privacy protection. Not all MUAs seem to be suited to work together perfectly with the postman.i2p system. The biggest differences between the clients can be found in the area of mail composing and disclosing more or less data to the SMTP session. Please note that the smtp.postman.i2p will sanitize ALL security relevant headers. Still it should be in your interest not to transmit identity disclosing information to postman.i2p. Pick the client best suited for you.

Program: Sylpheed Claws Platforms: Linux / Windows Observations: exposes version number and platform of the operating system (i686-linux-gnu/win32) creates a message ID that contains a local timestamp and the sender mail address. Please note that you can configure sylpheed not to create a message-ID at all. HELO host-name is the local client machine’s host-name – this is somewhat revealing. But you can manually set a HELO host-name in the configuration. Sylpheed can be configured not to write a Date: line at all. This way your local timezone isn’t disclosed to the mail server Rating: you need to manually configure a few important things. But after that the program is very usable [95%]

Program: KMail 1.x Platforms: Linux Observations:exposes only the version number of the software in User-Agent header. Creates a message ID that contains a local timestamp and the sender mail address. HELO host-name is ‘localhost’. Rating: Quite usable client – has seamless GPG integration as well. No vital data revealed. [90%]

Program: evolution 1.4 Platform: Linux Observations: exposes only the version number of the software in X-Mailer: header. Creates a message ID that contains a random stamp but the whole FQDN of your local SYSTEM! This information is sanitized – but this is still BAD. HELO host-name is your local host-name. Rating: Client full of eye-candy but it reveals too much data . [60%]

Program: Opera Mail Platform: Windows Observations: exposes only version number of the software in X-Mailer: header. creates a message ID that contains a random stamp but the whole FQDN of your local SYSTEM. This information is sanitized – but this is still BAD!!. HELO host-name is your local FQDN Rating: In normal life very usable client – not very usable for postman.i2p. [60%]

Program: Mozilla Mailer (Thunderbird) Platform: Windows/Linux Observations: exposes software release and OS in the X-Mailer: header. Creates a message ID that contains a random stamp and the sender domain – not critical. HELO host-name is your sender-domain. This is acceptable. Rating: Very usable client for win and linux – Consider using it together with enigmail for PGP integration [90%]

Program: Pegasus Mail

Platform:Windows Observations: exposes software release and OS in the X-Mailer: header. Creates no own Message-ID. HELO host-name is your local host-name. Not ideal but acceptable Rating: Quite usable client if there’s nothing else around to use [70%]

Program: Mutt 1.5 Platform: Linux Observations:exposes software release in User-Agent: header. Creates a Message-ID that contains a local timestamp as well as your local host-name – not that good. HELO host-name is your local host-name per default . You can change in configuration. Rating: usable client, but you have to configure quite extensively to make it work best in this environment [75%]

Program: MicroSoft Outlook Platform: Windows Observations: exposes software release in X-Mailer: header. Creates a Message-ID that contains a random stamp as well as your local host-name – not that good. HELO host-name is your local host-name. Different versions behave differently in terms of mail composing. Rating: Not exactly rateable since your Outlook might behave completely differently from mine. I would prefer not using it in the postman.i2p environment

5. Using the SMTP service

Your router’s hosts.txt will likely contain an entry for smtp.postman.i2p. If the key’s missing you can add it manually to your addressbook. The destination key is:

pop.postman.i2p=W4ZehJpFv9HnM4qnWb6c305H1vWRoghgSz~UXVVl7AM6cNYPU~DHzI0ezxyYIcsywhDvRdSvN5QQSyb2t-waFRaoMxmub9Z68uvcNPjAyG1Hc-igVbcmiGKo1RwXXO1JTzaAFE8NB2mvZmpksPDks0ugcd3AzBrrkxsqt8KLYSXBc7hDM59YUGl0j59NUZoE3tJgZlQ~fYr4P4P9VetBgVQ5mJFpwF~RvM2frx9zQ2SonCSTNFR88MEUJ6EoZUTDG-iz6mUVv2qOanAD1ZfSmmMZpbtFLovqvUGv8JLxhFdkNmt3AmIZzPjmvrAu2X~VnAhX80Wrvba8df9w0qtplH5LYBykmN~wndjcQxOH7~LbGeJ-8q4DHf-DSDPFyn6L4uCk35kCSGXjEf1f44DSHU338Wiagn9ut7twiFSf8NLXvKV2-uWmx~twDLTd9cEjCEBm7ZXMaqWTK1kOGj0nlybm~mgMW-~IRnb6alnR0GMxAE-6fnWS52PJtmWU0ToAAAA


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. Make sure the tunnels are running. Now you can test the tunnel:

Try to connect to the SMTP service with telnet:

donkey ~ # telnet localhost 2525 Trying 127.0.0.1… Connected to localhost. Escape character is ‘^]’. 220 smtp.postman.i2p ESMTP I2PNet Mailservice quit 221 Bye Connection closed by foreign host.

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

Your router’s addressbook will likely contain the destination key for pop.postman.i2p. If it’s missing you can add it manually to your addressbook. The key is:

pop.postman.i2p=W4ZehJpFv9HnM4qnWb6c305H1vWRoghgSz~UXVVl7AM6cNYPU~DHzI0ezxyYIcsywhDvRdSvN5QQSyb2t-waFRaoMxmub9Z68uvcNPjAyG1Hc-igVbcmiGKo1RwXXO1JTzaAFE8NB2mvZmpksPDks0ugcd3AzBrrkxsqt8KLYSXBc7hDM59YUGl0j59NUZoE3tJgZlQ~fYr4P4P9VetBgVQ5mJFpwF~RvM2frx9zQ2SonCSTNFR88MEUJ6EoZUTDG-iz6mUVv2qOanAD1ZfSmmMZpbtFLoqvUGv8JLxFhFdkNmt3AmIZzPjmvrAu2X~VnAhX80Wrvba8df9w0qtplH5LYBykmN~wndjcQxOH7~LbGeJ-8q4DHf-DSDPFyn6L4uCk35kCSGXjEf1f44DSHU338Wiagn9ut7twiFSf8NLXvKV2-uWmx~twDLTd9cEjCEBm7ZXMaqWTK1kOGj0nlybm~mgMW-~IRnb6alnR0GMxAE-6fnWS52PJtmWU0ToAAAA

Check if the pop3 client tunnel is running. Now try to telnet the POP3 service


donkey ~ # telnet localhost 1110 Trying 127.0.0.1… Connected to localhost. Escape character is ‘^]’. +OK ready user jondoe +OK Password required for jondoe pass thepassword +OK jondoe has 1 visible message (0 hidden) in 456 octets. quit +OK OK - Bye Connection closed by foreign host.

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 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 )

  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
  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 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 )

  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.

5. Quota … What Quota?

As much as mail communication to and from the Internet is appreciated among fellow I2P users – “fellow” spammers always looking for new and anonymous ways to spam effectively. To be honest, without any security measures the whole postman.i2p system would allow spammers to send large amounts of messages to the Internet – protected by the level of anonymity I2P offers all its users (and not only to those who aren’t spammers).

Since the out-proxy is not supposed to be listed on every blacklist and the operator of the out-proxy certainly does not want to be sued for allowing spam to be sent using this system, a quota system has been created.

  1. Every I2P mail user has a daily “quota” that restricts the amount of mail he’s able to send to the Internet (local I2P mail is not restricted). This quota is not based on the number of mails sent, but based on the number of recipients that receive mail from an I2P user.
  2. The quota is 20 recipients/day for mails to be sent to the Internet. This means a user can send 20 mails to one recipient each, or 4 mails to 5 recipients each or 1 mail to 20 recipients. Every combination is possible as long as the number

of recipients does not exceed 20 a day.

  1. Every night at 0:00 UTC, the quota is refreshed back to 20 recipients to spend.
  2. If a user needs more recipients he can purchase them through computing a hashcash token.
  3. Depending on the number of collision bits of the hashcash, the user can purchase another 20,40 or 80 recipients.
  4. The extra recipients expire after 24h. Recipients can not be accumulated. If they are not spent within a day they expire.
  5. Every hashcash token can only be used once to acquire extra accounts
  6. Every user can view/modify his quota with the help of a soon to be installed web interface
  7. A user cannot exceed his quota. The check will be done right within the SMTP session leading to a denial of recipients after each RCPT command that has a non-I2P recipient.

The quota can be managed in the new [ Manage Quota ] Area. Go there to acquire extra accounts via hashcash as well.

6. How to prevent spamming from the Internet?

For now the following model is implemented:

  1. deny incoming mails where the sanity/validity check of the SMTP session fails
  2. deny incoming mails from unknown domains
  3. deny incoming mails from domains with private network addresses NS/MX entries
  4. deny incoming mails from unknown/unaccepted senders (for a handful of usual suspect domains)
  5. deny incoming mails that are listed on certain blacklists
  6. gray-list mails
  7. accept the rest

8. The biff service

Since a large number of I2P users are active on the I2P-IRC network, we have created a little IRC bot that acts as a monitor service for mailboxes. Similar to the well known Unix biff program a user is notified on IRC when a new mail for his mailbox has arrived.

The bot is named “biff” and will reside on channel #mail.i2p. Please note that your ircnick must be identified with nickserv to use biff. The following commands are recognized by biff:

  1. .help – outputs a short help of all commands
  2. .register mail address password – activates the biff service for the given mail address. The password is the postman.i2p account password (the one used for SMTP and POP3).
  3. .cancel mail address – removes monitoring for the given account. You need to use the same irc-nickname for registration and cancellation.
  4. .show – shows which mail.i2p accounts are associated with your IRC nick. Biff prints some additional helpful information, like the last changed timestamp and a recent size of your mailbox in Bytes.

Please note, that “You have new mail”-notification messages will only be sent to identified nicks. Please don’t blame biff for not receiving any notifications for the 100s of mails you got. Furthermore it might take a few minutes until biff notifies you about new mail.

9. susimail

susimail is a piece of javabased software that is running on every I2P node per default. It provides trusted webbased access to postman’s SMTP and POP3 service. susimail is programmed and maintained by susi.

If you don’t feel comfortable configuring a dedicated mailclient for the postman mailsystem, susi is the right thing for you, since it allows a fast and easy access to your mailbox and works as a trusted SMTP proxy to the postman.i2p server.

Please note, that you need to create an account on postman.i2p before you can actually use susimail.

For any further information, help and bugreports please visit the susimail page on susi.i2p.

9a) The SMIGACY Proxy

Smigacy 0.1.2 by Adam Atlas

Smigacy (which stands for Send Messages through I2pmail with Greater privACY) is an anonymity filter for SMTP, primarily intended to be used with Postman’s I2PMail service.

Smigacy is placed in the public domain.

Requirements:

  1. Python 2.2 or later
  2. I2P with an I2PTunnel pointing to smtp.postman.i2p

Installation & Use

Before using it for the first time, edit Config.py. Set destinationPort to the I2PTunnel client pointing to smtp.postman.i2p. In the default I2P distribution, port 7659 points to this destination, so Smigacy is set to that by default. You can also change listenPort if you wish; this is the port upon which Smigacy will listen for requests from your mail client, so it must be an unused port. Finally, you must set your username and password for your account on Postman’s mail services.

To start Smigacy as a daemon, run Smigacy-Start.sh . To stop it, run Smigacy-Stop.sh .

To set up your MUA to use it, configure it to use SMTP through the host 127.0.0.1 and the port which you set as listenPort. Disable SMTP authentication ifyou had it enabled.

At this point it should work. Try sending a test message.

Version History - 2005-09-16: 0.1.2

Von „http://wiki.vorratsdatenspeicherung.de/Anleitung-i2p-Susimail-sicheres-Email“
Persönliche Werkzeuge
Werkzeuge