SMTP 메일 시간 초과 문제

Question

웹 응용 프로그램 용 사용자를 만들 때 SMTP 이메일 (ASP.NET의 SMTPClient 사용)이 자동으로 생성 된 비밀번호로 사용자에게 전송됩니다.그러나 때때로 시간이 초과되어 새 사용자가 비밀번호가 포함된 이메일을 받지 못하는 경우가 있습니다.

자, 메일이 통과되지 않았지만 사용자가 생성되었다는 메시지를 표시하겠습니다.

따라서 시스템 관리자에게는 지금까지 두 가지 옵션이 있습니다.

1. 사용자의 비밀번호를 재설정하고 자동 생성된 비밀번호로 다른 SMTP 메일이 전송되기를 바랍니다.
2. 사용자를 삭제하고 다시 만듭니다.

smtp가 전송되지 않으면 사용자 생성을 롤백할 수 있지만 이 문제를 해결하는 가장 좋은 방법은 무엇입니까?

각각 5초의 제한 시간을 두고 이메일을 3번 다시 보내야 한다고 생각하고 있습니다.따라서 15초가 최악의 시나리오가 됩니다.

이 길이 가는 길인가요?

Answer 1

글쎄, 플랫폼에 따라 메일을 로컬 MTA로 전달할 수 있다면 재시도 등을 처리해야 합니다.귀하의 프로그램은 시간 초과 및 그레이리스트 처리에 대해 걱정하지 않고 메일을 대기열에 추가하고 계속 진행할 수 있습니다.

그래도 메시지를 전달할 수 없는 경우 언제든지 비밀번호 재설정 기능을 통해 메시지를 다시 보내볼 수 있습니다.그래도 실패한다면 이메일 주소에 실수가 있을 가능성이 크므로 계정을 삭제하고 다시 등록하도록 권장합니다.

물론 이는 확인되지 않은 사용자로 무엇을 할 수 있는지에 따라 일부 시스템에서는 불가능할 수도 있습니다. 이는 실제로 이메일이 검증되기 전에 사람들이 무엇을 하도록 허용하는지에 따라 달라집니다.

Answer 2

귀하의 웹 앱이 사용자의 메일 서버에 직접 SMTP를 전달하는 것 같습니다.웹 앱은 MUA (메일 사용자 에이전트)입니다. 사용자의 MTA (메일 전송 에이전트)와 대화하는 것입니다.누군가 큐잉, 재시도 등을 제공하는지 확인하려면 자체 MTA를 실행해야 합니다.

정말로 과거로 돌아가고 싶다면 현재 하고 있는 작업을 수행하고(단 한 번만 시도) 메시지를 대기열에 추가하고 최소 24시간 동안 더 느린 일정으로 계속 재시도하고 완료되지 않은 상태를 사용자.

앱이 어떻게 작동해야 하는지에 대한 공식 답변은 다음에서 찾을 수 있습니다. RFC1123(인터넷 호스트 요구 사항 - 응용 프로그램 및 지원):

5.3.1.1 전송 전략

발신자 -SMTP의 일반적인 모델은 주기적으로 발신 메일을 전송하려고 시도하는 하나 이상의 프로세스입니다.일반적인 시스템에서 메시지를 작성하는 프로그램에는 새로운 발신 메일에 즉시주의를 기울이는 방법이 있으며 즉시 전송할 수없는 메일은 발신자가 대기하고 주기적으로 reted해야합니다.메일 대기열 항목에는 메시지 자체뿐만 아니라 봉투 정보도 포함됩니다.

발신자는 한 번의 시도가 실패한 후 특정 대상을 재활하는 것을 지연시켜야합니다.일반적으로 재 시도 간격은 30 분 이상이어야합니다.그러나 발신자 -SMTP가 비 배달 이유를 결정할 수있을 때보다 정교하고 가변적 인 전략이 유리할 것입니다.

메시지가 전송되거나 발신자가 포기할 때까지 재시는 계속됩니다.포기 시간은 일반적으로 4-5 일 이상이어야합니다.레트리 알고리즘의 매개 변수는 구성 가능해야합니다.

Answer 3

ASP.NET 및 System.Net.Mail 클래스를 사용하는 경우 아마도 웹 서버 시스템의 IIS 인스턴스를 통해 메일을 보내고 있을 것입니다(지정하지 않았기 때문에 확실하지 않습니다).메일 전송 에이전트(IIS SMTP)에 무슨 일이 일어나고 있는지 알 수 있는 좋은 방법은 없습니다.자체 재시도 논리가 있으며 기본적으로 메시지가 전달되는 데 오랜 시간이 걸릴 수 있습니다.

메일이 배달되지 않았음을 어떻게 감지합니까?"시간 초과"는 무엇에서 발생합니까?

메일 전송을 처리하는 백그라운드 프로세스가 있어야 합니다.MTA로의 전달이 성공하면 모든 것이 정상이라고 가정해야 합니다.SPAM 블랙리스트에 등록되지 않는 한 대부분의 MTA는 통과할 때까지 계속 재시도합니다.MTA를 사용하여 메시지를 삭제하는 중에 실제로 오류가 발생하면 반드시 다시 시도하거나 오류의 원인을 파악하고 버그를 수정하세요.솔직히 이 부분은 절대로 실패하면 안 됩니다.

NDR 메시지의 반송 주소를 모니터링하여 전자 메일이 배달되지 않은 시기를 확실히 알 때 일종의 조치를 취할 수 있습니다.그러나 사용자가 아직 시스템에 로그인할 수 없는 경우 무슨 일이 일어났는지 알릴 수 있는 좋은 방법이 없습니다.어쩌면 이메일과 관련된 값으로 쿠키를 설정하고, 메일을 전달할 수 없는 경우 로그인/등록 페이지에 뭔가를 입력할 수도 있습니다.

Answer 4

IMHO 재시도 없이 사용자에게 이메일 확인을 요청하도록 알려야 합니다.

사용자가 이메일을 확인하지 않고 페이지를 떠나는 경우 사용자는 어쨌든 해당 계정에 액세스할 수 없으므로 계정을 롤백하는 것이 좋습니다.

대부분의 시간 초과 사례는 유효하지 않은 이메일 계정으로 인해 발생합니다.사용자가 스팸을 피하기 위해 실수를 했거나 존재하지 않는 이메일 주소를 제공했습니다.

가능하다면 사용자에게 이메일을 요청하지 마세요.프로그래밍의 첫 번째 규칙은 다음과 같습니다.사용자를 짜증나게 하지 마십시오.