▲

유럽 주요 결제처리업체, Google Workspace 사용자에게 이메일 전송 불가

 (atha.io)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • 유럽 대형 결제업체 Viva.com이 Message-ID 헤더 없이 인증 메일을 발송해 Google Workspace 서버가 이를 거부함
  • RFC 5322(2008년 제정)에서 Message-ID는 필수 수준의 헤더로 규정되어 있으며, Google은 이를 엄격히 적용
  • Gmail 개인 주소로는 메일이 수신되어, Google Workspace와 Gmail의 처리 차이가 드러남
  • Viva.com 고객지원은 기술적 문제를 인정하지 않고, 사용자가 우회한 결과만 확인하는 비전문적 대응을 보임
  • 기본 RFC 준수조차 지키지 못한 사례로, 유럽 핀테크 인프라의 품질과 경쟁력 저하 문제를 드러냄

인증 메일이 도착하지 않은 문제

  • Viva.com 계정 생성 과정에서 인증 메일이 전혀 도착하지 않음
    • Google Workspace 기반의 커스텀 도메인 이메일을 사용했으며, 스팸함에도 메일이 없었음
  • Google Workspace의 Email Log Search 결과, 상태는 “Bounced”로 표시됨
    • 반송 사유는 “Messages missing a valid Message-ID header are not accepted”
    • Google은 RFC 5322 규격 위반으로 메일을 거부함
  • Viva.com의 발신 메일에는 Message-ID 헤더가 누락되어 있었으며, 이는 2008년부터 필수로 요구된 항목임

임시 해결책

  • 개인용 @gmail.com 주소로 변경하자 인증 메일이 정상적으로 수신됨
    • Gmail의 수신 인프라가 더 관대하거나 다른 경로로 처리된 것으로 보임
  • 그러나 비즈니스용 결제 플랫폼 가입에 개인 이메일을 사용해야 했다는 점은 문제로 지적됨

고객지원의 대응

  • Viva.com 고객지원에 Google Workspace 로그 스크린샷과 문제 설명을 전달함
  • 지원팀은 “귀하의 계정은 이미 인증된 이메일을 가지고 있으므로 문제가 없다”고 회신
    • 기술적 문제에 대한 인식이나 엔지니어링 팀 전달은 없었음
    • 사용자가 직접 우회한 결과를 문제 없음으로 간주한 대응임

문제의 본질

  • Message-ID는 모든 이메일 시스템이 기본적으로 생성하는 기본 헤더임
    • 이를 누락하려면 메일 파이프라인이 심각하게 잘못 구성된 상태여야 함
  • RFC 5322에서는 Message-ID를 “SHOULD”로 규정하지만, Google은 이를 사실상 필수(MUST) 로 취급
  • Viva.com이 이를 준수하지 않음으로써 Google Workspace 사용자에게 메일이 도달하지 않음
  • 유럽 전역에서 결제를 처리하는 기업이 기본 RFC 규격을 지키지 못한 점은 기술 신뢰성에 의문을 제기함

유럽 핀테크 인프라의 구조적 문제

  • 유럽의 기업용 API·서비스에서 문서 불완전, 오류 처리 미흡, 비전문적 지원이 반복적으로 발생
  • 이는 엔지니어 역량 문제가 아니라 시장 경쟁 부족과 우선순위 문제로 지적됨
  • Stripe가 높은 개발자 경험 기준을 세웠지만, 유럽 지역 결제망(예: IRIS) 을 완전히 지원하지 않아 대체재가 부족함
  • Stripe 수준의 경쟁자가 등장하지 않는 한, 이 같은 품질 문제는 계속될 가능성이 있음

기술적 수정 제안

  • Viva.com은 발신 메일에 Message-ID 헤더를 추가해야 함
    • 예시: Message-ID: <unique-id@viva.com>
    • 대부분의 이메일 라이브러리는 이를 자동 생성하며, 한 줄 수정으로 해결 가능
  • Google Workspace 사용자들이 정상적으로 인증 메일을 받을 수 있도록 즉각적인 수정 필요

RFC 용어 구분과 Google의 정책

  • RFC 2119에 따르면
    • MUST: 절대적 요구사항
    • SHOULD: 특별한 이유가 있을 때만 생략 가능
    • MAY: 완전한 선택사항
  • Message-ID가 SHOULD인 이유는 일부 클라이언트가 서버에 위임하기 때문
  • Google은 스팸 방지를 위해 이를 강제적 요건으로 적용, RFC보다 실질적 표준 역할을 수행
  • Viva.com이 이를 의도적으로 생략했다면, 최소한 “Google Workspace와 호환되지 않음” 경고를 제공해야 함
    • 아무런 안내 없이 운영하는 것은 SHOULD 규정의 취지에도 어긋남
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • Viva.com의 인증 이메일에 Message-ID 헤더가 없다는 점이 문제로 지적됨
    RFC 5322의 섹션 3.6에 따르면 “every message SHOULD have a Message-ID field”라고 되어 있는데, SHOULD는 MUST가 아니므로 ‘요구사항’이라 보기 어렵지 않느냐는 의문을 제기함

    • SHOULD는 사실상 의무적 요구사항임을 설명함
      특별한 사유가 없는 한 따라야 하며, 단순히 “귀찮아서”는 예외가 될 수 없다고 함
      과거에는 MUA가 Message-ID 없이 메일을 보내면 서버가 자동으로 추가했기 때문에 SHOULD로 표현되었다고 함
      관련 내용은 RFC 6409 섹션 8.3에 명시되어 있음
    • RFC2119에 따르면 SHOULD는 “특정 상황에서 무시할 수 있으나, 그 결과를 충분히 이해하고 신중히 판단해야 함”을 의미함
      Google이 이를 어떻게 해석했는지는 모르겠다고 함
    • 호스팅 회사의 postmaster로서, 실제 운영 환경에서는 Message-ID가 반드시 필요하다고 강조함
      테스트 메일은 몰라도, 실서비스 메일에 없으면 스팸 필터링 등에서 문제가 생김
      Message-ID가 없다는 건 보통 허술한 커스텀 발송 시스템의 신호라고 함
    • Message-ID는 필수가 아니지만, Amazon SES처럼 기존 Message-ID를 덮어쓰는 서비스도 있어 불만이라고 함
    • 기술적으로는 없어도 되지만, 정상적인 이메일로 분류되려면 사실상 필수라고 봄
      특히 결제 서비스가 Google Workspace 같은 주요 메일 서비스에서 테스트조차 안 한 건 황당하다고 함

  • ESP(Email Service Provider)에서 일했던 경험으로, 대부분의 서버 소프트웨어는 Message-ID 없는 메일을 거부했다고 함
    Google 같은 주요 수신자에게서 오는 반송(bounce) 을 무시하는 건 상상하기 어렵다고 함

    • 현실적으로는 표준보다 사용자 문제를 막는 게 더 중요하다고 함
      상대 시스템이 비합리적이라도, 사용자 불편을 막기 위해 맞춰주는 게 낫다고 함
    • Google Workspace로 메일을 보내려면 Message-ID는 사실상 MUST임
      이를 넣기 싫다면 “Google Workspace 사용자에게는 서비스 불가”라고 명시해야 한다고 주장함
    • 하지만 대부분의 기업은 이런 기술적 세부사항에 관심이 없고, “빨리 서비스만 되면 된다” 는 태도라고 함
      Viva나 Google 모두 너무 커서 일부 고객의 문제는 신경 쓰지 않는다고 봄
    • 유럽 기업 중심이라 Google Workspace 비중이 크지 않을 수도 있다고 지적함

  • 이메일의 text/plain 대체 파트를 엉망으로 보내는 서비스들에 대한 불만도 나옴
    링크가 빠진 텍스트 버전이나 “이건 plain text 이메일입니다” 같은 쓸모없는 내용만 보내는 경우가 있다고 함

    • 알림창에 “귀여운 문구”만 뜨는 plain text 버전이 가장 짜증난다고 함
      이메일 클라이언트가 AI로 HTML을 요약해주는 기능이 필요하다는 농담도 함
    • 어떤 서비스는 다른 고객의 예약 정보를 plain text에 포함시켜 보냈다고 함 (Avis 사례)
    • HTML을 Lynx 브라우저로 덤프해 text/plain을 만드는 구현을 본 적 있는데, 그게 실제로 가치가 있는지 궁금하다고 함
    • text/plain에 HTML 소스나 CSS를 그대로 넣는 경우도 봤다고 함

  • 금융기관의 기술적 무능함을 꼬집는 댓글도 있었음
    “Major European Payment Processor”는 사실상 “Major European Incompetence Center”라고 표현함

    • 다른 사용자는 과장된 말 같지만, 실제로 금융기관의 보안 수준이 끔찍했다고 함
      예를 들어 Harland Financial Systems는 2바이트 XOR 암호화를 쓰고, 키를 연결 초반에 평문으로 보냈다고 함
    • 또 다른 사용자는 미국 금융기관의 부패 사례(잘못된 승인, 무단 계좌 개설 등)를 언급하며 유럽도 비슷한지 묻는 의견을 남김

  • Gmail에서 Fastmail로 옮긴 사용자가 Google의 엄격한 스팸 필터링에 일정 부분 공감함
    Fastmail에서는 스팸과 피싱 메일이 더 많이 들어온다고 함

    • 다른 사용자는 Message-ID는 자동 메일에 사실상 업계 표준이라며 Google의 조치가 과하지 않다고 함
      스타트업이 기본 템플릿을 그대로 써서 피싱으로 오인받는 사례도 있다고 함
    • Fastmail은 시간이 지나면 스팸 필터가 학습되어 좋아진다고 조언함
    • 오랜 Fastmail 사용자로서, 가끔 스팸이 새지만 LinkedIn 메일만 유일하게 통과한다고 농담함
    • Fastmail은 주기적으로 스팸 대응이 느려질 때가 있지만, 전반적으로 만족스럽다고 함

  • RFC 상으로는 Viva.com이 틀렸지만, Google도 SHOULD 항목을 이유로 메일을 거부하는 건 부적절하다고 보는 의견도 있음
    다만 스팸 가능성이 높다면 스팸함으로 보내야지, 거부는 과하다고 함

    • 고객지원팀이 문제를 기술팀에 전달하지 않고 형식적인 답변만 반복하는 현실을 지적함
    • 지원 담당자 입장에서는 문제를 인정하면 성과 평가에 불이익이 있어 어쩔 수 없었다는 내부 경험담도 공유됨
    • 이메일 표준은 현실적으로 완벽히 작동하지 않으며, 모든 규칙이 사실상 “SHOULD” 수준이라는 냉소적 의견도 나옴

  • Viva.com이 Google Workspace와의 메일 송신 문제를 테스트조차 안 한 점이 가장 심각하다고 지적됨

    • 실제로는 사용자 가입 실패를 통해 “실시간 테스트” 중인 셈이라며 풍자함
      문제는 Google 쪽 변경일 수도 있지만, 모니터링 부재가 더 큰 문제라고 함
    • “세상 모든 기업이 Google Workspace를 쓰는 건 아니지 않느냐”는 반론도 있었음

  • Viva.com이 이런 문제를 얼마나 오래 인지하지 못했는지 의문을 제기함
    일반적인 메일 소프트웨어라면 이런 문제는 생기지 않았을 것이라며, misconfiguration 가능성을 언급함
    SHOULD는 MAY가 아니며, 구현하지 않으면 문제를 감수해야 한다고 함
    Google이 에러 메시지로 원인을 알려준 건 오히려 다행이라고 평가함

  • Message-ID는 원래 Usenet에서 유래된 필수 필드로,
    이메일의 스레딩, 회신, 아카이빙에 모두 필요하다고 설명함
    Message-ID가 없다는 건 “답장도 원치 않고 기록도 남기고 싶지 않다”는 의미로, 수상한 행위로 보인다고 함

  • 유럽 기업 API의 품질 문제를 지적한 원문에 대해,
    이런 현상은 지역 문제가 아니라 전 세계 스타트업과 금융기관 공통의 패턴이라고 함
    대기업은 API를 부가 사업으로 여기거나, 규제 대응용으로 억지로 운영하는 경우가 많다고 함
    반면 Stripe 같은 회사는 API가 생명줄이기 때문에 품질이 높다고 함
    스타트업은 리소스 부족으로 “사용하기 좋은 API”보다 “돌아가는 API” 를 우선시할 수밖에 없다고 덧붙임

답변달기