[mailop] Air Canada sending from Adobe space failing to send to server with Let's Encrypt SSL certificate

[Alan Hodgson via mailop]

This may be from Marketo or something? Whois shows Adobe with an
ab...@marketo.com contact address.

Oct 25 10:10:50 hyperion postfix/smtpd[1588023]: connect from
r117.mail.aircanada.com[172.82.216.117]
Oct 25 10:10:51 hyperion postfix/smtpd[1588023]: SSL_accept error from
r117.mail.aircanada.com[172.82.216.117]: -1
Oct 25 10:10:51 hyperion postfix/smtpd[1588023]: warning: TLS library problem:
error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate
expired:ssl/record/rec_layer_s3.c:1543:SSL alert number 45:
Oct 25 10:10:51 hyperion postfix/smtpd[1588023]: lost connection after
STARTTLS from r117.mail.aircanada.com[172.82.216.117]
Oct 25 10:10:51 hyperion postfix/smtpd[1588023]: disconnect from
r117.mail.aircanada.com[172.82.216.117] ehlo=1 starttls=0/1 commands=1/2



---

This is almost certainly caused by the expiration of the DST Root CA X3
certificate:
  https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

If anyone has a contact at this sender please suggest that they install a
trust certificate for Let's Encrypt's current root certificate (and maybe any
other security updates that they've missed since 2017).

Thanks.


signature.asc
Description: This is a digitally signed message part
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] .eml Attachments and the 1000-character SMTP Limit

[Simon Arlott via mailop]

On 12/10/2021 06:19, John via mailop wrote:
> The answer is yes, it's not good practice to block messages containing long 
> lines in emails. That will likely cause problems at either the sender or 
> recipient. Senders may receive non-delivery notifications, recipients may 
> miss mails.
> 
> RFC5322 (2008) advises to handle long lines at least up to 998 characters. 
> However, there is no pressing technical need to filter. The 1000 character 
> rule appeared in rfc821 (1982), probably because it was believed that it was 
> a good idea to limit the format to the capacity of hardware and software at 
> the time. We've moved on, systems have sufficient memory and mail readers 
> have been smart enough to wrap long lines for a long time already.

Exim has a fixed limit of 16384 bytes per line when doing DKIM operations
and version 4.95 now has a default limit of 998 bytes on the (outgoing)
smtp transport. I'd like to fix the DKIM code but it's currently easier
to just recompile with significantly increased limits.

I think Debian still have a default limit of 998 bytes for Exim on
incoming email.

-- 
Simon Arlott
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] WhatCounts/Costco silliness

[Steven Champeon via mailop]

on Sun, Oct 24, 2021 at 09:33:15PM -0400, John R Levine via mailop wrote:
> >>>List-Unsubscribe: 
> >>>List-Unsubscribe-Post: List-Unsubscribe=One-Click
> >>>
> >>>I don't know which fools to blame; The client Costco, or their ESP
> >>>WhatCounts.  Perhaps both.
> >>
> >>Definitely both.
> >
> >I don't work for or with WhatCounts, but I know who does, so I nudged them.
> 
> Considering that every message sent without working unsubscribe is a
> CAN SPAM violation, I'd think some tooling to check that the link at
> least connects to a server would be in order.

example.com seems to be a favorite of folks needing a placeholder for a PTR:

103.193.36.20:dns2.example.com.
104.248.162.121:109.248.10.0:subnet.example.com.
107.181.187.148:vds4274.example.com.
109.248.10.10:free.example.com.
109.248.10.16:free.example.com.
109.248.10.1:gw.example.com.
109.248.10.255:broadcast.example.com.
109.248.200.124:free.example.com.
109.248.202.101:free.example.com.
146.185.220.10:fgcp.au.example.com.
147.255.227.0:147-255-227-0.w.example.com.
147.78.64.134:korkin.v.d.example.com.
147.78.65.189:xdarker87.example.com.
147.78.65.250:mcdonaldsrestaurant72.example.com.
147.78.66.22:erinbaxtere8.example.com.
154.59.112.203:www.example.com.
185.104.249.100:yuriybiit0.example.com.
185.104.249.241:mail16.example.com.
185.127.24.107:free.example.com.
185.127.24.149:free.example.com.
185.127.24.169:free.example.com.
185.127.25.100:free.example.com.
185.127.25.204:free.example.com.
185.139.69.163:trushinskiys.example.com.
185.139.69.222:ilvalil26.example.com.
185.142.98.138:mgnhost.example.com.
185.17.120.165:ya1.danilovvs.example.com.
185.188.182.186:hasper8367.example.com.
185.242.84.10:gaev7.ilya.s.example.com.
185.246.153.137:katruk.example.com.
185.31.160.143:zakalyor28.example.com.
185.62.57.110:tempbackup.example.com.
185.63.190.142:ddic.sudarev.example.com.
192.83.197.0:82.202.165.178:kakallibi121.example.com.
193.0.178.110:mgnhost.example.com.
193.233.149.198:mgnhost.ru.example.com.
193.9.60.102:dominik1.muratov.example.com.
195.140.144.101:bet5.centr.example.com.
228.0.0.101:103.193.36.10:dns1.example.com.
37.9.33.11:platform-admin58.example.com.
45.87.128.0:sub0.example.com.
5.188.148.10:gcore5.example.com.
5.188.71.100:roberto77.example.com.
5.188.71.32:ovqtitdenis1.example.com.
5.8.24.53:viktor.example.com.
62.173.138.226:bigwashing87.example.com.
62.173.150.114:bigwashing87.051.example.com.
69.48.130.253.colo.example.com.
89.108.104.112:testudo1871891.example.com.
92.223.67.10:mahjong9.example.com.
92.38.135.127:aisles2.webmaster.example.com.
92.38.135.141:m881.8isles.example.com.
92.38.148.107:support108.example.com.

-- 
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/
Internet security and antispam hostname intelligence: http://enemieslist.com/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] WhatCounts/Costco silliness

[Laura Atkins via mailop]

> On 25 Oct 2021, at 02:33, John R Levine via mailop  wrote:
> 
 List-Unsubscribe: 
 List-Unsubscribe-Post: List-Unsubscribe=One-Click
 
 I don't know which fools to blame; The client Costco, or their ESP
 WhatCounts.  Perhaps both.
>>> 
>>> Definitely both.
>> 
>> I don't work for or with WhatCounts, but I know who does, so I nudged them.
> 
> Considering that every message sent without working unsubscribe is a CAN SPAM 
> violation, I'd think some tooling to check that the link at least connects to 
> a server would be in order.

I don’t think a List-Unsub header is sufficient to comply with CAN SPAM. 

Do you have better information from the FTC that suggests it does?

laura 

-- 
Having an Email Crisis?  800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: http://wordtothewise.com/blog  





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Freemail.hu postmaster - I need your help

[Victor Roemgens via mailop]

Hi all,

I'm looking for a postmaster or email deliverability specialist from
Freemail.hu.
Is this professional here in this list as well? Does anyone know?
Looking forward to hearing from you.

Kind regards,

Victor Roemgens
Email Deliverability Specialist
Harlem Next B.V.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] .eml Attachments and the 1000-character SMTP Limit

[Eliot Lear via mailop]

> On 12 Oct 2021, at 07:19, John via mailop  wrote:
> 
> Hello Matt,
> 
> The answer is yes, it's not good practice to block messages containing long 
> lines in emails. That will likely cause problems at either the sender or 
> recipient. Senders may receive non-delivery notifications, recipients may 
> miss mails.
> 
> RFC5322 (2008) advises to handle long lines at least up to 998 characters. 
> However, there is no pressing technical need to filter. The 1000 character 
> rule appeared in rfc821 (1982), probably because it was believed that it was 
> a good idea to limit the format to the capacity of hardware and software at 
> the time. We've moved on, systems have sufficient memory and mail readers 
> have been smart enough to wrap long lines for a long time already.

Indeed.  There were a lot of fixed limitations at the time, and that was at 
least in part due to common use of language constructs such as Pascal’s readln 
which took a fixed limit based on the size of the declared array.  Dynamic 
arrays were not yet a thing, as I recall.  Having written some of that code for 
TOPS-20, I just imagine how badly it would behave in today’s world.

There are still reasons to be a bit concerned if you see lines greater than the 
limit, the biggest of which is if someone is attempting to exercise a parser, 
either yours or someone else’s down the line.  I doubt such an attack would 
succeed today, but who knows?

Eliot


signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop