☰

Sendmail/procmail/Exchange 메일 자르기

tag-icon • tag-icon sendmail procmail exchange
Sendmail/procmail/Exchange 메일 자르기

동료는 나를 새로운 광기의 깊이에서 구해 주는 패턴을 찾도록 영감을 주었습니다. 여기 몇몇 싱크탱크가 이제 그 이유를 말해 줄 수 있기를 바랍니다...

현장:원래 수신자를 기준으로 메일을 재배포하기 위한 procmail 설정이 포함된 여러 범용 메일 ID가 있습니다. 예를 들어, generic_ID1로 전송된 이메일은 Staff1, Staff2로 전송되고, generic_ID2로 전송된 이메일은 Staff3, Staff4 등으로 전송됩니다.

GENERIC_ID1_RECIPIENTS="staff1@domain,staff2@domain"

:0
* ^TO.*generic_ID1
! $GENERIC_ID1_RECIPIENTS

질문:메시지가 잘려서 무작위로 나타납니다. 결국 발견된 패턴은 문장이 76열에서 마침표와 하드 리턴으로 끝났을 때 발생한 일임을 보여줍니다. 75열이나 77열에는 없고 76열에는 더 많은 텍스트가 있습니다. 같은 줄. 이 기간 이후의 모든 텍스트는 손실됩니다.

부록: 방금 226열에 마침표와 함께 다시 나타나는 것을 보았습니다. 나는 깜짝 놀랐다.

다시 전달하기 전에 메시지를 복사하여 procmail이 전체 ​​메시지를 수신했는지 확인할 수 있습니다.

:0c                       # note: 'c'
* ^TO.*generic_ID1
! $GENERIC_ID1_RECIPIENTS

나는 sendmail이 재전송 시 그것을 잘라낼 수 있다고 생각하지만 이것을 진단하거나 증명하는 방법을 잘 모르겠습니다. (저는 sendmail 관리자가 아니며 단지 procmail 사용자입니다.)

문제는 완전히 재현 가능합니다.

질문:왜 이런 일이 발생하며 어떻게 해결합니까?

매우 감사합니다.

편집: 제목과 태그를 업데이트했습니다. 해결방법은 댓글에 있습니다.

답변1

(질문 댓글에서 변환)

이 방정식은 실제로 sendmail, procmail 및 Exchange의 세 부분으로 구성됩니다.

  • 교환: 배달을 위해 메시지를 수락할 때 일반 텍스트 메시지의 형식을 다시 지정하고 줄 인코딩하고 75자로 줄 바꿈하는 것으로 나타납니다.

  • 이메일을 보내: 이 메시지에서는 고대의(그러나 알려진) 동작을 따릅니다. 여기서 한 줄의 단일 마침표는 메시지의 끝으로 해석된 다음 전달되어 실제 메시지 본문을 효과적으로 자릅니다.

  • 프로그램 메일: 문서에 따르면, 마침표를 무시하도록 강제하는 플래그를 사용하여 sendmail을 호출해야 합니다. 이는 이를 수행하지 않으며 명시적인 구성 파일 지시문을 따르지 않습니다. 단기 솔루션: 모든 재전송 레시피에 -oi -OIgnoreDots=T를 전달합니다. 장기적인 해결책: 이제 구성 설정을 지원하고 네이키드 사이클을 무시하도록 사이트의 procmail 설치를 업그레이드하십시오(전달된 플래그는 더 이상 필요하지 않음).

하드 래핑이 사용되는 이유는 Exchange가 이전에 일반 텍스트 메시지를 인코딩할 때 =20마침표가 자동으로 래핑되어 한 줄에 남을 수 있는 기능이 도입되었기 때문입니다.

관련 정보