잘못된 서명자를 선택하지 않고
이메일 서명 파싱하기

서명 블록에는 실제로 무엇이 들어 있을까

서명은 메시지 끝에 붙는 짧은 연락처 블록이며, 그 레이아웃에 표준화된 것은 거의 없습니다. 이메일에는 추출기가 주목해야 할 여섯 부분이 있습니다. 헤더, 새 메시지, 끝인사, 서명 블록, 인용 기록, 그리고 그 뒤에 오는 모든 것입니다. 마지막 부분을 사람들은 잊곤 합니다. 법적 면책 고지일 수도, 배너 이미지일 수도, 다른 사람의 인용 답장일 수도, 아니면 아무것도 아닐 수도 있습니다.

표준이라고 할 만한 표시는 하나뿐입니다. 대시 두 개와 공백이 있는 줄, 즉 2004년 RFC 3676에 문서화된 Usenet 서명 구분자입니다. 이는 관례일 뿐 필수 사항이 아니며, 많은 클라이언트가 이것 없이 서명을 작성합니다. HTML은 경계를 더욱 모호하게 만듭니다. 표로 배치된 서명은 이름을 한 셀에, 직함을 다른 셀에, 로고를 또 다른 셀에 넣을 수 있습니다. 텍스트는 모두 존재하지만, 읽는 순서는 HTML 소스가 말하는 대로이며, 그것이 항상 사람이 보는 순서는 아닙니다.

서명에는 필수 시작 표시가 없습니다. 모든 추출기는 블록이 어디서 시작하는지 추측해야 합니다.

실패는 패턴 매칭이 아니라 귀속입니다

이메일 서명 추출에서 가장 중요한 실패는 다른 사람의 올바른 서명을 가져오는 것입니다. 네 가지 상황이 이런 결과를 낳으며, 모두 충분히 흔해서 미리 대비해야 합니다.

서명이 두 개인 답장 체인. Alice가 Bob에게 답장합니다. 그녀의 메시지가 맨 위에 있고, Bob의 인용 메시지와 그의 서명이 아래에 있습니다. 마지막 블록을 가져오는 파서는 Bob을 반환합니다. 첫 블록을 가져오는 파서는 Alice가 인용문 위에 썼을 때만 Alice를 반환합니다. 인용문 아래에 답장했다면 첫 블록도 Bob의 것입니다. 두 규칙 모두 위치 기반이며, 스레드는 어느 규칙에도 안정적인 위치를 주지 않습니다.

공유 또는 역할 메일함. sales@ 또는 info@ 같은 주소는 한 사람이 서명할 수도 있고, 두 명을 나열한 팀 블록이 서명할 수도 있고, 임원을 대신해 비서가 서명할 수도 있습니다. 레코드 키가 발신자 주소라면 두 사람이 하나의 연락처가 됩니다. 키가 서명에 있는 이름이라면 이름 형식이 바뀔 때 한 사람이 두 개의 연락처가 됩니다. 2021년 HubSpot Community 스레드에서 CRM 사용자들은 같은 혼란을 설명합니다. 문의 메일이 일반 주소로 도착하고, 실제 연락처 정보는 본문 안에 있으며, 누군가 사람과 메일함을 수동으로 분리합니다(HubSpot Community).

같은 패턴이 부동산 리드 이메일 받은편지함에서도 나타납니다. 포털 알림과 오픈 하우스 방명록이 같은 구매자를 두 가지 형식으로 설명합니다.

전달된 메시지. "FYI, see below"에는 전달자의 서명이 없습니다. 본문에 있는 유일한 서명은 원래 발신자의 것입니다. 전달자의 주소를 키로 한 행은 이제 다른 사람의 전화번호를 담고 있습니다.

이 중 어느 것도 더 나은 패턴으로 해결되지 않습니다. 추출 전에 행의 소유자를 결정함으로써 해결됩니다. 본문의 마지막 이름이 아니라 처리 중인 메시지의 주소입니다. 입력이 스레드일 때는 서명 경계뿐 아니라 메시지 경계도 필요합니다. 이름 형식은 같은 문제의 더 작은 버전을 만듭니다. 헤더에 "J. Rivera"라고 쓰여 있고 서명에 "Jordan Rivera, VP of Sales"라고 쓰여 있다면 두 형식의 한 사람이며, 병합 규칙이 이를 알아야 합니다.

스레드에서 마지막 블록을 가져오는 파서는 처리 중인 메시지를 보낸 사람이 아니라 마지막으로 작성한 사람을 반환합니다.

정규식이 무너지는 지점: 네 가지 구체적 사례

정규식은 구두점이 있는 필드에서는 안정적이지만 의미가 담긴 필드에서는 불안정합니다. 서명의 대부분이 그렇습니다. 규칙으로 이메일 서명을 파싱하는 팀은 보통 전화번호, 이메일 주소, URL부터 시작합니다. 이런 패턴은 잘 작동하기 때문입니다. 실패는 그 주변 줄에서 나타납니다.

서명 아래의 법적 면책 고지. 기밀 유지 고지, 등록 법인명, 등록 사무소가 실제 블록 아래에 놓이는 경우가 많습니다. 끝인사 이후의 모든 것을 수집하는 규칙은 고지를 주소로 읽고, 그 안의 LLC나 GmbH 같은 접미사를 회사명으로 캡처할 수 있습니다. 의미 기반 리더는 법적 고지와 "Acme GmbH, Musterstrasse 1"을 구분할 수 있습니다. 고지는 메시지에 관한 문장이고, 주소는 위치이기 때문입니다.

두 번 나타나는 전화번호. 본문 줄에 "call my cell"과 함께 번호 하나가 있고, 서명에는 사무실 전화, 팩스, 휴대전화가 있을 수 있습니다. 정규식은 첫 번째 매칭을 반환하는데, 그것이 팩스 번호이거나 메시지에 인용된 고객 번호일 수 있습니다. 레이블이 곧 필드입니다. Tel, Mobile, Fax, 또는 携帯(일본어로 휴대전화)입니다. 레이블을 버리면 추출기는 그것이 무엇인지 모른 채 번호만 반환합니다.

영어 순서가 아닌 서명. 영어 서명은 이름, 직함, 회사 순으로 흐르는 경향이 있습니다. 일본어 서명은 회사, 부서, 직함, 이름 순이며 단어 사이에 공백이 없는 경우가 많습니다. 部長(부서장)은 직함이지만 영어 직함 사전에는 없고, 이름은 성이 먼저 쓰일 수 있습니다. 독일어 Geschäftsführer(대표이사)와 프랑스어 Directeur général(총괄 관리자)은 반대 방향으로 같은 불일치를 만듭니다. 직함과 회사 사이에 대문자 표기와 쉼표를 기대하는 규칙은 매칭할 대상이 없습니다.

텍스트가 없거나 거의 없는 블록. 이미지 전용 서명에는 텍스트가 전혀 없습니다. 휴대전화 답장에는 "Sent from my iPhone"만 있을 수 있는데, 이는 한 줄 서명의 형태를 갖췄지만 필드는 하나도 없습니다. HTML 테이블은 태그가 제거될 때 이름과 직함의 시각적 순서를 뒤집을 수 있습니다.

더 영리한 정규식으로는 이 문제를 해결할 수 없습니다. Mailgun이 2013년 Talon 라이브러리를 오픈소스로 공개했을 때, 기계학습 분류기를 사용해 서명 줄과 비서명 줄을 구분했습니다. 2,912줄 테스트 세트에서 분류기는 92%의 줄을 맞혔는데, 이는 여전히 열두 줄 중 약 한 줄이 틀린다는 뜻입니다(Mailgun). 그것은 줄 분류이지 필드 할당이 아닙니다. 2018년 HPI 이메일 코퍼스를 주석한 연구자들은 메시지를 서명을 포함한 다섯 구역으로 나눴습니다. 이 작업은 추출보다 분할이 먼저이기 때문입니다(Hasso Plattner Institute).

정규식은 역할이 아니라 형태를 읽습니다. 팩스 번호와 휴대전화 번호는 같은 형태입니다.

클라이언트와 언어를 넘어 어떤 필드가 유지되는가

이메일 주소, 성명, 회사, 직함은 대부분의 서명에서 유지됩니다. 전화와 우편 주소는 추출기가 이를 식별하는 레이블을 유지할 때만 유지됩니다.

패턴은 단순합니다. 필드는 그 의미가 블록 내 위치가 아니라 헤더나 레이블에서 비롯될 때 유지됩니다. 전화번호에는 레이블이 필요하고, 우편 주소에는 줄 바꿈이 함께 유지되어야 합니다.

언어는 두 번째 필터입니다. SigParser의 자체 FAQ는 영어를 1위, 독일어를 2위로 두고 그다음 스페인어, 프랑스어, 포르투갈어, 러시아어, 네덜란드어를 꼽습니다(SigParser). 이는 유용한 인정입니다. 많은 파서가 영어 우선이며, 서명이 영어 관습에서 멀어질수록 도구는 직함 목록보다 일반 언어 모델에 더 의존합니다.

원래 직함 문자열을 유지하십시오. 추출 중에 Geschäftsführer를 "Managing Director"로 번역하는 것은 되돌릴 수 없는 결정이며, 그 사람의 법적 역할에 맞지 않을 수 있습니다. 원본을 저장하고 나중에 매핑하십시오.

헤더 필드는 클라이언트가 작성하기 때문에 안정적입니다. 서명 필드는 레이블이 유지될 때만 안정적입니다.

메일함에서 연락처 테이블까지

테이블은 두 단계로 구축합니다. 먼저 메시지 하나가 행 하나가 되고, 그다음 명시적인 충돌 규칙에 따라 이메일 주소를 기준으로 행을 병합합니다. 이 두 단계를 한꺼번에 처리하면 두 사람이 한 연락처로 합쳐집니다. 이메일에서 연락처 정보를 추출하는 대부분의 팀은 두 번째 단계부터 시작했다가 첫 번째 단계가 잘못되었다는 사실을 뒤늦게 발견합니다. 이 작업은 보통 세일즈 운영 담당자나 CRM 관리자가 맡게 되며, 메일을 전달하는 영업 담당자와 정보가 저장되는 연락처 모두에게 문제없이 유지되어야 합니다.

충돌을 조용히 해결하는 것이 바로 연락처 테이블을 신뢰할 수 없게 만듭니다. 대신 해당 행에 플래그를 지정하세요.

ImageToTable.ai가 적합한 곳과 한계

ImageToTable.ai는 전달된 메시지에 대해 추출 작업을 실행할 수 있지만, 메일함 크롤러나 CRM이 필요한 부분은 처리하지 않습니다. 작동 여부를 결정하는 것은 처리 모드입니다.

Email Inbox는 모든 계정에 전용 주소를 부여합니다. 메시지를 이 주소로 전달하거나, Gmail 또는 Outlook에서 조건에 맞는 메일을 전달하는 규칙을 설정하면 됩니다. 받은편지함에는 첨부파일만, 본문만, 첨부파일과 본문 모두의 세 가지 처리 모드가 있습니다. 서명 작업에는 본문만이 적합한데, 서명은 파일이 아니라 메시지 안에 있기 때문입니다.

다음 단계는 Custom Column Extraction입니다. 원하는 열 이름을 입력하면 AI가 의미를 기준으로 각 값을 찾아냅니다. 이 이름들이 출력 테이블의 헤더가 됩니다. 서명의 경우 성명, 직함, 회사, 사무실 전화, 휴대전화가 되며, 열 이름은 값이 인용된 블록이 아니라 발신자의 블록에서 와야 함을 나타냅니다. 각 메시지는 하나의 행이 됩니다. 결과는 Excel, CSV 또는 JSON으로 내보낼 수 있으며, Google Sheets 추가 기능은 열려 있는 시트에 행을 기록하므로 목록이 이미 있는 곳에서 병합이 이루어집니다.

Review Mode를 사용하면 행을 열고, 셀을 확인하고, AI의 원래 값을 보고, 편집 내용을 되돌릴 수 있습니다. 병합 규칙이 플래그를 지정한 행을 수동으로 확인하는 절차이며, 가져온 후에 오류를 발견하는 것보다 비용이 적게 듭니다.

세 가지 한계가 중요합니다. 메일함 연결이나 과거 데이터 크롤링은 없습니다. 이 도구는 보내준 내용을 읽을 뿐, Gmail 계정의 지난 10년치를 읽지 않습니다. 서명 블록 감지가 보장되지도 않습니다. 메시지를 읽고 지정한 열을 채울 뿐이므로, 서명이 세 개 있는 전달된 스레드도 하나의 문서로 취급되어 귀속이 잘못될 수 있습니다. 또한 중복 제거나 CRM 동기화도 없습니다. 같은 사람이 보낸 두 메시지는 직접 병합하지 않으면 두 개의 행이 됩니다. 출력은 연락처 레코드가 아니라 테이블입니다.

같은 필드 문제는 종이에서도 나타납니다. 명함 사진은 이메일 없이 존재하는 서명 블록입니다.

상속받는 개인정보 보호 규칙

업무용 이메일 주소, 직함, 직통 전화번호는 EU와 영국에서 개인정보에 해당하므로, 연락처 테이블에는 적법 근거와 보존 의무가 따릅니다. 비즈니스 이메일에 해당 정보가 보였다고 해서 자유롭게 보관할 수 있는 것은 아닙니다.

많은 팀이 비즈니스 연락처 데이터에 정당한 이익을 근거로 삼습니다. ICO의 지침에 따르면 비즈니스 연락처는 자신의 업무 정보가 처리될 것이라고 예상할 가능성이 더 높지만, 근거가 자동으로 성립하는 것은 아닙니다. 문서화된 정당한 이익 평가, 필요성 테스트, 균형 테스트가 필요합니다. 직접 마케팅에 대한 반대 권리는 절대적이므로, 반대 의사는 캠페인의 수신 거부 링크뿐 아니라 테이블에까지 도달해야 합니다(ICO).

데이터 최소화는 실무적인 부분입니다. 서명에 있는 모든 필드가 아니라 실제로 사용할 필드만 수집하십시오. B2B 연락처를 라우팅하는 데 개인 휴대전화 번호와 소셜 프로필은 필요하지 않으며, 이를 저장하면 삭제 요청 비용이 증가합니다. 출처 날짜를 기록하고, 보존 기간을 설정하고, 메일함 소유자가 테이블의 존재를 알고 있도록 하십시오. 고객을 위해 연락처를 처리하는 경우 계약과 개인정보 처리방침에 이를 포함해야 합니다. 이는 체크리스트이며 법률 자문이 아닙니다.

사용할 필드만 수집하고, 출처를 기록하고, 이유가 사라지면 삭제하십시오.

FAQ

정규식으로 이메일 서명을 파싱할 수 있나요?

이메일 주소, 전화번호, URL은 가능합니다. 이름, 직함, 회사명은 안정적으로 불가능합니다. 정규식은 값의 형태를 일치시킬 수 있지만, 어떤 줄이 직함인지 부서인지, 어떤 번호가 팩스인지 휴대전화인지, 또는 해당 블록이 발신자 것인지 아래에 인용된 사람 것인지 판별할 수 없습니다.

스레드에서 파서가 왜 잘못된 사람을 선택하나요?

스레드에는 서명이 여러 개 있고 위치 기반 규칙은 메시지 소유권이라는 개념이 없기 때문입니다. 마지막 블록은 보통 마지막으로 작성한 사람의 것이며, 이는 처리 중인 메시지의 작성자가 아니라 인용된 사람일 수 있습니다. 귀속이 중요할 때는 행마다 메시지 하나씩 전달하세요.

이메일 서명에서 안정적으로 추출할 수 있는 필드는 무엇인가요?

이메일 주소, 성명, 회사, 직함이 안정적인 핵심입니다. 전화는 레이블을 유지할 때만 안정적이므로 사무실 전화, 휴대전화, 팩스를 별도 열로 사용하세요. 우편 주소는 줄 순서와 우편번호 위치가 국가마다 달라 가장 덜 안정적인 필드입니다.

서명 파싱이 일본어, 독일어, 아랍어에서도 작동하나요?

도구가 의미를 읽는지, 영어 패턴을 매칭하는지에 달려 있습니다. 일본어 서명은 회사, 부서, 직함, 이름이 공백 없이 이어지는 경우가 많고, 部長 같은 직함은 영어 직함 목록에 없습니다. 독일어와 프랑스어 직함도 반대 방향으로 같은 문제가 있으며, 오른쪽에서 왼쪽으로 쓰는 문자는 줄 순서 가정을 깨뜨립니다. 의미 기반 모델이 키워드 목록보다 이를 잘 처리하지만, 출력은 여전히 검토가 필요합니다.

ImageToTable.ai가 내 메일함 전체를 스캔할 수 있나요?

아니요. Email Inbox 주소로 전달한 메시지, 또는 전달 규칙으로 그곳에 라우팅된 메일만 처리합니다. 메일함 연결도, 과거 데이터 크롤링도, 전달하지 않은 메일에 대한 접근도 없습니다.

이메일 서명의 연락처 정보를 저장하는 것이 합법인가요?

EU와 영국에서는 평가를 문서화하고, 필요한 것만 수집하고, 보존 기간을 설정하고, 이의 제기를 존중한다면 보통 정당한 이익에 해당합니다. 직접 마케팅에 대한 이의 제기는 절대적입니다. EU와 영국 외 지역은 규칙이 다르므로 연락처가 있는 관할권을 확인하세요.

서명은 양식이 아니라 관례입니다

서명은 데이터베이스를 채우기 위한 것이 아니라 메시지를 정중하게 끝내기 위해 설계되었습니다. 그래서 블록에 안정적인 표시가 없고, 같은 사람이 다섯 개의 이메일에서 두 개의 레코드처럼 보일 수 있습니다. 추출 단계는 자동화할 수 있지만, 어느 행이 누구의 것이고 어떤 값이 최신인지에 대한 결정은 여전히 받은편지함에 대한 판단입니다.

알고 있는 서명이 포함된 전달된 이메일을 보내고, 실제로 필요한 열의 이름을 지정한 뒤, 그 행이 예상한 사람의 것인지 확인하세요. 첫 번째로 잘못된 서명자를 찾는 것은 CRM 가져오기에서 찾는 것보다 여기서 더 저렴합니다.

이메일 하나로 사용해 보기