이유 없이 메일이 반송되는 Postfix 메일

이유 없이 메일이 반송되는 Postfix 메일

대부분의 경우 잘 작동하는 Postfix 서버 설정이 있지만 매일 100 - 200개의 메일이 다음 오류와 함께 지연됩니다.

status=deferred (lost connection with alt1.gmail-smtp-in.l.google.com[74.125.142.27] while sending RCPT TO)

status=deferred (lost connection with mta6.am0.yahoodns.net[66.196.118.34] while sending message body)

이는 전체 발신 메일의 약 10%에 해당합니다. 들어오는 메일은 잘 작동하고 로컬 서버의 도메인으로 나가는 모든 메일도 잘 작동합니다.

문제를 해결하는 동안 Gmail이 계속 반송되는 특정 메일을 발견했습니다. 하지만 동일한 수신자에게 새 메일을 작성하면 Google에서는 문제 없이 해당 메일을 수락합니다.

반송되는 메일:

Sep  3 13:08:04 mail postfix/smtp[2623]: 72A66184148: to=<[email protected]>, relay=aspmx.l.google.com[173.194.79.27]:25, delay=2.5, delays=0.01/0/0.83/1.7, dsn=5.7.1, status=bounced (host aspmx.l.google.com[173.194.79.27] said: 554 5.7.1 9.9.9 (in reply to end of DATA command))

배달된 메일:

Sep  3 13:10:08 mail postfix/smtp[24005]: 38C47184147: to=<[email protected]>, relay=aspmx.l.google.com[173.194.79.27]:25, delay=3.3, delays=0/0.01/0.82/2.5, dsn=2.0.0, status=sent (250 2.0.0 OK 1378199356 hk5si14476075pac.241 - gsmtp)

반송된 동일한 메일을 로컬 서버의 다른 도메인으로 전달하면 문제가 없습니다.

그러나 Yahoo는 다음과 같은 오류로 이를 반송합니다.

host mta5.am0.yahoodns.net[66.196.118.240] said: 554 5.7.1 9.9.9 (in reply to end of DATA command)

두 이메일의 크기는 거의 동일하므로(100KB 미만) 여기서는 문제가 되지 않습니다.

서버 앞에 방화벽이 없습니다. 모든 DNS 설정이 정확하고 역방향 DNS가 올바르게 설정되었으며 제가 말했듯이 통과하지 못하는 특정 메일입니다.

ISP에 문의하여 MTU 설정이 괜찮은지 확인했습니다.

어떤 제안이 있으십니까?

업데이트 원격지에 두 번째 메일 서버를 관리하고 원격 도메인으로 반송되는 메일을 보내려고 했습니다. 무슨 일이 일어나고 있는지 확인하기 위해 수신 측에서 tcpdump를 실행했습니다. 반송되는 메일을 보내는 동안 서버는 RCPT TO를 보낸 후 RSET를 보냅니다.

16:17:23.249320 IP mail.mydomain.com.47556 > mail.myremotemailserver.com.smtp: P 74:126(52) ack 228 win 123 [email protected]...^.B2...}.....-B........{....... t...y...RCPT TO: ORCPT=

16:17:23.614527 IP mail.mydomain.com.47556 > mail.myremotemailserver.com.smtp: P 126:132(6) ack 242 win 123 E..:[email protected]^.B2...}.....-B........{....... t..vy...RSET

그러나 새 메일을 작성할 때 예상되는 RCPT 이후에 DATA를 보내고 메일은 정상적으로 전달됩니다.

16:19:20.911123 IP mail.mydomain.com.43064 > mail.myremotemailserver.com.smtp: P 73:125(52) ack 228 win 123 [email protected].*_^.B2...}.8..;&J.`..4...{P@..... t...y...RCPT TO: ORCPT=


16:19:21.297598 IP mail.mydomain.com.43064 > mail.myremotemailserver.com.smtp: P 125:131(6) ack 242 win 123 E..:[email protected].*.^.B2...}.8..;&K.`..B...{t5..... t..ay...DATA

나에게는별로 의미가 없습니다 ..

답변1

554는영구적인아시다시피 오류입니다. 이것은 대기열 구현 방법을 확인하기 위한 일종의 그레이리스트 테스트가 아닙니다.

다른 사람들이 지적했듯이 554개의 99.9%는 메시지가 스팸 방지 테스트에 실패했기 때문에 발행됩니다. DATA가 끝난 후 554가 표시된다는 사실은 메시지 내용에 마음에 들지 않는 내용이 있음을 의미합니다.~할 수 있었다그보다 훨씬 일찍 메시지를 거부하기로 이미 결정했으며 다양한 이유로 끝까지 기다리도록 구성되었습니다(1. 시간/대역폭/리소스 낭비, 2. 메시지에 대해 가능한 한 많은 정보 수집). .

이러한 상황에서 가장 어려운 부분은 수신 측에서 개발하고 시행하는 정책이 실패한다는 것입니다. 본문에 "apple"이라는 단어가 포함되어 있고 IP 주소의 마지막 옥텟이 우리가 알고 있는 3의 배수이기 때문에 그들은 귀하의 메시지를 거부할 수 있습니다. 가능성은 거의 없지만 가능합니다.

메시지는 일반적으로 1가지 기준에 실패하더라도 거부되지 않습니다. 특히 "큰 소년"의 경우에는 더욱 그렇습니다.추측하다여러 테스트에 실패했지만 정확하게 알아낼 수 있는 유일한 방법(거절 메시지에 정보가 부족하다는 점을 고려하여)은 불행하게도 그들에게 물어보는 것입니다.

나는 찾았다이 페이지귀하의 문제와 관련하여 Google에 알려주는 것이 좋은 방법일 수 있습니다. 얼핏 보면 야후와 비슷한 페이지를 찾을 수 없었다.

답변2

해당 특정 메시지에 대한 스팸 암살자 점수를 보려고 했습니까? 이 웹사이트로 이동하세요 [스팸 점수 검사기][1]

[1]:http://spamscorechecker.com/그 메시지와 전달된 다른 메시지를 그들에게 보내서 그들 사이의 차이점을 볼 수 있도록 하세요. 문제가 무엇인지 궁금하므로 계속 업데이트해 주세요.

답변3

Gmail 등처럼 들립니다. 스팸을 보내고 있다고 생각하므로 다시 시도하는지 확인하기 위해 제한을 받고 있습니다. 귀하는 귀하의 rdns가 올바르게 구성되었다고 말했지만 귀하가 보내는 도메인에 대한 모든 SPF 레코드가 귀하를 해당 도메인에 대해 허용된 발신자로 표시하는지 확인하십시오. 무료 온라인 도구 중 하나를 사용하여 귀하의 IP가 블랙리스트에 있는지 확인하고, 나타나면 해당 IP를 해당 목록에서 제거하도록 요청하십시오.

답변4

그들은 당신이 spamMTA다음에 따라 재구성하십시오 .스팸하우스, 또한 에 따라 MTA를 확인하십시오 Barracuda.(귀하의 IP address등)

관련 정보