# Encrypted messages not readable...received as named attachments "ATT00001.bin"

**URL:** <https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462>\
**Category:** Uncategorized\
**Created:** [June 18, 2019, 3:11am UTC](https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462 "2019-06-18T03:11:06Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![danny](https://support.delta.chat/letter_avatar_proxy/v4/letter/d/848f3c/32.png) [@danny](https://support.delta.chat/u/danny)\
**Post date:** [June 18, 2019, 3:11am UTC](https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462/1 "2019-06-18T03:11:06Z")

</div>

Big bug and makes me wanna just drop the damn thing for Signal.  
Receiving messages from a DeltaChat android user (installed via play store), to my linux Deltachat (flatpak) and all received messages are just attached files named “ATT00001.bin” with garbage in them. Looks like my client can’t decrypt them for some reason. We’ve both exchanged keys via contacts.

What’s going on?  
Thanks

---

<div class="post-metadata">

**Author:** ![Simon](https://support.delta.chat/user_avatar/support.delta.chat/simon/32/287_2.png) [@Simon](https://support.delta.chat/u/Simon)\
**Post date:** [June 18, 2019, 8:16am UTC](https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462/2 "2019-06-18T08:16:55Z")

</div>

Which dc versions and which Providers are you using?  
Some provides like outlook mess with the headers…

---

<div class="post-metadata">

**Author:** ![adbenitez](https://support.delta.chat/user_avatar/support.delta.chat/adbenitez/32/2323_2.png) [@adbenitez](https://support.delta.chat/u/adbenitez)\
**Post date:** [June 19, 2019, 5:38pm UTC](https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462/3 "2019-06-19T17:38:17Z")

</div>

Hi @danny, welcome to our community, this looks a lot like:

> [@Problem in using hotmail.com/outlook.com](https://support.delta.chat/t/problem-in-using-hotmail-com-outlook-com/242):
>
> Maybe noone noticed my last comment in Provider Overview and therefore I opened this seperate topic. Hopefully someone has experience about. [1](https://support.delta.chat/t/provider-overview/56/11#)[7d](https://support.delta.chat/t/provider-overview/56/11)[hotmail.com](http://hotmail.com) / [outlook.com](http://outlook.com) seems not to work! DC version v0.100.0 from github. A colleague of mine installed v0.100.0, created a new free account at [outlook.com](http://outlook.com). Mails sent from v0.100.0 to me without encryption are displayed at my phone (v0.20.0 and Thunderbird with Enigmail). After I did first reply next mails from v0.100.0 peer are shown as e…

and:

> [@Provider Overview](https://support.delta.chat/t/provider-overview/56/11):
>
> [hotmail.com](http://hotmail.com) / [outlook.com](http://outlook.com) seems not to work! DC version v0.100.0 from github. A colleague of mine installed v0.100.0, created a new free account at [outlook.com](http://outlook.com). Mails sent from v0.100.0 to me without encryption are displayed at my phone (v0.20.0 and Thunderbird with Enigmail). After I did first reply next mails from v0.100.0 peer are shown as empty mail with two binary attachments (ATT00001, 12 Bytes; ATT00002.bin, 2021 bytes). Both parts are encoded as “Content-Transfer-Encoding: base64” N…

which as @Simon suggested is a know issue with outlook

---

<div class="post-metadata">

**Author:** ![csb0730](https://support.delta.chat/user_avatar/support.delta.chat/csb0730/32/45_2.png) [@csb0730](https://support.delta.chat/u/csb0730)\
**Post date:** [July 13, 2019, 11:00pm UTC](https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462/4 "2019-07-13T23:00:52Z")

</div>

As @adbenitez describes:

Please check the provider!  
[outlook.com](http://outlook.com) or similar doesn’t work properly!

I think any Microsoft provider cuts autocrypt header, so DC only works with them only without encryption.

---

<div class="post-metadata">

**Author:** ![csb0730](https://support.delta.chat/user_avatar/support.delta.chat/csb0730/32/45_2.png) [@csb0730](https://support.delta.chat/u/csb0730)\
**Post date:** [July 13, 2019, 11:02pm UTC](https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462/5 "2019-07-13T23:02:24Z")

</div>

Check the full email header content. If the DC headers are missing the provider is the problem!  
☹

---

<div class="post-metadata">

**Author:** ![enacting](https://support.delta.chat/user_avatar/support.delta.chat/enacting/32/512_2.png) [@enacting](https://support.delta.chat/u/enacting)\
**Post date:** [January 31, 2020, 7:09am UTC](https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462/6 "2020-01-31T07:09:21Z")

</div>

when “rekey” happens however can the receiver of unreadble background request resend after key sync?

---

<div class="post-metadata">

**Author:** ![csb0730](https://support.delta.chat/user_avatar/support.delta.chat/csb0730/32/45_2.png) [@csb0730](https://support.delta.chat/u/csb0730)\
**Post date:** [December 19, 2020, 10:10am UTC](https://support.delta.chat/t/encrypted-messages-not-readable-received-as-named-attachments-att00001-bin/462/7 "2020-12-19T10:10:37Z")

</div>

Excuse but I don’t understand this question. Maybe meanwhile it’s solved or if not please post it more clear if possible.
