I've just got an interesting idea about how a malicious e-mail sender could try to get a unseen by the recipient reading confirmation, including the IP address of the recipient. I was working on S/MIME messages and I thought about the signature validation process, where some of the steps could require external information (like a CRL) to be accessed. The interesting part of it is that the location of this information can be included in the message itself, as the PKCS#7 package can also include the certificate used to generate the signature. I went into Microsoft documentation about the validation process from Outlook, and found this: (reference: http://technet.microsoft.com/en-us/library/bb457027.aspx#EKAA) When the first certificate in the chain is validated, the following process takes place. 1. The chaining engine will attempt to find the certificate of the CA that issued the certificate being examined. The chaining engine will inspect the local system certificate stores to find the parent CA certificate. The local system stores include the CA store, the Root store, and the Enterprise Trust store. If the parent CA certificate is not found in the local system certificate stores, the parent CA certificate is downloaded from one of the URLs available in the inspected certificates AIA extensions. The paths are built without signature validation at this time because the parent CA certificate is required to verify the signature on a certificate issued by the parent CA. 2. For all chains that end in a trusted root, all certificates in the chain are validated. This involves the following steps. * Verify that each certificate's signature is valid. * Verify that the current date and time fall within each certificate's validity period. * Verify that each certificate is not corrupt or malformed. 3. Each certificate in the certificate chain is checked for revocation status. The local cache is checked to see if a time valid version of the issuing CA's base CRL is available in the cache. If the base CRL is not available in the local cache, or the version in the local cache has expired, the base CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate. If available, it is confirmed that the certificate's serial number is not included in the CA's base CRL. As described, the recipient system will try to gather the CA certificate from a URL that is specified on the signers' certificate, that is embedded in the signed message. A specially crafted certificate (not from a trusted CA) can be generated with an AIA (Authority Information Access) extension containing an URL controlled by the malicious sender. By doing that the sender will immediately know when the message recipient read the message on Outloook. I performed some tests that confirmed this scenario. Other e-mail clients like Mozilla Thunderbird and Lotus Notes have not presented the same behavior. It seems that only Outlook implements this part of RFC2459. It's behaving in the right way, but I believe that the user should have the ability to disable it. Here is a sample of a web access from the recipient of a message crafted like that. On this case, the AIA address included in the certificate was poitining to the "http://www.securitybalance.com/ca.html" URI. 10.10.10.31 - - [12/May/2008:15:47:43 -0400] "GET /ca.html HTTP/1.1" 200 116 "-" "Microsoft-CryptoAPI/5.131.2600.3311" (anonymized IP address) Microsoft was notified about this issue last May. Augusto Paes de Barros http://www.securitybalance.com/