Anleitung-i2p-Susimail-sicheres-Email

Aus Freiheit statt Angst!

(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
K (Änderungen von Wir speichern nicht! (Beiträge) rückgängig gemacht und letzte Version von Roam wiederhergestellt)
K (Hob den Schutz von „Anleitung-i2p-Susimail-sicheres-Email“ auf)

Version vom 12:39, 22. Aug. 2010

Inhaltsverzeichnis

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. Mailheaders

Let’s have a look at a typical mail sent via smtp.postman.i2p – delivered into a local mailbox: 

Return-Path:
X-Original-To: 
Delivered-To: 
Received: from localhost (localhost [127.0.0.1])
by smtp.postman.i2p (I2pMailer) with ESMTP id A2F8F38811B
for ; Sat, 18 Sep 2004 17:56:25 (UTC)
From: testuser
Organization: mail.i2p
To: 
Subject: Testmail
Date: Sat, 18 Sep 2004 17:55:41 +0200
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
charset=”us-ascii”
Content-Transfer-Encoding: 7bit
Message-Id: <>

Hello,
this is just a test to see it in action

In general mail headers contain administrative information about a mail. When you write a mail with your mail program (commonly called a Mail User Agent, MUA for short), the MUA will create header lines along with the message you typed. A blank line is used to separate the header lines from the body.

A few of the header lines will later be seen by the recipient as sender and subject and things like priority or the date the message has been created or sent.

According to RFC2822 a few header lines MUST exist in a mail:

  1. From: describes the sender of this mail. Usually it contains your name along with your mail address. A normal MUA will use the address and name from the active configuration profile. Your From: address will also be used within the SMTP dialogue as MAIL FROM: address. The sender address used in the SMTP dialogue is called “envelope-sender” while the address printed in the From: header is called “header-sender”. Normally the envelope sender and the sender “printed” on the mail itself are equal.
  2. To: One or more recipients of a mail. If there’s more then one recipient, they’re separated by commas. Most MUAs allow you to send mail to more than one recipient by using the Cc: (Carbon Copy) and the Bcc: (Blind Carbon Copy) fields. At least one recipient in one of those fields is needed. The MUA picks ALL recipients in ALL those fields and uses them for the SMTP dialog to tell the mail relay which addresses your mail is to be sent to. The mail server does not check these fields to determine the recipients of a mail after it’s queued. The MUA has to present the list of recipients BEFOREHAND.
  3. Date: The Date of the message creation. Usually in the human readable form: Day, Date Month Year, Time (OFFSET to UTC)
  4. Message-ID:An unique identifier for the message. Normally it’s up to the MUA to create a message-ID. If the MUA does not create one, the MTA will insert the header line instead. Message-IDs can contain sensitive information, like local host names, local user names, local dates or timezones. Check the message-IDs your MUA creates. The ID shown in the header was created by KMail/1.6 and only discloses the local time of creation in its tag.

Most MUAs create many more lines though, because they’re needed to declare the mail content or priority. Commonly added headers include:

  1. Subject: The Subject of the mail message. This header line is one of the few that will be shown by all MUAs along with From: and To:. But it does need to exist.
  2. Organization: The Organization the sender belongs to. Normally you are asked to fill in this information during the creation of your account. Before you send mail, check your account settings. Organization should be left empty or contain something like mail.i2p or another fantasy name that cannot be associated with your real life identity.
  3. User-Agent: This header line will be added by the MUA and indicates what kind of software has been used by the sender to compose the message. This field gets automatically filled. Most MUAs don’t allow it to be removed or edited.
  4. Reply-To: This header line contains the reply address for a mail. It will be only filled when the reply address differs from the original From: address. Most MUAs allow you to enter e Reply-To address. Please check that it is left empty or filled with a valid mail.i2p address.
  5. In-Reply-To: / References:If you answer a mail a fellow I2P user sent to you, it is quite likely that your MUA will add an In-Reply-To: or References: header line. This header line does not contain mail addresses or host names, but the message-ID or message-IDs (in the case of a mail thread with multiple replies and re-replies) that your mails refers to. It’s not considered critical if the message-IDs created by all participating MUAs do not contain critical information either.
  6. X- header lines: Both MUA and Mailrelay are free to add custom lines that are not described in the standards. Depending on the MUA you’re using, more or fewer X-headers are added. Common used headers are X-Priority and X-Status, X-Mailer, mostly added by Microsoft MUAs. On the server side, X- headers are commonly used for mail tagging, i.e. tagging a mail as spam or virus-checked (X-Spam-Status, X-Virusscanned,...). To find about your MUA inspect a freshly composed mail in the outbox and check for X- header lines. None of the *nix MUAs we tested created X-headers by default.
  7. Content Description / MIME:Since E-mails can contain plain text, html messages, even attached files, the MIME standard is used for content declaration in mails. This standard is widely applied in all MUAs. In general MIME headers do not contain much harmful information. There is always a MIME-Version: header line. It is followed by a Content-Type: or a Content-Disposition: line, depending on the mail being a single message or a multi-parted message.

While the MUA composes the mail and adds quite a bunch of (mostly harmless if done rightly) header lines, the Mail Transfer Agent (Mail server/Relay, or MTA for short) receives the mail from the MUA. This is done via the Simple Mail Transfer Protocol. During an SMTP session some additional data is being exchanged between MUA and MTA. Let’s have a look. Lines starting with < << are sent by the server and received by the client. Lines starting with >>> are sent by the client and received by the server.. 


< << 220 mail.i2p ESMTP I2PNet Mailservice
>>> ehlo localhost
< << 250-mail.i2p
< << 250-PIPELINING
< << 250-SIZE 8388608
< << 250-ETRN
< << 250-AUTH LOGIN PLAIN
< << 250-AUTH=LOGIN PLAIN
< << 250 8BITMIME
>>> MAIL FROM: 
< << 250 Ok
>>> RCPT TO: 
< << 250 Ok
>>> DATA
< << 354 End data with .
>>> From: testuser
>>> Organization: mail.i2p
>>> To: 
>>> Subject: Testmail
>>> Date: Sat, 18 Sep 2004 17:55:41 +0200
>>> User-Agent: KMail/1.6.2
>>> MIME-Version: 1.0
>>> Content-Disposition: inline
>>> Content-Type: text/plain;
>>> charset=”us-ascii”
>>> Content-Transfer-Encoding: 7bit
>>> Message-Id: <>
>>>
>>> Hello,
>>> this is just a test to see it working
>>>
>>>.
< << 250 Ok Message queued as 09FBAD27A2

As you can see, the client announces the sender of the mail and the recipient(s) of a mail before it sends the mail itself to the server. The MTA does not work with any address related information of the header. After transmitting the sender/recipient, the client starts transmitting the mail as it has been composed. Transmission ends with a dot on a line by itself. If the mail relay accepts the transmission it has to decide what to do with it. In our example, the MTA comes to the conclusion that the recipient is a local mailbox and delivers it locally.

During the whole process of queuing/routing and delivering the MTA adds a few header lines to the mail itself. Those header lines are inserted to track mail loops or delivery loops and to create a traceinfo about the path a mail has taken from its beginning to the final delivery. You cannot influence the creation or content of those lines, the explanation should serve your comprehensive understanding of the mail header.

  1. Return-Path: Contains the sender address the client used for the MAIL FROM command during the SMTP session. If a mail turns out finally to be undeliverable, the resulting bounce message will be sent to the Return-Path and not to the From: address in the mail header. In a normally composed mail From: address and Return-Path address are however the same.
  1. Received: Every MTA receiving the mail will add its own Received: line on top of all the others. A normally sent mail contains 2-5 received lines, indicating that the mail was handled by this number of MTAs on its way from start to destination. The Received: lines contains quite useful information allowing mail administrators to trace back the path of a mail to spot problems or to judge the probability of a mail being SPAM or not. The received line contains: the sending host (with his HELO host-name, DNS name and IP), the receiving host, the protocol used(SMTP/ESMTP/QMQP/LMTP…), time and queueid.
  1. Delivered-To:This header line is added when the mail leaves the MTA system and is delivered into a mailbox. Mailbox delivery is normally done by a component called Mail Delivery Agent (short MDA. Most modern mail systems bundle MTA and MDA). The MDA adds this header to prevent local delivery loops. If the mail somehow gets resent (forwarded) to another address and then back again to the old address (maybe because of another forward pointing back to the original address), the mail system is not allowed to overload. Thus the MDA looks for Delivered-To: headers in every mail to deliver. If it finds a Delivered-To line with a mailbox address matching the recent target address, the mail will be bounced immediately.

What happens on the MTA side? – What if I haven’t got it properly but still want to use the service?

Let us assume that you configured your client OK. This will make sure, that no really compromising data will be leaked to the recipient of the mails you send. In addition to that the MTA itself can help with a set of measures to support the anonymity of users towards the recipients of mails. mtp.postman.i2p does the following every time a mail passes

  1. All User-Agent: and X-Mailer: header lines are automatically removed and replaced by the line X-Mailer:

smtp.postman.i2p Official I2P Mailer.

  1. All X- header lines are completely removed
  2. All message IDs are replaced by server-side generated message-IDs
  3. All Date: tags are removed and replaced by server-side generated Dates in UTC
  4. All Received: tags are removed (apart from the very last one)

This will lead to a sanitizing of mail headers in an acceptable form.

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