- 홈
- /
- 문서
피드백을 보내 주셔서 감사합니다.
이 문서에서
피드백이 있습니까?컨트롤 허브에서 이메일 디지털 자산을 생성하고 인증한 다음 Webex Connect 또는 웹엑스 컨택 센터 같은 웹엑스 서비스에 할당하세요.
개요
컨트롤 허브의 디지털 자산을 사용하여 Webex 서비스가 이메일 상호 작용에 사용하는 사서함 및 OAuth 2.0 인증을 구성하세요. Control Hub에서 자산을 관리하면 승인된 웹엑스 워크로드가 공유 디지털 자산 서비스를 통해 자산에 액세스해요.
자산을 만들 때, 그것을 사용할 Webex 서비스에 할당하세요. 인증이 성공하면 컨트롤 허브가 인바운드 이메일의 전달 주소를 생성해요. Webex 컨택 센터의 경우, 에셋을 이메일 진입점과 연결할 수 있어요. 다른 Webex 워크로드의 경우, 에셋을 생성한 후 해당 워크로드에서 계속 설정하세요.
시작하기 전에
- 조직의 디지털 자산을 관리할 수 있는 전체 관리자, 고객 관리자 또는 파트너 관리자로 Control Hub에 로그인하세요.
- 지원되는 이메일 제공자를 사용하세요. 웹엑스 컨택 센터와의 통합의 경우Webex Connect, 지메일과 마이크로소프트 365가 지원돼요. 공급자별 세부 정보는 이메일 - WXCC를 참조하세요.
- 구성하려는 사서함을 준비하세요. 서비스 계정을 사용하는 경우 이메일을 보내고 그 사서함에 액세스할 수 있는지 확인하세요.
- ID 공급자 관리자와 상의하여 OAuth 애플리케이션을 등록하고, 동의를 부여하고, SMTP AUTH 또는 외부 포워딩 같은 공급자 설정을 켜세요.
- Control Hub에서 OAuth 애플리케이션의 리다이렉트 URL로 콜백 URL을 복사하고 이메일 자산에 대해 생성된 주소로 자동 전달을 구성할 준비를 하세요.
OAuth 2.0을 위한 지메일 준비하기
이메일 자산을 위한 Gmail 계정을 준비하려면:
| 1 |
Google Cloud 콘솔에 로그인해서 프로젝트를 만들거나 기존 프로젝트를 선택해요. |
| 2 |
API 및 서비스 > OAuth 동의 화면으로 가서 외부를 선택하고 앱 이름, 사용자 지원 이메일, 개발자 연락처 정보를 입력하세요. |
| 3 |
앱이 테스트 중이면 메일함이나 토큰 생성 ID를 테스트 사용자로 추가하세요. 프로젝트에는 최대 100명의 테스트 사용자가 있을 수 있어요. |
| 4 |
API 및 서비스 > 자격 증명으로 가서 웹 애플리케이션의 OAuth 클라이언트 ID를 만들고 클라이언트 ID와 클라이언트 암호를 복사하세요. |
| 5 |
컨트롤 허브가 콜백 URL을 표시하면, OAuth 클라이언트로 돌아가서 그 값을 승인된 리디렉션 URI로 추가하세요. |
| 6 |
프로덕션 용도로 OAuth 앱을 게시하고 요청된 범위에 필요한 구글 인증을 완료하세요. |
| 7 |
컨트롤 허브 구성에 대해 다음 공급자 값을 기록해 두세요.
외부 Google OAuth 앱의 테스트 시, 테스트 사용자 승인 및 새로 고침 토큰은 동의 후 7일 후에 만료돼요. 프로덕션용으로 앱을 게시하세요. 구글이 새로고침 토큰을 반환하지 않으면 동의 흐름을 다시 실행하고 해당 옵션을 사용할 수 있을 때 인증 동의를 제공하기 전에 명시적으로 검토하겠습니다를 선택해 주세요. 구글의 SMTP OAuth 문서에 지메일 SMTP OAuth 범위가 설명되어 있어요.구글의 OAuth 잠재고객 지침은 내부 및 외부 잠재고객과 게시 상태 행동을 설명해요. |
OAuth 2.0용 마이크로소프트 365를 준비하세요
이메일 자산을 위한 마이크로소프트 365 메일박스를 준비하려면:
| 1 |
Microsoft Entra 관리 센터에서 앱 등록으로 가서 새 등록을 선택하고 조직에서 허용하는 계정 유형의 애플리케이션을 등록하세요. |
| 2 |
애플리케이션 (클라이언트) ID 및 디렉토리 (테넌트) ID를 기록해 두세요. |
| 3 |
인증에서 웹 플랫폼 추가하세요. 컨트롤 허브가 콜백 URL을 표시하면 그 값을 리다이렉트 URI로 추가해요. |
| 4 |
인증서 및 비밀에서, 페이지를 떠나기 전에 고객 비밀번호를 생성하고 값을 복사하세요. |
| 5 |
토큰 생성을 선택할 때 사용되는 대화형 인증 코드 흐름의 경우 위임된 Office 365 Exchange Online SMTP.전송 권한 (https://outlook.office.com/SMTP.Send) 을 추가하고 offline_access 범위를 요청하세요. 조직의 동의 정책에 필요한 경우 관리자에게 동의를 부여하세요. |
| 6 |
Microsoft 365 관리 센터에서 사용자 > 활성 사용자로 이동하여 사서함 사용자를 선택하고 메일 > 이메일 앱 관리를 선택하고 해당 사서함에 대해 인증된 SMTP를 켜고 변경 사항을 저장하세요. |
| 7 |
다음 공급자 값을 기록해 두세요. {테넌트-id} 를 앱 등록의 디렉토리 (테넌트) ID로 바꾸세요.
이 대화형 토큰 흐름에는 offline_access와 함께 위임된 https://outlook.office.com/SMTP.Send 범위를 사용하세요. SMTP 인증이 필요한 사서함에만 SMTP 인증을 활성화하세요. 조직에서 최근에 Microsoft Entra 동의 설정을 변경했다면 변경 사항이 적용될 때까지 기다렸다가 토큰을 생성하세요. 마이크로소프트의 SMTP OAuth 지침은 위임된 SMTP 전송 및 오프라인 액세스를 다룹니다.마이크로소프트의 SMTP 인증 구성은 특정 사서함에 SMTP 인증을 활성화하는 방법을 설명해요. |
컨트롤 허브에서 이메일 자산 구성해요
이메일 자산을 구성하려면:
| 1 | |
| 2 |
서비스 > 디지털 자산으로 가세요. |
| 3 |
자산 생성을 선택해요. |
| 4 |
자산 세부 정보 구성 섹션에서 다음 필드에 값을 입력하세요.
|
| 5 |
이메일 제공자 > 사서함에 자산이 사용하는 사서함의 이메일 주소를 입력하세요. |
| 6 |
OAuth 2.0 인증 섹션에서 다음 필드에 값을 입력하세요.
|
| 7 |
ID 공급자에서 Control Hub의 콜백 URL을 OAuth 애플리케이션에 추가하고, 공급자 구성을 저장하고, 리디렉션 URI가 정확히 일치하는지 확인하세요. |
| 8 |
동의하는 사람이 사서함과 다른 이메일 주소를 사용하는 경우, 사서함 주소와 다른 이메일 주소를 사용하여 토큰 생성을 선택하고 그 ID를 입력하세요. 공유 사서함: 공유 사서함에는 자체 로그인 자격 증명이 없어요. 공유 사서함에 액세스할 수 있고 다른 사람 이름으로 보내기 권한을 가진 사용자로 토큰을 생성하세요. 사용자에게는 관리자 권한이 필요 없어요. 사용자 주소가 사서함과 다를 때 사서함 주소와 다른 이메일 주소를 사용하여 토큰 생성을 선택하세요. |
| 9 |
토큰 생성을 선택하고 ID 제공자 로그인 및 동의 절차를 완료한 다음 Control Hub로 돌아가세요. 토큰 생성이 성공하면 액세스 토큰, 토큰 새로 고침, 유효성 필드가 자동으로 채워져요. 동의 제한: 제공자가 사용자 동의를 차단하는 경우, 확인 인증 동의를 제공하기 전에 명시적으로 검토하겠습니다. 사용자가 요청한 동의를 받아들일 수 없어서 옵션을 사용하면 인증이 실패할 수 있어요. 대신 공급자 관리자에게 필요한 동의를 요청하세요. 토큰 생성이 작동하지 않는 경우: Gmail의 경우 사용자가 앱을 승인할 수 있고 앱의 게시 상태가 올바른지 확인하세요. 마이크로소프트 365의 경우, offline_access 범위, 동의 정책, 리디렉션 URI, SMTP 인증 설정을 확인해 보세요. 공급자 구성을 수정하고 토큰을 다시 생성하세요. 토큰 갱신: 서비스가 만료되기 전에 토큰을 새로 고쳐요. 테넌트 소유자가 토큰 재생을 요청하는 자동 이메일을 받으면 자산을 열고 토큰 생성을 다시 선택해요. |
| 10 |
토큰 생성이 성공하면 생성을 선택해요. 에셋이 Webex 컨택 센터에 할당된 경우, 엔트리 포인트로 이동을 선택하고 컨택 센터 구성을 계속하세요. 다른 Webex 워크로드의 경우, 확인 페이지를 닫고 해당 워크로드에서 설정을 계속하세요. |
인바운드 이메일 포워딩 구성하세요
먼저 자산에 대해 생성된 전달 주소를 복사해 주세요.
| 1 |
디지털 자산에서 이메일 자산을 열고 설정을 선택해요. |
| 2 |
이메일 제공자 > 메일박스에서, 메일박스 이메일 주소에 연결된 전달 주소를 복사해요. |
Gmail에서 전달 구성하세요
들어오는 Gmail 메시지를 이메일 자산에 전달하려면:
| 1 |
Google Workspace를 사용하는 경우 관리자가 앱 > Google 워크스페이스 > Gmail > 최종 사용자 액세스에서 사서함 조직 단위에 자동 전달을 허용하는지 확인하세요. |
| 2 |
Gmail에서 지원 메일함에 로그인하고 설정 > 모든 설정 보기 > 전달 및 POP/IMAP으로 이동해요. |
| 3 |
전달 주소 추가를 선택하고 컨트롤 허브의 전달 주소를 붙여넣은 다음 확인 프롬프트를 완료하세요. 지메일에서 생성된 주소로 확인 링크나 코드를 보낸대요. |
| 4 |
인바운드 이메일에 대한 아웃바운드 웹훅 페이로드에서 확인 링크나 코드를 Webex Connect 검색하거나 이메일 자산의 해독된 디버그 로그의 전체 이메일 본문에서 검색하세요. 그런 다음 Gmail 인증을 완료하세요. |
| 5 |
Gmail 전달 설정으로 돌아가서 페이지를 새로고침하고 수신 메일 사본 전달 대상을 선택하고 Gmail에서 복사본으로 수행할 작업을 선택하고 변경사항 저장을 선택해요. |
마이크로소프트 365에서 포워딩 구성하세요
마이크로소프트 365 수신 메시지를 이메일 자산에 전달하려면:
| 1 |
Control Hub에서 전달 주소로 새 메시지가 전송되도록 사서함 전달 또는 지원 사서함의 받은 편지함 규칙을 구성하세요. |
| 2 |
마이크로소프트 디펜더 포털에서 사서함에 적용되는 아웃바운드 스팸 정책을 검토하세요. 자동 전달 규칙을 켜기로 설정하세요. - 보안 관리자가 승인한 좁은 범위의 정책에서 전달이 활성화돼요. |
| 3 |
Exchange Online에서 해당 원격 도메인 설정이 전달 주소 도메인으로 자동 전달을 허용하는지 확인하세요. |
| 4 |
Exchange 메일 흐름 규칙을 검토하고 자동으로 전달된 메시지를 차단하는 규칙이 없는지 확인하세요. 예외가 필요하면 지원 사서함과 승인된 목적지로 제한하세요. |
| 5 |
전달 구성을 저장하고 Microsoft 365 정책 변경이 적용될 때까지 기다려 주세요. 필수: 인바운드 이메일은 전달이 활성화될 때까지 지정된 Webex 워크로드에 도달하지 않아요. Microsoft 365에서는 아웃바운드 스팸 차단 정책, 원격 도메인 설정 또는 메일 흐름 규칙이 전달을 허용하는 설정보다 우선해요. 첨부 파일 제한: 인바운드 이메일 첨부 파일은 25MB로 제한돼요. 첨부 파일이 너무 커서 메시지가 실패하면 보낸 사람은 전송 실패 메시지를 받고 작은 첨부 파일로 다시 보내야 해요. 인라인 이미지: 인라인 이미지가 에이전트 데스크톱에 첨부 파일로 도착해요. PCI 스캐닝이 활성화되면 그 이미지들은 차단돼요. Microsoft Outlook첨부 파일: 제한 때문에 .msg 첨부 파일이 있는 인바운드 이메일은 해당.msg에 파일이 포함되지 않은 상태로 도착할 수 있어요. Microsoft Outlook |
이메일 자산 테스트해봐요
전체 이메일 경로를 확인하려면:
| 1 |
외부 이메일 계정에서 구성된 지원 사서함으로 메시지를 보내고 메시지가 지정된 Webex 워크로드에 도달하는지 확인하세요. |
| 2 |
지정된 Webex 워크로드에서 새 메시지를 보내거나 인바운드 메시지에 회신하고 외부 수신자가 수신하는지 확인하세요. 전송 상태: SMTP 채널을 통해 보낸 이메일에는 배송 추적이 포함되어 있지 않고 서비스에서 전송 실패 알림을 받지 않아요. 테스트 중에 받는 사람 우편함에서 배달 확인해요. |
| 3 |
인바운드 배송이 작동하지 않으면 제공업체의 전달 주소 확인, 전달 규칙, 조직 전달 정책을 확인해 보세요. |
| 4 |
아웃바운드 전송이 작동하지 않으면 SMTP 서버 및 포트, 공급자 권한, 클라이언트 자격 증명, 동의, Microsoft 365 SMTP AUTH 설정, 토큰 상태를 확인해 보세요. 문제를 해결하고 필요하면 토큰을 다시 생성하세요. |
