Entender o limite de taxa de mensagens do Exchange - 4.4.2 A taxa de envio de mensagens para este cliente excedeu o limite configurado

Question

Eu tenho esse problema no meu aplicativo para retransmitir e-mail através da porta 587 do nosso Exchange 2010: prompt de erro foi 4.4.2 Taxa de envio de mensagens para este cliente excedeu o limite configurado.

Eu entendo que isso se deve ao MessageRateLimit do meu conector do receptor. Eu verifiquei o limite é 5 e limite por usuário (MessageRateSource), e acho que o problema provavelmente será corrigido, aumentando o limite para 50 ou 100. No entanto, gostaria de entender essa configuração mais (como se eu configurá-lo para 50 agora e atingiu o mesmo erro amanhã?)

Com base no site MS , essa é a configuração de limitação para limite "O número máximo de mensagens por minuto que podem ser enviadas por uma única fonte". Então testei usando o script powershell (não tenho certeza se isso importa, então incluo o código parcial abaixo):

$SMTPClient = New-Object System.Net.Mail.SmtpClient( $emailSmtpServer , $emailSmtpServerPort )
$SMTPClient.EnableSsl = $true
$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($emailSmtpUser , $emailSmtpPass );
#[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { return $true }
$SMTPClient.Send( $emailMessage )

Neste script, primeiro envio o e-mail com outro ID de usuário e o resultado: posso enviar e-mails para o mesmo destinatário mais de cinco vezes em um minuto. Então, por que o limite não se aplica a este caso?

Depois disso, eu tentei o script com o meu ID de aplicativo, o mesmo erro (4.4.2) solicitado. Em seguida, verifiquei o explorador de log de acompanhamento e descobri que não há outro e-mail enviado com esse ID de aplicativo. Então é o Exchange armazena o usuário conta algum onde eu preciso redefini-lo? E como posso rastrear o envio de e-mail? Não parece aparecer no rastreamento log explorer, assim como a minha preocupação anterior, pode acertar o mesmo erro, mesmo que eu mude para 50, não consigo resolver ainda mais sem poder rastreá-los.

Desculpe, a questão é um pouco longa.

Aprecio se alguém puder me fornecer algumas dicas.

    

Answer 1

Vou virar essa questão de cabeça para baixo. Quando um cliente chega a mim com esse problema, a primeira coisa que pergunto é por que as mensagens estão sendo transmitidas pelo Exchange? O Exchange faz um e-mail em massa muito ruim, e há melhores opções. Por que o aplicativo não está enviando o próprio email ou por meio de seu próprio servidor em vez do Exchange?

Se você tem um aplicativo enviando tanto email para destinatários externos que ele está tropeçando nos limites de limitação, eu não gostaria que ele chegasse perto do Exchange. É apenas uma questão de tempo antes de ficar na lista negra. Endereço IP próprio, próprio PTR e DNS e envie o próprio email.

Não é a resposta que você está procurando, eu admito, mas freqüentemente pensar na questão de outra maneira lhe dá uma maneira melhor de lidar com a questão.

    

Answer 2

A limitação na troca é bastante poderosa, mas é difícil controlar a afaik.

Na minha experiência, estabelecer limites em conectores é bastante problemático, já que você pode ter apenas um pequeno subconjunto de usuários que estão enviando alto volume. Pressionar os limites dos conectores para poucos usuários expõe um risco maior de abuso por uma conta comprometida.

Políticas de limitação

Ao trabalhar com volumes maiores, você deve determinar as taxas mais altas de mensagens e defini-las no conector de recebimento. Este é o seu limite global .

Em seguida, você deve estabelecer primeiro uma política de limitação que reduza o limite a uma política de valor moderado (como 5 msg / min) como organizacional .

Por fim, você pode adicionar políticas adicionais que aumentam o limite de envio para usuários específicos.

Isso não expõe limites de "envio em massa" a todos os usuários que podem acessar o conector fornecido e permite um controle mais granular.

Você pode obter mais informações sobre políticas na documentação .

Detectando limites

Embora seja um bom ponto para o diagnóstico, eu não começaria a tentar lidar com os limites do lado do servidor.

Existem mais resultados que indicam falhas no sucesso ao enviar e-mails. Alcançar o limite de taxa é apenas um deles. E seu aplicativo precisa lidar com isso, assim como cenários em que o servidor de email inteiro pode não estar acessível devido a um tempo de inatividade.

Portanto, recomendamos enfaticamente que você se concentre no tratamento adequado de erros e em um mecanismo de enfileiramento em seu aplicativo. Confira maneiras de obter as mensagens de diálogo SMTP e registrá-las em caso de falha. Isso permitirá um diagnóstico rápido e fácil na produção - não apenas para este caso específico.

Como @seembee disse, o envio de grandes volumes aumenta o risco de ficar na lista negra. Esse risco ainda é dado ao ignorar a troca e usar hosts dedicados de mala direta. Enviando coisas como newsletters eu concordaria completamente. Mas quando você está enviando e-mails importantes, como faturas, que podem até ter restrições legais no fluxo de correspondência, eu não recomendaria ignorar a infra-estrutura de troca.