Gsuite를 가져온 이유는 무엇입니까?

사내 파일 서버를 클라우드로 옮겨 재택근무 환경을 정비한다.

COVID-19 유효기간 이전에는 직접적인 원인이 아닙니다.

반드시 연구해야 할 일

Gsuite의 영역이 이미 존재하기 때문에 메일 서버의 이동이 필요합니다.

메일 서버를 이전하여 메일 불통으로 인한 업무 정지를 피해야 한다.

이전 후 검증을 위해 기존에 저장된 메일 서버로부터 수발을 진행하여 Gmail에서 수발할 수 있는 병행 운용 기간을 가지도록 한다.

Gsuite 가져오기에서 옮기기 전에 뭐 했어요?

각 직원의 계정 만들기

나는 이것이 특별한 설명이 필요 없다고 생각하지만, Gsuite에서 몇 분 (기존 메일 서버의 계정) 이 필요한 계정을 만들었다.
그러나 계정을 만들었더라도 메일을 Gmail로 볼 수는 없습니다.DNS의 MX 기록에 기존 메일 서버도 지정돼 있어 메일이 Gmail 측으로 발송되지 않았기 때문이다.
또 기존 메일 서버의 메일 리스트 주소와 관련해서도 Gsuite의 그룹으로 제작해 기존 메일 서버의 메일 리스트와 마찬가지로 그룹 소속 계정을 만들도록 했다.

메일을 기존 메일 서버로 전송하기 설정

계정을 만들면 Gsuite 기능을 사용할 수 있습니다.
그러나 메일과 관련해서는 Gmail에 발송되지 않아 DNS의 MX 기록을 수정해야 한다.
이에 따라 MX 음반 업데이트만 하면 되지만, 우선 병행 운용하기로 했다.
따라서 기존 메일 서버에 Gmail로 전송하는 설정이 추가되었습니다.
Gsuite 계정을 만들면 메일 주소의 별명이 할당됩니다.
메일 주소가 [email protected]인 경우 별명[email protected]이 지정됩니다.
기존 메일 서버의 전송 설정에 이것을 추가합니다.
또 메일리스트와 관련해서는 메일리스트에서 각 계정으로[email protected] 이송한 뒤 각 계정에서 Gmail의 별명[email protected]으로 이송하기 때문에 메일리스트에 추가 이송 설정이 없다.
이렇게 되면 Gmail에서 각 계정과 메일 리스트의 메일을 받을 수 있다.

또 메일의 발송에 대해서는 지정된 메일 서버를 통해 각각 발송할 수 있다.

SPF 레코드 수정

병행 운용 중 일부 지역의 메일을 발송할 수 없다는 보고가 있다.
이는 일부 Gmail로 이전한 사용자가 보낸 메일로, 기존 메일 서버를 통해 메일을 보내는 데 문제가 없기 때문에 대상역에 대한 메일은 기존 메일 클라이언트에서 보내는 것으로 대응한다.
결과적으로 일부 도메인의 수신 메일 서버에서 SPF 인증을 통과하지 않은 경우 불허가로 설정됐기 때문입니다.

SPF는 소스 도메인 이름 전송을 인증하는 메커니즘입니다.
전송 소스 IP 주소가 SPF 레코드에 지정된 IP 주소 범위 내에 있는지 확인합니다.
대상 도메인의 SPF 로깅은 다음과 같습니다.

example.com. IN TXT "v=spf1 include:spf.example.com ~all"

include 이전의 SPF 레코드를 참조하여 IP 주소의 범위를 가져옵니다.
따라서 Gmail에서 온 메일 서버도 발송원으로 사용할 수 있도록 SPF 기록을 수정했습니다.

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

SPF 레코드에서 전송된 서버의 IP가 무엇인지 확인할 수 있습니다.

dig TXT _spf.google.com
  # ...
  # ;; ANSWER SECTION:
  # _spf.google.com.        300     IN      TXT     "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
dig TXT _netblocks.google.com
  # ...
  # ;; ANSWER SECTION:
  # _netblocks.google.com.  144     IN      TXT     "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

이 설정을 변경하면 일부 도메인 이름이 거부된 메일도 Gmail에서 보낼 수 있습니다.

그룹 설정 수정

검증 작업 중 Gsuite에 설정된 그룹이 메일 리스트로 메일을 받을 수 있는지 확인하는 과정에서 외부에서 메일을 메일 리스트로 보낼 수 없음을 발견했다.
다만 기존 메일 서버에 대한 전송 설정은 주목하기 어려운 부분이다.
검증 방법은 Gsuite를 통해 그룹 설정을 한 후에도 계정과 마찬가지로 별명을 분배하기 때문에 목적지를 지정하고 메일을 보낼 때 이 별명을 알아차렸다.
그룹을 만들 때 기본 사용 권한은 다음과 같습니다.

그렇습니다.
이렇게 하면 계좌 내부에서 그룹을 메일 목록으로 교환할 수 있다
외부와 연락할 메일 목록으로 설정이 부족합니다.
변경은 다음과 같습니다.

이렇게 하면 대외적으로 공개된 메일 리스트도 받을 수 있다.

다양한 메일 클라이언트 설정

이미 Gmail로 옮겼으니 앞으로 잘 부탁드립니다.이렇게 되면 우편물은 받을 수 없습니다.이런 소리는 필연적이다.
또 전체에 공식 통보했더라도 이후에는 다시 가지 않을 방침이다.
스스로 조사할 수 있는 방법이 아닌 문제도 있는데, 각자 이 일을 하면 전체 일당 인원을 대폭 가져간다.
브라우저에서 Gmail을 사용하기 위해서, 누군가가 기존의 메일 클라이언트로 이동하여 일한다.이런 사람이 적지 않기 때문에 기존의 메일 클라이언트도 수신할 수 있다.
이 설정은 조직에서 '안전성이 낮은 응용 프로그램에 대한 사용자 관리 허용' 이다.
사용자 기본 설정에서 '접근 안전성이 낮은 프로그램' 이 비활성화되었습니다.
이에 따라 기존 메일 클라이언트에서 수신된 사용자는'액세스 보안이 낮은 애플리케이션'을 활성화하고 자신의 계정과 비밀번호를 이용해 메일 클라이언트로부터 전송·수신한다.
물론'안전성이 낮은 앱의 접근'이 비활성화된 상태에서 앱 코드를 발행해 메일 클라이언트 설정을 요청하는 방법도 있지만, 2단계 인증이 필요하기 때문에 각 사용자와의 편의성을 고려한 절충은 우선필요하다면 사용하기 쉬운 방법을 선택할 수 있다.
그러나 안전성이 낮은 응용 프로그램에 대한 접근은 추천이 아니기 때문에 활용 후 다시 연구해야 할 수도 있다.

그렇게 옮기다

확인 후 DNS의 MX 레코드가 수정되었습니다.
기존 MX 레코드

example.com.  IN  MX  10   ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  20   ALT1.ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  20   ALT2.ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  30   ALT3.ASPMX.L.GOOGLE.COM.
example.com.  IN  MX  30   ALT4.ASPMX.L.GOOGLE.COM.

변경되었습니다.

최후

이상은 내가 병행하여 운용하기 전에 대응하는 방법이다.
기존 메일 서버와 Gsuite를 병행적으로 활용하는 요점

MX 기록을 Gmail의 메일 서버로 업데이트하기 전에는 메일이 Gmail에 도착하지 못하기 때문에 Gmail의 별명 필드를 이용하여 기존 메일 서버에 전송을 설정한다.

SPF 인증을 엄격히 하는 수신 서버도 있기 때문에 gmail의 송신 서버를 송신 원본으로 허용하는 서버의 SPF 기록에 추가합니다.

팀은 권한을 상세하게 설정할 수 있다.외부에서 온 메일 목록으로 사용되는 경우 기본이 아니라 외부에서 온 투고를 유효하게 해야 합니다.

기존 메일 클라이언트에서 받아 활용하려는 사람도 있기 때문에 편의성 등을 고려해 규칙을 정해 이 방법을 제공할 수 있다.

운용 후 문제가 발생하면 별도로 전개한다.
깨우고 싶지 않아요.