Resumo

  • A Hetzner vincula o bloqueio de portas de e-mail à conta. Um servidor transferido para projeto de outro proprietário segue as regras desse novo dono.
  • Um mês como cliente e o pagamento da primeira fatura permitem solicitar abertura de 25 e 465, mas a aprovação continua individual.
  • A porta 587 com serviço externo é uma alternativa publicada. Disponibilidade de rede não prova aceitação do serviço nem entrega na caixa do destinatário.

Quem recebeu a máquina recebeu o quê?

Uma agência poderia entregar ao cliente uma aplicação que depende de e-mails. O servidor aparece no projeto correto e a relação de ativos registra o novo dono. Esse cenário hipotético ainda não comprova o fim da entrega. A FAQ de servidores Cloud da Hetzner diz que o bloqueio de portas é aplicado por conta e que o recurso transferido fica sujeito às regras do proprietário de destino.

Não há aqui relato de incidente. Se a conta receptora já possui as permissões necessárias, pode não haver interrupção. Caso não possua, o fato de o sistema ter enviado mensagens anteriormente não comprova que conservará a mesma saída. A orientação oficial é verificar o desbloqueio do novo dono antes de transferir um servidor que usa 25 e 465.

O ponto decisivo não é a idade do equipamento. A máquina pode ter história operacional sem carregar a exceção concedida ao antigo usuário. Aceitar o inventário transferido como prova de aplicação pronta mistura a movimentação de um recurso com a autorização de uma dependência.

Propriedade não se resume à colaboração

A FAQ geral de Cloud descreve a transferência entre contas por meio de um projeto pertencente à conta de destino. O receptor cria o projeto e convida o proprietário atual, que move o recurso. O guia de migração de produtos apresenta o procedimento do servidor Cloud em uma seção própria.

Convite e propriedade não são sinônimos. Uma pessoa pode colaborar em um projeto sem que sua conta se torne proprietária. A FAQ diferencia papéis, reserva ao dono do projeto de origem a saída de recursos e atribui a cobrança ao dono do projeto de destino. O plano de entrega precisa identificar qual ato muda a autoridade que governa a máquina.

Também não deve importar regras de outro produto. Transferências de servidores dedicados no Robot, domínios e outros serviços têm descrições próprias. Conhecer uma dessas rotinas não prova que a permissão de e-mail Cloud seja herdada ou dispensada. O escopo de recurso precisa acompanhar o raciocínio.

Fatura quitada não é autorização emitida

A Hetzner explica o bloqueio padrão de 25 e 465 como resposta a spam e fraude. A FAQ em inglês informa que, após um mês de relacionamento e o pagamento da primeira fatura, o cliente pode pedir desbloqueio para um uso válido. A decisão é caso a caso. A FAQ em alemão também descreve revisão individual, não liberação automática.

Há três estados diferentes: cumprir condições, enviar pedido e obter aprovação. O pagamento não comprova sozinho a abertura. O histórico de uma máquina sob outra conta tampouco comprova que a conta de destino recebeu a mesma exceção. A política revisada não transmite essas condições por meio do passado do servidor.

A FAQ geral acrescenta que pedidos de limite são processados manualmente em horário comercial. As fontes não oferecem prazo garantido para essa decisão de portas. Uma entrega planejada sobre aprovação imediata ou automática inclui, portanto, uma premissa de calendário que os documentos não sustentam.

O incentivo por trás da separação é relevante. Computação fácil de contratar pode servir usuários legítimos e remetentes abusivos. Parte do efeito do abuso chega a destinatários e outras redes, além de quem compra a máquina. Examinar a conta permite considerar a parte que recebe poder de envio. Essa é uma leitura da estrutura de controle, não uma medição de spam evitado.

A alternativa externa muda a relação

A Hetzner documenta a porta 587 para envio por serviços externos de e-mail como alternativa que dispensa esse pedido de limite. A porta não é bloqueada segundo a política. Isso pode mudar uma arquitetura legítima, mas não significa que basta trocar um número para reproduzir envio direto.

O RFC 6409 separa submissão e retransmissão de mensagens e reserva 587 para submissão. O prestador externo adiciona sua própria relação de autorização. Uma porta acessível não comprova que o serviço aceitou a aplicação, menos ainda que uma mensagem entrou na caixa do destinatário.

O projeto precisa distinguir manter uma rota direta sujeita à conta de destino de organizar submissão por serviço externo admitido. Trabalho e controle ficam distribuídos de maneira diferente. Os documentos revisados não dão preços comparáveis, cotas ou resultados de entrega para declarar uma solução sempre mais barata ou segura.

Essa distinção não propõe burlar controles com proxies ou caminhos escondidos. A alternativa publicada é outro arranjo de serviço. Seu valor está em tornar a dependência explícita, não em fingir que a autorização da arquitetura anterior deixou de ser necessária.

A cobrança começa antes da prontidão

A FAQ de cobrança Cloud diz que um servidor criado permanece cobrável enquanto existe, mesmo desligado. Desligar não suspende genericamente o custo desse recurso durante uma espera. É uma afirmação de escopo limitado, não recomendação de excluir servidores do cliente nem cálculo de prejuízo.

Isso reforça a diferença entre contratar capacidade e colocar a aplicação em serviço. O recurso pode estar presente e gerar cobrança enquanto uma permissão necessária ainda não foi resolvida. Um caso de investimento deve reconhecer a possibilidade sem inventar dias, valores ou taxas de rejeição.

A conclusão não é evitar transferências. É julgar a prova correta. Mover um servidor Hetzner Cloud estabelece destino e propriedade do recurso, mas não demonstra que a autorização de e-mail anterior seguiu com ele. A entrega precisa enfrentar a conta receptora e a dependência escolhida. Um inventário correto comprova o servidor; não comprova sozinho o serviço pronto.

Fontes