[1] Comentário enviado por fabio em 17/09/2009 - 11:42h

Em tempo, tais comandos são de aprendizado (ou decoreba) obrigatório aos sysadmins :P

Parabéns pelo artigo, curto e objetivo.

0 0

[2] Comentário enviado por removido em 17/09/2009 - 11:45h

Quem sabe como funciona de verdade é o cara que resolve o problema quando quem somente clica não sabe o porque. Parabéns pela iniciativa...

0 0

[3] Comentário enviado por canaman em 17/09/2009 - 19:07h

Realmente, apesar de eu saber de cor os comandos, não sabia como fazer isso sobre uma coneção encriptada.

0 0

[4] Comentário enviado por removido em 19/09/2009 - 08:07h

Bakana amigo, principalmente a parte da conexão criptografada com o SSL.

0 0

[5] Comentário enviado por valdemir1971 em 14/10/2009 - 00:03h

Boa noite. Este artigo será de grande utilidade para mim. Mas estou tendo um poblema. No momento de informar o DESTINATÁRIO recebo a seguinte resposta:

MAIL FROM:<poulghet@gmail.com>
250 2.1.0 OK 26sm1592109qwa.1
RCPT TO:<cpd@gomagril.com.br>
RENEGOTIATING
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=21:unable to verify the first certificate
verify return:1

Quaquer e-mail que coloco no destinatário retorna a mesma resposta.
Desde já agradeço a atenção !!!

0 0

[6] Comentário enviado por keustps em 14/10/2009 - 08:50h

Bom dia. Na época que escrevi este artigo não tive este problema. Lendo seu comentário, realizei teste e realmente acontece este problema que você relatou. Este é um problema temporário do certificado que o gmail envia com a interpretação de caracter do openssl SSLv2. Para contornar o problema você deve especificar ao openssl que não use SSLv2, para isso basta acrescentar o parâmetro: -no_ssl2, o comando completo ficaria o seguinte:
openssl s_client -crlf -no_ssl2 -connect smtp.gmail.com:465. Aqui isso funcionou. Porém como é um problema temporário pode ser que volte a funcionar milagrosamente sem esse argumento depois de algum tempo.
Faça o teste e me informe se funcionou ou não :D

0 0

[7] Comentário enviado por valdemir1971 em 14/10/2009 - 22:40h

Obrigado pela atenção.
Mas continua aparecendo a mesma coisa.
Não tenho conhecimentos sobre certificação.
Será necessário gerar um certificado para isso ?
Abaixo segue o que aparece após a executar o comando:

depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDYzCCAsygAwIBAgIQUR2EgGT4+hGKEhCgLMX2sjANBgkqhkiG9w0BAQUFADCB
zjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEhMB8GA1UEAxMYVGhh
d3RlIFByZW1pdW0gU2VydmVyIENBMSgwJgYJKoZIhvcNAQkBFhlwcmVtaXVtLXNl
cnZlckB0aGF3dGUuY29tMB4XDTA3MDczMDAwMDAwMFoXDTEwMDcyOTIzNTk1OVow
aDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDU1v
dW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBJbmMxFzAVBgNVBAMTDnNtdHAu
Z21haWwuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD+RiG+G3Mo9Q9C
tcwDjpp6dJGifjiR5M2DbEbrsIOlth80nk5A7xstKCUfKobHkf/G9Y/DO24JP5yT
s3hWep05ybyiCmOzGL5K0zy3jIq0vOWy+4pLv2GsDjYi9mQBhobAAx3z38tTrTL+
WF4p0/Kl014+wnukIpj4MdF35rIkgQIDAQABo4GmMIGjMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vY3JsLnRo
YXd0ZS5jb20vVGhhd3RlUHJlbWl1bVNlcnZlckNBLmNybDAyBggrBgEFBQcBAQQm
MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLnRoYXd0ZS5jb20wDAYDVR0TAQH/
BAIwADANBgkqhkiG9w0BAQUFAAOBgQBeNYOZwMVQ7bd6b4sueAkgm57Cyv2p1Xv1
52e8bLnWqd03mWgn/+TQtrwbE1E6pVuQaZJY33ILpt8IfzwVf2TGQI+M5yazZ2fC
xwArHo20iAss3MLQR8tDXWfBoH2Lk9BBsEKDRP4hp83yfpZgdY3pinHTCbqHpsiS
v97epiiFBA==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
issuer=/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
---
No client certificate CA names sent
---
SSL handshake has read 1229 bytes and written 303 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 03B3A677A42092F6967E715F9C9FD4056DF806E3ADEF76509F1FD3BE4EA4B7BC
Session-ID-ctx:
Master-Key: 4F69BB7EC8C2E8E793B9261F090731AA34D97A486709D47CDC0EFD9CE7C43EE513EE5342FFDCF9D05E013B762BF37464
Key-Arg : None
Start Time: 1255556098
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
250 PIPELINING

0 0

[8] Comentário enviado por keustps em 15/10/2009 - 08:18h

Bom dia. Estas informações que aparecem indicam que seu certificado não pode ser comprovado como autêntico, uma vez sendo que você não tem registro de nenhum certificado digital em nenhum CA(autoridade que emite os certificados digitais). Isto não é um problema para nós, conseguimos conectar ao e-mail e enviar da mesma maneira, tanto é que conseguimos nos autenticar no servidor(AUTH PLAIN). Você pode ignorar essa mensagem que ele envia dizendo que seu certificado é inválido tranquilamente. Acho que sei qual o problema do RENEGOTIATING que disse no comentário anterior: o comando RCPT TO quando digitado todo em maiúsculo pode causar um problema com o openssl, por que o openssl identifica linhas iniciadas com o caracter R como renegociação de conexão. Para driblar isso, você pode fazer de duas maneiras: ou digitar os comandos do SMTP em minúsculo, ou passar o parâmetro -ign_eof para o openssl. O comando então ficaria: openssl s_client -crlf -ign_eof -connect smtp.gmail.com:465 .

0 0

[9] Comentário enviado por valdemir1971 em 15/10/2009 - 10:21h

Rapaz, você é "O CARA" !!!
Funcionou tudo beleza.
Isso vai me resolver um grande problema que será o ENVIO DE XML de NF-e para os clientes.
Obrigadão mesmo...

0 0

[10] Comentário enviado por keustps em 19/10/2009 - 06:39h

Que bom que funcionou =)
Sobre o envio que vc pretende fazer utilizando este artigo, não seria o ideal fazer um script com estes comandos, eu postarei daqui uns dias um artigo com um script em Perl que fiz sobre envio de e-mail, o qual vc poderia enviar até mesmo anexos. É só aguardar até eu concluir o artigo ;)

0 0

[11] Comentário enviado por valdemir1971 em 27/10/2009 - 20:24h

Olha, eu já fiz um script utilizando o "expect" e ficou muito bom mesmo. Inclusive consigo anexar vários arquivos usando o "base64" para codificar o mesmos. Pretendo fazer um artigo sobre isso aqui. Afinal, o VOL tem sido uma fontes de inesgotável de informações. Segue abaixo um exemplo do comando expect que usei para fazer a transmissão:

#!/usr/bin/expect --
set timeout 600
spawn openssl s_client -crlf -ign_eof -connect smtp.gmail.com:465
expect "220 "
send "HELO\r"
expect "250 "
send "AUTH PLAIN AG5mZS50XXXXXXXXXXXXXXXXXXXXXicgAzMzI2NTU1NQ== \r"
expect "235 "
send "MAIL FROM: <nfe@empresa.com.br>\r"
expect "250 "
send "RCPT TO: <nfe@cliente.com.br>\r"
expect "250 "
send "DATA\r"
expect "354 "
send "From: <nfe@empresa.com.br>
To: <nfe@cliente.com.br>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=\"3MwIy2ne0vdjdPXF\"
Content-Disposition: inline
Subject: (27/10/2009 20:11:13) XML NF-e 51091001888888888897550010000005370111127290

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

NOTA FISCAL: 00000537.xml
DATA.......: 27/10/2009

--3MwIy2ne0vdjdPXF
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=\"51091001888888888897550010000005370111127290.xml\"
Content-Transfer-Encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIj8+
PE5GZSB4bWxucz0iaHR0cDovL3d3dy5wb3J0YWxmaXNjYWwuaW5mLmJyL25mZSI+CiAgPGlu
Zk5GZSB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3Rh
...
ESTE BLOCO DE CÓDIGO FOI GERADO PELO COMANDO: base64 --wrap=72 nomeoriginal.pdf nomedesaida.b64
...
WW83T1FJLy9IYjRMRUdMdUtOMnMxTVQ1b3VXVllWN1U4UlhMTG5UamRUMmcwego2QWc5c3V6
WTV5ZDRadzlnVjJYbmo5clZmVU1yTCtoSzJ6WHZvNDkyNFNFVGNucDFVTG9DSXc9PTwvWDUw
OUNlcnRpZmljYXRlPjwvWDUwOURhdGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvTkZlPg==

.\r"
expect "250 "
send "quit\r"

0 0

[12] Comentário enviado por keustps em 28/10/2009 - 06:25h

Bom dia, seu script ficou muito bom mesmo. O expect é mesmo muito bom para automatizar essas tarefas, na época eu achei que teria um pouco de trabalho seria para "catar" o erros utilizando o expect, pq por exemplo se a autenticação do usuário falhar, o servidor não retornará o código 235 que o expect estaria esperando, aí teria que começar a tratar todas estas situações de erro, foi então que eu resolvi fazer em perl. Mas gostei sim de seu script, principalmente da parte que você codifica o conteúdo em base64 para enviar. O meu script em perl não criptografava o conteúdo, vou modificá-lo para criptografar =).

0 0

[13] Comentário enviado por porducel em 27/06/2013 - 15:38h

Show, desatolou meu caminhão, valeu !

0 0

[14] Comentário enviado por tnrv_ em 17/10/2019 - 10:03h

Bom dia

Estou tentando fazer no cent os 7 e aparece um problema
socket: Bad file descriptor
connect:errno=9

alguém sabe o que é?

0 0