음, 그 예에서, 그리고 저에게 메신저로 보내주신 전체 이메일 소스에서 (감사합니다!) moz-do-not-send 속성은 해당 속성이 포함된 <img> 또는 <a> 태그의 표시에 영향을 주지 않아야 합니다. mozfilter는 class 속성의 값만 확인하며, 다른 곳에서 필터링될 수 있는 곳을 바로 찾지 못하고 있습니다.
따라서 별칭이 있는 링크의 콘텐츠와 href가 분리되는 이유를 알 수 없으며, 이는 discourse import가 갑자기 Mime 인코딩된 이메일의 plain/text 부분을 사용하기로 결정했기 때문일 수 있습니다(이 부분에는 텍스트와 URL이 분리되어 있습니다). 그렇게 하는 이유는 알 수 없습니다.
테스트용 discourse 설정에서 별칭이 있는 링크와, 예를 들어 내장 이미지 또는 이메일의 HTML 부분임을 나타내는 다른 요소를 함께 포함한 Thunderbird HTML 이메일을 가져오거나 이메일로 보내어 볼 수 있을까요?
여전히 디스코스가 이메일의 다른 MIME 부분을 사용하고 있을 수 있다고 생각합니다. (이 경우, 텍스트/텍스트 부분 뒤에 이미지/… 부분이 따라와 마크다운 버전을 생성하는 방식인데, 왜 그런지는 모르겠습니다. 아마도 moz-do-not-send! 같은 엄격하게 유효하지 않은 속성 때문에 HTML 유효성 검사기가 text/html 부분을 거부하고 있는 걸까요?)
한 번 더 테스트해 주실 수 있을까요? 같은 게시글(텍스트 중간에 이미지가 있는 것)을 사용하되, 텍스트의 일부(전부가 아니라 일부, 한 단어만이라도)를 굵게 표시해 주세요. 이렇게 하면 텍스트 부분이 text/plain 블록에서 오는 것인지 text/html 블록에서 오는 것인지 판별할 수 있을 것 같습니다.
죄송하지만, 확인 차 여쭤봅니다. incoming_email_prefer_html이 true(체크됨)로 설정되어 있나요?!
@Flominator 님, 감사합니다. 굵은 글씨가 기울어짐으로 표시되는 것을 보니 HTML을 직접 사용하는 것은 분명 아니지만, 강조 처리를 어떻게든 반영하고 있는 것 같습니다. 이메일의 text/plain 부분에 어떤 종류의 마크업이 추가되거나 제거되는 것 아닌지 궁금하네요. 지난번처럼 이메일 원본을 개인 메시지로 보내주실 수 있을까요?
@Flominator 님, 안녕하세요. 원본 이메일을 보내주셔서 감사합니다. 이메일의 text/plain 대안 부분을 살펴보니, text/html 부분에서 굵게 표시된 텍스트 주위에 실제로 별표(*)가 붙어 있는 것을 확인했습니다. 대부분의 마크다운 렌더러(디스코스의 렌더러 포함)는 이를 기울임체로 해석합니다. 아래는 text/plain 단락을 단독으로 복사하여 붙여넣은 것입니다:
Und nochmal soll ich für hier
https://meta.discourse.org/t/urls-being-dropped-from-thunderbird-generated-replies/163751/24
eine Testnachricht schicken.Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben istGruß
Flo
이는 님의 스크린샷과 동일해 보입니다.
따라서 제 생각에는 text/html 단락이 잘못된 HTML로 인해 거부되고 있는 것 같습니다(아마도 a 태그에 있는 비표준 moz-do-not-send 속성 이름 때문일 것입니다). 이를 해결하려면 유효한 HTML을 검사하는 방식을 변경하는 패치가 필요하며(아마도 해당 속성을 제거하는 것만으로도 충분할 것입니다), 코어 코드에 포함되지 않을 경우 그 안정성에 대해 확신이 적습니다. 시간이 나면 살펴보겠습니다.
이 토픽을 보고 계신 분들 안녕하세요,
업데이트를 하기 전에 이 문제에 대한 별도의 수정 사항(같은 방향이지만 더 구체적인 내용)이 커밋된 것을 발견했습니다:
이슈: FIX: properly clean Thunderbird emails, don't remove links - Pull Request #16543 - discourse/discourse - GitHub
커밋: FIX: properly clean Thunderbird emails, don't remove links (#16543) · discourse/discourse@f7540aa · GitHub
이것은 위 댓글에 첨부된 패치가 이 새로운 커밋을 포함하도록 업데이트할 때(아마도 다음 업데이트일 것입니다) 실패할 것임을 의미합니다(아마도 "파란불"처럼 화려하게 실패하지는 않겠지만, 업그레이드를 다시 진행하려면 재빌드가 필요할 수 있습니다). 자동으로 적용되도록 설정되어 있다면(예: 위에서 설명한 대로 app.yml에 git apply cmd를 사용한 경우), 다음 업데이트 전에 해당 설정을 제거해야 합니다. 실제로는 재빌드가 필요할 수 있습니다. receiver.rb에서 커밋 차이가 적용될 위치가 이미 패치에 의해 변경되었기 때문에 해당 커밋이 적용되지 못할 수 있기 때문입니다.
저는 1) app.yml에서 git apply cmd를 제거하고, 2) 앱을 재빌드하고, 3) 업데이트(재빌드 중에 아직 업데이트되지 않았다면)할 예정입니다. 진행 상황을 알려드리겠습니다…
[10분 후…]
결국 재빌드 중에 다운타임이 필요하지 않으므로 대신 다음과 같은 조치를 취했습니다.
git apply를 제거 (다음 앱 컨테이너 재빌드 전에만 수행하면 됩니다)launcher enter appcd /var/www/discoursegit checkout ./lib/email/receiver.rbexit이 패치의 작성자입니다. 제 환경에서는 잘 작동하며, 단점을 찾지 못했습니다.