[arch-general] fetchmail/exim line length messages
My email processing system has suddenly started throwing error messages on line lengths recently: fetchmail: SMTP error: 550 maximum allowed line length is 998 octets, got 1047 fetchmail: mail from MAILER-DAEMON@<my email server> bounced to bounces+11930396-d424-darose=darose.net@sendgrid.meetup.com fetchmail: SMTP listener refused delivery The messages seem to be generated by exim. (I have fetchmail configured to pull my emails in from my ISP's mail drop, and deliver them to my exim daemon.) I've received a number of these in recent days. The first one occurred on Nov. 20 at about 9.30am (EST). I'm not sure what, if anything, has changed recently to start causing this. Anyone else run into this recently, or know what the issue might be? Thanks, DR
On 11/26/21 12:34, David Rosenstrauch via arch-general wrote:
fetchmail: SMTP error: 550 maximum allowed line length is 998 octets, got 1047 Does this 1️⃣ rather old note help at all?
Not sure it does as error you quote seems to be from fetchmail suggesting the problem may lie with the mail server at other end if it's also running exim. 1️⃣ https://blog.dhampir.no/content/exim4-line-length-in-debian-stretch-mail-del... gene
On 11/26/21 12:59, Genes Lists via arch-general wrote:
Not sure it does as error you quote seems to be from fetchmail suggesting the problem may lie with the mail server at other end if it's also running exim. Or perhaps it could be fetchmail speaking to your exim.
gene
Hi DR,
fetchmail: SMTP error: 550 maximum allowed line length is 998 octets, got 1047
That's a very long-standing rule on SMTP.
bounces+11930396-d424-darose=darose.net@sendgrid.meetup.com ... I'm not sure what, if anything, has changed recently to start causing this.
Have they something in common, e.g. all being bounced to sendgrid.meetup.com which indicates it's a problem with what the remote side is feeding fetchmail? Also, fetchmail(1)'s -v option will show the dialogue it has with the remote and local servers; this will confirm it's being fed invalid SMTP by the remote one. -- Cheers, Ralph.
On 11/26/21 2:06 PM, Ralph Corderoy via arch-general wrote:
I'm not sure what, if anything, has changed recently to start causing this.
Have they something in common, e.g. all being bounced to sendgrid.meetup.com which indicates it's a problem with what the remote side is feeding fetchmail?
I suspected that as well, but the answer seems to be no. Several were from meetup, a couple from groups.io, one from a company, etc. Seems like something changed somewhere but I can't figure out what. In the mean time, I commented out that "998 octets" check in my exim.conf. I realize that emails that have lines larger than that are violating spec, but there's no real harm in allowing them in - since I'm already using good spam filtering, and especially if I know that I'm losing legit emails because of this. Thanks, DR
On 11/26/21 14:06, Ralph Corderoy via arch-general wrote:
That's a very long-standing rule on SMTP.
Yep Ralph is correct - its a violation of section 2.1.1. of RFC 5322 [a] [a] https://www.rfc-editor.org/rfc/rfc5322#page-7
Hi DR,
I realize that emails that have lines larger than that are violating spec, but there's no real harm in allowing them in - since I'm already using good spam filtering, and especially if I know that I'm losing legit emails because of this.
You're encouraging their spread. Take a stand! Bounce! :-) You could look at what Exim deposits to see what's on the overlong lines. That may give a clue why it has started. Or it might show some upstream corruption problem is deleting the odd linefeed thus joining two lines together. -- Cheers, Ralph.
participants (3)
-
David Rosenstrauch
-
Genes Lists
-
Ralph Corderoy