사람을 겨냥한 스팸은 주의력을 낭비하게 만들지만, 자율 에이전트(autonomous agent)를 겨냥한 스팸은 입력값(input)이 됩니다. 따라서 모델이 확인하기 전에 미리 필터링하십시오:

curl --request POST \
  --url "https://api.us.nylas.com/v3/policies" \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
...

이것은 에이전트 계정(Agent Accounts)을 위한 정책입니다. 에이전트 계정은 AI 에이전트와 시스템 ID를 위해 구축된 Nylas 호스팅 메일함(현재 베타 버전)입니다. 이를 워크스페이스(workspace)에 연결하면 해당 워크스페이스의 모든 계정이 스팸 설정을 상속받습니다. 다음은 각 설정 항목이 어떤 역할을 하는지, 그리고 스스로는 의심할 줄 모르는 리더(reader)를 위해 어떻게 조정해야 하는지에 대한 설명입니다.

정책이 실제로 확인하는 사항

LLM 에이전트는 받은 편지함에 들어오는 것이라면 피싱(phishing), 정크(junk), 자동 회신(auto-replies), 그리고 모델을 조작하는 것이 유일한 목적인 메시지 등 무엇이든 성실하게 처리할 것입니다. 위협은 단순한 번거로움이 아니라, 오염된 컨텍스트(contaminated context)입니다. 정책 수준의 스팸 탐지는 메일이 SMTP를 통해 도착할 때 평가되는 두 가지 독립적인 신호를 제공합니다:

• use_list_dnsbl: 메시지 내용과 관계없이 알려진 악성 인프라를 잡아내는 고전적인 평판 조회 방식인 DNS 차단 목록(DNS blocklists)을 통해 발신 서버를 확인합니다.
• use_header_anomaly_detection: 메시지 헤더(headers)에서 구조적 이상 징후를 찾습니다. 이는 정상적인 메일 서버에서는 발생하지 않는 형태의 변형을 탐지합니다.

두 기능 모두 애플리케이션이 확인하기 전에 실행되며, 이는 이러한 작업을 수행하기에 가장 적합한 위치입니다. 메일함 계층(mailbox layer)에서 필터링하는 것은 모든 다운스트림 프롬프트(downstream prompt)에 회의적인 태도를 갖도록 가르치는 것보다 비용이 저렴합니다. 또한 메일함 가이드에 따르면, 인바운드 필터링은 에이전트가 루프(loops)나 메일러 데몬(mailer-daemon) 노이즈에 반응하는 것을 방지합니다.

플래그가 지정된 메일의 행방

스팸 탐지 경로를 트리거하는 메시지는 inbox 대신 모든 계정에 기본적으로 제공되는 6개의 시스템 폴더 중 하나인 junk 폴더로 이동합니다. 에이전트의 일반적인 읽기 경로(inbox 메시지 목록화, 새 메일에 대한 inbound webhook 반응)에서는 해당 메시지를 단순히 마주치지 않게 되지만, 데이터가 파괴되는 것은 아닙니다. 튜닝 시점에 junk 폴더를 검사할 수 있으며, 오탐(false positives)도 복구 가능합니다.

보관(Retention) 또한 동일한 정책의 일부입니다. limit_spam_retention_period와 limit_inbox_retention_period를 독립적으로 설정할 수 있지만, 미리 알아두어야 할 한 가지 제약 사항이 있습니다. 스팸 보관 기간은 반드시 inbox 보관 기간보다 짧아야 하며, 이를 통해 실제 메일보다 스팸이 먼저 삭제되도록 합니다. 일시적인 워크플로우(transient workflows)를 처리하는 에이전트의 경우, 공격적인 스팸 보관 정책은 별도의 비용 없는 위생 관리(hygiene)와 같습니다. 몇 시간 내에 작업이 완료되는 메일함의 스팸을 한 달 동안 보관할 이유는 없습니다.

플래그(flag) 대신 차단(block)해야 하는 경우

스팸 탐지는 확률적(probabilistic)입니다. 때로는 정답을 미리 알고 있는 경우도 있습니다. 이미 판단을 내린 발신자에 대해서는 block 액션이 포함된 규칙을 사용하여 SMTP 레이어에서 메시지를 거부할 수 있습니다. 이 경우 메시지는 저장되지도, 전달되지도 않으며, 애플리케이션이 무시해야 할 이벤트로조차 남지 않습니다.

curl --request POST \
  --url "https://api.us.nylas.com/v3/rules" \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
...

범위(scoping)에 관한 참고 사항: 인바운드 규칙(inbound rules)은 is, is_not, contains, in_list 연산자를 사용하여 발신자 필드인 from.address, from.domain, from.tld만 매칭합니다. 문자열 매칭은 대소문자를 구분하지 않으므로 SPAM-Domain.com과 같은 변형을 따로 고려할 필요가 없습니다.

재배포 없이 차단 목록(blocklist) 확장하기

규칙 조건에 도메인을 하드코딩(Hardcoding)하는 방식은 세 번째 스팸 파도가 몰려와 누군가 다시 규칙 정의를 수정해야 할 때까지는 작동합니다. 리스트(Lists)는 이러한 유지보수 문제를 해결합니다. 리스트는 규칙이 in_list 연산자를 통해 참조하는 타입화된 컬렉션(domain, tld, 또는 address)입니다. 따라서 차단 대상을 업데이트하려면 리스트만 업데이트하면 됩니다. 해당 리스트를 가리키는 모든 규칙에 변경 사항이 즉시 반영되며, 엔지니어가 아닌 사람도 이를 수행할 수 있습니다.

차단 목록(blocklist)에 추가 — 요청당 최대 1,000개 항목

curl --request POST
--url "https://api.us.nylas.com/v3/lists/$LIST_ID/items"
...

값은 쓰기 작업 시 소문자로 변환되고 공백이 제거(trimmed)되며, 리스트의 유형에 따라 유효성 검사가 수행됩니다 (예: domain 리스트는 전체 이메일 주소를 거부함). 중복 항목은 조용히 무시되므로, 자동화된 "스팸 신고(report spam)" 파이프라인이 아무런 확인 없이 항목을 추가할 수 있습니다. 규칙 측면에서는 연산자만 교체하면 됩니다: 동일한 block 액션을 사용하되 { "field": "from.domain", "operator": "in_list", "value": ["<LIST_ID>"] }와 같이 설정합니다.

메시지가 왜 스팸 처리되었는지 감사(Audit)하기

무작정 튜닝하는 것은 추측에 불과합니다. 규칙 엔진(rule engine)이 에이전트 계정(Agent Account)을 위해 인바운드 메시지를 평가할 때마다, Nylas는 GET /v3/grants/{grant_id}/rule-evaluations를 통해 목록을 확인할 수 있는 감사 항목(audit entry)을 기록합니다. 각 레코드에는 평가 단계(메시지가 수락되기 전에 거부되었다면 smtp_rcpt, 수락 후에 평가되었다면 inbox_processing)와 고려된 정규화된 발신자 데이터, 일치한 규칙, 적용된 액션이 표시됩니다.

운영 매뉴얼(runbook)에 반드시 포함해야 할 두 가지 세부 사항은 다음과 같습니다:

• Fail-closed 차단은 라벨이 지정됩니다. 일시적인 오류(예: in_list 도중 리스트 조회 실패)로 인해 block 규칙을 평가할 수 없는 경우, Nylas는 메시지를 통과시키는 대신 차단하며, 감사 레코드에는 blocked_by_evaluation_error: true가 포함됩니다. SMTP 측면에서 이는 451 일시적 실패(tempfail)로 나타나므로, 발신 서버는 메시지를 반송(bounce)하는 대신 재시도합니다. 즉, 정당한 메일이 유실되지 않고 지연될 뿐입니다.
• 스팸으로 표시된 메일은 쿼리가 가능합니다. matched_rule_ids를 Rules API와 교차 참조하면 어떤 조건이 정확히 메시지를 잡아냈는지 확인할 수 있습니다. 이를 통해 "필터가 고객 이메일을 먹어버렸다"는 미스터리를 단 한 줄의 수정 사항으로 바꿀 수 있습니다.

민감도 조절(Tuning the sensitivity dial)

튜닝에는 피드백이 필요하므로, 처음 몇 주 동안은 필터가 어떻게 작동하는지 확인해야 합니다. 주기적으로 스팸 폴더(junk folder) 목록을 확인하고 쌓이고 있는 내용을 훑어보세요. 발견되는 모든 오탐(false positive)은 민감도를 낮추거나, 스팸 체크 이전에 명시적인 허용 패턴(allow-pattern) 규칙을 추가하기 위한 데이터 포인트가 됩니다.

에이전트가 무엇인가를 읽기 전에 설정하세요

팀들이 범하는 순서상의 실수는 에이전트를 먼저 배포한 뒤, 첫 번째 이상한 사건이 발생하고 나서야 인바운드 위생(inbound hygiene) 기능을 추가하는 것입니다. 반대로 하세요. 정책(policy)은 한 번의 API 호출로, 워크스페이스 첨부(workspace attachment)는 한 번의 호출로 처리되며, 그 시점부터 추가되는 모든 계정은 보호 기능을 상속받습니다. 제한 사항(limits), 보관(retention), 민감도(sensitivity), 그리고 이와 결합되는 규칙 작업(rule actions)을 포함한 전체 스키마(schema)는 Policies, Rules, and Lists에서 확인할 수 있습니다.

다음에 에이전트 메일함(agent mailbox)을 프로비저닝(provision)할 때는, 계정을 생성하는 것과 동일한 스크립트 내에서 정책을 생성하세요. 그런 다음 본인에게 명백한 스팸 메시지 하나와 정상적인 메시지 하나를 보내서, 각각 예상한 위치에 정확히 도착하는지 확인하십시오.