Exchange 2013 mailbox mag alleen encrypted email ontvangen

[Postmen]

De organisatie waarin ik werk is bezig met het opzetten van een responsible disclosure. In deze disclosure geven we aan dat bevindingen per mail gestuurd kunnen worden naar een bepaald emailadres. De email die verstuurd wordt moet worden voorzien van PGP encryptie door middel van onze public key.

De mailbox komt op een Exchange 2013 server, nu wil ik graag afvangen dat alleen encrypted mails naar deze mailbox gestuurd mogen worden. Mail zonder encryptie moet worden gebounced met een antwoord naar de afzender dat de mail niet is afgeleverd omdat er geen encryptie is toegepast.

Het lukt me niet om een rule te bouwen die dit kan afvangen. Is er iemand die iets dergelijks gebouwd heeft en die me op weg kan helpen? Ik kan er helaas maar weinig over vinden, de combinatie Exchange / PGP levert een hoop resultaten op, maar dan zijn allemaal clientside problemen.

Voor de duidelijkheid, andere mailboxen moeten wel unencrypted email kunnen ontvangen!

[paulhekje]

ik snap het doel niet helemaal van die mail met jullie PGP public key. Die is public, dat is niet om mail mee encrypten.
Als iemand encrypted mail stuurt, zal je eers key-exchange moeten doen, lijkt me?

[Room42]

paulhekje schreef op donderdag 19 oktober 2017 @ 15:52:
ik snap het doel niet helemaal van die mail met jullie PGP public key. Die is public, dat is niet om mail mee encrypten.

Juist wel dus. Zo versleutel je je e-mail met PGP

Als iemand encrypted mail stuurt, zal je eers key-exchange moeten doen, lijkt me?

Het uitgeven van de publieke sleutel is de key-exchange.

[ Voor 32% gewijzigd door Room42 op 19-10-2017 15:56 ]

[Vorkie]

Maar als het zonder PGP wordt gestuurd is het al over alle lijntjes heen geweest en wordt het pas bij jullie mailserver gebounced... wat is dan de toegevoegde waarde? De Encryptie begint bij deze bij de verzendende client.

[Postmen]

Mail die gestuurd wordt, moet met onze public key worden versleuteld. Die is dus pas te lezen wanneer je de private key hebt om te ontsleutelen, en die hebben we!

Waar het om gaat is dat niet-versleutelde mail niet afgeleverd mag worden in de mailbox. (Heeft er mee te maken dat onze organisatie niet per mail met klanten communiceerd, dit mag dus niet een stiekem achterdeurtje worden om toch mail naar ons te kunnen versturen)

[Room42]

Ik heb deze case nog nooit gehad, dus ik opper maar wat uit de lucht;
Kun je niet naar bepaalde headers in de mail zoeken, die juist wel of juist niet aanwezig moeten zijn? Niet echt waterdicht, misschien.

[Vorkie]

Postmen schreef op donderdag 19 oktober 2017 @ 16:00:
Mail die gestuurd wordt, moet met onze public key worden versleuteld. Die is dus pas te lezen wanneer je de private key hebt om te ontsleutelen, en die hebben we!

Waar het om gaat is dat niet-versleutelde mail niet afgeleverd mag worden in de mailbox. (Heeft er mee te maken dat onze organisatie niet per mail met klanten communiceerd, dit mag dus niet een stiekem achterdeurtje worden om toch mail naar ons te kunnen versturen)

Nogmaals, ook al krijg je het voor elkaar om niet PGP mails te blokkeren voor deze mailbox, die hele ongecodeerde mail is al over de hele internetpijp gegaan en wordt pas bij jullie gebounced.

Dus zeg: Client - Mailserver1 - Antispam1 - Antispam2 - jullie mailserver. (en dan eventuele transparante SMTP proxy's erbuiten gelaten.... of....)

Dus die encryptie wel of niet toelaten op je mailserver heeft weinig nut m.b.t veiligheid (en ik dan niet snap wat dan nog het doel is, want ik kan ook PGP mailen naar jullie met de vraag wanneer de koffie klaar is...die komt alsnog aan...want PGP)

Draai de case om en maak een automatisch antwoord op de mailbox (voor alle emails!) dat alleen PGP gesigneerde e-mails worden verwerkt en alle andere worden verwijderd.

[Postmen]

Vorkie schreef op donderdag 19 oktober 2017 @ 16:07:
[...]


Draai de case om en maak een automatisch antwoord op de mailbox (voor alle emails!) dat alleen PGP gesigneerde e-mails worden verwerkt en alle andere worden verwijderd.

Eens, dat was/is mijn alternatief. Maar als techneut ben ik benieuwd of ik het ook technisch kan afdwingen. Ik moet toegeven dat ik er vanuit ga dat iemand die serieus de disclosure heeft doorgenomen en ons wil tippen, gebruik maakt (en ook weet hoe) van PGP. Ik verwacht dus eigenlijk geen serieuze un-encrypted emails.

[gekkie]

Je hebt nogal wat varianten om te encoden .. S/MIME, PGP/MIME, PGP/INLINE.

[Verwijderd]

Als alternatief kan je ook denken aan een webform in bijv. WordPress op jullie website die gebruik maakt van een PGP plugin om het formulier versleuteld met jullie key te versturen.
Een aantal voordelen:
- je hoeft het mailadres dat de pgp plugin gebruikt niet bekend te maken aan derden
- je kan afdwingen dat het formulier altijd encrypted verzonden wordt
- mails die afkomstig zijn van een andere afzender dan die je ingesteld hebt in de pgp plugin kan je meteen verwijderen/bouncen
- derden hoeven geen pgp geinstalleerd te hebben in bijv. outlook

[Brahiewahiewa]

Postmen schreef op donderdag 19 oktober 2017 @ 15:33:
...Het lukt me niet om een rule te bouwen die dit kan afvangen. Is er iemand die iets dergelijks gebouwd heeft en die me op weg kan helpen? Ik kan er helaas maar weinig over vinden, de combinatie Exchange / PGP levert een hoop resultaten op, maar dan zijn allemaal clientside problemen...

Dat ga je inderdaad niet vinden in de userinterface van outlook.
Maar je kunt het wel scripten op je vSMTP-server(s)

code:

if message.to = "<die ene mailbox die alleen encrypted mail mag ontvangen>" then
     if message.mimetype <> "<encrypted>" then
          message,reject
end if; end if

je moet even uitzoeken welk mime type PGP hanteert

[Postmen]

Ik bedoel ook inderdaad een Exchange transport rule. Ik wil het absoluut server-side houden.

Wat betreft het script, goede tip, ik ga dit verder onderzoeken!

[Slux]

Zo te lezen gaat het maar om een paar domeinen die zo ie zo mogen mailen naar die exchange server ?
dan kan je toch ook deny all doen en alleen die domeinen excluden ?

Ik hoop voor je dat de verzenden partij ook weten hoe ze om moeten gaan me de key

Die oplossing van Remark is ook wel een goede alleen dan moet je het formulier wel weer afschermen voor de rest van de wereld lijkt mij, of een aparte inlog maken voor bepaalde gebruikers, maar dan krijg je ook weer het verhaal of gebruikers het wel snappen en je moet het bijhouden/wachtwoorden regelmatig aanpassen als gebruikers weg gaan