困るのは、PCなどから使うアドレス宛であっても携帯端末に転送されていたり、SNSなどのメッセージでも、携帯端末に通知が行くようになっている場合である。
送り手側からは相手の設定は判らないので、その可能性を考慮せざるを得ない。奇妙なUXが生じてしまった、と言えるだろう。
これは、本質的には受け取り手側が、時間帯などによって、即時に通知されるか否か、どういう形で通知されるかを制御すべき問題である。
実際、最近ではそういう設定が可能になっているものも出てきつつある。
研究レベルでは、そうした制御をユーザーがいちいち担うのではなく、端末側がユーザーの状況（コンテキスト）を認識して自動的に設定するものも考えられている。
送り手と受け取り手の自由度
電子メールのような非同期のメッセージの場合、送り手は受け取り手にメッセージが届いたか、読まれたか、ということが気にかかる。
エラーが返ってこないかぎりは相手のサーバに届いてはいるはずであるが（「3日間がんばったけど届けられなかった」というエラーメッセージが来ることもなくはない…）、相手の端末に届きそれが通知されているか、その通知を相手が見てメッセージの中身を読んだかどうかは、何らかの返信がない限り判らない。
それを改善するために受け取り手がメールを読むと（正確には「一定時間表示すると」だが…）それを送り手に自動的に知らせる「開封通知」という機能が出てきた。
しかし、メールアプリが対応している必要があるし、そもそもスパムメールなどに対して通知が送られたくはなく、そうでなくとも、見ず知らずの人からも送られ得るメールをいつ読んだか、などはプライバシの領域に踏み込む情報である。
こうした通知も「メッセージ」の一種であり、メタメッセージともなるので、発信側（元のメッセージの受け取り手）はなるべく制御したいと思うのは当然である。
業務の都合などで必要とされる場合以外、開封通知を送る設定をしている人はほとんどいないであろう（受け取り手の自由度である）。
一方、登録した相手とのみ直接のやりとりが可能という設定になっているSNSでは、「既読通知」などが不可分に組み込まれていることも多い。
受け取り手側の自由度が少ないので、送り手側がその分、気を遣うべき要素が増えているのであるが、逆に相手の状況などを無視して「既読スルー」と非難するようなゴタゴタが起きたりしている。
自由度という観点からは課題の本質は変わらないが、形を変えてまた浮上していると言えよう。
送り手と受け手の自由度のバランスを取るのは難しいが、今後、徐々に双方のUXが改善されていくであろう。
