On Thu, 25 Dec 2014, Michiel van der Vlist wrote to Torsten Bamberg:

 TB> 1.) your system gets an pgp-encrypted echomail, but the public key 
 TB> doesn't match. Basically, your system bounces the echomail, and it 
 TB> will get lost.

 MvdV> Encrypted echomail does not make much sense. The idea of using 
 MvdV> encryption is that only the intended receiver can read it. Makes 
 MvdV> no sense for echomail. 

sure it does... it can be encrypted from the sender using their private key or
it can be encrypted to a group using their public key...

 TB> 2.) your system gets a zip-encrypted netmail via unprotect inbound 
 TB> Usually this netmail will be bounced, because it comes up via 
 TB> unprotect inbound. But, because of your enc-flag you've got to 
 TB> route or crash the netmail to the specific exit-system.

 MvdV> No. The ENC flag just means that you will not treat it different 
 MvdV> from unencrypted mail. If you do not automatically process 
 MvdV> compressed netmail from your unsecure inbound, you do not have 
 MvdV> to process it either if it is encrypted. 

that is and always has been my understanding since the early days of any of the
encryption flags and secure mail hubs...

 MvdV> The ENC flag just means that you will not refuse to route it 
 MvdV> simply because it is encrypted.

exactly...

 MvdV> You still do not have to route mail for everyone. If you have 
 MvdV> not agreed to route mail from A to B, than you do not have to 
 MvdV> route encrypted mail from A to B either.

exactly, again :)

)\/(ark