Hi. Relevantly, I am responsible for various xenproject.org systems,
as part of my employment with Citrix. I had a report recently of a
genuine mail being blocked by exceeding a Received lines limit of 25.
This provked me to look at Exim's default:
+--------------------------------------------------------+
|received_headers_max|Use: main|Type: integer|Default: 30|
+--------------------------------------------------------+
Coincidentally I happened to look at the headers of a mail I sent this
morning to a work distribution list which contains my own work
mailbox.
That message had *17* Received lines. Apparently this kind of thing
is normal nowadays.
Looking at it, I make the following observations:
* In general the complexity of fighting spam means that mail plumbing
is both significantly more complex than in past decades.
* Wioth virtualisation, containerisation, and, so on, hosts are
typically not taking on multiple roles. So tasks which were
previously performed on one host, producing one Received line, now
can produce one per task.
* The increased complexity of mail plumbing means that, sadly, there
are many more things to go wrong; Received lines are one way of
leaving a trail for hapless sysadmins to follow. So non-MTA mail
processing software is probably more likely to add Received lines
than in the past.
Some specific observations:
* With the rapid deployment of DKIM/DMARC/SPF, outbound messages must
often now follow more complex routing than previously. My own
outbound messages from my @xenproject.org address go through three
hosts: my workstation on which I write the mail; the Xen Project
shell account server; and the main Xen Project mail server.
* Every time a message goes through an on-prem Exchange, Exchange
adds 3 Received headers. Every time a message goes through
Exchange Online, that adds 3 headers plus 1 more for a
spamfiltering system. When an organisations is migrating between
Exchange on-prem and Exchange Online, some receipients and
distribution lists may be in one system and one in the other, so a
single organisation's Exchange setup may easily add as many as 7
Received lines.
* Transitions from one mail jurisdiction to another go through a
spamfiltering stage which is often a separate host - sometimes
separate inbound/filtering hosts, and queueing/delivery ones. So
outsourced services typically add *at least* one Received header.
Often filtering like this happens on outbound mail too.
* Many of these numbers need to be multiplied by the number of
aliasing / role address / mailing list steps that a message goes
through.
* Computers are much faster nowadays so mail loops do not need to be
stopped so quickly.
I suggest that the limit should be raised to, let us say, 100.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
as part of my employment with Citrix. I had a report recently of a
genuine mail being blocked by exceeding a Received lines limit of 25.
This provked me to look at Exim's default:
+--------------------------------------------------------+
|received_headers_max|Use: main|Type: integer|Default: 30|
+--------------------------------------------------------+
Coincidentally I happened to look at the headers of a mail I sent this
morning to a work distribution list which contains my own work
mailbox.
That message had *17* Received lines. Apparently this kind of thing
is normal nowadays.
Looking at it, I make the following observations:
* In general the complexity of fighting spam means that mail plumbing
is both significantly more complex than in past decades.
* Wioth virtualisation, containerisation, and, so on, hosts are
typically not taking on multiple roles. So tasks which were
previously performed on one host, producing one Received line, now
can produce one per task.
* The increased complexity of mail plumbing means that, sadly, there
are many more things to go wrong; Received lines are one way of
leaving a trail for hapless sysadmins to follow. So non-MTA mail
processing software is probably more likely to add Received lines
than in the past.
Some specific observations:
* With the rapid deployment of DKIM/DMARC/SPF, outbound messages must
often now follow more complex routing than previously. My own
outbound messages from my @xenproject.org address go through three
hosts: my workstation on which I write the mail; the Xen Project
shell account server; and the main Xen Project mail server.
* Every time a message goes through an on-prem Exchange, Exchange
adds 3 Received headers. Every time a message goes through
Exchange Online, that adds 3 headers plus 1 more for a
spamfiltering system. When an organisations is migrating between
Exchange on-prem and Exchange Online, some receipients and
distribution lists may be in one system and one in the other, so a
single organisation's Exchange setup may easily add as many as 7
Received lines.
* Transitions from one mail jurisdiction to another go through a
spamfiltering stage which is often a separate host - sometimes
separate inbound/filtering hosts, and queueing/delivery ones. So
outsourced services typically add *at least* one Received header.
Often filtering like this happens on outbound mail too.
* Many of these numbers need to be multiplied by the number of
aliasing / role address / mailing list steps that a message goes
through.
* Computers are much faster nowadays so mail loops do not need to be
stopped so quickly.
I suggest that the limit should be raised to, let us say, 100.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##