I am having a problem with Google's SMTP servers. They reject my SMTP server's IP for no valid reason. My server complies with all the necessary rules to deliver the message but Google rejects it by IP without giving me details and I cannot find support either. I have written to postmaster#gmail.com but got no response. My server sends notifications to the users of the system, it does not do SPAM and apparently everything is correct. I don't see a valid reason for this crash, and I can't find a way to fix it. I would like to know if the same thing happened to someone and how they could solve it. Next I copy the console with the delivery attempt and additionally some DNS checks that show that apparently there is no problem on my server:
root#venabili:~# hostname -f
venabili.tecnologica.com.ar
root#venabili:~# id
uid=0(root) gid=0(root) grupos=0(root)
root#venabili:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 200.69.236.179 netmask 255.255.255.0 broadcast 200.69.236.255
inet6 fe80::f816:3eff:fe27:b8e1 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:27:b8:e1 txqueuelen 1000 (Ethernet)
RX packets 302342269 bytes 32703331063 (30.4 GiB)
RX errors 0 dropped 17 overruns 0 frame 0
TX packets 75025298 bytes 12670842456 (11.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root#venabili:~# nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> set type=mx
> tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
tecnologica.com.ar mail exchanger = 10 venabili.tecnologica.com.ar.
Authoritative answers can be found from:
> set type=a
> venabili.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: venabili.tecnologica.com.ar
Address: 200.69.236.179
> set type=aaaa
> venabili.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: venabili.tecnologica.com.ar
Address: fe80::f816:3eff:fe27:b8e1
> set type=ptr
> 200.69.236.179
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
179.236.69.200.in-addr.arpa name = venabili.tecnologica.com.ar.
Authoritative answers can be found from:
> set type=txt
> tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
tecnologica.com.ar text = "v=spf1 a mx ip4:200.69.236.179 ip6:fe80::f816:3eff:fe27:b8e1 ~all"
Authoritative answers can be found from:
> set type=txt
> default._domainkey.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
default._domainkey.tecnologica.com.ar text = "v=DKIM1; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz+GrX8vxp9W51ehJuixhL5AbjmCgcN2h7KqMiLI8LMUfmpWPP1GIhxlWCieFUVMOAQGlQrImuFE3kk/qLOgyumzUTRBwxlNX+7tix7dlBclXAWq8SjB9SbbAcPKkTBAq0pvXvp4l4qTCFnfVXAs1g/lCywlJrbfAFVVXWdN44ElFz+bD4YRYsXSmz//L1uFU7YE" "zkFUvbMtwBOL1xRvjAFXH4xQ7/vkHX6+OIxnm47vO/a2CqFVXok0FhAj44BmlBT+Py0x0SP8jsm+xhnLc238ZIsGylTwCb0Zbl3DR9bKGBy9FqXoUyRIzWKEkAtwaKq7qeBO3oRT4kQOKEOog2QIDAQAB"
Authoritative answers can be found from:
> _dmarc.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
_dmarc.tecnologica.com.ar text = "v=DMARC1; p=reject; rua=mailto:postmaster#tecnologica.com.ar; ruf=mailto:postmaster#tecnologica.com.ar"
Authoritative answers can be found from:
> _smtp._tls.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
_smtp._tls.tecnologica.com.ar text = "v=TLSRPTv1; rua=mailto:postmaster#tecnologica.com.ar"
Authoritative answers can be found from:
> _mta-sts.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
_mta-sts.tecnologica.com.ar text = "v=STSv1; id=20200918192500"
Authoritative answers can be found from:
> set type=cname
> mta-sts.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
mta-sts.tecnologica.com.ar canonical name = venabili.tecnologica.com.ar.
Authoritative answers can be found from:
> exit
root#venabili:~# openssl s_client -connect mta-sts.tecnologica.com.ar:443
CONNECTED(00000004)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mta-sts.tecnologica.com.ar
verify return:1
---
Certificate chain
0 s:CN = mta-sts.tecnologica.com.ar
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFbTCCBFWgAwIBAgISBC7Vr1sblDEJHYgxBtfro6xcMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA5MTgyMzM4MjdaFw0y
MDEyMTcyMzM4MjdaMCUxIzAhBgNVBAMTGm10YS1zdHMudGVjbm9sb2dpY2EuY29t
LmFyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5glA7vEmuS0EzKhn
w9IfLPHHertYYOYx54t/2zr8G1pSmkCjrOlfV+YHwIuWeehxDUz/ezy1JXyK11kd
raDd71MoBd9mV12fjITO99oDpkYu9g09TxJ9rpIEkU8LRGkgjfDGBBtf5X5Za+Ah
gWbJ4JudVoykVZ00riQsZzbfJ8FNZcwEgErWCZCBL45tR7tfeFlXTJGFhyszqQN+
r4gS3C/JpsObIMaoqmkJrO5YUGcfGvqDOG3INthp2L9/t743OfYUGTqRFu09Rq5S
xwEYxR8GksaLwzMWOIRelMP4W5F9ce7hhdxU68cK4j9rHXaaeNXLySeMs7K9C2vt
p1nnowIDAQABo4ICcDCCAmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQ1A7mXXvtb
eS6ZYRtw4EA7WhJ3/zAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBv
BggrBgEFBQcBAQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5s
ZXRzZW5jcnlwdC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5s
ZXRzZW5jcnlwdC5vcmcvMCUGA1UdEQQeMByCGm10YS1zdHMudGVjbm9sb2dpY2Eu
Y29tLmFyMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYI
KwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBQYKKwYBBAHW
eQIEAgSB9gSB8wDxAHcA5xLysDd+GmL7jskMYYTx6ns3y1YdESZb8+DzS/JBVG4A
AAF0o8xFcQAABAMASDBGAiEAlc3Q8FEkd5ZUayxVfeorQv9+Jt1OSgOOP+jqVw5K
sskCIQCE0Hx7YDWcJ9o4Cck50WP7UtA/qRgmfn1fVIHyEZMftwB2AAe3XBvlfWj/
8bDGHSMVx7rmV3xXlLdq7rxhOhpp06IcAAABdKPMRZcAAAQDAEcwRQIgBVUd9xxC
DVX/kr0+308ra9YOqJC/yvBJnktxWg6YUVMCIQCR14/ouxc+Ydm4tePVBjBnmpRq
QzQEDYrd+4R7JjpiCjANBgkqhkiG9w0BAQsFAAOCAQEAlCnRwvP7wNRHTzB5N9/N
2cBPuVxKbvf1rHwusXYzQBVlyM6grEvjTgd5V/C+we1ueDUp991tP3z5AAksIGWM
/ssDlK0VSxv9PIzC1LxDK39Sl+P8xkuGj0zSDYg321sFjFyZLashP+xFYyzx3QdD
9h65J0uB/BigWOIN9sK1vLVhIB4yqV190vucyMamJBZ1dvSaYCi52dCgEEsAxM3v
LksETYgpSqB4+6zB2ae3/FN2/m3vyWCdFv1fL19hIidKjwIYhIKVOLKTQCYvCd+p
srhlTtnRf8i+P8Dni9xKmKSFwSGc8L+AS0AfTh6M/+IEPOO2zJsp1R/PBWgiy42v
fw==
-----END CERTIFICATE-----
subject=CN = mta-sts.tecnologica.com.ar
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3203 bytes and written 403 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305
Session-ID: 38FDD25BCB4C28F5364CA3418C05D13F279E62882E594190276850599BB67EAB
Session-ID-ctx:
Master-Key: 41AEF29EC1545AAE8C53958032EFF464E237232D8AA9D22CF9513297DFFBA40645226685FE58FEC782DA20CDFFEB5EDB
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 5f 78 fa 6f 3a 54 9c c2-f0 8e b2 b7 70 13 05 d4 _x.o:T......p...
0010 - 4b 39 84 62 c7 cb 96 f8-89 5c 27 09 6c 2b aa ad K9.b.....\'.l+..
0020 - 52 22 36 d6 a3 0b 8b 5e-ed 4b 78 f5 49 61 47 69 R"6....^.Kx.IaGi
0030 - c9 e7 41 88 c2 e6 29 86-b5 52 a9 8f 56 3f 79 3e ..A...)..R..V?y>
0040 - 14 bd b5 24 ca c5 f7 a4-ab b9 f9 26 dc 1c 71 7a ...$.......&..qz
0050 - ab 5a a2 a9 76 df 61 70-a5 91 5f 69 36 bc 64 69 .Z..v.ap.._i6.di
0060 - 02 b5 4b ba 79 e0 c9 a7-3b e2 a6 30 9b 2b 34 33 ..K.y...;..0.+43
0070 - 02 af 1e 3c 82 90 bc ca-32 b3 57 5b e0 b6 33 b0 ...<....2.W[..3.
0080 - a6 4c dc a8 c9 01 29 cf-98 ba 7c 40 3a ae 4b 04 .L....)...|#:.K.
0090 - 95 66 2f 96 b2 b9 5b f1-b0 f2 b0 6c e4 61 6f d0 .f/...[....l.ao.
00a0 - 98 a2 67 06 c9 22 ef a3-f5 ec 24 ac a2 b1 5f 4e ..g.."....$..._N
Start Time: 1600571394
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
GET /.well-known/mta-sts.txt HTTP/1.1
Host: venabili.tecnologica.com.ar
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Sun, 20 Sep 2020 03:10:22 GMT
Content-Type: text/plain
Content-Length: 77
Last-Modified: Sat, 19 Sep 2020 14:07:46 GMT
Connection: keep-alive
ETag: "5f6610b2-4d"
Accept-Ranges: bytes
version: STSv1
mode: testing
mx: venabili.tecnologica.com.ar
max_age: 604800
^C
root#venabili:~# openssl s_client -starttls smtp -connect venabili.tecnologica.com.ar:587 -crlf -ign_eof
CONNECTED(00000004)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = venabili.tecnologica.com.ar
verify return:1
---
Certificate chain
0 s:CN = venabili.tecnologica.com.ar
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFbzCCBFegAwIBAgISBAyLUnN1zyR0tAMF7k1G3023MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA5MTgyMjMxMjZaFw0y
MDEyMTcyMjMxMjZaMCYxJDAiBgNVBAMTG3ZlbmFiaWxpLnRlY25vbG9naWNhLmNv
bS5hcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/svQH9FsoQZyGh
krGZLrN3GAzwuAV2IEsYdAixVrVXGPPjA4oTxQDWncBPVh8x6nMstJqq4xP19aBr
pw5P2rcsMvLT9RJ14wGuNzzDcx9uOmR709ZrPpPzZJ4JJnZxQP5dE2jJMrPQ7tnI
3AudscEaAMW8qBLj91jPDiv4LbRHL4xU+w46yZbB6szgb4u567SSKFaVlRQ8tmCt
msIkYdA5mP5/1Z0QN6PgtAzCWECEkn/eRpuTUHliMjgCocwQ3RYkofGrNQ1a4H7F
RgdaQzjCjQ7JdT/pZTYWrejr3alMsFAukRfIH/FMI5v8ojaxzlQOhz46WJiw3qNH
rmjb+G0CAwEAAaOCAnEwggJtMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr
BgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU91GfsO41
iPZN1SROqwqnCPSN9yIwHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl7/Oo7KEw
bwYIKwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5pbnQteDMu
bGV0c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMu
bGV0c2VuY3J5cHQub3JnLzAmBgNVHREEHzAdght2ZW5hYmlsaS50ZWNub2xvZ2lj
YS5jb20uYXIwTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAm
BggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEFBgorBgEE
AdZ5AgQCBIH2BIHzAPEAdwDnEvKwN34aYvuOyQxhhPHqezfLVh0RJlvz4PNL8kFU
bgAAAXSjjusOAAAEAwBIMEYCIQDOwhtVW/tkJzexdCpcX2gLXX7axA8Fw4bDURrr
tu/ecQIhAKpdzqz+iWGw9I7pkKfYNjyyLdWojRlT+IYQfR7qxQc4AHYAB7dcG+V9
aP/xsMYdIxXHuuZXfFeUt2ruvGE6GmnTohwAAAF0o47rMwAABAMARzBFAiBUUOSO
S+8ueu2ACk+862qxbAsXylwZAfHhg/7HmEeEQQIhAKq3jqMMSIjTo47t2JXrU58d
PP6E3NwNHOgGCNje4R/nMA0GCSqGSIb3DQEBCwUAA4IBAQAua/T4drS/7xpNmGDV
Xp2iFhSaVsbWeHh5+40POEAy9NvaZ8O4CeNjV3NeV84QI2Jh1PjehebM72K85rCT
7jEOqaJY5vmKrLBVji6MsgryyGLm4Y368nMR3JrXDLUkATgart+jLdsxLbaRsI1t
Gf+BLc6TYb4roGiI7TTjEQDAy2SOGqfOWbAEdVKIEr9P3IBrlOSOl2o8gd97PXQ/
vEmklVM/5zr5l5paInHOidBL8y8qVk2s9AkaQNAS2QTX5+iFl9D1u8z5mz49eKPb
sb9GSFVTm/qe0KHl02qga4/1ANRoNCuKoaE5xxhqyboJwy58qp7opbzipqxbQI0T
N8e/
-----END CERTIFICATE-----
subject=CN = venabili.tecnologica.com.ar
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3389 bytes and written 432 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 CHUNKING
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: D8A0F5C48FBFE47FAEF6482AC696CBCAB01EB030F683053A41539DCD5B91E593
Session-ID-ctx:
Resumption PSK: 3CACF3832764ACCF8A00FFDAFA9A8771E62C04FCDF1429A85EB2A3AC0F39733F642045E4602CE73F62AEC75745B51392
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 30 00 51 89 4c df 15 62-da 50 55 37 92 60 65 f2 0.Q.L..b.PU7.`e.
0010 - 05 72 39 3d fb 1e 8a 05-2f 95 6b f0 cd 33 29 b0 .r9=..../.k..3).
0020 - b7 38 89 4f 2f 32 91 66-f7 59 2f 80 43 fc 81 f7 .8.O/2.f.Y/.C...
0030 - c6 53 68 3d d8 69 0d 10-6c 4c 62 9c 81 d9 ec 60 .Sh=.i..lLb....`
0040 - 9f ef a0 95 46 d3 e0 10-29 09 20 ab 48 3b 07 34 ....F...). .H;.4
0050 - 82 d3 0e 39 3d 11 18 e8-9e 44 b7 69 b9 d0 45 2e ...9=....D.i..E.
0060 - 97 4f da 69 aa 89 27 2c-e5 9c 63 39 4b f8 3f 54 .O.i..',..c9K.?T
0070 - 23 1a db 73 ac 7e 78 20-76 f5 67 b9 8f e1 c3 34 #..s.~x v.g....4
0080 - d7 f0 b5 0b 0d c7 dc 80-f6 40 0c 20 3f 8d 16 b7 .........#. ?...
0090 - 3a c2 e2 a9 c1 b6 fd 84-65 7f a5 1c 16 81 60 5a :.......e.....`Z
00a0 - 53 12 3a bf d0 4a 0c 0e-a2 3b 57 ce ad 63 89 e6 S.:..J...;W..c..
00b0 - a7 58 ea 21 f9 2e 04 00-ff 6f a7 40 9d 2c bf 39 .X.!.....o.#.,.9
00c0 - 8d d9 19 c9 e1 05 a6 19-a4 60 06 75 8d 3e 95 89 .........`.u.>..
Start Time: 1600567929
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
ehlo venabili.tecnologica.com.ar
250-venabili.tecnologica.com.ar
250-PIPELINING
250-SIZE
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
auth login
334 VXNlcm5hbWU6
bm8tcmVzcG9uZGVyQHRlY25vbG9naWNhLmNvbS5hcg==
334 UGFzc3dvcmQ6
!!!
235 2.7.0 Authentication successful
mail from: no-responder#tecnologica.com.ar
250 2.1.0 Ok
rcpt to: jmouriz#gmail.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
from: root <no-responder#tecnologica.com.ar>
to: Juan Manuel Mouriz <jmouriz#gmail.com>
subject: Mensaje de prueba
Hola, este es un mensaje de prueba
.
250 2.0.0 Ok: queued as 5E50844853
quit
221 2.0.0 Bye
closed
root#venabili:~# grep 5E50844853 /var/log/mail.log
Sep 19 23:18:54 venabili postfix/submission/smtpd[7994]: 5E50844853: client=venabili.tecnologica.com.ar[200.69.236.179], sasl_method=login, sasl_username=no-responder#tecnologica.com.ar
Sep 19 23:20:35 venabili postfix/cleanup[8543]: 5E50844853: message-id=<20200920021854.5E50844853#venabili.tecnologica.com.ar>
Sep 19 23:20:35 venabili postfix/qmgr[5677]: 5E50844853: from=<no-responder#tecnologica.com.ar>, size=554, nrcpt=1 (queue active)
Sep 19 23:20:35 venabili postfix/cleanup[8543]: 6F3BE4485D: message-id=<20200920021854.5E50844853#venabili.tecnologica.com.ar>
Sep 19 23:20:35 venabili amavis[26666]: (26666-19) Passed CLEAN {RelayedOutbound}, ORIGINATING LOCAL [200.69.236.179]:55833 [200.69.236.179] <no-responder#tecnologica.com.ar> -> <jmouriz#gmail.com>, Queue-ID: 5E50844853, Message-ID: <20200920021854.5E50844853#venabili.tecnologica.com.ar>, mail_id: bcEyyqxUQvNK, Hits: -1, size: 554, queued_as: 6F3BE4485D, dkim_new=default:tecnologica.com.ar, 329 ms
Sep 19 23:20:35 venabili postfix/smtp[8676]: 5E50844853: to=<jmouriz#gmail.com>, relay=127.0.0.1[127.0.0.1]:10026, delay=115, delays=115/0.02/0.01/0.32, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10027): 250 2.0.0 Ok: queued as 6F3BE4485D)
Sep 19 23:20:35 venabili postfix/qmgr[5677]: 5E50844853: removed
root#venabili:~# grep 6F3BE4485D /var/log/mail.log
Sep 19 23:20:35 venabili postfix/smtpd[8679]: 6F3BE4485D: client=localhost[127.0.0.1]
Sep 19 23:20:35 venabili postfix/cleanup[8543]: 6F3BE4485D: message-id=<20200920021854.5E50844853#venabili.tecnologica.com.ar>
Sep 19 23:20:35 venabili postfix/qmgr[5677]: 6F3BE4485D: from=<no-responder#tecnologica.com.ar>, size=1625, nrcpt=1 (queue active)
Sep 19 23:20:35 venabili amavis[26666]: (26666-19) Passed CLEAN {RelayedOutbound}, ORIGINATING LOCAL [200.69.236.179]:55833 [200.69.236.179] <no-responder#tecnologica.com.ar> -> <jmouriz#gmail.com>, Queue-ID: 5E50844853, Message-ID: <20200920021854.5E50844853#venabili.tecnologica.com.ar>, mail_id: bcEyyqxUQvNK, Hits: -1, size: 554, queued_as: 6F3BE4485D, dkim_new=default:tecnologica.com.ar, 329 ms
Sep 19 23:20:35 venabili postfix/smtp[8676]: 5E50844853: to=<jmouriz#gmail.com>, relay=127.0.0.1[127.0.0.1]:10026, delay=115, delays=115/0.02/0.01/0.32, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10027): 250 2.0.0 Ok: queued as 6F3BE4485D)
Sep 19 23:20:37 venabili postfix/smtp[8680]: 6F3BE4485D: to=<jmouriz#gmail.com>, relay=gmail-smtp-in.l.google.com[172.217.192.26]:25, delay=1.7, delays=0.02/0.02/0.88/0.8, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[172.217.192.26] said: 550-5.7.1 [200.69.236.179] The IP you're using to send mail is not authorized to 550-5.7.1 send email directly to our servers. Please use the SMTP relay at your 550-5.7.1 service provider instead. Learn more at 550 5.7.1 https://support.google.com/mail/?p=NotAuthorizedError a44si4686321qtk.87 - gsmtp (in reply to end of DATA command))
Sep 19 23:20:37 venabili postfix/bounce[8681]: 6F3BE4485D: sender non-delivery notification: 32EF64485E
Sep 19 23:20:37 venabili postfix/qmgr[5677]: 6F3BE4485D: removed
root#venabili:~#
The domain in question is tecnologica.com.ar and I leave a link to some verifications where it is seen that the RR SPF, DKIM, DMARC, _SMTP._TLS, _MTA-STS, MTA-STS, CAA and PTR are correct and it is not a open relay:
https://mxtoolbox.com/domain/tecnologica.com.ar
The certificates are signed by Let's Encrypt. The host name matches the certificate. The classes are correct. And finally, I do not SPAM. I would greatly appreciate a help because at this point I am completely disoriented and can't find what else to do.
I am not looking for a solution but rather where I can find it.
Thank you very much for your help
Additional info
This is a report domain for DMARC:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support#google.com</email>
<extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
<report_id>7762784093316082866</report_id>
<date_range>
<begin>1603756800</begin>
<end>1603843199</end>
</date_range>
</report_metadata>
<policy_published>
<domain>tecnologica.com.ar</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>200.69.236.179</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>tecnologica.com.ar</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>tecnologica.com.ar</domain>
<result>pass</result>
<selector>default</selector>
</dkim>
<spf>
<domain>tecnologica.com.ar</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
And this is a report domain for TLS:
{"organization-name":"Google Inc.","date-range":{"start-datetime":"2020-10-26T00:00:00Z","end-datetime":"2020-10-26T23:59:59Z"},"contact-info":"smtp-tls-reporting#google.com","report-id":"2020-10-26T00:00:00Z_tecnologica.com.ar","policies":[{"policy":{"policy-type":"sts","policy-string":["version: STSv1\r","mode: testing\r","mx: venabili.tecnologica.com.ar\r","max_age: 604800\r","\r"],"policy-domain":"tecnologica.com.ar"},"summary":{"total-successful-session-count":1,"total-failure-session-count":0}}]}
Related
My application sends an email to an Exchange mail server, mail server is configured with a third party application where it routes email to agent and agent replies to that email. Application reads agent reply from the mailbox which is used to send the email.
Email sending code is below;
Message mimeMessage = new MimeMessage(session);
mimeMessage.setFrom(new InternetAddress(from));
mimeMessage.addRecipient(Message.RecipientType.TO, new InternetAddress(to));
mimeMessage.setSubject(subject);
mimeMessage.setContent(emailText,"text/plain");
mimeMessage.setReplyTo(replyToAddress);
Transport.send(mimeMessage);
This works perfectly. When agent reply is received, Application read it as;
if (message.isMimeType("multipart/MIXED")) {
logger.info("Email MIME Type is: multipart/MIXED");
MimeMultipart multipart =(MimeMultipart)message.getContent();
logger.info("Content type = "+multipart.getContentType());
int count = multipart.getCount();
}
The content type is "multipart/mixed" but the count is 0 means there are no parts in this emails.
I need to set System property,
System.setProperty("mail.mime.multipart.allowempty", "true");
if it is not set, multipart.getCount() throws "missingBoundryException".
Why it is so ?
I can see that the agent's reply is not empty.
The email was sent with content type as text/plain, why reply type is multipart/mixed?
Is this due to any invalid formatting of email by third party application, what is the workaround?
Below is the snap of agent reply.
Below is the raw MIME content,
Received: from sociaminer.host (192.168.1.29) by thirdpartHost
(192.168.1.53) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 19 Jan
2017 17:06:26 +0500
To: hafiz <hafiz#bla.bla>
Message-ID: <hassan.MESSAGEID#bla.bla>
In-Reply-To: <CF72F94#bla.bla>
References: <CF72F945A#bla.bla>
Subject: Re: 1122+50
Content-Type: multipart/mixed;
boundary="----=_Part_127_14151461.1484827604583"
From: <reply#bla.bla>
Return-Path: reply#bla.bla
Date: Thu, 19 Jan 2017 17:06:26 +0500
X-MS-Exchange-Organization-AuthSource: bla.bla
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 06
X-Originating-IP: [SocialMinerIP]
MIME-Version: 1.0
------=_Part_127_14151461.1484827604583
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">Reply to 50<br>
<blockquote><hr>
<b>From:</b> hafiz <hafiz#bla.bla><br><b>Sent:</b> Thursday, January 19, 2017 5:05 PM<br><b>To:</b> testing2 <testing2#bla.bla><br><b>Subject:</b> 1122+50<br>
<html dir="ltr">
<head>
<style type="text/css" id="owaParaStyle"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Testing 50</div>
</body>
</html>
</blockquote>
------=_Part_127_14151461.1484827604583--
JavaMail debug output looks like below,
DEBUG: setDebug: JavaMail version 1.4.7
DEBUG: getProvider() returning javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Oracle]
DEBUG IMAP: mail.imap.fetchsize: 16384
DEBUG IMAP: mail.imap.ignorebodystructuresize: false
DEBUG IMAP: mail.imap.statuscachetimeout: 1000
DEBUG IMAP: mail.imap.appendbuffersize: -1
DEBUG IMAP: mail.imap.minidletime: 10
DEBUG IMAP: disable AUTH=PLAIN
DEBUG IMAP: enable STARTTLS
DEBUG IMAP: trying to connect to host "Echange IP", port 143, isSSL false
* OK The Microsoft Exchange IMAP4 service is ready.
A0 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 LOGINDISABLED STARTTLS UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+
A0 OK CAPABILITY completed.
DEBUG IMAP: protocolConnect login, host=192.168.1.53, user=hafiz#bla.bla, password=<non-null>
A1 STARTTLS
A1 OK Begin TLS negotiation now.
A2 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 AUTH=NTLM AUTH=GSSAPI AUTH=PLAIN UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+
A2 OK CAPABILITY completed.
DEBUG IMAP: AUTH: NTLM
DEBUG IMAP: AUTH: GSSAPI
DEBUG IMAP: AUTH: PLAIN
DEBUG IMAP: AUTHENTICATE NTLM command trace suppressed
DEBUG NTLM: type 1 message: 4E 54 4C 4D 53 53 50 00 01 00 00 00 03 A2 00 00 00 00 00 00 23 00 00 00 03 00 03 00 20 00 00 00 31 39 32
DEBUG NTLM: type 3 message: 4E 54 4C 4D 53 53 50 00 03 00 00 00 18 00 18 00 68 00 00 00 18 00 18 00 80 00 00 00 00 00 00 00 40 00 00 00 22 00 22 00 40 00 00 00 06 00 06 00 62 00 00 00 00 00 00 00 98 00 00 00 01 82 00 00 68 00 61 00 66 00 69 00 7A 00 40 00 65 00 66 00 6C 00 61 00 62 00 2E 00 6C 00 6F 00 63 00 61 00 6C 00 31 00 39 00 32 00 3B 5E 2B 86 67 49 E3 01 C9 9E F2 CA ED 54 21 11 81 89 94 C6 EC E0 26 E3 BA DB E7 5A F4 CA 28 17 7C 0E 8A 08 18 B5 5A 4E 72 4F C5 7F 52 64 FA 76
DEBUG IMAP: AUTHENTICATE NTLM command result: A3 OK AUTHENTICATE completed.
A4 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 AUTH=NTLM AUTH=GSSAPI AUTH=PLAIN UIDPLUS CHILDREN IDLE NAMESPACE LITERAL+
A4 OK CAPABILITY completed.
DEBUG IMAP: AUTH: NTLM
DEBUG IMAP: AUTH: GSSAPI
DEBUG IMAP: AUTH: PLAIN
DEBUG IMAP: connection available -- size: 1
A5 SELECT INBOX
* 40 EXISTS
* 0 RECENT
* FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)
* OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)] Permanent flags
* OK [UNSEEN 39] Is the first unseen message
* OK [UIDVALIDITY 436] UIDVALIDITY value
* OK [UIDNEXT 46] The next unique identifier value
A5 OK [READ-WRITE] SELECT completed.
A6 SEARCH UNSEEN ALL
* SEARCH 39
A6 OK SEARCH completed.
A7 SEARCH UNSEEN ALL
* SEARCH 39
A7 OK SEARCH completed.
main INFO emailToSms.EmailReader - 1 unread emails read from inbox.
A8 STORE 39 +FLAGS (\Seen)
* 39 FETCH (FLAGS (\Seen))
A8 OK STORE completed.
A9 FETCH 39 (BODY.PEEK[HEADER])
* 39 FETCH (BODY[HEADER] {851}
MIME-Version: 1.0
Received: from HOST (IP) by HOST
(192.168.1.53) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 19 Jan
2017 17:06:26 +0500
To: hafiz <hafiz#bla.bla>
Message-ID: <hassan.B69E3DD110000159000004A73F57FEE3.1484827604448.cisco-ccp#bla.bla>
In-Reply-To: <CF72F945A1ED2E438A53A11DA9415F65A0E981#Expert.bla.bla>
References: <CF72F945A1ED2E438A53A11DA9415F65A0E981#Expert.bla.bla>
Subject: Re: 1122+50
Content-Type: multipart/mixed;
boundary="----=_Part_127_14151461.1484827604583"
From: <testing2#bla.bla>
Return-Path: testing2#bla.bla
Date: Thu, 19 Jan 2017 17:06:26 +0500
X-MS-Exchange-Organization-AuthSource: Expert.bla.bla
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 06
X-Originating-IP: [IP]
)
A9 OK FETCH completed.
A10 FETCH 39 (ENVELOPE INTERNALDATE RFC822.SIZE)
* 39 FETCH (ENVELOPE ("Thu, 19 Jan 2017 17:06:26 +0500" "Re: 1122+50" ((NIL NIL "testing2" "bla.bla")) NIL NIL (("hafiz" NIL "hafiz" "bla.bla")) NIL NIL "<CF72F945A1ED2E438A53A11DA9415F65A0E981#Expert.bla.bla>" "<hassan.B69E3DD110000159000004A73F57FEE3.1484827604448.cisco-ccp#bla.bla>") INTERNALDATE "19-Jan-2017 17:06:26 +0500" RFC822.SIZE 1250)
A10 OK FETCH completed.
A11 FETCH 39 (BODYSTRUCTURE)
* 39 FETCH (BODYSTRUCTURE ("multipart" "mixed" ("boundary" "----=_Part_127_14151461.1484827604583") NIL NIL 7BIT 0 NIL NIL NIL NIL))
A11 OK FETCH completed.
DEBUG IMAP: IMAPProtocol noop
A12 NOOP
A12 OK NOOP completed.
This is a bug in Microsoft Exchange. Report this bug to Microsoft and upgrade to a newer version or newer service pack if possible in case they've already fixed it.
Exchange is returning the BODYSTRUCTURE information for the message as if it were a single part message when in fact it is a multipart message. This is a violation of the IMAP protocol spec.
You can use the workaround in the JavaMail FAQ.
Also, you might want to upgrade to a newer version of JavaMail - 1.4.7 is pretty old, the current version is 1.5.6.
I am doing a tutorial on Mutual SSL authentication using tomcat. I tried google and stackoverflow for the answer but I haven't been lucky so far. I have done the following steps
1. Generated a self signed Certificate using the command as...
keytool -genkey -v -alias tomcat -keyalg RSA -validity 3650 -keystore D:\server.keystore -dname "CN=KeshavServer,OU=AppDev,O=Netambit,L=Noida,S=UP,C=IN" -storepass server123 -keypass server123
Result(DOS Output):
Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 3,650 days for: CN=KeshavServer, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
New certificate (self-signed):
[
[
Version: V3
Subject: CN=KeshavServer, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 169745031109692228700332160907879660712549791227819060217679327134557
60724387920644418620368961814809125561438164385172820012631533276651192871536066
44484789458740611952365817466495640787815691991239210085729312562284526930712191
68874744017392521167643053301439564836240073082909781032758910760996909343586608
99178037089977353808963798076122662239868847716719923568980681140353282369676681
53737103284233931190726847482006084262000642602659963850552605206369455374224663
42718874198088754429094645464054866254482989193982685337964154043630072713972109
68332098433075932439269617793403644275259520886009675985568022246951
public exponent: 65537
Validity: [From: Mon Aug 12 12:16:13 IST 2013,
To: Thu Aug 10 12:16:13 IST 2023]
Issuer: CN=KeshavServer, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
SerialNumber: [ 713ab315]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D6 0E 1F 23 B2 11 92 D2 19 7B C9 AA 19 EF 82 EB ...#............
0010: A6 0C 35 57 ..5W
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 4C 36 84 CD FE 2C 11 4B 88 C1 AE 3A 7A 6A A1 C4 L6...,.K...:zj..
0010: 2C 6E F5 73 33 64 57 06 04 7F AC 1B D6 CA BF E0 ,n.s3dW.........
0020: D2 88 09 A9 B8 4D 70 EE 73 6E 02 45 33 83 42 1E .....Mp.sn.E3.B.
0030: C4 8E 67 F3 51 D7 9C 53 08 CD C7 EA 4B BC 27 0D ..g.Q..S....K.'.
0040: 17 36 9B 12 4A F7 F7 23 0E C2 51 0A 18 06 B5 80 .6..J..#..Q.....
0050: 1C 44 17 0D 99 14 6E 27 40 30 56 DF 31 D9 CC 15 .D....n'#0V.1...
0060: 46 7C 72 C2 54 CE 2E 2B 41 94 19 54 9B 3A F7 85 F.r.T..+A..T.:..
0070: 96 CE 5F 80 C5 A5 02 AE 09 17 A5 C3 E4 A6 BB 63 .._............c
0080: A3 EF 99 4F BC A4 FF 4F 2B BD 46 E5 BE 57 C7 BD ...O...O+.F..W..
0090: 85 54 F9 B1 5F 01 18 07 9F DD 02 99 91 B3 35 FB .T.._.........5.
00A0: 62 74 2A 0A 37 8A 9B 0D E8 BF B4 24 CE 24 12 8A bt*.7......$.$..
00B0: 22 68 39 90 BD 02 24 A4 E9 9B 52 E1 AA 76 1D 16 "h9...$...R..v..
00C0: 91 2A 60 49 D3 F6 91 0A 01 E4 98 1B BB EB B7 E5 .*`I............
00D0: E3 DF 39 B8 73 02 C3 1D EA 95 D1 95 A7 27 53 FC ..9.s........'S.
00E0: 28 2B 21 50 90 BF 48 9A 25 92 28 D8 EC FE 82 60 (+!P..H.%.(....`
00F0: B9 21 28 B3 1A 37 B6 79 17 8B FF 4C 0B C1 6D 0C .!(..7.y...L..m.
]
[Storing D:\server.keystore]
2. Generated the developer key by using the command as...
keytool -genkey -v -alias developerKey -keyalg RSA -storetype PKCS12 -keystore dev.p12 -dname "CN=KeshavClient,OU=AppDev,O=Netambit,L=Noida,S=UP,C=IN" -storepass dev123 -keypass dev123
Result(DOS Output):
Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) wi
th a validity of 90 days
for: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
New certificate (self-signed):
[
[
Version: V3
Subject: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 257861330490904259854513552509935970316490717846991127699603148980652
01114722960469328519589253139525292368465436006354129813882061510118729695295380
60706390500779076802188937858019079525575493711793923541823056735274180328061957
20693618061100873813154701306998418961615717804323475393466678818363454317730604
32071710089666113885067366725913386597296681138020057906688646996872449490785655
01898351843152376966821908896570275550705585694195185294854938453556896208850780
54361881798687601045808741784626686357148783050499722574071065943861302398542177
91929018282855348848062666985932392623629290470810910913665654471519
public exponent: 65537
Validity: [From: Mon Aug 12 12:16:26 IST 2013,
To: Sun Nov 10 12:16:26 IST 2013]
Issuer: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
SerialNumber: [ 503c03cf]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AD 4A E3 0E 3D E9 DB B0 8E DF 8F 66 34 28 AE AF .J..=......f4(..
0010: 34 63 F2 4C 4c.L
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 91 79 CF CC 0F FD CA BB 2A 60 5E 87 8F 2F 6D B6 .y......*`^../m.
0010: DD 71 05 6A B1 21 DB B0 B0 0F D7 3E 7A DB 12 84 .q.j.!.....>z...
0020: 3A C0 63 1B C1 FE FD C5 60 27 E3 2E 14 A0 38 2C :.c.....`'....8,
0030: EE 82 8C 6E 13 05 8A BC 24 2F A1 4F 5C 25 24 10 ...n....$/.O\%$.
0040: EC 5A D1 E3 23 AC 51 BA D4 33 6C AF AF A2 68 2F .Z..#.Q..3l...h/
0050: 29 4F 33 F9 0A 56 C1 83 0C 07 30 14 40 A2 CF 17 )O3..V....0.#...
0060: B1 A1 18 AD 51 76 EA 8E D6 6E 50 4E 7A 7C F5 89 ....Qv...nPNz...
0070: B1 73 F4 05 D2 E9 1B 94 48 2F 65 30 33 F4 1B 28 .s......H/e03..(
0080: AA 36 4C 11 52 C5 2A 9D 4A 11 6D FA 9B C6 09 37 .6L.R.*.J.m....7
0090: A1 CC AC A3 67 B1 60 E6 65 F1 0C 98 0E 5E C0 89 ....g.`.e....^..
00A0: BD 54 98 81 51 DB 6C 53 A5 8C AD 05 57 60 46 20 .T..Q.lS....W`F
00B0: 5E 60 74 58 F8 88 2A 46 F6 F5 5A D3 20 FC 9E FA ^`tX..*F..Z. ...
00C0: 8D 14 A8 72 99 F5 FF 9E 0B 5B F9 68 77 30 75 93 ...r.....[.hw0u.
00D0: 3E 7A 16 38 55 11 30 D6 A1 39 97 97 DB 86 B8 9E >z.8U.0..9......
00E0: 3F 08 84 93 A3 A7 E0 4F 6D 07 A2 E6 F9 09 E8 3B ?......Om......;
00F0: 6C 86 F2 26 F6 20 04 D9 92 66 DC 3B 69 FA 75 30 l..&. ...f.;i.u0
]
[Storing dev.p12]
3 Exported and saved the certificate in dev.cer
keytool -export -alias developerKey -keystore dev.p12 -storetype PKCS12 -storepass dev123 -rfc -file dev.cer
Result(DOS Output):
Certificate stored in file <dev.cer>
4.Imported dev.cer in the keystore as using the command as... and selected y
keytool -import -v -file dev.cer -keystore tomcat.keystore -storepass server123
Result(DOS Output):
Owner: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
Issuer: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
Serial number: 503c03cf
Valid from: Mon Aug 12 12:16:26 IST 2013 until: Sun Nov 10 12:16:26 IST 2013
Certificate fingerprints:
MD5: 7A:CE:AD:78:31:12:89:3A:20:94:01:63:5C:E6:6D:48
SHA1: 4C:E3:4A:CF:93:EF:69:46:AD:01:B1:AC:22:F4:E6:91:B5:62:D1:C3
SHA256: D1:E6:20:9C:A7:3C:82:46:7A:2A:E6:61:1E:30:E3:F0:B9:E6:F0:03:DA:
19:87:B4:6F:F2:B1:BE:D3:89:A8:2B
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AD 4A E3 0E 3D E9 DB B0 8E DF 8F 66 34 28 AE AF .J..=......f4(..
0010: 34 63 F2 4C 4c.L
]
]
Trust this certificate? [no]: y
Certificate was added to keystore
[Storing tomcat.keystore]
5.Added the connecter entry to server.xml as...
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="D:/server.keystore" keystorePass="server123"
truststoreFile="D:/server.keystore" truststorePass="server123"
clientAuth="true" sslProtocol="TLS" />
6. Started Tomcat, firefox and on Tools->Options->Advanced->View Certificates->Your Certificate->import, imported the dev.p12 file
Result: asked me for the password which I entered as dev123 then i hit next, next till finish
Final Result on opening https://localhost:8443/CertificatePOC/
Secure Connection Failed
An error occurred during a connection to localhost:8443.
SSL peer cannot verify your certificate.
(Error code: ssl_error_bad_cert_alert)
If in the server.xml I change the attribute clientAuth to false then the web page opens correctly.
Any help will be appreciated
I am using tomcat7 with eclipse indigo OS windows 7
If any more details/screenshot is required I will happily provide
The ssl_error_bad_cert_alert error in this case means the server doesn't trust your self-signed cert. One way to solve this is to generate certs and CSR's, and then sign them with a local development CA. Then you just add your dev CA to the JVM truststore. It is slightly more setup, but is more flexible (e.g., you can create signed certs for a whole development team, test revocation via OCSP/CRL, etc).
These steps are copied from my history and probably require changes:
Create a local dev CA
openssl genrsa -out ca.key -aes256 -passout pass:changeit 4096
openssl req -new -x509 -key ca.key -config openssl.conf -days 3560 -sha256 -out ca.pem -passin pass:changeit
openssl rsa -in ca.key -out ca.key -passin pass:changeit
Generate client and server keystores with a keypair in each
keytool -genkey -keyalg RSA -alias client -keystore client.jks -storepass changeit -validity 1000
keytool -genkey -keyalg RSA -alias tomcat -keystore ~/.keystore -storepass changeit -validity 1000
Generate client and server cert signing requests (csr) based on above keystore keypairs
keytool -certreq -v -alias client -keystore client.jks -storepass changeit -file client.csr
keytool -certreq -v -alias tomcat -keystore ~/.keystore -storepass changeit -file tomcat.csr
Sign the requests (create certs) for client/server csr's
openssl x509 -req -CA ca.pem -CAkey ca.key -in client.csr -out client.cer -days 1000 -CAcreateserial
openssl x509 -req -CA ca.pem -CAkey ca.key -in tomcat.csr -out tomcat.cer -days 1000 -CAcreateserial
Import the CA cert into client/server keystores (possibly not necessary, since it must be added to truststore anyway)
keytool -import -keystore client.jks -file ca.pem -alias rootca
keytool -import -keystore ~/.keystore -file ca.pem -alias rootca
Import the client and server certs into their respective keystores
keytool -import -keystore client.jks -file client.cer -alias client
keytool -import -keystore ~/.keystore -file tomcat.cer -alias tomcat
Convert the client cert to a p12 (PKCS12) so it can be imported into firefox or wherever
keytool -importkeystore -srckeystore client.jks -destkeystore client.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass changeit -deststorepass changeit -srcalias client -destalias client -srckeypass changeit -destkeypass changeit -noprompt
Import the CA cert into the JVM truststore
sudo keytool -import -trustcacerts -alias suter-dev-ca -file ca.pem -keystore /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/lib/security/cacerts
Optionally, import the CA cert into your browser.
Your post was hard to read because of the formatting. Hope this helps.
Sources: http://shib.kuleuven.be/docs/ssl_commands.shtml, https://docs.oracle.com/cd/E19509-01/820-3503/ggezy/index.html
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I've encountered a serious bug in OpenSSL 1.0.1 on Ubuntu 12.04:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666051 <- dated Oct 3 2012!
The gist of it is that I'm able to connect to some servers but not others. Connecting to google works:
openssl s_client -connect mail.google.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
...
Protocol : TLSv1.1
Cipher : ECDHE-RSA-RC4-SHA
Session-ID: 94DB1AC8531115C501434B16A5E9B735722768581778E4FEA4D9B19988551397
Session-ID-ctx:
Master-Key: 8694BF510CD7568CBAB39ECFD32D115C511529871F3030B67A4F7AEAF957D714D3E94E4CE6117F686C975EFF21FB8708
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - fb 52 d6 d3 3c a8 75 e1-1f 1d f6 23 ab ce 55 44 .R..<.u....#..UD
0010 - 27 bf ad c4 7a 0d 83 c8-48 59 48 4b 39 bb 3c c7 '...z...HYHK9.<.
0020 - 01 1e ad b3 13 de 65 d4-e8 ea e4 35 89 83 55 8e ......e....5..U.
0030 - e4 d5 9f 60 58 51 33 9b-83 34 b9 35 3d 46 cb a3 ...`XQ3..4.5=F..
0040 - 35 7b 48 5d 7b 86 5c d5-a1 14 9d 8c 3e 93 eb fb 5{H]{.\.....>...
0050 - ac 78 75 72 9b d2 bc 67-f2 fa 5b 75 80 a6 31 d8 .xur...g..[u..1.
0060 - 71 15 85 7f 55 4d dc fb-b0 b5 33 db 6d 36 8c c6 q...UM....3.m6..
0070 - e8 f9 54 7a 29 69 87 2c-dd f3 c5 cf 26 55 6f 6e ..Tz)i.,....&Uon
0080 - 45 73 7a 1d e4 b3 be b2-92 3f 0b ed c4 1c a5 24 Esz......?.....$
0090 - 3c f0 ca a5 <...
Start Time: 1354063165
Timeout : 300 (sec)
Verify return code: 0 (ok)
But connecting to facebook doesn't:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt -cipher SRP-AES-256-CBC-SHA
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0xddd2c0 [0xddd340] (64 bytes => 64 (0x40))
0000 - 16 03 01 00 3b 01 00 00-37 03 02 50 b5 5d 75 42 ....;...7..P.]uB
0010 - c2 78 55 49 b5 2e de 4f-00 a6 a8 d5 cf 10 92 44 .xUI...O.......D
0020 - 28 62 34 d6 61 5e 88 c3-68 8b 96 00 00 04 c0 20 (b4.a^..h......
0030 - 00 ff 02 01 00 00 09 00-23 00 00 00 0f 00 01 01 ........#.......
>>> TLS 1.1 [length 003b]
01 00 00 37 03 02 50 b5 5d 75 42 c2 78 55 49 b5
2e de 4f 00 a6 a8 d5 cf 10 92 44 28 62 34 d6 61
5e 88 c3 68 8b 96 00 00 04 c0 20 00 ff 02 01 00
00 09 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
read from 0xddd2c0 [0xde28a0] (7 bytes => 7 (0x7))
0000 - 15 03 02 00 02 02 28 ......(
SSL3 alert read:fatal:handshake failure
<<< TLS 1.1 [length 0002]
02 28
SSL_connect:error in unknown state
140581179446944:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 64 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
The facebook connection either hangs after the client sends its hello buffer and never receives the server hello response, or returns with an error code if I pass in a cipher it recognizes. This happens with both -tls1 and -ssl3. I've tried every parameter to openssl I can think of.
apt-cache showpkg openssl
...
Provides:
1.0.1-4ubuntu5.5 -
1.0.1-4ubuntu5.3 -
1.0.1-4ubuntu3 -
I've also tried every parameter I can think of to curl but with no success, because it uses openssl under the hood.
I'm concerned that Ubuntu can't establish secure connections (an astounding statement, I realize). After two solid days of beating my head against this problem, I'm basically praying at this point that someone knows a workaround. I'm considering a downgrade to OpenSSL 1.0.0 or using libcurl4-dev with gnutls-dev instead. Both solutions leave a rotten taste in my mouth. Thanks in advance for any help you can provide.
P.S. all of this work is so that my server can interface with external https REST APIs. I consider this a fundamental requirement in any webserver today, no excuses.
UPDATE: Here is my output without passing a cipher. It doesn't matter if I pass -CAfile or not either:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x14ed1a0 [0x1515bf0] (226 bytes => 226 (0xE2))
0000 - 16 03 01 00 dd 01 00 00-d9 03 02 50 b6 39 78 6a ...........P.9xj
0010 - 24 95 8e dc 62 19 37 4b-ab 77 b8 66 cd 48 ba a2 $...b.7K.w.f.H..
0020 - a1 2a f8 1d f8 c9 5d fb-9d db 84 00 00 66 c0 14 .*....]......f..
0030 - c0 0a c0 22 c0 21 00 39-00 38 00 88 00 87 c0 0f ...".!.9.8......
0040 - c0 05 00 35 00 84 c0 12-c0 08 c0 1c c0 1b 00 16 ...5............
0050 - 00 13 c0 0d c0 03 00 0a-c0 13 c0 09 c0 1f c0 1e ................
0060 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 0e c0 04 .3.2.....E.D....
0070 - 00 2f 00 96 00 41 c0 11-c0 07 c0 0c c0 02 00 05 ./...A..........
0080 - 00 04 00 15 00 12 00 09-00 14 00 11 00 08 00 06 ................
0090 - 00 03 00 ff 02 01 00 00-49 00 0b 00 04 03 00 01 ........I.......
00a0 - 02 00 0a 00 34 00 32 00-0e 00 0d 00 19 00 0b 00 ....4.2.........
00b0 - 0c 00 18 00 09 00 0a 00-16 00 17 00 08 00 06 00 ................
00c0 - 07 00 14 00 15 00 04 00-05 00 12 00 13 00 01 00 ................
00d0 - 02 00 03 00 0f 00 10 00-11 00 23 00 00 00 0f 00 ..........#.....
00e0 - 01 01 ..
>>> TLS 1.1 [length 00dd]
01 00 00 d9 03 02 50 b6 39 78 6a 24 95 8e dc 62
19 37 4b ab 77 b8 66 cd 48 ba a2 a1 2a f8 1d f8
c9 5d fb 9d db 84 00 00 66 c0 14 c0 0a c0 22 c0
21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02
01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34
00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09
00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15
00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f
00 10 00 11 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
Why are you passing -cipher SRP-AES-256-CBC-SHA when connecting to graph.facebook.com? Facebook certainly doesn't support SRP: http://srp.stanford.edu/.
Does it work if you don't pass that?
Also, can you give the IP address that you're getting? With 69.171.229.17, I can reproduce that exact ClientHello (modulo the nonce and with RC4-SHA are the only cipher save the SCSV) and I get a successful handshake.
Lastly, have you tried doing over an SSH tunnel to somewhere else? Sadly, when deploying TLS features in Chrome we have repeatedly found networking hardware that breaks TLS connections. (Although I can't think of a case where -ssl3 wouldn't fix it unless the hardware was actively trying to censor connections.)
Setting the MTU on my Ubuntu box from 1500 to 1496 (due to one of our firewalls being set too low) allows me to receive a response from the server without having to reboot (be sure to call ifconfig first and write down your original MTU which should be 1500):
sudo ifconfig eth0 mtu 1496
I discovered my MTU by pinging with successively larger buffers (add 28 bytes for UDP header):
Fails for 1472 + 28 = 1500:
ping -s 1472 facebook.com
PING facebook.com (66.220.158.16) 1472(1500) bytes of data.
...
Works for 1468 + 28 = 1496:
ping -s 1468 facebook.com
PING facebook.com (69.171.229.16) 1468(1496) bytes of data.
1476 bytes from www-slb-ecmp-06-prn1.facebook.com (69.171.229.16): icmp_req=1 ttl=242 time=30.0 ms
...
With 1496 I'm now able to curl to facebook.com:
curl -v https://facebook.com
* About to connect() to facebook.com port 443 (#0)
* Trying 66.220.152.16... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
* subject: C=US; ST=California; L=Palo Alto; O=Facebook, Inc.; CN=www.facebook.com
* start date: 2012-06-21 00:00:00 GMT
* expire date: 2013-12-31 23:59:59 GMT
* subjectAltName: facebook.com matched
* issuer: O=VeriSign Trust Network; OU=VeriSign, Inc.; OU=VeriSign International Server CA - Class 3; OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: facebook.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://www.facebook.com/
< Content-Type: text/html; charset=utf-8
< X-FB-Debug: 3vAg1O5OG9hB/EWC+gk1Kl3WLJRGmlQDaEodirWb+i0=
< Date: Wed, 28 Nov 2012 19:52:25 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host facebook.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
I personally think that MTU should have absolutely nothing to do with what the user sees at the stream level with TCP so I hope the OpenSSL folks fix this. I also wish that someone would invent an automagic bug submitter for bugs that are profoundly widespread and time-sucking.
Any code using Mail::IMAPClient is having this error. To verify I have used the below example from the topic: How do I authenticate into Gmail using Perl?
#!/usr/bin/env perl -w
use strict; use warnings;
use Mail::IMAPClient;
# Connect to IMAP server
my $client = Mail::IMAPClient->new(
Server => 'imap.gmail.com',
User => $user,
Password => $pass,
Port => 993,
Ssl => 1,
)
or die "Cannot connect through IMAPClient: $#";
# List folders on remote server (see if all is ok)
if ( $client->IsAuthenticated() ) {
print "Folders:\n";
print "- ", $_, "\n" for #{ $client->folders() };
};
# Say so long
$client->logout();
Now, I have gone through questions similar to this but have never seen such a strange error like "Network Unreachable". There is no actual network problem, ping works fine. I have IO::Socket::SSL, Net::SSLeay installed.
$ echo -n | openssl s_client -connect imap.gmail.com:993
CONNECTED(00000003)
depth=2 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = imap.gmail.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
i:/C=US/O=Google Inc/CN=Google Internet Authority
1 s:/C=US/O=Google Inc/CN=Google Internet Authority
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDWzCCAsSgAwIBAgIKFefcnAADAAA7OzANBgkqhkiG9w0BAQUFADBGMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu
dGVybmV0IEF1dGhvcml0eTAeFw0xMTExMTgwMjAxMjRaFw0xMjExMTgwMjExMjRa
MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N
b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw5pbWFw
LmdtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAmv2pvvhXOyOA
Uq053VLGMAErgk2NcDzxWNB5PWwXHzkcFuZOa0q1YUlff6LaJurq5UctkOO+3mt1
L+/wcZiEzxTdfOclyJcY/qBsjz8qgG+4Kx3/dVlTYz2geUyxvGNibNQfuXpoI1M5
iUQ/FSaFIazXZ01tpb+mgCOtwzENMk8CAwEAAaOCASwwggEoMB0GA1UdDgQWBBRd
l+HsAH5IwfNuc25lLuryGEaXwzAfBgNVHSMEGDAWgBS/wDDr9UMRPme6npH7/Gra
42sSJDBbBgNVHR8EVDBSMFCgTqBMhkpodHRwOi8vd3d3LmdzdGF0aWMuY29tL0dv
b2dsZUludGVybmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9yaXR5LmNy
bDBmBggrBgEFBQcBAQRaMFgwVgYIKwYBBQUHMAKGSmh0dHA6Ly93d3cuZ3N0YXRp
Yy5jb20vR29vZ2xlSW50ZXJuZXRBdXRob3JpdHkvR29vZ2xlSW50ZXJuZXRBdXRo
b3JpdHkuY3J0MCEGCSsGAQQBgjcUAgQUHhIAVwBlAGIAUwBlAHIAdgBlAHIwDQYJ
KoZIhvcNAQEFBQADgYEAa6JYZBInXMfojI4bXLusfDlzZ6gnGtHxOO8hUZbDAwcL
t2/4uDDj8sroVrTWXMqURzk1lCsXlGPFhaKdnsMrmcgC01THAKPFrrQnQc/BM5H/
kr5ZAyJKHyu4dNnL3NNjig+22fp8slaLo25C95YQT5LiBL2qnAzLs4nWBzqih74=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority
---
No client certificate CA names sent
---
SSL handshake has read 1850 bytes and written 299 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: D98F3659858A0F39D32F1B5D96F756DE6E093E849A6AE0066C391BE2881B9A69
Session-ID-ctx:
Master-Key: 8D4BE4DFEB7F3218A501FE9240E0B51CC987B99EE0DDBA5EC13E9A10137B63508692DA684DA25E8B2839906F0F7ADDD5
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 6e 26 64 bb c3 97 30 9c-32 6f c5 38 d6 db 23 54 n&d...0.2o.8..#T
0010 - 65 43 b8 01 4e 46 5b b3-81 7e 26 6b 3a 36 2b 62 eC..NF[..~&k:6+b
0020 - 03 96 44 de 3d b0 81 be-18 b0 14 a1 09 99 28 73 ..D.=.........(s
0030 - 2d 5a 87 6c b9 26 64 94-af f2 5e f1 f4 10 ba ff -Z.l.&d...^.....
0040 - 68 a0 6a 31 d6 10 f8 88-61 63 5a 58 0b 1d d0 98 h.j1....acZX....
0050 - 81 ed f7 45 11 1d 4a 22-23 2f 44 0c 62 b4 18 e9 ...E..J"#/D.b...
0060 - e7 4a 57 10 f1 3c a0 d6-ee 46 98 5d df e9 a5 52 .JW..<...F.]...R
0070 - a6 75 da a6 25 89 87 f0-b0 ec 60 0d c0 19 0e 6f .u..%.....`....o
0080 - 23 53 a2 f2 18 e8 8d 51-28 e7 f2 d3 52 8a 02 f4 #S.....Q(...R...
0090 - 32 aa 82 db 2...
Start Time: 1342180574
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
this could be an ipv6 error. Gmail enabled ipv6 access recently. Can you try putting this before the 'use Mail::IMAPClient;' line:
use IO::Socket::SSL 'inet4';
Out of curiosity, how much data is actually sent when establishing a connection to a port (using Java sockets). Is it the size of a Socket object? SocketConnection object?
Your understanding of TCP network connections seems to conflate them with electrical circuits. (Understandable, given your background.)
From a physical standpoint, there's no such thing as a connection, only data packets. Through the TCP protocol, two devices agree to establish a logical (that is, software) connection. A connection is established by a client first sending data to the remote host (SYN), the server sending data back to the client (SYN-ACK), and the client sending a final acknowledgement (ACK). All of this negotation necessarily consumes bandwidth, and when you terminate a connection, you must negotiate a completely new connection to begin sending data again.
For example, I'll connect from my machine to a local web server, 192.168.1.2:80.
First, my machine sends a TCP SYN. This sends 66 bytes over the wire: (headers deliniated with |)
0000 00 24 8c a9 4c b4 00 1e 68 66 20 79 08 00|45 00 .$..L... hf y..E.
0010 00 34 53 98 40 00 80 06 00 00 c0 a8 01 0b c0 a8 .4S.#... ........
0020 01 02|36 0a 00 50 09 ef 3a a7 00 00 00 00 80 02 ..6..P.. :.......
0030 20 00 50 c8 00 00 02 04 05 b4 01 03 03 02 01 01 .P..... ........
0040 04 02 ..
The first 14 bytes are the Ethernet frame, specifying that this packet's destination MAC address. This will typically be an upstream router, but in this case, the server happens to be on the same switch, so it's the machine's MAC address, 00:24:8c:a9:4c:b4. The source (my) MAC follows, along with the payload type (IP, 0x0800). The next 20 bytes are the IPv4 headers, followed by 32 bytes of TCP headers.
The server responds with a 62-byte SYN-ACK:
0000 00 1e 68 66 20 79 00 24 8c a9 4c b4 08 00|45 00 ..hf y.$ ..L...E.
0010 00 30 69 b9 40 00 80 06 0d b1 c0 a8 01 02 c0 a8 .0i.#... ........
0020 01 0b|00 50 36 0a d3 ae 9a 73 09 ef 3a a8 70 12 ...P6... .s..:.p.
0030 20 00 f6 9d 00 00 02 04 05 b4 01 01 04 02 ....... ......
Again, 14 bytes of Ethernet headers, 20 bytes of IP headers, and 28 bytes of TCP headers. I send an ACK:
0000 00 24 8c a9 4c b4 00 1e 68 66 20 79 08 00|45 00 .$..L... hf y..E.
0010 00 28 53 9a 40 00 80 06 00 00 c0 a8 01 0b c0 a8 .(S.#... ........
0020 01 02|36 0a 00 50 09 ef 3a a8 d3 ae 9a 74 50 10 ..6..P.. :....tP.
0030 fa f0 83 78 00 00 ...x..
14 + 20 + 20 = 54 bytes over the wire (this is the smallest possible TCP packet size, by the way – the SYN and SYN-ACK packets were larger because they included options).
This adds up to 182 bytes over the wire to establish a connection; now I can begin sending actual data to the server:
0000 00 24 8c a9 4c b4 00 1e 68 66 20 79 08 00 45|00 .$..L... hf y..E.
0010 01 9d 53 9d 40 00 80 06 00 00 c0 a8 01 0b c0 a8 ..S.#... ........
0020 01 02|36 0a 00 50 09 ef 3a a8 d3 ae 9a 74 50 18 ..6..P.. :....tP.
0030 fa f0 84 ed 00 00|47 45 54 20 2f 20 48 54 54 50 ......GE T / HTTP
0040 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 66 73 0d 0a /1.1..Ho st: fs..
...
14 Ethernet + 20 IP + 20 TCP + data, in this case HTTP.
So we can see that it costs ~182 bytes to establish a TCP connection, and an additional 162-216 bytes to terminate a TCP connection (depending on whether a 4-way FIN ACK FIN ACK or more common 3-way FIN FIN-ACK ACK termination handshake is used), adding up to nearly 400 bytes to "pulse" a connection by disconnecting and reconnecting.
Compared to the 55 bytes you'd use to send one byte of data over an already established connection, this is obviously wasteful.
What you want to do is establish one connection and then send data as-needed. If you're really bandwidth constrained, you could use UDP (which requires no handshaking at all and has an overhead of only 14 Ethernet + 20 IP + 8 UDP bytes per packet), but then you face the problem of using an unreliable transport, and having to handle lost packets on your own.
The minimum size of a TCP packet is 40 bytes. It takes three exchanged packets to create a connection, two from the client and one from the server, and four more to close it, two in each direction. The last packet in a connect exchange can also contain data, as can the first in the close exchange in each direction, which can amortize it a bit, as can combining the outgoing FIN and ACK as per #josh3736's comment below.