Os comentários apontando que o SMTP não requer autenticação estão corretos. Dito isso, todos os três das opções especificadas não são seguras, supondo que o servidor use hardware e software comuns. Mostrarei por que cada um é inseguro, embora não siga sua ordem original.

E se alguém roubasse o servidor? Depois, bastava abrir o arquivo ou banco de dados, ler a senha e ter acesso imediato a todas as informações importantes da empresa. Então, a menos que você tenha guardas armados ao redor do servidor dia e noite, isso já é bastante inseguro.

Mas fica pior. Nenhum sistema de computador é completamente invulnerável a ataques, e vários ataques bem divulgados (PlayStation Network da Sony, por exemplo) nos últimos anos mostraram que um invasor pode acessar o conteúdo de arquivos de disco e bancos de dados sem acesso físico. Além disso, parece pela sua pergunta que o servidor em questão deve aceitar pacotes (solicitações HTTP, e-mails recebidos, etc.) do mundo exterior, o que aumenta sua superfície de ataque.

Isso é tentador, mas é ainda mais pernicioso do que a opção 2 ou a opção 3. Por um lado, um campo de string final privado é armazenado no arquivo .class gerado pelo compilador Java, então com esta opção você já está armazenando a senha não criptografada no disco rígido do servidor. Depois de comprometer o servidor como na opção 2 ou 3, um invasor pode simplesmente executar javap para obter a senha de texto simples do arquivo .class.

Essa abordagem amplia ainda mais sua superfície de ataque. Se a senha for armazenada como parte do código-fonte, de repente ela estará disponível para todos os desenvolvedores que estão trabalhando no código. Sob o princípio de privilégio mínimo, os desenvolvedores não devem saber senhas extras, e há uma boa razão aqui. Se algum dos desenvolvedores máquinas são roubadas ou comprometidas de fora, o invasor pode examinar o disco rígido da máquina comprometida e obter a senha em texto simples. Depois, há o controle de origem. Um dos benefícios realmente importantes do controle do código-fonte é que ele permite que você inspecione qualquer versão anterior do seu código. Portanto, mesmo que você alterne para um método seguro no futuro, se a senha já tiver entrado no controle do código-fonte, o servidor de controle do código-fonte será um ponto de ataque em potencial.

Todos esses fatores se somam para mostrar que, mesmo que a segurança do servidor HTTP/mail seja de alto nível, a opção 1 aumenta tanto a superfície de ataque que a segurança do servidor HTTP/mail não ajuda muito.

Detalhe extra:No início eu especifiquei "assumindo que o servidor usa hardware e software de commodities." Se você não estiver usando hardware e software comuns, poderá fazer coisas como inicializar a partir do armazenamento somente leitura e usar apenas um banco de dados criptografado, exigindo que uma pessoa forneça a chave de descriptografia em cada inicialização. Depois disso, as informações descriptografadas vivem apenas na memória e nunca são gravadas em disco. Dessa forma, se o servidor for roubado, um invasor precisa desconectar o servidor e, assim, perder todas as informações descriptografadas que estavam apenas na memória. Esse tipo de configuração às vezes é usado para um Kerberos KDC (com o servidor em uma caixa trancada para segurança extra), mas raramente é usado de outra forma e é francamente exagerado quando há uma maneira fácil de resolver seu problema sem precisar de todo esse extra despesa.