문의 양식이 가장 큰 스팸 리스크가 되는 이유

문제는 생각보다 오래되었습니다

문의 양식은 2000년대 초반부터 스팸 경로로 이용되어 왔지만, 이메일 제공업체들이 인증 요구사항을 강화하면서 문제는 더 심각해졌습니다. 대부분의 문의 양식은 여전히 같은 방식으로 만들어집니다. 사용자가 양식을 작성하면, 서버가 사용자의 주소를 From 헤더에 넣어 이메일을 보내고, 운영자는 답장을 기다립니다.

이는 교과서적인 이메일 스푸핑 취약점입니다. 스패머는 당신의 양식을 이용해 원하는 어떤 주소에서 온 것처럼 보이는 이메일을 당신 서버의 IP를 통해 보낼 수 있습니다. 이런 방식으로 스팸이 충분히 많이 발송되면, 당신의 도메인은 플래그 처리되고 정상적인 트랜잭션 이메일도 받은편지함에 도달하지 못하게 됩니다.

해결책은 간단하지만, 대부분의 튜토리얼은 여전히 잘못 안내합니다.

문의 양식이 쉽게 악용되는 이유

일반적인 문의 양식은 세 가지 필드, 즉 이름, 이메일, 메시지를 받습니다. 서버 측 핸들러는 그 이메일 주소를 가져와 발송 SMTP 메시지의 From 헤더에 그대로 넣습니다. 답장하기에는 편리합니다. 받은편지함에서 "답장"만 누르면 되기 때문입니다. 하지만 이는 스패머에게도 좋은 선물입니다.

스패머가 당신의 양식을 발견하면 다음과 같은 일이 벌어집니다.

1. "from" 필드에 피해자의 이메일 주소를 넣어 양식을 제출합니다
2. 당신의 서버는 성실하게 그 피해자의 주소를 From 헤더에 넣은 이메일을 보냅니다
3. 피해자의 메일 서버는 자기 도메인에서 온다고 주장하지만 당신의 IP에서 출발한 이메일을 보게 됩니다
4. 당신의 도메인에 적절한 SPF/DKIM/DMARC 레코드가 없으면(있더라도), 많은 서버가 문의 양식 트래픽에 관대하기 때문에 이메일이 통과할 수 있습니다
5. 피해자는 자기 주소에서 온 것처럼 보이는 스팸을 받거나, 당신의 도메인이 스푸핑으로 플래그 처리됩니다

이것은 이론적인 공격이 아닙니다. 끊임없이 발생합니다. 문의 양식을 운영하면서 메일 서버 로그를 확인해 본 적이 없다면, 이미 이런 방식으로 사용되고 있을 가능성이 높습니다.

문의 양식 이메일을 보내는 올바른 방법

해결책은 사용자 입력을 절대 From 헤더에 넣지 않는 것입니다. 대신 다음처럼 구성합니다.

• From: [email protected] (또는 당신이 제어하는 아무 주소)
• Reply-To: 사용자가 제출한 이메일 주소
• Subject: 원한다면 사용자의 이름은 포함해도 되지만, 이메일은 절대 포함하지 않습니다
• Body: 모든 양식 데이터를 명확한 레이블과 함께 포함합니다

이렇게 하면 서버는 당신이 소유하고 적절히 인증한 주소에서만 이메일을 보냅니다. 받은편지함에서 "답장"을 누르면 여전히 사용자에게 전달됩니다. 그것이 Reply-To의 역할입니다. 하지만 스패머가 당신의 양식을 이용해 임의의 주소를 사칭할 수는 없습니다.

대부분의 이메일 라이브러리는 이를 기본적으로 지원합니다. PHP의 PHPMailer에서는 다음과 같습니다.

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

Python의 smtplib와 email.mime에서는 다음과 같습니다.

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

Node.js의 Nodemailer에서는 다음과 같습니다.

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

현재 문의 양식이 사용자 입력을 From 헤더에 넣고 있다면, 이는 한 줄로 고칠 수 있는 문제입니다. 오늘 바로 수정하세요.

속도 제한은 선택 사항이 아닙니다

헤더를 올바르게 관리하더라도, 보호되지 않은 문의 양식은 여전히 스팸 경로가 됩니다. 스패머는 서로 다른 메시지 본문으로 양식을 수백 번 제출하고, 받은편지함은 쓰레기로 가득 찹니다.

여러 수준에서 속도 제한이 필요합니다.

• IP별: 같은 IP에서 시간당 5회 이하 제출
• 이메일별: 같은 이메일 주소에서 하루 3회 이하 제출
• 전체: 모든 사용자 전체에서 시간당 50회 이하 제출(트래픽에 맞게 조정)

속도 제한은 웹 서버 설정에만 둘 것이 아니라 애플리케이션 코드에 있어야 합니다. Nginx와 Apache의 속도 제한도 도움이 될 수 있지만, 이들은 요청 수준에서 동작하며 이메일 주소나 양식별 악용 패턴을 알지 못합니다.

프레임워크를 사용하고 있다면 바로 넣을 수 있는 속도 제한 미들웨어가 있을 가능성이 큽니다. 처음부터 구축한다면, 만료 키를 사용하는 간단한 Redis 카운터로도 충분합니다.

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

이 방식이 완벽한 것은 아닙니다. 스패머는 IP를 순환할 수 있습니다. 하지만 악용 비용을 크게 높입니다.

CAPTCHA는 해결책이 아니라 트레이드오프입니다

Google의 reCAPTCHA v3는 보이지 않으며 행동을 기반으로 사용자 점수를 매기므로 이상적으로 들립니다. 실제로는 예상보다 자주 정상 사용자를 차단합니다. 특히 VPN, Tor, 공유 회사 네트워크를 사용하는 사용자에게 그렇습니다.

reCAPTCHA v2("I'm not a robot" 체크박스)는 더 안정적이지만 마찰을 추가합니다. Honeypot 필드, 즉 사람은 채우지 않지만 봇은 채우는 숨겨진 양식 입력은 사용자 영향 없이 단순한 봇을 잡아내지만, 진지한 스패머라면 우회하기 매우 쉽습니다.

가장 좋은 접근은 계층화입니다.

1. 올바른 이메일 헤더(타협 불가)
2. 속도 제한(타협 불가)
3. Honeypot 필드(쉽게 얻는 이점, 단점 없음)
4. 위 조치 이후에도 의미 있는 스팸이 계속될 때만 CAPTCHA

CAPTCHA를 추가한다면, 낮은 임계값(0.5 이하)의 reCAPTCHA v3를 사용하고 점수가 낮은 사용자를 위해 v2로 대체 경로를 제공하세요. 이렇게 하면 대부분의 사용자에게는 마찰을 낮게 유지하면서도 봇을 차단할 수 있습니다.

서드파티 양식 서비스를 사용할 때

작은 사이트를 운영하고 양식 인프라를 유지 관리하고 싶지 않다면, Formspree, Tally, Netlify Forms 같은 서드파티 서비스가 이 모든 것을 대신 처리합니다. 이들은 속도 제한, 검증, 자체 도메인에서의 이메일 발송을 수행하므로 당신의 평판은 깨끗하게 유지됩니다.

트레이드오프는 사용자 데이터를 제3자에게 보낸다는 점이며, 이는 개인정보 처리방침이나 GDPR 의무와 충돌할 수 있습니다. 클라이언트 측 데이터 처리는 개인정보 보호를 중시하는 팀 사이에서 커지는 흐름이지만, 문의 양식은 본질적으로 서버 측 처리가 필요합니다. 자격 증명을 노출하지 않고 브라우저에서 이메일을 보낼 수는 없습니다.

민감한 문의(법률, 의료, 금융)를 다룬다면 자체 양식 인프라를 운영해야 할 가능성이 높습니다. 그 외의 경우에는 서드파티 서비스가 합리적인 선택입니다.

DMARC 문제

문의 양식 헤더를 수정하더라도, 도메인에 DMARC 정책이 없다면 안전하지 않습니다. DMARC는 SPF 또는 DKIM 검사에 실패한 이메일을 어떻게 처리할지 수신 메일 서버에 알려줍니다. 이것이 없으면, 스패머는 당신의 서버를 사용하지 않더라도 당신의 도메인에서 온 것처럼 보이는 이메일을 여전히 보낼 수 있습니다.

DMARC 설정은 이 글의 범위를 벗어나지만, 이메일 평판을 진지하게 관리한다면 타협할 수 없는 요소입니다. 모니터링 전용 정책(p=none)으로 시작한 뒤, 정상 이메일이 적절히 인증되는지 확인하면서 점진적으로 p=quarantine 또는 p=reject로 이동하세요.

쿠키 동의와 양식 추적은 어떻게 해야 할까요?

문의 양식이 제출을 추적하기 위해 분석 도구나 마케팅 픽셀을 사용한다면, GDPR과 ePrivacy 규칙의 적용을 받을 가능성이 높습니다. 대부분의 문의 양식에는 추적이 필요하지 않습니다. 이메일을 받았기 때문에 누군가 양식을 제출했다는 사실은 이미 알 수 있습니다. 하지만 Facebook Pixel이나 Google Analytics 이벤트 같은 것을 사용한다면, 해당 스크립트가 로드되기 전에 명시적 동의가 필요합니다.

가장 단순한 접근은 문의 양식 제출을 전혀 추적하지 않는 것입니다. 반드시 추적해야 한다면, 사용자가 동의한 뒤에만 추적 스크립트를 로드하고 동의 배너가 규정을 준수하는지 확인하세요.

핵심 요약

• 사용자가 제출한 이메일 주소를 절대 From 헤더에 넣지 마세요. 대신 Reply-To를 사용하세요.
• 속도 제한은 필수입니다. 웹 서버뿐 아니라 애플리케이션 수준에서 구현하세요.
• Honeypot 필드는 비용 없이 얻는 이점입니다. CAPTCHA는 최후의 수단이어야 합니다.
• 서드파티 양식 서비스는 작은 사이트에 합리적인 선택이지만, 개인정보 보호 측면의 트레이드오프가 있습니다.
• 도메인에서 이메일을 하나라도 보낸다면 DMARC 정책이 필요합니다.

FAQ

Q: 문의 양식을 그냥 비활성화하고 mailto 링크를 대신 사용해도 되나요?

A: 가능은 합니다. 하지만 mailto 링크는 이메일 주소를 스크레이퍼에게 노출하고, 구조화된 데이터를 수집할 수 없게 됩니다. 스팸이 감당할 수 없을 정도라면 고장 난 문의 양식보다 mailto 링크가 낫지만, 양식을 고치는 것이 둘 다보다 낫습니다.

Q: 정당한 이유로 사용자의 주소에서 이메일을 보내야 한다면 어떻게 하나요?

A: 거의 확실히 그럴 필요가 없습니다. 필요하다고 생각한다면, 아마도 Reply-To가 이미 해결하는 워크플로 문제(예: 답장 라우팅)를 해결하려는 것일 가능성이 큽니다. 정말로 임의의 주소에서 이메일을 보내야 한다면, 문의 양식이 아니라 적절한 인증을 갖춘 전용 이메일 서비스가 필요합니다.

Q: 내 문의 양식이 이미 악용되고 있는지 어떻게 알 수 있나요?

A: 발신 SMTP 연결에 대한 메일 서버 로그를 확인하세요. 알 수 없는 주소로 나가는 이메일이 대량으로 보이거나, 도메인이 Spamhaus 같은 스팸 데이터베이스에 플래그 처리되어 있다면, 릴레이로 사용되고 있을 가능성이 큽니다. MXToolbox 같은 도구로 도메인 평판을 확인할 수 있습니다.

Q: 무료 CAPTCHA 서비스를 사용해도 안전한가요?

A: Google의 reCAPTCHA는 무료이고 널리 사용되지만, 사용자 데이터를 Google로 전송하므로 개인정보 처리방침과 충돌할 수 있습니다. hCaptcha는 사용자 데이터를 AI 모델 학습에 사용하지 않는 개인정보 보호 중심 대안입니다. Cloudflare Turnstile은 기존 CAPTCHA보다 덜 침해적인 또 다른 선택지입니다.

Q: SPF, DKIM, DMARC의 차이는 무엇인가요?

A: SPF는 어떤 메일 서버가 당신의 도메인에서 이메일을 보낼 수 있는지 나열합니다. DKIM은 발신 이메일에 암호화 서명을 해 수신자가 이메일이 변조되지 않았음을 확인할 수 있게 합니다. DMARC는 이 둘을 연결하고, 이메일이 SPF 또는 DKIM 검사에 실패했을 때 수신자가 무엇을 해야 하는지 알려줍니다. 적절한 이메일 인증을 위해서는 세 가지가 모두 필요합니다.

Sources

• OWASP: Email Header Injection — 문의 양식이 이메일 스푸핑에 어떻게 악용될 수 있는지에 대한 자세한 설명입니다.
• RFC 5322: Internet Message Format — From과 Reply-To를 포함한 이메일 헤더를 정의하는 기술 표준입니다.
• DMARC.org: Overview — DMARC 정책을 이해하고 구현하기 위한 공식 자료입니다.
• Spamhaus: Domain Blocklists — 도메인이 스팸으로 플래그 처리되었는지 확인하고 차단 목록이 어떻게 작동하는지 이해할 수 있습니다.