Bote-mail.i2p-internet gateway (Trac #1362)

[str4d]

A gateway for mails between internet, mail.i2p and Bote. ideally open-source and freely available so in the event of it going down, alternatvies need not reimplemented, but can easily be set up by volunteers with the required ressources.

Migrated from https://trac.i2p2.de/ticket/1362

{
    "status": "accepted", 
    "changetime": "2017-04-16T22:57:40", 
    "description": "A gateway for mails between internet, mail.i2p and Bote.\nideally open-source and freely available so in the event of it going down, alternatvies need not reimplemented, but can easily be set up by volunteers with the required ressources.", 
    "reporter": "user", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1492383460162293", 
    "component": "other", 
    "summary": "Bote-mail.i2p-internet gateway", 
    "priority": "minor", 
    "keywords": "I2P-Bote privacy", 
    "version": "0.9.14.1", 
    "parents": "", 
    "time": "2014-08-26T10:00:07", 
    "milestone": "eventually", 
    "owner": "str4d", 
    "type": "enhancement"
}

[str4d]

Trac update at 20140826T12:10:43: str4d commented:

On the gateway side, the IMAP and SMTP interfaces make this easier to implement.

On the client side, the trivial case is already deployed: users can add a gateway !EmailDestination to their Bote client's settings, and emails with non-!EmailDestination recipients will be sent to the gateway.

The trivial case does not account for several issues:

• Making the gateway known is hard. It could be hard-coded into the source, but that is inflexible. For desktop I2P-Bote, it could be possible to use e.g. Seedless as a gateway distribution channel.
• Gateways "hobble" the perceived security of Bote. If a user sends Bote emails to a non-Bote address, they have none of the regular security properties of Bote emails (wrt hidden metadata etc.). This is of particular importance when an email is sent to both a Bote address and a non-Bote address.
  • Part of the solution to this is UI-based: making sure the users understand that Bote is strongest when used for Bote-internal communication.
  • But it might be possible to partly mitigate this in the client, for example by integrating PGP into Bote, and requiring that non-Bote addresses have a corresponding PGP public key. Then after sending the email to Bote addresses, the content of the email could be PGP-encrypted before sending to the gateway for forwarding. This would not protect metadata, but would provide a halfway-house to increase interoperability with existing systems.
  • Likewise, Bote clients could perhaps "render" their public key as a PGP key (or have a PGP key linked to their Destination), and transparently strip out PGP encryption from received emails (which would enable encrypted replies via the gateway).

[str4d]

Trac update at 20140826T14:32:41: user commented:

very good remarks. I don't know how big PGP implementations are. so if it'S easy to integrate and does not bloat Bote too much and keeps it maintanable, then icluding PGP would not be bad. But otoh PGP is widely used and the user likely has it installed on his system anyway. And a receiver on the internet might really not have PGP, and all that the sender wants is send an anonymous mail to him, caring only about being anon, not about the content of the mail. Metadata could also be minimized in that kind to a minimum, like omitting sent time - to be discussed.

In case a mail is sent to various destinataries, the sender would likely want to set the others into BCC so that not the entire internt surveillance industry knows with whom you (that anon identity) are communicating with. So the UI warning about lack of encryption and about visible metadata, to both the gateway itself and internet surveillance could suffice. I like the wording of "Bote is strongest when used for Bote-internal communication". :)

[str4d]

Trac update at 20150111T06:01:49:

• str4d changed _comment0 from:

I have recently migrated I2P-Bote's address crypto to use the JCA for ECC and AES, instead of BouncyCastle directly. This means that I2P-Bote will now be bundled with the full BouncyCastle crypto provider (instead of the ECC-only stripped-down classes), and it would be trivial to also bundle the BouncyCastle OpenPGP implementation. It would increase the package size, but the full BC provider has already done that :-P

I have a rough draft idea of how this gateway would operate, which I am discussing with postman. Details will follow once we have something worth posting.

to:

1420956144017988

• str4d commented:

I have recently migrated I2P-Bote's address crypto to use the JCA for ECC and AES, instead of !BouncyCastle directly. This means that I2P-Bote will now be bundled with the full !BouncyCastle crypto provider (instead of the ECC-only stripped-down classes), and it would be trivial to also bundle the !BouncyCastle OpenPGP implementation. It would increase the package size, but the full BC provider has already done that :-P

I have a rough draft idea of how this gateway would operate, which I am discussing with postman. Details will follow once we have something worth posting.

• str4d changed keywords from "" to "I2P-Bote privacy"
• str4d changed milestone from "0.9.16" to ""

[str4d]

Trac update at 20151102T12:24:06:

• str4d changed milestone from "" to "eventually"
• str4d changed status from "new" to "open"
• str4d changed type from "task" to "enhancement"

[str4d]

Trac update at 20170416T22:57:40:

• str4d changed owner from "postman" to "str4d"
• str4d changed status from "open" to "accepted"