none
Envio de respostas automáticas no Exchange 2010 RRS feed

  • Pergunta

  • Boa tarde a todos,

    Temos um servidor SBS 2011, com Exchange 2010, onde usamos no SMTP o conector Smart Host para um provedor de internet.

    Todos os e-mails são enviados corretamente, mas percebemos que as confirmações de entrega e as respostas automáticas, como as de ausência temporária ficam paradas na fila com o seguinte erro:

    "You are send e-mails with an empty from: or an empty return-path"

    Pesquisei e descobri que de acordo com o RFC 2298, esse tipo de mensagem é considerado um MDN (Message Disposition Notifications) e que deve ser enviado com o remetente em branco, com isso meu provedor de email onde uso o SMTP nega a retransmissão da mensagem, gerando o erro acima.

    Gostaria de saber se é possível configurar o Exchange para enviar essas mensagens MDN com um remetente especifico (por exemplo "postmaster@dominio.com") ou usar o próprio destinatário para responder as MDN.

    Se não for possível, existe outra forma de enviar respostas automáticas pelo Exchange? Tentei com regras, mas para enviar respostas via Exchange, ele precisa de um modelo, então vira uma regra local e só funciona com o Outlook aberto.

    Obrigado pela atenção de todos!

    Renato Pacheco

    quarta-feira, 20 de janeiro de 2016 17:31

Respostas

  • Olá Renato,

    Você chegou a configurar algo na borda, tipo um Forefront, EOP ou algum antispam do tipo? Pois, conforme você mesmo citou, esta configuração é default no Exchange Server e é "by design", ou seja; o produto foi desenhado desta forma e não há como mudar.

    A criação de regras tbém não irá lhe attender, pois elas não irão alterar o conteúdo do OOF, ou seja, será necessário trabalhar com o produto que está fazendo a filtragem, seja o Antispam ou o destinatário.

    Abaixo, a documentação referenciando a informação discutida:

    Reference:
    http://tools.ietf.org/html/rfc2821
    =================
    4.5.5   Messages with a null reverse-path
       There are several types of notification messages which are required
       by existing and proposed standards to be sent with a null reverse
       path, namely non-delivery notifications as discussed in section 3.7,
       other kinds of Delivery Status Notifications (DSNs) [24], and also
       Message Disposition Notifications (MDNs) [10].  All of these kinds of
       messages are notifications about a previous message, and they are
       sent to the reverse-path of the previous mail message.  (If the
       delivery of such a notification message fails, that usually indicates
       a problem with the mail system of the host to which the notification
       message is addressed.  For this reason, at some hosts the MTA is set
       up to forward such failed notification messages to someone who is
       able to fix problems with the mail system, e.g., via the postmaster
       alias.)

       All other types of messages (i.e., any message which is not required
       by a standards-track RFC to have a null reverse-path) SHOULD be sent
       with with a valid, non-null reverse-path.

       Implementors of automated email processors should be careful to make
       sure that the various kinds of messages with null reverse-path are
       handled correctly, in particular such systems SHOULD NOT reply to
       messages with null reverse-path.

    • Marcado como Resposta Marcos SJ segunda-feira, 25 de janeiro de 2016 19:19
    segunda-feira, 25 de janeiro de 2016 12:31

Todas as Respostas

  • Olá Renato,

    Você chegou a configurar algo na borda, tipo um Forefront, EOP ou algum antispam do tipo? Pois, conforme você mesmo citou, esta configuração é default no Exchange Server e é "by design", ou seja; o produto foi desenhado desta forma e não há como mudar.

    A criação de regras tbém não irá lhe attender, pois elas não irão alterar o conteúdo do OOF, ou seja, será necessário trabalhar com o produto que está fazendo a filtragem, seja o Antispam ou o destinatário.

    Abaixo, a documentação referenciando a informação discutida:

    Reference:
    http://tools.ietf.org/html/rfc2821
    =================
    4.5.5   Messages with a null reverse-path
       There are several types of notification messages which are required
       by existing and proposed standards to be sent with a null reverse
       path, namely non-delivery notifications as discussed in section 3.7,
       other kinds of Delivery Status Notifications (DSNs) [24], and also
       Message Disposition Notifications (MDNs) [10].  All of these kinds of
       messages are notifications about a previous message, and they are
       sent to the reverse-path of the previous mail message.  (If the
       delivery of such a notification message fails, that usually indicates
       a problem with the mail system of the host to which the notification
       message is addressed.  For this reason, at some hosts the MTA is set
       up to forward such failed notification messages to someone who is
       able to fix problems with the mail system, e.g., via the postmaster
       alias.)

       All other types of messages (i.e., any message which is not required
       by a standards-track RFC to have a null reverse-path) SHOULD be sent
       with with a valid, non-null reverse-path.

       Implementors of automated email processors should be careful to make
       sure that the various kinds of messages with null reverse-path are
       handled correctly, in particular such systems SHOULD NOT reply to
       messages with null reverse-path.

    • Marcado como Resposta Marcos SJ segunda-feira, 25 de janeiro de 2016 19:19
    segunda-feira, 25 de janeiro de 2016 12:31
  • Boa tarde Bruno, obrigado pelas informações.

    Não tenho nada na borda, é um SBS, fica em uma empresa pequena, com link de internet banda larga, por isso utilizamos o smarthost para o Exchange enviar e-mails. Na verdade o bloqueio acontece no provedor do serviço SMTP, que nega o envio de mensagens com o remetente em branco.

    Se não haverá uma forma de configurar esta opção, a única solução seria configurar o Exchange para enviar via DNS, mas em link banda larga isso será quase impossível, por causa de registros em blacklists.

    Se encontrar alguma solução eu informo aqui.

    • Sugerido como Resposta Cristopher C I_ quinta-feira, 28 de janeiro de 2016 18:30
    terça-feira, 26 de janeiro de 2016 20:35
  • Entendi Renato.

    Cara, acredito que o EOP (Exchange Online Protection) não gera este transtorno, até por ser a recomendação da Microsoft para serviços de borda para ambientes de mensageria.

    Eu recomendo estudar a viabilidade de trocar seu provedor de AntiSpam/SMTP para o EOP. O custo é baixo, e é por usuários, então no seu caso de ser um portfolio small, deve ser favorável.

    Abaixo, algumas documentações interessantes para este cenário recomendado:

    How do connectors in EOP or Exchange Online work with my own email servers (also called on-premises servers)?
    https://technet.microsoft.com/en-us/library/ms.exch.eac.connectorselection%28v=exchg.150%29.aspx#HowDoConnectors1

    Best practices for configuring EOP
    https://technet.microsoft.com/en-us/library/jj723164%28v=exchg.150%29.aspx

    Protect on-premises mailboxes with Exchange Online Protection
    https://support.office.com/en-us/article/Protect-on-premises-mailboxes-with-Exchange-Online-Protection-C5E95951-DA67-4EC7-92C5-982ABD477E69

    Set up your EOP service
    https://technet.microsoft.com/en-us/library/jj723153%28v=exchg.150%29.aspx

    Abços,

    quarta-feira, 27 de janeiro de 2016 13:50