Discourse가 생성한 이메일(이 이메일과 내 이메일)을 받았는데, 해당 이메일에 다음과 같은 헤더가 포함되어 있습니다:
Mime-Version: 1.0
rspamd는 이 헤더에 대해 0.5의 부정적 스팸 점수를 부여합니다. 
헤더는 다음과 같이 작성되어야 한다고 생각합니다:
MIME-Version: 1.0
그들에게 그들이 틀렸다고, 그리고 그들의 도구를 수정해야 한다고 말하세요.
RFC 5322 - Internet Message Format : (강조는 저의 것입니다)
1.2.2. 문법 표기법 이 명세는 메시지 문법의 공식적인 정의를 위해 확장된 바커스-노름 형식(ABNF) [RFC5234] 표기법을 사용합니다. 문자는 10진수 값(예: 대문자 A는 %d65, 소문자 a는 %d97) 또는 대소문자를 구분하지 않는 리터럴 값(예: 대문자 또는 소문자 A를 나타내는 “A”)이 따옴표 안에 포함되어 지정됩니다.
대문자 ID 문자가 기대되는 헤더 Message-ID에 대해서도 동일한 주장이 적용된다고 생각합니다. 그렇지 않으면 이 항목도 감점을 받습니다.
rspamd가 이러한 기대치로 인해 표준을 위반할 수 있지만, 합리적인 선택일 수 있습니다. 해메일(ham-mail)이 이러한 구문을 더 많이 사용하고 스팸메일은 대부분 다른 구문을 사용하는 경우, 이러한 방식으로 필터링하는 것이 괜찮을 수 있습니다.
rspamd에 해당 Q&A를 방금 추가했습니다:
개인적 의견으로는, ‘스팸에서 흔히 사용되는’ 것을 부정적으로 평가하는 것은 옳지 않다고 생각합니다. 왜냐하면 그것은 해당 사항이 일반적으로 흔히 사용되는지 여부는 고려하지 않기 때문입니다.
모든 Discourse 설치 환경에서 Mime과 Id 변형이 사용된다는 사실을 고려하면, 이는 스팸이 아닌 정상 메일에서도 흔히 사용된다는 것을 명확히 보여줍니다. 이 부분에 대한 수치 자료를 보고 싶습니다.
물론 그들이 RFC 검증 도구가 아니라고 주장하는 것은 옳습니다. 하지만 이는 사실상 de facto 대안 표준 기관의 역할을 스스로 맡게 된다는 것을 의미하며, 이는 오히려 더 나쁜 결과를 초래할 수 있습니다.
그리고 나쁜 점은, 해당 인스턴스의 사용자나 관리자로서 우리는 그 사이에 끼어 있어 누가 맞는지 판단할 수 없다는 것입니다.
또한 단순히 올바르게 하는 것과 더 잘하는 것 사이에는 항상 차이가 있을 수 있습니다.
외부 시스템과의 기술적 소통에서 유연해야 했던 경험이 여러 번 있었습니다. 상대방은 100% 올바르게 하거나, 적어도 제가 표준을 이해한 방식대로 하지 않는 경우가 많았기 때문입니다. 따라서 표준을 둘러싸고 항상 어느 정도의 회색지대, 즉 유연한 여지가 존재하게 됩니다.
저에게는 더 큰 플레이어가 이러한 규칙을 따르며 헤더를 작성하는 것처럼 보입니다:
- 약자인 경우 해당 부분을 모두 대문자로 사용
- 단어인 경우 첫 글자만 대문자, 나머지는 소문자
이 패턴에 따라 MIME과 ID는 의미가 있으며, Message나 Version도 마찬가지입니다.
이는 대소문자를 구분하지 않는다고 명시된 표준 내에 있으며, RFC와 마찬가지로 더 표준에 가깝다는 작은 힌트일 뿐입니다. 제 이해로는 이메일을 생성할 때 Discourse에서도 동일한 방식을 따르는 것이 해가 되지 않습니다.