= Сообщение: 1684 из 7125 ====================================== FTSC_PUBLIC = От : mark lewis 1:3634/12 25 Dec 14 11:35:49 Кому : Michiel van der Vlist 25 Dec 14 11:35:49 Тема : ENC user flag FGHI : area://FTSC_PUBLIC?msgid=1:3634/12.0+49c2d7c1 На : area://FTSC_PUBLIC?msgid=2:280/5555+549be7f3 = Кодировка сообщения определена как: CP866 ================================== ==============================================================================
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.
