'전체 글'에 해당하는 글 2265건

EKS 무중단 배포

Server/AWS 2022. 1. 11. 19:57

 

$ kubectl get pods -o wide -w -n exapi
NAME                         READY   STATUS    RESTARTS   AGE   IP            NODE                                                     NOMINATED NODE                                READINESS GATES
oauth-b88bb75fb-cbpfb        1/1     Running             0          12m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        1/1     Running             0          12m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Running             0          9m47s   10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Running             0          9m47s   10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          0s      <none>        <none>                                                   <none>                                        0/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          1s      <none>        <none>                                                   3e4a3b4284-f3a1e8e9245847e19d248aa203cec099   0/1
oauth-6889b9d9d8-89f8d       0/1     Pending             0          65s     <none>        fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   3e4a3b4284-f3a1e8e9245847e19d248aa203cec099   0/1
oauth-6889b9d9d8-89f8d       0/1     ContainerCreating   0          65s     <none>        fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          100s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          101s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          102s    10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          2m11s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-zx68l        1/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-89f8d       1/1     Running             0          3m34s   10.1.22.204   fargate-ip-10-1-22-204.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          0s      <none>        <none>                                                   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          1s      <none>        <none>                                                   16625974aa-a093eb0abc954f958086de0c456c0ea2   0/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-b88bb75fb-zx68l        0/1     Terminating         0          14m     10.1.27.53    fargate-ip-10-1-27-53.ap-northeast-2.compute.internal    <none>                                        1/1
oauth-6889b9d9d8-8n2mf       0/1     Pending             0          50s     <none>        fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   16625974aa-a093eb0abc954f958086de0c456c0ea2   0/1
oauth-6889b9d9d8-8n2mf       0/1     ContainerCreating   0          50s     <none>        fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          85s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          86s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          87s     10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          116s    10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        0/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-6889b9d9d8-8n2mf       1/1     Running             0          3m19s   10.1.18.160   fargate-ip-10-1-18-160.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        1/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1
oauth-b88bb75fb-cbpfb        0/1     Terminating         0          20m     10.1.19.219   fargate-ip-10-1-19-219.ap-northeast-2.compute.internal   <none>                                        1/1

 

자알 돌아간다~ 정상적인 것처럼 보이나...

 

 

 

다른분들 시간 낭비하지 않도록 결론부터 얘기한다. 무중단 배포 실패!

EKS 에서 Rolling update 가 무중단 배포가 아니라니... 겉보기에는 잘 작동하는 것처럼 보이나 배포시 약 5초간 502 Gateway Error 뒤에 504 Gateway Time-out 이 발생한다. 후... 

 

우선 502 에러가 발생하는 시점을 찾아봤다.

 

쿠버네티스에서 kubectl rollout restart 명령으로 배포할 경우, 새 pod 가 추가되고 Running 상태가 되면 기존 포드가 삭제되는 식이다. 확인 결과 pod 가 Terminating 되는 순간에 502 에러가 발생했다. ALB 의 Target 이 동시에 draining 되는 시점이기도 하다. 인터넷을 후벼파본 결과, 502 에러를 최소화 할 수 있는 몇가지 방법만 있을 뿐. 완벽한 무중단배포는 결국 찾지 못했다.

 

 

 

502 Gateway Error / 504 Gateway Time-out Error 최소화

 

1. ingress : connection-draining 설정

 

ALB 에 connection-draining 관련 옵션을 주어 기존 연결에 대한 처리를 유지한다. (이미 기본값으로 동작중. 효과없음.)

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  ...
  annotations:
    ...
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "30"

 

 

2. pod : readiness-gate 설정

 

readiness-gate 옵션을 활성화 하여 새로운 target 이 healthy 상태로 연결되기 전까지 기존 target 을 종료하지 않음. (마찬가지로 502 에러는 발생하나, ALB 내의 target 이 healthy 상태가 한개도 유지되지 않는 어이없는 상황은 막을 수 있음). 반드시 필요!

 

$ kubectl label namespace {mynamespace} elbv2.k8s.aws/pod-readiness-gate-inject=enabled

 

apiVersion: apps/v1
kind: Deployment
metadata:
spec:
  template:
    spec:
      containers:
      - name: api
      readinessGates:
      - conditionType: target-health.alb.ingress.k8s.aws/api-ingress_api-nodeport_80

 

readiness-gate 옵션을 활성화할 namespace 에 레이블을 설정하고, target-health.alb.ingress.k8s.aws/{ingress-name}_{service-name}_{port} 를 위처럼 삽입한다. 설정이 올바르지 않으면 ALB 에서 target 그룹을 인식하지 못할 수도 있으니 주의!

 

 

3. pod : preStop 설정

 

life-cycle hooks 에서 pod 가 중지되기 전에(preStop) 딜레이를 가지며 기존 연결을 마저 처리한다. 새로운 연결을 이루어지지 않는다. (가장 좋아요가 많으나, 502 에러는 마찬가지임)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: api
        lifecycle:
          preStop:
            exec:
              command: ["sleep", "60"]

 

 

4. pod : terminationGracePeriodSeconds 설정

 

preStop 가 실패했을 때 대신 컨테이너를 종료시킨다. (502 에러 변함없음)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: web-api
      ...
      terminationGracePeriodSeconds: 70

 

 

5. pod livenessProbe / readinessProbe 설정

 

pod 의 활성화 상태를 나타내는 livenessProbe 가 실패하면 재시작 정책의 대상이 된다. pod 준비 상태를 나타내는 readinessProbe 가 실패하면 해당 pod 는 모든 엔드포인트에서 제거된다. (두 방법 모두 비정상 pod 에 연결을 못받게 하여 502 에러를 줄인다고는 하는데 효과는 잘 모르겠음.)

 

kind: Deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: api
      ...
        livenessProbe:
          httpGet:
            path: /
            port: 80
          periodSeconds: 4
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 30
          periodSeconds: 10

 

 


 

정리

 

이 정도가 구글링 싹다 한 결과이다. 말 그대로 502 에러가 발생할 확률을 줄여주는 것이지, 지금 내 상황을 해결해 줄 것들은 아니다. 물론 잘된다는 사람도 있긴한데 믿음이 가진 않고...; 다시 한번 정리하자면,

 

ALB draning = POD terminating

pod 가 먼저 terminating 상태에 돌입하고, 그를 인지한 로드밸런서가 draning 상태로 변경하는데 이미 로드밸런서를 통과한 연결이 terminating 인 pod 를 만나 에러가 발생했고, 그 상황을 방지하기 위해 나는 preStop hook 로 실질적인 terminating 을 딜레이 시켰는데 쌩까고 502 에러가 계속 난다는...

 

그나마 건진건 readiness-gate 하나. 거의 이틀동안 rolling update 로 테스트해 볼만한건 다 해봤다. 그나마 이틀만에 이렇게 포기할 수 있게 해줘서 감사할따름. EKS 를 사용하는 모든 사용자들이 502 를 마주하지는 않을텐데, rolling update 를 손절해야 하나. 하... 모르겠다...

 

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

 

Oauth2.0 에서 Token 발급에 필요한 ClientId 와 SecretKey 생성하기.

 

 

ClientId

 

  • 일반적으로 길이 16~32자 16진수 문자열로 생성.
  • 모든 클라이언트에서 고유함.

 

SecretKey

 

  • 일반적으로 길이 32~64자 16진수 문자열로 생성.
  • TimeStamp / UUID 라이브러리 등은 지양.
  • 일반 암호와 동일하므로 DB 에는 암호화 되거나 해시된 버전으로 저장.

 

ClientId ex)

 

Foursquare: ZYDPLLBWSK3MVQJSIYHB1OR2JXCY0X2C5UJ2QAR2MAAIT5Q
Github: 6779ef20e75817b79602
Google: 292085223830.apps.googleusercontent.com
Instagram: f2a1ed52710d4533bde25be6da03b6e3
SoundCloud: 269d98e4922fb3895e9ae2108cbb5064
Windows Live: 00000000400ECB04
Okta: 0oa2hl2inow5Uqc6c357

 

 

Client Id / Secret Key 생성

 

commons-lang3 의 RandomStringUtils 를 사용하여 특정 길이의 랜덤한 문자열을 생성할 수 있다.

 

dependencies {
    implementation 'org.apache.commons:commons-lang3:3.12.0'
}

...

RandomStringUtils.randomAlphanumeric(32));  
// 1JhGTHmGlCP037aATyJzph983FRl5r14
RandomStringUtils.randomAlphanumeric(64));  
// 84ldr2jaagfMiIwzj2wFnaPxXBV2Yc9WC1AbJPaugEj5qHSWHkPjt2HInLdlzV7S

 

spring-security 를 사용할 경우, SecretKey 를 한번 더 암호화 하기 위해 BCryptPasswordEncoder 클래스를 사용한다.

 

PasswordEncoder passwordEncoder = new BCryptPasswordEncoder();
String encodeKey = passwordEncoder.encode(secretKey);

 

PasswordEncoder.encode 는 항상 랜덤키를 생성하기 때문에 인코딩된 결과끼리의 비교는 불가능하지만, secretKey 와 encodeKey 의 비교는 가능하다.

 

if (passwordEncoder.matches(secretKey, encodeKey)) {
    System.out.println("matching~");
}

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

2022년의 시작

Daily/Diary 2022. 1. 1. 02:10

2022years

 

피곤하다. 힘들다. 하지만 재미있고 행복하다...

 

2021년 신축년(흰소띠해)은 44살로 딱히 좋아하지 않는 숫자가 두개나 들어있는데도 나름 운이 좋은 해였다. 일단 기억나는 악재가 없었다. 수년째 그렇긴 하지만... 올초에 쓴 반성문을 보니 원룸살던 그때가 조금은... 아니 매우 그립다. 벌써 1년이 지난것도 신기하고, 지금이 한 해가 끝나는 12월 31일이 맞나 싶기도 하고... 11월부터 크런치 모드에 돌입했더니 정신을 차리기가 힘들다. 이 힘든 와중에도 결산은 해야지. 2021년의 이슈들을 한번 돌이켜 봤다.

 

 

1. 합가

 

같이 사는게 효도라고 생각하고 살림을 합쳤지만, 생각처럼 쉽지는 않았다. 혼자 살다가 다시 돌아와보니, 누군가와 함께 산다는 것은 정말 쉬운 일이 아니었다. 그 누군가가 부모님이더라도... 나를 향한 부모님의 걱정이 점점 더 커져간다. 과도한 부모 사랑이 부작용을 일으키고 있다. 하루에 부모님을 마주치는 시간도 얼마 안되는데 신기하기도 하지. 함께 살면 부모든 형제든 누군가는 참아야 하고, 누군가는 이해해야 하고, 누군가는 희생해야 한다. 가족끼리 그렇게 사는 것이 이상한 일은 아닌데... 하... 혼자 살고 싶다. 아니면 둘이... 부모님이 그립다면 자주 찾아뵈면 된다. 용돈을 더 드리면 된다. 같이 살지 않으면서도 효도할 방법은 많지 않을까. 마침(?) 3월부터는 판교로 출근을 해야 한다. 다시 한번 선택의 기로에 서야 하는 날이 머지않아 올 것 같다.

 

 

2. 이직

 

한 회사에 조용히 있으면서 6년이란 박봉의 시절을 보냈다. 이래저래 아끼고 살면 모을 수 있으니 박봉인 줄도 모르고 만족하고 살았는데, 나와보니 박봉이었다. 다행히 그 곳은 너무도 일이 없어 한가로이 보냈으니 대충 퉁이라 치자. 이직할 때 즈음에 '네카라쿠배당토' 등의 회사들과 더불어 개발자 버프가 생기면서부터 개발자들의 몸값이 많이 높아졌다. 그렇게 SI 란 생소한 직군을 선택했지만 적응하기도 전에, 또 한번의 기회가 찾아왔다. 그리고 두번의 이직 후 지금까지 크런치 모드가 이어지고 있다. 불과 1~2년 전까지만 해도 잉여시간에 무엇을 해야 할까 고민을 많이 했었는데... 물론 워라밸 좋다. 그게 사는 맛이지.  하지만 그렇게 몇년을 살았는데도 만족을 주지는 못하더라. 못가졌을 때나 갖고 싶은 거지, 가지고 나면 기존의 상상은 다 허상이 된다. 지금은 닥치고 개발이다. 그때가 굳이 노력을 하지 않아도 되는 자리였다면, 지금은 최선을 다해야 하는 자리이다. 모두의 기대가 크고, 잘하고 싶고, 잘해야 한다. 어깨가 무겁다... 털썩...

 

 

3. 운동

 

2월 쯤이었나. 집에서 맨몸으로 스쿼트 하다가 디스크가 터져서 한달쯤 고생했던 기억이 난다. 그렇게 허리 개입 운동을 피하다가 레그 컬/프레스와 익스텐션에 반해 버렸다. 하체는 물론이고 몇일을 앉아 있어도 허리에 통증이 생기지 않았다. 그걸 알게 된 순간부터 하루에 한시간씩 레그 컬/프레스, 익스텐션을 꾸준히 했다. 얼마 전까지는... 거리두기 때문에 헬스장을 못가면서 이번에는 집에서 스쿼트를 연구(?) 하다가 드디어 맨몸 스쿼트에 성공했다. 44년만에 만족스러운 자세, 느낌(?) 나옴.ㅋ 하지만 그건 몇달전 얘기고... 지금은 7시출근, 23시퇴근, 안피곤하면 홈짐 1시간. 이게 요즘 루틴이다. 주말도 여지없고. 게임에 미쳐있을 때도 눈알이 이렇게 힘들어하지는 않았었는데 지금은 눈에 좋다는 약은 다 먹고 있다. 보통 12시간은 계속 앉아서 모니터만 보고 있으니... 체력이 받쳐줘야 하는데 꾸준히 운동할 여건이 안되네. 등산은 시간도 없을 뿐더러 다치면 짤릴지도 모르니 일단 참는 중. 당분간 집에서 시간 날 때마다 홈짐으로 몸만 풀기로.

 

 

4. 연애

 

작년 사주풀이에서 2022년에 결혼운이 있다길래 용기내서 한번 찔러봤는데 역시나... 꽝이었다. 이 나이에도 찝쩍거릴 수 있다는 사실이 놀라웠다. 올해도 어김없이 우리은행의 사주풀이를 보았다. 여전히 2022년에 남쪽에서 귀인을 만날 수 있다고 한다. 남쪽이라면... 판교인가.ㅋ 정말 마지막이다. 1년만 더 믿어봐야지.

 


 

* 계획

 

2022년 임인년(검은 호랑이해)은 피아노고 나발이고 일단 닥치고 개발. 지금처럼 꾸준히 건강하게 열심히. 하루에 딱 2시간만 고정으로 다닐 수 있는 헬스장만 있으면 좋겠는데, 일단 거주지가 확정되기 전까지는 대기. 가장 중요한... 주거지 선택에 만전을 기하기. 지금은 연봉이 얼마던 그런건 중요하지 않다. 그저 집 가진 백수의 승리. 그렇다고 해서 최고점에 물리지 않기. 서두르지 않기. 2022년 12월 31일에 기쁜 마음으로 다시 결산할 수 있기를...

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

EKS ingress https

Server/AWS 2021. 12. 28. 23:37

EKS 에서 http 를 https 로 리다이렉트 시켜주는 ALB 가 필요하다면, 아래와 같은 ingress 를 구성한다.

 - 사전에 ACM 의 인증서 arn 이 필요하다.

 

$ vi ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: example
  name: example-ingress
  annotations:
    # Ingress Core Settings
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=60
    # SSL Settings
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:ap-northeast-2:111122223333:certificate/11fceb32-9cc2-4b45-934f-c8903e4f9e12
    alb.ingress.kubernetes.io/ssl-redirect: '443'
spec:
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: example-nodeport
                port:
                  number: 80

 

기존 http 구성에 # SSL Setting 아래 3줄만 추가하였음.

기존 ingress 삭제하고 다시 생성.

 

$ kubectl delete -f ingress.yaml
ingress.networking.k8s.io "example-ingress" deleted

$ kubectl apply -f ingress.yaml
ingress.networking.k8s.io/example-ingress created

 

alb-redirect

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Received-SPF: none

Daily/Prog 2021. 12. 28. 21:24

장애


메일 이상 작동 접수,

 

  • Google Workspace Email 에서 @example.com 끼리는 메일이 주고 받아짐.
  • 다른 도메인에서 @example.com 으로의 메일도 잘 받아짐.
  • @example.com 에서 다른 도메인으로 메일을 발송하면 누구는 받아지고, 누구는 안받아지고, 누구는 스팸함에... 복불복임.ㅋ

 

테스트로 받아진 메일 원문을 보니, 첫줄부터 힌트를...

 

Received-SPF: none (kakao.com: domain of gabriel@example.com does not designate permitted sender hosts)

 

SPF: none - 발신 도메인이 SPF(Sender Policy Framework) 레코드를 설치하지 않았거나 제공된 발신자 정보에서 해당 도메인 정보를 구할 수 없음. SPF 확인 장치가 메일의 위조여부를 판정할 수 없음.

 

결국 DNS 서버에 SPF 세팅이 잘못됐을 것이라 추측하고 설정 확인.

 

SPF "v=spf1 include:_spf.google.com ~all"

 

구글에서 하라는 대로 잘되어 있는 것 같아서, 도메인이나 ip 를 추가해 줘야하나... 했는데,

 

https://aws.amazon.com/ko/premiumsupport/knowledge-center/route53-spf-record/

 

Route 53의 SPF 레코드 문제 해결

Internet Explorer에 대한 AWS 지원이 07/31/2022에 종료됩니다. 지원되는 브라우저는 Chrome, Firefox, Edge 및 Safari입니다. 자세히 알아보기

aws.amazon.com

 

* 요점
대부분의 메일 공급자에서는 SPF 레코드가 2014년 4월에 더 이상 사용되지 않으므로 SPF 구성이 적용되지 않습니다. 자세한 내용은 Internet Engineering Task Force(IETF) 웹 사이트에서 RFC 7208을 참조하십시오. SPF 레코드 대신 적용 가능한 값이 포함된 TXT 레코드를 만드는 것이 좋습니다.

 

 

해결


 

TXT "v=spf1 include:_spf.google.com ~all"

 

레코드 유형을 TXT 로 추가하여 해결...

 

Received-SPF: pass (kakao.com: domain of gabriel@example.com designates 123.123.123.123 as permitted sender)

 

하는 김에 DMARC 설정 추가하고, DKIM 은 관리자 권한 있으면 추가, 그리고 테스트 ㄱㄱ

 

 

Check MX: MX 및 SPF 레코드 확인

 

toolbox.googleapps.com

 

checkmx

 

 

또 하나,,, 테스트 한답시고 test1, test2, test3 이 따위로 메일 반복해서 보내면,

 

Delivery failed: gabriel@kakao.com
10.61.236.127 failed after I sent the message.
Remote host said[Response Message]: 554 5.7.1 DAS41 209.85.210.193: Your mail is blocked automatically by anti-spam system. (E04)
STEP: DATA SEND

 

이렇게 반송 메일 수신 가능...ㅋㅋ

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret