최근까지 내 Postfix 서버는 잘 돌아가고 있었습니다. 그런 다음 a) 스팸을 방지하고 b) 나 자신을 대신하여 나에게 이메일이 전송되는 것을 허용하지 않도록 몇 가지 제한 사항을 구현했습니다. 내 이메일 주소에서 누군가에게 비트코인을 보내달라고 요청하는 이메일을 받기 시작했습니다.
a와 b를 모두 고치고 싶습니다.
이제 내 Postfix 서버를 통해 이메일을 보낼 수 없습니다.
Client host rejected: cannot find your reverse hostname, [<my ip here>]
저는 노트북을 다른 장소와 국가로 가져가서 그곳에서 Wi-Fi에 연결합니다. 나는 항상 이메일을 보낼 수 있기를 원합니다.
이것은 내 Postfix 구성의 일부입니다. 계정 및 도메인 데이터베이스의 경우 Postgresql을 사용합니다.
smtpd_helo_required = yes
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_reverse_client_hostname,
reject_unknown_client_hostname,
reject_unauth_pipelining
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_helo_hostname,
### reject_non_fqdn_helo_hostname,
reject_unauth_pipelining
smtpd_sender_restrictions =
permit_mynetworks,
reject_sender_login_mismatch,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unauth_pipelining
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unauth_destination
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unauth_pipelining
smtpd_data_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_multi_recipient_bounce,
reject_unauth_pipelining
# deliver mail for virtual users to Dovecot's LMTP socket
virtual_transport = lmtp:unix:private/dovecot-lmtp
# query to find which domains we accept mail for
virtual_mailbox_domains = pgsql:/etc/postfix/virtual_mailbox_domains.cf
# query to find which email addresses we accept mail for
virtual_mailbox_maps = pgsql:/etc/postfix/virtual_mailbox_maps.cf
# query to find a user's email aliases
virtual_alias_maps = pgsql:/etc/postfix/virtual_alias_maps.cf
virtual_alias_domains =
alias_database =
alias_maps =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
inet_interfaces = all
답변1
짧은 답변
구성 postfix이 불필요하게 복잡합니다. 구성의 일부 제한 사항은 서로 상쇄되거나 너무 제한적이어서 ssh서버에 가서 모든 발신 이메일을 수동으로 보내야 할 수도 있습니다.
이 답변은 게시된 구성을 검색하는 대신 대부분의 목적에 맞게 합리적으로 안전한 이메일 시스템을 구성하는 데 일반적으로 필요한 사항을 간략하게 설명합니다. 각 구성 요소를 구성하는 방법에 대한 철저한 자습서는 아닙니다. 그러나 마지막으로 내 이메일 서버를 구성하는 데 유용하고 가치 있는 온라인 리소스 목록이 있습니다.
postfix귀하의 의견에는 단일 설치로 여러 도메인을 처리하는 것과 같이 해결되지 않은 몇 가지 추가 요구 사항이 있습니다 . 합리적으로 숙련된 관리자가 설정을 조정하고 필요한 다중 도메인 구성 요소를 추가할 수 있다고 가정합니다.
최신 소규모 이메일 서비스 제공업체의 필수 요소 개요
보안 및 평판 관련 이메일 헤더의 그래픽 보기
최신 이메일 시스템은 많은 보안 및 도메인 관련 평판 요소를 포함하도록 발전했습니다. 아마도 시작하는 가장 쉬운 방법은 이메일 헤더에 포함된 더 중요한 새 요소 중 일부에 대한 다이어그램을 보는 것입니다.
스푸핑 시도 및 평판 문제로부터 도메인을 보호하세요.
도메인에서 발생한 것으로 보이는 이메일 트래픽의 신뢰성을 보장하려면 세 가지 기본 구성 요소를 구성해야 합니다.
이것들은 모두:
- 발신자 정책 프레임워크(자외선 차단 지수)
- 도메인 키로 메일 식별(DKIM)
- 도메인 기반 메시지 인증 보고 및 일관성(DMAARC)
이들 각각에는 서버에서 실행되는 데몬과 서버에 연결하여 자동으로 도메인 정책을 확인하고 암호화 서명을 확인하는 데 사용되는 DNS 레코드가 있습니다.
- 간단한 SPF 설명:
Postfix는 발신자가 아웃바운드 이메일 정책을 준수하는지 평가하는 SPF 데몬을 통해 아웃바운드 이메일을 전달합니다. 수신 메일 서버는 DNS에서 도메인의 SPF 레코드를 검색하고 송신 서버가 이메일에 배치한 SPF 헤더와 비교하여 레코드를 확인합니다.
- 간단한 DKIM 설명:
Postfix는 자동으로 메시지에 서명하고 이메일 헤더에 해시를 포함하는 DKIM 데몬을 통해 보내는 이메일을 전달합니다. 수신 메일 서버는 DNS 레코드에서 도메인의 DKIM 공개 키를 검색하고 메시지의 본문 해시를 확인합니다.
- 간단한 DMARC 설명:
수신 메일 서버는 DNS에서 DMARC 정책 레코드를 검색하고 메시지를 수락 또는 거부하거나 메시지에 대해 소프트 실패를 수행합니다.
고려되었습니다최고의 보안 관행도메인에서 이메일이 전송되지 않더라도 "거부" DMARC 정책 레코드를 입력하세요.
SPF, DKIM 및 DMARC에 대한 DNS 항목의 예
MX 10 mail.domain.tld.
TXT "v=spf1 a:mail.domain.tld -all"
mail._domainkey IN TXT ( "v=DKIM1; h=sha256; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0w7N0fWtTndtlR+zOTbHyZOlvFiM73gyjjbHDN1OhhcPCbhRUqTsA7A8uXHGHao6nZ5qejlVtn6NfZwbn7rdhJ0MTjlgTnTsVa8E9rgS6dFo0bEIzeFecDr/4XOF9wpNjhHlnHm4wllkPheFnAWpZQiElZeYDN5Md47W1onwZ3DwcYJNX/3/GtfVZ0PrjisC4P0qeu+Z8jIgZc"
"MLvBm8gj2pX3V6ntJY9QY09fWSVskvC6BQhi6ESOrqbM63f8ZJ4N/9ixPAMiD6k/lyGCokqc6sMuP6EC7z5McEOBbAVEuNy3idKi1sjwQH8WZHrvlSBlzx1wwmpFC1gqWcdTiEGwIDAQAB" ) ; ----- DKIM key mail for domain
_dmarc IN TXT v=DMARC1;p=reject;sp=reject;fo=0:d;adkim=s;aspf=s;rua=mailto:[email protected];ruf=mailto:[email protected];
_domainkey IN TXT o=-;
명명된 DNS 레코드에 mail._domainkey암호화 공개 키가 포함되어 있음을 알 수 있습니다. 이 키 및 관련 기록은 패키지가 서버에 설치될 opendkim-genkey때 설치된 프로그램을 사용하여 생성 할 수 있습니다.opendkim
키 생성은 매우 간단합니다.
opendkim-genkey -b 2048 -d yourdomain -h sha256 -s mail
이 명령은 개인 키, 공개 키 및 올바른 형식의 DNS 레코드를 생성합니다. 개인 키는 opendkim 구성에 나열된 디렉터리에 있어야 합니다. 공개 키와 관련 DNS 레코드는 도메인의 DNS 영역 파일에 저장됩니다. 안타깝게도 일부 DNS 제공업체에는 레코드 길이 제한이 있습니다. 따라서 DNS 공급자가 공개 키 길이를 수용할 수 있는지 확인하십시오.
SPF 및 DKIM 밀터 추가
SPF
매뉴얼 페이지에서 발췌 policyd-spf:
접미사 통합
1. Add the following to /etc/postfix/master.cf:
policyd-spf unix - n n - 0 spawn
user=policyd-spf argv=/usr/bin/policyd-spf
2. Configure the Postfix policy service in /etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_policy_service unix:private/policyd-spf
...
policyd-spf_time_limit = 3600
Decim
데몬 opendkim은 표준 UNIX 소켓으로 구성되거나 inetd서비스 포트에서 실행될 수 있는 UNIX 소켓에서 실행됩니다. 내 Debian 설치에서 이 구성은 에 있습니다 /etc/default/opendkim. 를 실행한 후 milter를 의 구성 opendkim에 추가해야 합니다 .postfix/etc/postfix/main.cf
다음은 작동 중인 서버의 예입니다.
# DKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
DMARC
소규모 또는 개인 이메일 서버의 경우 DMARC는 단순히 DNS 레코드로 제한될 수 있습니다. DMARC 검사 데몬을 사용하면 수신 메시지를 보내는 도메인의 정책에 따라 거부하고 요청된 보고서를 보내는 도메인으로 다시 보낼 수 있습니다. 신고는 "선량한 이웃"으로 간주됩니다. 그러나 구성 오버헤드가 상당히 높기 때문에 일반적으로 소규모 또는 개인 시스템에서는 이 기능을 활성화하지 않습니다.
그러나 DMARC DNS 레코드는 도메인 평판을 유지하는 데 매우 중요합니다. 모든 최신 대형 이메일 제공업체는 이 기록을 사용하여 귀하의 도메인에서 보낸 것으로 보이는 메시지를 수락하거나 거부합니다. 따라서 DMARC 레코드가 없으면 도메인에서 보낸 것으로 보이는 모든 수신 메시지는 도메인의 평판 점수에 포함됩니다. 따라서 메일 전송을 전혀 원하지 않는 도메인은 "거부" DMARC 레코드를 게시하여 스패머가 보낸 사기성 메일로 인해 발생하는 평판 문제를 방지해야 합니다.
이메일 서버와 클라이언트 간의 TLS 연결
구성 정보는 Dovecot 및 Postfix를 실행 중임을 나타냅니다.
Dovecot은 서버의 Postfix와 연결됩니다. 많은 소규모 설치에서 서버 연결은 동일한 물리적/논리적 하드웨어의 Unix 소켓을 통해 수행됩니다.
따라서 MUA(메일 사용자 에이전트) 연결은 실제 메일 서버가 아닌 미들웨어에 의해 처리됩니다. 당신이 생각하는 한 그것은 Dovecot입니다.
MUA(예: Evolution, Sylpheed, Mutt 등)에서 사용자 이름과 비밀번호를 안전하게 전송하려면 TLS를 활성화하고 Dovecot에서 적절하게 설정해야 합니다.
참고로 다음을 참조하세요.Dovecot의 TLS 설정 문서.
postfix를 사용한 서버 간 또는 미들웨어 연결은 동일한 TLS 인증서로 암호화될 수 있지만 필수는 아닙니다. 그러나 소규모 이메일 서버의 경우 Postfix Connect의 "미들웨어"는 동일한 하드웨어에 있기 때문에 반드시 암호화가 필요하지 않습니다.
메일 서버 및 MUA 인터페이스(POP3, IMAP 등)에 대한 LetsEncrypt TLS 인증서를 받으세요.
이것암호화하자이 프로젝트는 도메인 검증 TLS 인증서 획득을 단순화하는 데 큰 도움이 됩니다. 도메인에 이미 인증서가 있다고 가정하면 이 --expand옵션을 사용하여 메일 서버의 하위 도메인을 인증서에 추가할 수 있습니다.
- postfix 및 dovecot 서비스를 중지합니다.
- 웹 서버가 실행 중이면 서버를 중지합니다.
- 현재 인증서에 포함되어 실행 중인 모든 서비스를 중지합니다.
- 인증서 확장
certbot certonly --expand -d domain.tld,www.domain.tld,mail.domain.tld
그런 다음 구성에 인증서 경로를 추가합니다 main.cf.
smtpd_tls_key_file = /etc/letsencrypt/live/domain.tld/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/domain.tld/fullchain.pem
그리고 위에 나열된 Dovecot 문서에 따라 Dovecot 구성에 인증서 경로를 추가합니다.
- 모든 서비스를 다시 시작하고 구성이 유효한지 확인하십시오.
SMTP TLS 연결은 서버가 다른 서버에 연결하는 것입니다. 그러나 Dovecot TLS 연결은 일반적으로 웹 메일이 아닌 클라이언트에서 이메일을 보내기 위해 사람들이 연결하는 것입니다.
SMTP 서버 간 TLS 호환성 설정
일부 메일 서버는 다른 서버에서 받은 메일에 대해 여전히 TLS 암호화 연결을 사용하지 않습니다. 이 경우 엄격한 TLS 시행으로 인해 메일이 해당 서버 및 도메인으로 전달되지 않습니다. 그러나 많은 대규모 이메일 제공업체는 연결이 TLS로 보호되지 않는 경우 수신 이메일을 의심스러운 것으로 표시합니다. 따라서 최적의 호환성을 유지하려면 애플리케이션에 다음 설정을 포함하십시오./etc/postfix/main.cf
smtpd_tls_security_level = may
대부분의 이메일 공급자는 CA 승인 인증서를 사용하기 위해 이러한 서버 간 연결을 요구하지 않으며, 인증서가 CA 승인을 받은 경우에도 일반적으로 유효성 검사가 수행되지 않는다는 점에 유의하는 것도 중요합니다.
단, Dovecot에 포함된 TLS 인증서는 CA의 승인을 받아야 합니다. Dovecot의 자체 서명된 인증서는 대부분 의 MUA(예 sylpheed: .evolutionthunderbird
합리적인 SMTP 클라이언트 제한
내 경험상 스팸의 99%는 SPF, DKIM 검사, RBL 검사를 통해 거부될 수 있습니다.
이것은 내 "표준" 클라이언트 제한 사항의 일부입니다. 이러한 제한 사항은 순차적으로 처리된다는 점에 유의하는 것이 중요합니다. 내 경험에 따르면 다음 순서가 매우 잘 작동합니다.
smtpd_client_restrictions = permit_mynetworks
permit_sasl_authenticated
check_helo_access hash:/etc/postfix/helo_access
check_client_access hash:/etc/postfix/client_checks
reject_unauth_destination
check_policy_service unix:private/policy-spf
reject_rbl_client cbl.abuseat.org
reject_rbl_client pbl.spamhaus.org
reject_rbl_client sbl.spamhaus.org
reject_rbl_client bl.blocklist.de
reject_unknown_client
SMTPD 클라이언트 제한 호환성 설정
가장 예외적인 제한 사항은 reject_unknown_client설정입니다. 많은 온라인 서비스는 역방향 도메인을 올바르게 구성하지 않거나 올바르게 매핑되거나 매핑되지 않을 수 있는 일련의 전송 도메인을 활용하지 않습니다. 따라서 잘못 구성된 이메일 공급자와의 호환성을 최대화하려면 이 제한을 제거하십시오.
그러나 스팸의 거의 100%가 올바른 역방향 도메인 기록이 없는 이메일 서버에서 전송됩니다.
헬리콥터 검사
스패머는 도메인 이름, IP 주소 또는 로컬 호스트를 전송하여 HELO를 스푸핑하려고 시도하는 경우가 많습니다. check_helo_access위에 표시된 옵션을 사용하면 이러한 스푸핑 시도를 즉시 거부할 수 있습니다. HELO 텍스트 데이터베이스는 도메인 이름, IP 주소 또는 IP 주소 범위, 그 뒤에 다시 전송될 작업 및 메시지로 구성됩니다.
매우 간단한 HELO 확인은 다음과 같습니다.
# helo access
# check_helo_access hash:/etc/postfix/helo_access
localhost REJECT Only I am me
127.0.0.1 REJECT Only I am me
example.com REJECT Only I am me
dns.host.ip.addr REJECT Only I am me
"example.com"은 도메인 이름이고 "dns.host.ip.addr"은 서버의 DNS 목록에 있는 IP 주소입니다.
이 데이터베이스 예제는 실제 서버 로그에서 다음과 유사한 결과를 생성합니다.
Oct 30 06:32:49 <domain> postfix/smtpd[22915]: NOQUEUE: reject: RCPT from xxx-161-xxx-132.dynamic-ip.xxxx.net[xxx.161.xxx.132]: 554 5.7.1 <xxx.xxx.xxx.xxx>: Helo command rejected: Only I am me; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<xxx.xxx.xxx.xxx>
잠재적인 스팸 발송자/스푸퍼는 "나만" 메시지를 받습니다. 메시지가 무엇인지는 중요하지 않지만 적어도 스팸 발송자/스푸퍼는 귀하가 그것을 알고 있다는 것을 알고 있습니다.
postfix다음 명령을 사용하여 데이터베이스를 생성 하십시오 .
postmap helo_access
client_check 화이트리스트를 통해 제한 예외 추가
개별 고객 수표는 다음과 같습니다.
ip.addr.hack.attmpt REJECT
misconfig.server.but.good OK
postfix다음 명령을 사용하여 데이터베이스를 생성 하십시오 .
postmap client_checks
그게 다야. 한 달에 3통 정도의 스팸 이메일을 받았는데 그 중 수백 통이 거부되었습니다.
자원
답변2
포트 587의 제출 인터페이스(MSA - Mail Submission Agent)에 대해 다양한 제한 사항을 사용하십시오. 예를 들면 다음과 같습니다(발췌 master.cf).
submission inet n - - - - smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_sender_restrictions=reject_authenticated_sender_login_mismatch
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
STARTTLS를 강제하고 인증 후에만 전송을 활성화하는 것이 가장 간단한 방법입니다. 댓글에서 제안한 대로 VPN 또는 이와 유사한 것을 사용하고 이 방법을 사용하여 IP/범위를 화이트리스트에 추가할 수도 있습니다.
MSA(포트 587)와 MTA(메일 전송 에이전트, 포트 25, 465)에 대해 서로 다른 포트를 사용하는 것이 좋습니다. 이는 서로 다르게 설정해야 하기 때문입니다.
이것은가장 작은예를 들어 필요에 따라 확장하세요.