postfix와 dbmail을 사용하여 freebsd 서버를 통해 외부 주소로 이메일을 보내려고 합니다.
나는 다음을 발견했습니다.
myserver->myserver=확인
외부 서버 -> 내 서버 = OK
MYSERVER -> EXTERNALSERVER = 오류(454 4.7.1 릴레이 액세스 거부)
이 오류가 발생하는 이유는 무엇입니까? 내 생각엔 이것이 내 main.cf와 관련이 있는 것 같아요.
####MAIN.CF######
queue_directory = /var/spool/postfix
command_directory = /usr/local/sbin
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
mail_owner = postfix
default_privs = nobody
myhostname = server.domain.nl
mydomain = domain.nl
myorigin = $mydomain
inet_interfaces = all
virtual_transport = dbmail-lmtp:localhost:24
virtual_mailbox_domains = domain.nl
unknown_local_recipient_reject_code = 550
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/local/sbin/sendmail
mailq_path = /usr/local/bin/mailq
setgid_group = maildrop
html_directory = /usr/local/share/doc/postfix
manpage_directory = /usr/local/man
sample_directory = /usr/local/etc/postfix
readme_directory = /usr/local/share/doc/postfix
inet_protocols = ipv4
smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination
답변1
아웃바운드 이메일을 보내기 위해 메일 클라이언트를 통해 올바르게 인증하지 않았습니까? 아니면 네트워크의 모든 시스템이 인증 없이 보낼 수 있도록 mynetworks를 설정하지 않았습니까?
https://serverfault.com/questions/42519/how-to-Cordirect-postfix-relay-access-denied
답변2
설정할 때 다음 sendmail과 유사한 오류 메시지가 표시되었습니다.이 스레드. 나에게 문제는 포트 465(즉, TLS가 있는 SMTP)를 통해 인증했지만, 프로토콜에서는 포트 25(즉, TLS가 없는 SMTP)를 통한 인증과 같이 인증 후에 TLS를 실행해야 한다는 것이었습니다.
해결책은 포트를 ~/.authinfo다음으로 변경하는 것입니다.
machine server.domain.tld login [email protected] port 25 password XYZ
고쳐 쓰다: 저는 SMTP 전문가가 아닙니다. 내 대답은 내 경험과이 스레드, 댓글 중 하나는 인증을 위해 포트 25를 사용하는 것에 대한 반박을 언급합니다.
이는 SMTP AUTH의 작동 방식이 아닙니다. 동일한 포트(이 경우 587)를 사용하여 인증하고 전송합니다.
답변3
역사적으로 이메일 클라이언트(MUA)는 포트 25/TCP에 대한 SMTP 연결을 사용하여 나가는 메일을 로컬 메일 서버로 보내거나 메일 서버(MTA)가 한 메일 서버에서 다른 메일 서버로 이메일을 전달했습니다. 인증은 표준에 포함되지 않습니다. 이것은 매우 나쁜 생각으로 판명되었습니다.
이로 인해 발생하는 문제를 해결하기 위해 최신 메일 서버는 포트 587을 사용하여 클라이언트로부터 들어오는 이메일을 수락하도록 설정되는 경우가 많습니다. 이 포트를 사용하는 경우 일반적으로 인증이 강제로 수행되며 TLS 암호화(STARTTLS 사용)를 적극 권장합니다.
포트 25는 점점 더 "유효한" 메일 서버 간의 트래픽 전용으로 사용되고 있으며, 특정 메일 서버의 유효성은 주로 다양한 DNS 레코드에 의해 결정됩니다.
"릴레이 액세스 거부됨"은 현재 외부 서버를 통해 다른 메일 서버로 이메일을 보낼 수 있는 권한이 없음을 의미합니다.
YOURSERVER -> EXTERNALSERVER -> THIRD-PARTY-SERVER
차단됩니다. EXTERNALSERVER가 직접적으로 책임을 맡고 있는 도메인 중 하나와 일치하는 대상 주소로 이메일을 보내는 경우, 다른 스팸 방지 검사에 실패하지 않는 한 해당 이메일은 계속 허용됩니다.
다른 메일 서버는 들어오는 SMTP 연결에 다양한 스팸 방지 테스트를 적용할 수 있습니다.
연결할 때 연결 호스트는 해당 호스트 이름을 선언해야 합니다. 수신 호스트는 소스 IP 주소에 대해 역방향 DNS 조회를 수행합니다. DNS에서 보고한 이름이 연결 호스트에서 선언한 이름과 일치합니까? 정기적인 정방향 DNS 조회도 수행됩니다. 해당 이름에 대해 DNS가 보고한 IP 주소가 실제로 연결이 시작된 소스 IP 주소와 일치합니까? 이것은 가장 오래된 스팸 방지 테스트 중 하나입니다. 이 테스트에 실패하고 인증되지 않으면 대상 호스트를 직접 담당하는 이메일 주소로만 이메일을 보낼 수 있으며 제3자에게는 이메일을 보낼 수 없습니다.
특정 DNS 도메인의 어느 호스트가 인터넷으로 이메일을 보내야 하는지 (선택적으로) 지정할 수 있는 DNS SPF 레코드도 있습니다. 도메인에 SPF 레코드가 있는 경우(
dig domain.name TXT확인해 보세요)그리고이 기록은 귀하의 호스트가해서는 안 된다메일 서버가 인증되지 않은 경우 외부 서버에서 연결 시도를 완전히 거부할 수 있습니다.DNS MX 레코드는 이메일 전달의 또 다른 중요한 부분입니다. 이는 특정 도메인을 제공하는 메일 서버의 실제 호스트 이름을 지정합니다. 수신자의 이메일을 어디로 보내야 하는지 결정하기 위해
[email protected]이메일 서버는 먼저 MX 레코드를 찾습니다domain.example. 유사한 명령을 사용하여 직접 수행할 수 있습니다dig domain.example MX. 특정 DNS 도메인에 MX 레코드가 없는 경우 대체 규칙이 존재합니다. 일반 기존 DNS A 레코드가 존재하고domain.example해당 A 레코드로 식별된 IP 주소의 호스트가 포트 25/TCP에서 수신 대기하는 경우 다음으로 전송되는 모든 이메일은 다음과 같습니다. 해당 도메인이 이 IP 주소로 전송됩니다. 스팸 방지 확인을 위해 메시지의 MX 레코드보내다호스트를 확인할 수 있습니다. "이메일을 받을 준비가 되지 않은 것 같으면 이메일을 보내지 말아야 합니다."라고 생각합니다. 메일 서버 설정이 다양하므로 이것이 엄격하고 빠른 규칙은 아닐 것입니다. 하지만 가끔 "이게 스팸인가요?"에서 작은 긍정적/부정적 요소로 사용됩니다. 결정하다.
귀하가 가정 사용자이거나 고정 공용 IP 주소가 없는 소규모 기업인 경우 ISP는 귀하를 간단한 이메일 클라이언트로 취급하고 공급자의 이메일 서버로 나가는 SMTP 연결만 보내도록 허용할 수 있습니다. 이 시점에서 인증이 필요할 수도 있고 네트워크의 물리적 구조에 따라 인증되지 않은 연결을 허용할 수도 있습니다. 이 경우에도 자신만의 개인 메일 서버를 가질 수 있습니다. 이는 일반 이메일 클라이언트처럼 공급자의 메일 서버를 통해 모든 발신 이메일을 보냅니다. 이는 클래식 Sendmail의 구성 옵션 이름에 따라 "스마트 호스트" 구성이라고도 합니다. 기존의 인증되지 않은 포트 25 대신 최신 포트 587과 인증이 필요한 경우가 많습니다.
자신의 서버에서 수신 이메일을 받는 것도 인터넷 공급자가 허용하는 사항에 따라 달라집니다. 연결이 NAT인 경우(가정 및 소규모 비즈니스 인터넷 연결의 경우가 점점 늘어나고 있음) NAT를 통해 포트 25에 대한 고정 터널을 열지 않으면 들어오는 연결을 수신할 수 없습니다. IP 주소가 가끔 변경되는 경우 이메일 관련 DNS 기록을 최신 상태로 유지하는 것이 이메일 전달의 안정성에 매우 중요합니다.
공용 고정 IP 주소와 자체 DNS 도메인이 있으면 일반적으로 전체 인터넷에서 "실제" 메일 서버를 가질 수 있을 만큼 "충분히 큰" 것으로 간주됩니다. 메일 서버를 설정할 때 이메일 전달과 관련된 다양한 유형의 DNS 레코드에 세심한 주의를 기울여야 하며, 서버가 등록된 정확한 이름(SNMP 연결의 HELO/EHLO 메시지)을 사용하여 DNS에 자신을 소개하는지 확인해야 합니다. . 또한 역방향 DNS 레코드(IP 주소 -> 도메인 이름 매핑에 사용되는 PTR 레코드)가 올바른지 확인하세요.
답변4
내 네트워크 = 127.0.0.0/8[::1]/128
취소하세요. #라인당 양 수# mynetworks = 127.0.0.0/8 [::1]/128