SPF Record와 Gmail
글쓴이: modestcode / 작성시간: 목, 2007/10/04 - 5:44오후
요즘은 spf record가 별도 네임서버에 추가 안 돼 있으면 아예 보내지를 못하는 곳이 있더군요. gmail처럼. 대부분 그런가요?
gmail은 올 초에는 안 그랬는 것 같은데 언제 이렇게 됐죠?
mail이 돌아오면서 다음과 같은 메세지를 담고 있더군요.
(mail이 아예 안 보내지면 smtp-auth와 같은 설정에 문제가 있다고 생각하심이......)
Diagnostic-Code: smtp; 550-5.7.1 [your_mailserver_ip] The IP you're using to send
email is not authorized 550-5.7.1 to send email directly to our servers.
Please use 550 5.7.1 the SMTP relay at your service provider instead.
n37si2713999wag이 때 dns log를 보면,
Oct 04 16:04:53.471 client 127.0.0.1#1810: query: gmail.com IN MX Oct 04 16:04:53.850 client 127.0.0.1#1810: query: gmail-smtp-in.l.google.com IN A Oct 04 16:04:54.519 client 127.0.0.1#1810: query: alt2.gmail-smtp-in.l.google.com IN A Oct 04 16:04:54.826 client 127.0.0.1#1810: query: alt1.gmail-smtp-in.l.google.com IN A Oct 04 16:04:55.152 client 127.0.0.1#1810: query: gsmtp163.google.com IN A Oct 04 16:04:55.333 client 127.0.0.1#1810: query: gsmtp183.google.com IN A Oct 04 16:04:58.742 client 209.85.146.133#12455: query: your_domain IN TXT
TXT에서 뭔가 찾더라고요.
메일 서버랑 네임서버랑 같이 있으니까 spf record가 있더라도 보내지 못하더군요.
근데 나중에 찾아 보니 구글이 권장하는 것처럼[1],
v=spf1 include:aspmx.googlemail.com ~all
하는 것은 내키지 않습니다. 이미 있는 record를 사용하는 것은[2], goole를 믿을 수 있냐의 문제도 있지만, 내가 맞다고 얘기 해서는 안 되고 누구에게 계속 물어봐야 하는, 인터넷의 속성과 맞지 않는, 상황을 만듭니다. 궁극적으로 스팸 필터링을 제대로 하는 기본기를 쌓아서 극복해야할 문제라고 봅니다. 물론 쉽지 않겠지만 출입문을 원천 봉쇄하는 방식이라면 스팸을 차라리 더 참을 수 있을 것 같다는 생각입니다.
어쨌든 이제 구글로 메일을 보낼 수 있게 됐지만, 인터넷 인프라에 관한 구글의 생각을 엿봤다고 느끼니 좀 불편해 지는군요.
[1] http://www.google.com/support/a/bin/answer.py?hl=en&answer=33786
[2] http://www.openspf.org/FAQ/Common_mistakes#include
Forums:
요즘 국내 대부분의
요즘 국내 대부분의 포탈에서 SPF가 적용된 것으로 알고 있습니다.
까라면 까야죠.
그래도 도메인키보다는 편하다고 생각중입니다. ^^;
그렇더군요. 제가
그렇더군요. 제가 요즘 사정을 잘 몰랐습니다. 확실히 간단하긴 합니다. 구글의 경우 돌아오는 메세지가 좀 더 구체적이었으면 좋았겠지만, 스팸머들이 너무 쉽게 알아버려도 곤란할 것 같기도 합니다.
......
SPF(RFC4408), SenderID(RFC4406) 은 둘 다 'Experimental'입니다..
DomainKeys(RFC4870)을 보완한.. DKIM(RFC4871)은... 'Standards Track'입니다..
'Experimental' 과 'Standards Track' 의 차이는.. 영구에게 물어봅시다.. 제가 영어가 짧아서.. 흐흑..
대부분의 포털 메일 업체들이.. SPF를 사용하고 있다고 저도 어디선가 소문을 들었는데..
전 포털을 책임지고 있는 분들이 조금 더 신중해야한다고 생각합니다..
이를테면 SPF 쿼리로 들어오는 메일들을 'hotmail.com' 처럼 강제하지 않았으면 좋겠네요..
--
이 아이디는 이제 쓰이지 않습니다.
dig로 확인한 몇몇
dig로 확인한 몇몇 포털에서는 모두 spf record가 들어있더군요.
지금 hotmail.com 보내 보니 다음과 같은 메세지가 오더라고요.
gmail처럼 첨에 spf record를 보지 않고(좀 더 복잡한 메커니즘이 있어 보이지만) 바로 DB를 활용한다는 것입니다.
그래서 spamhaus에 가보니 PBL에 등록돼 있다고 나오더군요. 아마 같은 블럭에서 다른 아이피를 쓰는 누군가 때문에
그렇게 된 것 같습니다. 근데 독일 gmx.net 같은 업체는 아예 아무 응답도 없이 먹어버리는 것 같더군요. 이렇게 보내는 것은 그나마 양반인 것 같습니다.
......
[...snip...]
--
이 아이디는 이제 쓰이지 않습니다.
이젠 테스트하다가
이젠 테스트하다가 완전히 막혀버린 느낌이네요;(.
......
[...snip...]
언제 한 번.. SPF vs SenderID, DK vs DKIM 과 같은 진지한 토론을 해봤으면 좋겠습니다.
--
이 아이디는 이제 쓰이지 않습니다.
위의 메시지로
위의 메시지로 보아서는 SPF 와는 관련이 없는 것 같은데요. 메시지를 잘 읽어보면..
메일을 직접 보내지 마라.. 메일은 SMTP relay 를 통해서만 보내라.. 라고 하는 것 같습니다. 아마도 smtp 를 통하지 않고 직접 google 의 25번 포트를 열어서 메일을 발송하신 것이 아닌가 싶은데요.
인용:위의 메시지로
그것이 제가 첨에 혼동한 이윱니다. 그렇지만 위에 올린 bind log 에서도 알 수 있듯이 TXT 를 분명히 본다는 것은 관련이 있다는 뜻입니다. 실제로 그랬고요. 아래에 로그처럼요.
google의 25번 포트를 직접 열었다는 말이 분명하지 않지만, 전 서버에서 mail 명령어를 사용하거나 smtp-auth로 보냈을 뿐입니다.
제 메일서버가 gmail.com 속한 서버의 25(또는 465?)번 포트를 직접 열지 않고 메일을 보낼 수는 없을 것 같습니다.
gmail이 보낸 메세지는 기본적으로 당신이 사용하는 IP는 메일을 보낼 권한이 없다고 말하는 것일 뿐입니다. 물론 왜 그런지 정확히 아는 것은 google 뿐이겠죠.
spf는 당연히 TXT를
spf는 당연히 TXT를 보는 것이 맞습니다. 하지만 보통 TXT 가 없을 경우에는 대부분의 업체들이 통과를 시키고 있으며 구글 역시 통과를 시키고 있습니다. 며칠전에 제 google account 로 온 메일 중의 SPF header 입니다.
10월 1일날 들어온 홍보 메일의 SPF header 이며, 설정이 안되어 있는 호스트에서 발송된 경우입니다만..
인용:pf는 당연히
제가 asiana.co.kr로 확인한 것은 다르군요. 분명 저 아이피가 들어 있습니다. 만약 그렇다면, 첫 글에서 include 관련 인용한 링크에서도 나와있듯이 우려한 한 단면일 수도 있고요.
근데 neutral 이라고한 부분이 설정과 다르군요. 제 경우를 봐도 그렇고 gmail이 설정한 대로 해석하지는 않는 것 같습니다.
신규 도메인 경우 축적된 정보가 없기 때문에 상대적으로 spf record가 많이 반영된 것이 아닌가 생각합니다.
위의 발송 도메인은
위의 발송 도메인은 ac2.asiana.co.kr 이기 때문에 ac2.asiana.co.kr 의 TXT record 를 확인 하셔야 합니다. ac2.asiana.co.kr 은 SPF 설정이 되어 있지 않습니다. 그렇기 때문에 newtral 로 status 가 잡힌 것입니다. mailer@asiana.co.kr 로 보냈다면 modestcode님의 말씀대로 SPF 가 좀 의아(?)스럽게 작동한다고 볼 수도 있겠지만, 제가 적어드린 헤더는 ac2.asiana.co.kr 입니다.
인용:위의 발송
ac2.asiana.co.kr를 있는 그대로 보지 못한 불찰입니다.
메세지로 봐서 이 부분은 v=spf1 a/24 mx/24 ptr ?all 처럼 해석하는 best-guess mechanism이 동작한 것 같습니다.
이것이 또 제가 말하고 싶은 것을 드러내는 경우가 아닌가 생각합니다. 기존 domain에 대해서는 best-guest를 해서 통과시키면서 왜 신규 도메인에 대해서는 (제 테스트 결과가 틀릴 가능성이 있지만) 그렇게 하지 않는 것일까요? 같은 None인데 더 심한 대우를 하는 것입니다.
SPF 자체가 reply to
SPF 자체가 reply to address 에 있는 도메인의 SPF 값을 확인한 후 허용된 서버에서 보낸 것인지를 확인하는 것이기 때문에...
내 서버가 SPF 를 지원하건 지원하지 않건 TXT 정보를 확인하게 됩니다. 만약 허용되지 않았다면 Fail, 서버에서 좀 약한 정책을 사용한다면 Soft-fail 혹은 Netural, 통과했다면 Pass 가 되는 것이죠.
아직까지 대부분의 서버에서 Soft-fail 이나 Netural 등은 걸러내지 않는 것으로 알고 있으며, 역시 대부분의 경우 SPF 를 위반했을 경우에는 Reply 를 해주지 않습니다.
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
인용:내 서버가 SPF 를
지원할 생각이 없다면 볼 이유가 없을 것 같습니다.
저 아래 글에
저 아래 글에 써놨듯이 SPF 는 보낼 때 어떤 정보를 더해서 보내는 게 아닙니다.
받는 메일 서버와 보내는 메일주소의 네임서버 이 두가지에서 SPF 를 지원하면 되는 것이고, 받는 측 메일 서버에서 보내는 메일주소의 네임서버의 TXT 를 확인하기 전까지는 SPF 를 지원하는지 여부를 알 수 없습니다.
그렇기 때문에 무조건 확인은 해야합니다 그냥 아니다 아니다 라고 답글만 다시기 보다는 문서를 다시 한 번 제대로 읽어봐주셨으면 합니다.
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
인용: 받는 메일
전 계속 gmail의 스팸 처리에 대해서 말하고 있었습니다. 받는 쪽(gmail)에서 spf를 지원할 생각이 없다면 볼 필요가 없다는 뜻입니다.
문서를 제대로 읽어 보란 얘기를 하시기 전에 생각할 문제입니다. gmail 이 spf spec이 없을 당시에 txt lookup을 했겠습니까?
인용:SPF 자체가 reply
reply to address가 아니고 From address 라고 말하려고 하신 것이 아닌지?
원래 spf 문서를 보면
원래 spf 문서를 보면 From 이라고 되있는데 구현체에 따라 Reply-to 를 보기도 하고 약간 제각각인거 같아요. postfix 에서는 reply-to 를 보던데
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
reply-to 라고 얘기
reply-to 라고 얘기 하시는 것이 혹시 RCPT TO 가 아닌지요?
제 짐작으로는 RCPT TO command가 올 때가지 delay 되는 상황을 얘기하는 것 같습니다만.
다시 원점으로
다시 원점으로 돌아가서 SPF 를 사용하시는데 거부감이 있는 특별한 이유가 있으신가요?
참고로 아래 코드는 google.com/a 서비스를 이용할 때 필요한 것입니다.
IN TXT "v=spf1 include:aspmx.googlemail.com ~all"google.com/a 와 관련없는 경우라면 아래같은 코드가 되죠.
IN TXT “v=spf1 a mx ptr ~all/아시아나 같은 경우처럼 아예 자신의 ip 를 적어주는 것도 상관없구요.
IN TXT "v=spf1 ip4:자신의아이피 ~all"이미 있는 record를 사용하는 것도 아니고, goole를 믿을 수 있는지를 의심해볼 이유도 없으며, 내가 맞다고 얘기 하는 것입니다. 제 생각에는 잘못 이해하고 오해를 하고 계신게 아닐까 싶은데...
아래 링크는 제가 써놨던 spf 관련 포스트들...
http://b.mytears.org/tag/spf
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
인용:참고로 아래
이 부분은 전체적인 문맥과 관련이 있습니다.
제가 해석한 대로라면, aspmx.googlemail.com에 Fail 나면 메일을 못 보낼 수 있습니다. google.com/a 서비스를 사용하지 않는 사용자가 google.com/a 서비스를 사용하는 example.com 사에 메일 보낼 때 해당되기 때문입니다.
include mechanism 관련 연장 선상에서 이해했기 때문에 그럴 수 있다고 생각한 것입니다.
제가 생각할 때는 내가 맞다고 좀 다른 방식으로 얘기 해라 인 것 같습니다. 내가 어떤 글을 쓰는지 보고 판단하는 것이 아니라 돈 들여서 양장본에 넣으면 통과라는 식이죠. 이것은 인터넷에 첫 발을 내디딘 풋내기 도메인에게는 더욱 불합리해 보일 수 있다는 것이죠.
저는 별로
저는 별로 불합리하다고 생각하지 않습니다.
메일을 보내기 위해서
MX 레코드를 넣어주는 것처럼(이건 그 도메인의 수신용 서버를 찾기 위한 조회용)
SPF관련 문구를 적은 TXT 레코드를 넣어준다고 생각하시면 속편합니다.(이건 그 도메인의 발신용 서버가 맞는지 확인용)
제가 운영하는 메일서버도 SPF패치를 하지 않았습니다만 네임서버에는 SPF정보를 넣어놨지요.
그렇지만 SPF를 적용하기 전부터 hanmail.net 에서 발송했다고 해놓고서 발송처가 hanmail.net 의 서버가 아니면 스팸으로 처리하고 있었는데..
SPF는 그 수고를 덜어줄수 있어서 좋다고 봅니다. :)
SPF 나 DomainKey 등의
SPF 나 DomainKey 등의 문제점은 메일 포워딩에 있습니다. 즉, 이렇게 되면 .forward 를 사용하지 못하게 되죠. .procmail 로 원본 주소를 변경하지 않도록 해서 포워딩을 해야 합니다.
앗 제가 관련된
앗 제가 관련된 문제를 겪고 있는데, 혹시 조금 더 자세히 설명을 들을 수 있을까요 +_+?
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
인용:저는 별로
제가 말한 전체 문맥에서 이해해 주시기 바랍니다. 판단한 자료가 없을 땐 받고 내용으로 결정하라는 것입니다.
저도 SPF 자체는 기존 DNS 인프라를 이용해서 간단하고 실용적인 면이 있다고 생각합니다. 물론 문제도 있지만 이것은 다음 기회로 미루지요.
인용:제가 해석한
확실히 잘못이해하시고 계신 것 같습니다.
SPF 는 아주 간단히 얘기하면 '난 이 서버를 통해서 메일을 보내니 다른 서버를 통해서 내 메일주소(정확히는 호스트네임)로 메일을 보냈다면 그것은 스팸이라고 판단해도 좋다." 입니다. 다시 말해 메일을 받는 사람의 메일주소가 지메일이건 뭐건 상관이 없으며, 메일을 받는 측에서 google.com/a 서비스를 사용하는 것 또한 아무 상관이 없습니다.
저 TXT 정보를 추가해줘야 하는 경우는 어떤 도메인을 가지고 google.com/a 서비스를 받으려 할 때 뿐입니다. 그 외의 경우엔 오히려 저 줄을 넣음으로 인해 (SPF 를 이용해 스팸여부를 판단하는 곳으로) 메일을 보내는 것이 불가능해질 수 있습니다. aspmx.google.com 에서 해당 ip 를 추가해주질 않을텐데, 무조건 스팸으로 판명나는거죠.
SPF 가 어떻게 동작하는지 간단히 알아보면 아래와 같습니다.
A: 메일을 보냄 (추가적인 동작이 없음)
B: 받은 메일에서 Sender 에 있는 혹은 Reply-to 에 있는 메일주소를 이용 호스트네임을 얻음 (ex: Sender: nospam@example.com 에서 example.com 을 가져옴)
B: example.com 의 도메인 정보를 관리하는 네임서버에 접속
B: 네임서버에서 example.com 에 대한 TXT 정보를 가져옴
B:
거기에 SPF 관련 정보가 없으면
->neutral
SPF 정보가 있고 허용된 아이피 혹은 서버 리스트에 메일을 보내온 곳이 들어있음
->Pass
보내온 곳이 들어가 있지 않음
-> 정책이 ~all 일 경우 softfail
-> 정책이 -all 일 경우 fail
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
인용:> 제가 해석한
이것은 제가 잘못 이해한 것 맞습니다.
확실히 google.com/a 서비스를 사용하는 example.com 사에서 메일 보낼 때 해당되기 때문입니다라고 해야 말이 됩니다.
example.com 사에서는 다른 메일 서버를 추가하거나 별도 레코드를 넣고 싶으면 google 에 물어 봐야 합니다. 그러나 이것은 include mechanism 상 SPF 관련 기술적 문제일이며 또 example.com 사가 결정한 것일 뿐입니다. 단지 이 레코드가 gmail 사용자들에게 스팸을 판단하는데 SPF 스펙 이상의 어떤 작용을 했다면 문제가 있다고 생각합니다.
스펙(rfc4408)에 보면 는 SMTP MAIL FROM 에서 가져오는 것이 필수입니다.
Neutral은 SPF 정보가 없을 때가 아니라 일치하는 mechanism이 없거나 redirect modifier가 없을 때 반환하는 기본값입니다.
없다면 None입니다.