# Import\_mbox.sh가 listserv 서버를 통해 Samsung 폰에서 보낸 이메일과 함께 작동하지 않음

**URL:** https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435
**Category:** Support
**Created:** [1월 20, 2022, 11:04오전 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435 "2022-01-20T11:04:35Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![markcoley](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markcoley/32/242366_2.png) [@markcoley](https://meta.discourse.org/u/markcoley)
#### Post date: [1월 20, 2022, 11:04오전 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/1 "2022-01-20T11:04:35Z")

</div>

테스트 환경에서 기이한 문제가 발견되었습니다. 저는 이메일을 Discourse 서버로 복사한 후 import\_mbox.sh 스크립트를 실행하여 해당 이메일을 가져오고 있습니다. 원본 이메일은 listserv 메일링 리스트에서 온 것입니다.

삼성 갤럭시 폰 사용자가 이전의 listserv 이메일에 회신할 때, 그 결과로 생성된 이메일을 Discourse로 가져오려고 하면 새로운 콘텐츠가 추출되지 않고, 원래 이메일의 중복본만 표시되며 마치 회신한 사람이 작성한 것처럼 라벨이 붙는 것을 확인했습니다.

문제가 있는 원본 이메일을 ‘이메일/고급 테스트’ 상자에 복사/붙여넣기해도 동일한 문제가 발생합니다. 이메일을 잘라서 삼성이 추가한 여러 부분을 제거하면 정상적으로 작동하는 것으로 보입니다.

이 문제를 유발하는 이메일의 사본은 기밀 사항이므로 여기에 올릴 수 없습니다. 가져오지 못하는 이메일에는 다음과 같은 섹션이 포함되어 있으며(사람이 읽을 수 있는 콘텐츠는 없고 모두 base64 인코딩으로 되어 있음):

```plaintext
[truncated headers here]
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_341310020171250"

----_com.samsung.android.email_341310020171250
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

VGhlIGxlZ2lzbGF0aW9uI[truncated]
[...]
[truncated]X19fX19fX19fX18NCg==
----_com.samsung.android.email_341310020171250
Content-Type: multipart/related;
	boundary="--_com.samsung.android.email_341310031317791"

```

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 20, 2022, 1:18오후 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/2 "2022-01-20T13:18:02Z")

</div>

> [@markcoley](#):
>
> 문제가 되는 원본 이메일을 이메일/고급 테스트 상자에 복사/붙여넣기하면 동일한 문제가 발생합니다. 이메일을 잘라서 삼성이 추가한 여러 부분을 제거하면 작동하는 것 같습니다.

따라서 이메일을 잘라서 삼성의 불필요한 부분을 제거하도록 `import_mbox.sh`를 수정해야 합니다.

이것은 코어에서 해결할 수 있는 문제일 수도 있습니다. 해당 메시지들은 이메일로 전송되어 처리될 때 실패할 가능성이 높기 때문입니다(하지만 최근 코드를 살펴본 적이 없어서 확신할 수 없습니다). 어쨌든, 해당 메시지에 대해 가장 신속한 해결책은 아마도 가져오기 스크립트를 수정하는 것일 것입니다.

아니면 누군가가 이것이 코어의 문제임을 알아채고 수정할 수도 있습니다.

---

<div class="post-metadata">

### Author: ![markcoley](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markcoley/32/242366_2.png) [@markcoley](https://meta.discourse.org/u/markcoley)
#### Post date: [1월 20, 2022, 1:56오후 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/3 "2022-01-20T13:56:58Z")

</div>

조금 더 조사해 보니, 삼성 메일 앱은 평문과 HTML 부분을 각각 base64로 인코딩하여 전송하는 것 같습니다. 두 인코딩 사이에 빈 줄을 하나 추가하면 메일 필터가 정상적으로 작동하는 것을 확인했습니다. 삼성이 빈 줄을 넣어야 할 위치에 넣지 않는 것일 수도 있고, 메일 필터가 평문/HTML 텍스트 부분을 올바르게 찾지 못해서 HTML 부분을 발견한 후 해당 헤더가 끝나는 위치와 메시지 본문이 시작되는 위치를 인식하지 못하는 것일 수도 있습니다.

Gmail에서 원본 보기(view original)를 통해 원본 메일을 복사해 보고, Thunderbird에서 동일한 메시지를 내보내 보았지만 결과는 동일했습니다.

삼성에서 생성된 메일은 헤더 하단에 다음과 같은 내용이 포함되어 있는 것 같습니다:

```plaintext
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_396413402758380"

----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

WWVz[base64로 인코딩된 평문 메시지]

```

그리고 여기서는 다음과 같이 끝납니다:

```plaintext
[기타 base64로 인코딩된 데이터]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0b[다시 base64로 인코딩, 이번에는 동일한 메시지의 HTML 버전]

```

그리고 여기서는 다음과 같이 끝납니다:

```plaintext
[기타 base64로 인코딩된 데이터]NCg==
----_com.samsung.android.email_396413402758380--

```

이제 중간 부분을 수정하여 빈 줄을 하나 추가하면(“email\_396413402758380” 부분 뒤에) 모든 것이 완벽하게 작동합니다!

```plaintext
[기타 base64로 인코딩된 데이터]19fDQo=
----_com.samsung.android.email_396413402758380

Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0b[다시 base64로 인코딩, 이번에는 동일한 메시지의 HTML 버전]

```

이것은 가져오기(importer)에 버그가 있다는 것을 시사하는 건가요?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1월 20, 2022, 2:01오후 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/4 "2022-01-20T14:01:31Z")

</div>

> [@markcoley](#):
>
> 이것은 가져오기(importer)에 버그가 있다는 것을 시사하는 건가요?

제 생각에는 삼성의 메일 클라이언트에 버그가 있는 것 같습니다. 하지만 확신은 없고, 누구의 버그인지는 중요하지 않습니다.

다만, 가장 쉬운 해결책은 설명하신 대로 빈 줄을 추가하는 [`gsub`](https://apidock.com/ruby/String/gsub)를 가져오기 스크립트에 추가하는 것입니다.

`Content-Transfer-Encoding: base64` 앞에 줄을 삽입하는 것이 더 쉬울 수 있습니다.

기다 다른 문제가 발생하지 않기를 바랍니다.

그레하르트(Gerhard)가 더 나은 답변을 작성하고 있습니다… 지금 바로

---

<div class="post-metadata">

### Author: ![gerhard](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/gerhard/32/119479_2.png) [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [1월 20, 2022, 2:09오후 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/5 "2022-01-20T14:09:31Z")

</div>

음, 그렇다면 이메일 파싱에 사용하는 [mail gem](https://github.com/mikel/mail)의 버그이거나 삼성 앱의 버그일 가능성이 높습니다. RFC를 빠르게 살펴본 결과, 파서 쪽의 버그일 가능성이 더 높은 것 같습니다.

혹시 그런 문제 있는 이메일의 전체 예시를 제공해 주실 수 있을까요? 기밀 이메일의 작성자 중 한 명에게 비기밀 이메일을 보내달라고 요청해 보시는 건 어떨까요?

---

<div class="post-metadata">

### Author: ![markcoley](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markcoley/32/242366_2.png) [@markcoley](https://meta.discourse.org/u/markcoley)
#### Post date: [1월 20, 2022, 3:36오후 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/6 "2022-01-20T15:36:02Z")

</div>

base64를 디코딩하고, 문구를 변경한 뒤 다시 인코딩하여 이메일을 만들어 보았는데, 또 다른 흥미로운 점을 발견했습니다.

원본 메시지 중간에 있는 공백 문자를 제거하면, 위에 작성된 답글을 올바르게 추출할 수 있습니다.

이 예시에서는 base64로 인코딩된 HTML 메시지의 중간에서 슬래시 div 앞에 [공백]이 포함된 줄을 찾아 그 공백을 제거합니다. 즉, 다음과 같이 변경합니다.

```plaintext
21 20:17 (GMT+00:00) </div><div>To: LIST@LISTS

```

다음과 같이 변경합니다.

```plaintext
21 20:17 (GMT+00:00)</div><div>To: LIST@LISTS

```

/div 앞의 [공백] 문자를 제거한 후, 다시 base64로 인코딩하여 관리자 설정의 메시지 테스트 상자에 다시 넣으면 필터가 정상적으로 작동합니다.

도움이 필요하시다면 다이렉트 메시지로 이메일을 보내도 될까요?

---

<div class="post-metadata">

### Author: ![markcoley](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markcoley/32/242366_2.png) [@markcoley](https://meta.discourse.org/u/markcoley)
#### Post date: [1월 20, 2022, 10:45오후 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/7 "2022-01-20T22:45:06Z")

</div>

문제를 보여줄 수 있다고 생각하는, 제가 만든 인위적인 이메일 예시입니다. HTML 부분을 보면 이전 메시지에 대한 답장이 포함되어 있습니다. 가져오기(importer) 기능은 원본 메시지가 어디에서 시작되었는지 인식하지 못하는 것 같습니다.

```plaintext
From someone@gmail
Delivered-To: someone@gmail
Importance: Normal
MIME-Version: 1.0
Message-ID: <E1mt6gg-00H2OV-6N@relay01.mail.eu.clara.net>
Date: Fri, 3 Dec 2021 11:25:05 +0000
From: someone <someone@somewhere.net>
Subject: Re: Example e-mail
To: <LIST@LISTSERV>
In-Reply-To: <007301d7e834$c268a3e0$4739eba0$@sslmc.co.uk>
Precedence: list
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_7076959834053910"

----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

WWVzIGFuZCB3ZSBhcmUgZ2V0dGluZyBsb3RzIGluIEFCQyBhbmQgdXJnZW50IGNhcmUsIGFsb25n
IHdpdGggdmFjY2luYXRpb24gc2lkZSBlZmZlY3RzIGZyb20gZmx1ICsgYm9vc3Rlci4gQXBwYXJl
bnRseSBERUYxMTEgY2FuJ3QgZGVhbCB3aXRoIHRoaXMgc29ydCBvZiBxdWVyeS4gTG9va2luZyBn
b29kIGZvciBYbWFzIGFuZCBOWSB3ZWVrICAgIDIyMjIKClNhbQoKRHIgU2FtIFNtaXRoeSAKCgot
LS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IFNvdXRoIFNvdXRocyBYWVog
PGVucXVpcnlAU1NYWVouQ08uVUs+CkRhdGU6IDAzLzEyLzIwMjEgMTA6NTkgKEdNVCswMDowMCkK
VG86IExJU1RTQ0FMSVNUU0VSVi5BQkMuT1JHLlVLKU3ViamVjdDogZXZlcnl0aGluZyBsYW5kcyBi
YWNrIGF0IG91ciBkb29yIQoKUHJhY3RpY2VzIHJlcG9ydGluZyB0byBnZXQgIDIgb3IgMyBxdWVy
aWVzL2RheSBmcm9tIHBhdGllbnRzIHJlZ2FyZGluZyBmaXZlcyB2YWNjaW5lIGlzc3VlcyB3aG8g
aGF2ZSBiZWVuIHJlZmVycmVkIHRvIHRoZWlyIEdQIGJ5IFhZWiAxMjMgb3IgdGhlIE5CUy4gIFRo
ZXNlIHF1ZXJpZXMgaW5jbHVkZSBzY2hlZHVsaW5nIGRvc2VzIGZvciBpbW11bm9zdXBwcmVzc2Vk
IHB0cyBhcyB3ZWxsIGFzIHBoYXJtYWNldXRpY2FsIHF1ZXN0aW9ucy4gIA==
----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh
dXRvIj5ZZXMgYW5kIHdlIGFyZSBnZXR0aW5nIGxvdHMgaW4gQUJDIGFuZCB1cmdlbnQgY2FyZSwg
YWxvbmcgd2l0aCB2YWNjaW5hdGlvbiBzaWRlIGVmZmVjdHMgZnJvbSBmbHUgKyBib29zdGVyLiBB
cHBhcmVudGx5IERFRjExMSBjYW4ndCBkZWFsIHdpdGggdGhpcyBzb3J0IG9mIHF1ZXJ5LiBMb29r
aW5nIGdvb2QgZm9yIFhtYXMgYW5kIE5ZIHdlZWsmbmJzcDsgJm5ic3A7IDIyMjI8L2Rpdj48ZGl2
IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5TYW08L2Rpdj48ZGl2IGRpcj0i
YXV0byI+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSIgZGlyPSJhdXRvIj48
bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl
dD1VVEYtOCI+RHIgU2FtIFNtaXRoeSZuYnNwOzwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9k
aXY+PGRpdj48YnI+PC9kaXY+PGRpdiBhbGlnbj0ibGVmdCIgZGlyPSJhdXRvIiBzdHlsZT0iZm9u
dC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdl
IC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBTb3V0aCBTb3V0aHMgWFlaICZsdDtlbnF1aXJ5QFNT
WFlaLkNPLlVLJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDAzLzEyLzIwMjEgIDEwOjU5ICAoR01UKzAw
OjAwKSA8L2Rpdj48ZGl2PlRvOiBMSVNUU0BMSVNUU0VSVi5BQkMuT1JHLlVLIDwvZGl2PjxkaXY+
U3ViamVjdDogZXZlcnl0aGluZyBsYW5kcyBiYWNrIGF0IG91ciBkb29yISA8L2Rpdj48ZGl2Pjxi
cj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5QcmFjdGljZXMgcmVwb3J0aW5nIHRvIGdldCAmbmJzcDsyIG9yIDMgcXVl
cmllcy9kYXkgZnJvbSBwYXRpZW50cyByZWdhcmRpbmcgZml2ZXMgdmFjY2luZSBpc3N1ZXMgd2hv
IGhhdmUgYmVlbiByZWZlcnJlZCB0byB0aGVpciBHUCBieSBYWVogMTIzIG9yIHRoZSBOQlMuJm5i
c3A7IFRoZXNlIHF1ZXJpZXMgaW5jbHVkZSBzY2hlZHVsaW5nIGRvc2VzIGZvciBpbW11bm9zdXBw
cmVzc2VkIHB0cyBhcyB3ZWxsIGFzIHBoYXJtYWNldXRpY2FsIHF1ZXN0aW9ucy4mbmJzcDsgPC9z
cGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg==
----_com.samsung.android.email_7076959834053910--

```

---

<div class="post-metadata">

### Author: ![markcoley](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markcoley/32/242366_2.png) [@markcoley](https://meta.discourse.org/u/markcoley)
#### Post date: [5월 7, 2022, 9:11오후 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/8 "2022-05-07T21:11:38Z")

</div>

지금 발견하고 있는 바로는, 이 문제가 다른 메일 클라이언트에서 온 메시지에 대해서도 발생하는 것 같습니다. 오류를 일으키는 이메일을 공개적으로 게시해 모든 사람이 볼 수 있게 하지는 않겠지만, 원하시는 분께는 비공개로 보여드릴 수 있습니다.

현재 제 설정은 다음과 같습니다. 가정용 서버에 Discourse를 설치했으며, listserv 메일링 리스트로 보내진 이메일은 저에게 전송됩니다(이메일은 Gmail 계정으로 전달됨). ‘To:’ 필터가 메일링 리스트 이름과 일치하면, Gmail에서 해당 이메일의 사본을 [mailinglist@mydiscoursedomain.org.uk로](mailto:mailinglist@mydiscoursedomain.org.xn--uk-qj9i) 전달하도록 설정해 두었습니다. Discourse에는 메일링 리스트를 미러링하는 카테고리가 설정되어 있으며, 이 이메일을 검색합니다.

이메일을 수동으로 복사한 후 import\_mbox.sh 스크립트를 사용해도 동일한 문제가 발생하므로, 메시지 내 새 부분을 검색하는 코드 부분이 혼란을 겪고 있는 것으로 보입니다.

---

<div class="post-metadata">

### Author: ![markcoley](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/markcoley/32/242366_2.png) [@markcoley](https://meta.discourse.org/u/markcoley)
#### Post date: [5월 9, 2022, 10:09오전 UTC](https://meta.discourse.org/t/import-mbox-sh-not-working-with-e-mails-from-samsung-phone-sent-via-a-listserv-server/215435/9 "2022-05-09T10:09:41Z")

</div>

이전에 저장된 가져온 이메일 전체를 빠르게 스캔하여, 위의 문제를 일시적으로 해결할 수 있는지 확인하기 위해 원본 이메일의 평문(plain text) 부분을 사용하여 다시 서식을 지정할 수 있는 방법이 있을까요? 가져오기 전에는 HTML 부분을 사용하도록 설정되어 있었습니다. 'rails c’를 둘러본 결과, 각 게시글에는 수신된 메시지의 전체 텍스트(이메일 헤더 포함)가 저장되어 있는 것 같습니다. HTML 옵션을 끄고 'rake posts:rebuild’를 실행해 보았는데, 모든 메시지를 천천히 처리하긴 했지만 실제로 변경된 것이 있는지 확신이 서지 않습니다. 예를 들어, 잘림된 콘텐츠 표시 옵션을 켰다 껐다 해 보았지만, rake 작업이 완료된 후에도 게시글에 세 점으로 표시된 작은 상자가 여전히 남아 있는 것 같습니다.
