Re: [exim] Additional line in body when submitting?
Jeremy Harris via Exim-users writes:
> On 31/05/2022 15:39, Kamil Jońca via Exim-users wrote:
>> Andrew C Aitchison via Exim-users writes:
>>> Is this a blank line after every real line or just the last one ?
>> Last one.
>> As I wrote elsewhere postfix did not add this.
> Just tested, and I don't see any extra line. Are you certain
> your "mail" command is directly executing exim? Does your configuration
> have any filters, or unusual transport options?
- "mail" command is the same in both cases. But there is another thing:
Normally, when message is delivered I use pipe transport:
--8<---cut here---start->8---
dovecot_pipe:
debug_print = "T: dovecot_pipe for $local_part@$domain ${reduce{
$sender_address : 'kjonca+fake@localhost' }{}{ ${if def:value {$value} {$item}
}}}"
driver = pipe
path = "/usr/lib/dovecot/:/bin:/usr/bin:/usr/local/bin"
command = /usr/lib/dovecot/dovecot-lda -f
"${reduce{$sender_address:kjonca+fake@localhost}{}{${if def:value
{$value}{$item"
return_path_add
delivery_date_add
envelope_to_add
temp_errors = 64 : 69 : 70: 71 : 72 : 73 : 74 : 75 : 78
--8<---cut here---end--->8---
And these messages have additional line.
But when I turned it off and use appendfile to maildir - messages in
maildir have no additional lines.
KJ
--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
> 2022-05-31 21:02:45 Exim configuration error in line 67 of > /usr/local/etc/exim/configure: > main option "message_linelength_limit" unknown > > It's an option for the SMTP transport doh thanks! randy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
On 31/05/2022 22:06, Randy Bush via Exim-users wrote: 2022-05-31 21:02:45 Exim configuration error in line 67 of /usr/local/etc/exim/configure: main option "message_linelength_limit" unknown message_linelength_limit is an option for the smtp transport. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
On 6/1/22 05:06, Randy Bush via Exim-users wrote: 2022-05-31 21:02:45 Exim configuration error in line 67 of /usr/local/etc/ex im/configure: main option "message_linelength_limit" unknown It's an option for the SMTP transport -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] TLS "certificate expired" warnings on inbound connections
On 2022-05-31 at 14:33:19 UTC-0400 (Tue, 31 May 2022 20:33:19 +0200) Tim Jackson via Exim-users is rumored to have said: I have some legitimate-looking hosts from a major bank producing log lines like this when attempting incoming connections to a public MX: TLS error on connection from r209.notifications.natwest.com [130.248.154.209]:44104 I=[167.235.252.255]:25 (SSL_accept): error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired Is this me (server) dropping the connection or them? Them. (From the log, it reads a bit like me, but I'm definitely not trying to do any client certificate verification so it's unclear which certificate is "expired"). I'm far from an expert on TLS, but I believe I have a sane certificate chain (up to date from Let's Encrypt via acme-tiny; neither the cert nor the CA certs are expired). Other hosts successfully send mail via TLS all the time; it's only this specific group of hosts (*.notifications.natwest.com) where I'm seeing the issue. Is this likely an instance of the Let's Encrypt issue [1][2], where the client is using an old/buggy SSL implementation? Yes, it is likely the referenced issue, but that's NOT an "old/buggy SSL implementation" it's an obsolete secondary signing chain used for LE certs before last year. I can exclude these hosts via tls_advertise_hosts to (presumably) "solve" the issue, but it would be interesting to know if - I could/should do anything different (e.g. Workaround 3 from [1], i.e. request a different CA chain?), or Yes. Workaround 3 is what everyone using LE certs should do. - just put it down to a broken client. No. This can be fixed client-side but the root cause is fundamentally a certificate trust chain error and the client is arguably Not Wrong in considering the cert bad. (I've been using this configuration for quite a while and don't recall ever seeing this issue before). Environment: Exim 4.94.2 / Linux / OpenSSL 1.1.1k # exim -bP tls_try_verify_hosts tls_try_verify_hosts = # exim -bP tls_verify_hosts tls_verify_hosts = # openssl s_client -starttls smtp mx1.firecluster.net:25 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = mx1.firecluster.net verify return:1 --- Certificate chain 0 s:CN = mx1.firecluster.net i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 A working LE chain will terminate with: 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 Which should work because by now, everyone should have a self-signed root cert with "CN = ISRG Root X1" in their trust store. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] TLS "certificate expired" warnings on inbound connections
On Tue, May 31, 2022 at 09:55:22PM +0200, Tim Jackson via Exim-users wrote: > Thanks for the clarification. So the issue is the client verification of the > server cert, not a client cert. Yes, unless I've grossly misread your description of the symptoms. > > The DST Root CA is expired. You can configure LE to build a > > "fullchain.pem" using the ISRG root instead. The only downside is that > > old Android systems may no longer be able to verify your chain. > > OK, so my original theory was right (and, if I understand rightly, this is an > outdated client implementation). Yes. > Is the solution 'certbot --preferred-chain > "ISRG Root X1"' then? (As I mentioned, I currently use acme-tiny rather than > certbot, which unfortunately doesn't seem to support choosing the chain [1], > so I guess I have to switch) Something like that. One way or another avoid the DST root. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
# exim --version Exim version 4.95 #5 (FreeBSD 13.0) built 14-May-2022 14:50:01 # service exim restart Stopping exim. Waiting for PIDS: 1218. Starting exim. 2022-05-31 21:02:45 Exim configuration error in line 67 of /usr/local/etc/exim/configure: main option "message_linelength_limit" unknown /usr/local/etc/rc.d/exim: WARNING: failed to start exim h randy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] TLS "certificate expired" warnings on inbound connections
On 31/05/2022 21:14, Viktor Dukhovni via Exim-users wrote: TLS alerts report error conditions from the remote peer. If your server logs a TLS alert, that alert was generated on the remote end. So if this is a connection from a client to your server, then the "certificate expired" condition is something that the client believes to be the case. Thanks for the clarification. So the issue is the client verification of the server cert, not a client cert. Certificate chain 0 s:CN = mx1.firecluster.net i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 The DST Root CA is expired. You can configure LE to build a "fullchain.pem" using the ISRG root instead. The only downside is that old Android systems may no longer be able to verify your chain. OK, so my original theory was right (and, if I understand rightly, this is an outdated client implementation). Is the solution 'certbot --preferred-chain "ISRG Root X1"' then? (As I mentioned, I currently use acme-tiny rather than certbot, which unfortunately doesn't seem to support choosing the chain [1], so I guess I have to switch) You can use a different cert chain for submission than for port 25 (where you're unlikely to need Android support). Indeed. Thank you very much for the advice! Tim [1] https://github.com/diafygi/acme-tiny/issues/255 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Additional line in body when submitting?
On 31/05/2022 15:39, Kamil Jońca via Exim-users wrote: Andrew C Aitchison via Exim-users writes: Is this a blank line after every real line or just the last one ? Last one. As I wrote elsewhere postfix did not add this. Just tested, and I don't see any extra line. Are you certain your "mail" command is directly executing exim? Does your configuration have any filters, or unusual transport options? -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] TLS "certificate expired" warnings on inbound connections
On Tue, May 31, 2022 at 09:20:25PM +0200, Tim Jackson via Exim-users wrote: > > Is there any chance that the client tries to present you a certificate, > > even if you do not request it? No. The TLS protocol precludes the presentation of unsolicited client certificates. If the server does not send the certificate request message, the protocol state machine does not support any way for the client to send one anyway. If it tries, that would be a protocol error, and the server would drop the connection with a suitable alert to the client. -- VIktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] TLS "certificate expired" warnings on inbound connections
On 31/05/2022 20:53, Heiko Schlittermann via Exim-users wrote: TLS error on connection from r209.notifications.natwest.com [130.248.154.209]:44104 I=[167.235.252.255]:25 (SSL_accept): error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired Is there any chance that the client tries to present you a certificate, even if you do not request it? Well, anything is possible I suppose. It's a good question; I did wonder if it was a client certificate issue, but I assumed Exim wouldn't complain if a client certificate (even expired) is presented when not requested. (Hence why I started looking at the server certificate). Would we consider that an Exim bug if so? I'm a bit suprised that Exim drops the connection (doesn't it?) seeing the expired certificate, but this isn't very unlikely. I'd you a packet capture to check the certificates from both sides. Good idea - I'll see if I can capture next time they retry. Tim -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] TLS "certificate expired" warnings on inbound connections
On Tue, May 31, 2022 at 08:33:19PM +0200, Tim Jackson via Exim-users wrote: > [130.248.154.209]:44104 I=[167.235.252.255]:25 (SSL_accept): > error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired TLS alerts report error conditions from the remote peer. If your server logs a TLS alert, that alert was generated on the remote end. So if this is a connection from a client to your server, then the "certificate expired" condition is something that the client believes to be the case. Perhaps your Let's Encrypt certificate chain includes the expired DST root CA certificate, you can configure certbot to not send it. > Certificate chain > 0 s:CN = mx1.firecluster.net > i:C = US, O = Let's Encrypt, CN = R3 > 1 s:C = US, O = Let's Encrypt, CN = R3 > i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 > 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 > i:O = Digital Signature Trust Co., CN = DST Root CA X3 The DST Root CA is expired. You can configure LE to build a "fullchain.pem" using the ISRG root instead. The only downside is that old Android systems may no longer be able to verify your chain. You can use a different cert chain for submission than for port 25 (where you're unlikely to need Android support). -- VIktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] TLS "certificate expired" warnings on inbound connections
Hi Tim,
Tim Jackson via Exim-users (Di 31 Mai 2022 20:33:19 CEST):
>
> TLS error on connection from r209.notifications.natwest.com
> [130.248.154.209]:44104 I=[167.235.252.255]:25 (SSL_accept):
> error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired
Is there any chance that the client tries to present you a certificate,
even if you do not request it?
I'm a bit suprised that Exim drops the connection (doesn't it?) seeing
the expired certificate, but this isn't very unlikely. I'd you a packet
capture to check the certificates from both sides.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
signature.asc
Description: PGP signature
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] TLS "certificate expired" warnings on inbound connections
I have some legitimate-looking hosts from a major bank producing log lines like this when attempting incoming connections to a public MX: TLS error on connection from r209.notifications.natwest.com [130.248.154.209]:44104 I=[167.235.252.255]:25 (SSL_accept): error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired Is this me (server) dropping the connection or them? (From the log, it reads a bit like me, but I'm definitely not trying to do any client certificate verification so it's unclear which certificate is "expired"). I'm far from an expert on TLS, but I believe I have a sane certificate chain (up to date from Let's Encrypt via acme-tiny; neither the cert nor the CA certs are expired). Other hosts successfully send mail via TLS all the time; it's only this specific group of hosts (*.notifications.natwest.com) where I'm seeing the issue. Is this likely an instance of the Let's Encrypt issue [1][2], where the client is using an old/buggy SSL implementation? I can exclude these hosts via tls_advertise_hosts to (presumably) "solve" the issue, but it would be interesting to know if - I could/should do anything different (e.g. Workaround 3 from [1], i.e. request a different CA chain?), or - just put it down to a broken client. (I've been using this configuration for quite a while and don't recall ever seeing this issue before). Environment: Exim 4.94.2 / Linux / OpenSSL 1.1.1k # exim -bP tls_try_verify_hosts tls_try_verify_hosts = # exim -bP tls_verify_hosts tls_verify_hosts = # openssl s_client -starttls smtp mx1.firecluster.net:25 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = mx1.firecluster.net verify return:1 --- Certificate chain 0 s:CN = mx1.firecluster.net i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 --- Server certificate -BEGIN CERTIFICATE- [snip] -END CERTIFICATE- subject=CN = mx1.firecluster.net issuer=C = US, O = Let's Encrypt, CN = R3 Tim [1] https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ [2] https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Additional line in body when submitting?
Jeremy Harris via Exim-users writes: > On 31/05/2022 14:28, Kamil Jońca via Exim-users wrote: >> I have some instances, which generates mail from stdin >> (ie something like "echo bla|mail root") >> and recently I found that there exists additional empty line in such >> emails, ie instead of >> --8<---cut here---start->8--- >> bla >> --8<---cut here---end--->8--- >> I have >> --8<---cut here---start->8--- >> bla >> --8<---cut here---end--->8--- >> I am rather confusing with it. Is this intentional? > > Could we see the actual message? > -- > Cheers, > Jeremy I make some test and now I am quite confused. I attached 5 messages. all of them were created by --8<---cut here---start->8--- echo bla|mail root --8<---cut here---end--->8--- command. You can see that there were different configurations (postfix to postfix) postfix to exim exim to exim exim to postfix Four were created on "dorsz" machine (and by aliases redirected to alfa machine) one were created on alfa machine directly. --- Begin Message --- bla --- End Message --- --- Begin Message --- bla --- End Message --- --- Begin Message --- bla --- End Message --- --- Begin Message --- bla --- End Message --- --- Begin Message --- bla --- End Message --- Now I do not know if I should blame exim for adding line or postfix for removing it. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Additional line in body when submitting?
Andrew C Aitchison via Exim-users writes: > > Is this a blank line after every real line or just the last one ? Last one. As I wrote elsewhere postfix did not add this. KJ -- http://wolnelektury.pl/wesprzyj/teraz/ -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Additional line in body when submitting?
On Tue, 31 May 2022, Kamil Jońca via Exim-users wrote: I have some instances, which generates mail from stdin (ie something like "echo bla|mail root") and recently I found that there exists additional empty line in such emails, ie instead of --8<---cut here---start->8--- bla --8<---cut here---end--->8--- I have --8<---cut here---start->8--- bla --8<---cut here---end--->8--- I am rather confusing with it. Is this intentional? KJ Is this a blank line after every real line or just the last one ? My guess would be confusion over whether a line ending is being marked with CRLF or LF. This could be disagreement between echo/shell and mail rather than just between mail and exim. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Additional line in body when submitting?
On 31/05/2022 14:28, Kamil Jońca via Exim-users wrote: I have some instances, which generates mail from stdin (ie something like "echo bla|mail root") and recently I found that there exists additional empty line in such emails, ie instead of --8<---cut here---start->8--- bla --8<---cut here---end--->8--- I have --8<---cut here---start->8--- bla --8<---cut here---end--->8--- I am rather confusing with it. Is this intentional? Could we see the actual message? -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Additional line in body when submitting?
Bill Cole via Exim-users writes: > On 2022-05-31 at 09:28:38 UTC-0400 (Tue, 31 May 2022 15:28:38 +0200) > Kamil Jońca via Exim-users > is rumored to have said: > >> I have some instances, which generates mail from stdin >> (ie something like "echo bla|mail root") >> and recently I found that there exists additional empty line in such >> emails, ie instead of >> --8<---cut here---start->8--- >> bla >> --8<---cut here---end--->8--- >> >> I have >> >> --8<---cut here---start->8--- >> bla >> >> --8<---cut here---end--->8--- >> >> I am rather confusing with it. Is this intentional? > > That's almost certainly being done before submission to Exim by the > 'mail' program. Some versions enforce a requirement that messages end > with a blank line. There are also some delivery agents that add a > blank line when delivering to mbox files which MUAs may or may not > treat as part of the message boundary. I forgot to mention: when such message is pasing by postfix only instances - there is no such additional line. So it seems, that not only during submission exim adds this line, but always wants message to end with empty line and enforces it. I am not sure if this is but or not. KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Additional line in body when submitting?
On 2022-05-31 at 09:28:38 UTC-0400 (Tue, 31 May 2022 15:28:38 +0200) Kamil Jońca via Exim-users is rumored to have said: I have some instances, which generates mail from stdin (ie something like "echo bla|mail root") and recently I found that there exists additional empty line in such emails, ie instead of --8<---cut here---start->8--- bla --8<---cut here---end--->8--- I have --8<---cut here---start->8--- bla --8<---cut here---end--->8--- I am rather confusing with it. Is this intentional? That's almost certainly being done before submission to Exim by the 'mail' program. Some versions enforce a requirement that messages end with a blank line. There are also some delivery agents that add a blank line when delivering to mbox files which MUAs may or may not treat as part of the message boundary. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
On 2022-05-31 at 07:40:00 UTC-0400 (Tue, 31 May 2022 13:40:00 +0200) Heiko Schlichting via Exim-users is rumored to have said: I see the good intention of enforcing RFCs, but it should be limited to things that really make sense and not enforce otherworldly limits. I generally agree with the principle. And to which - for good reason - no other software sticks. That's actually a bit of an exaggeration. Many MUAs (albeit not the most popular and modern ones) will adhere to the 998 limit by using a transport encoding (QP or Base64) which create shorter lines (of encoded text) or to use 'format=flowed' (RFC2646/3676) rather than use the fundamentally broken model of linebreak-per-paragraph text. Sendmail's default mailer flags include an 'auto-conversion' flag which happily re-encodes messages at delivery time, breaking any DKIM signature that might be present. Postfix has 3 different line length limits, with the defaultb global limit being 2048 and the default limit for LMTP and SMTP clients (i.e. local and relayed delivery) is 998. For a long time (through v2.8) it was 990. There's a lesson somewhere in the fact that the solution for the root problem was essentially solved with 'format=flowed' in 1999 and was adopted by some MUAs then, only to be swamped by Microsoft ignoring it and then Apple and Mozilla abandoning it so that their MUAs would be more Outlook-like. 23 years later, we have threads on this list and the Mailman2 list the same week full of frustration over the 'fixed' problem. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Additional line in body when submitting?
I have some instances, which generates mail from stdin (ie something like "echo bla|mail root") and recently I found that there exists additional empty line in such emails, ie instead of --8<---cut here---start->8--- bla --8<---cut here---end--->8--- I have --8<---cut here---start->8--- bla --8<---cut here---end--->8--- I am rather confusing with it. Is this intentional? KJ -- http://stopstopnop.pl/stop_stopnop.pl_o_nas.html -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
Jarland Donnell wrote: > A new variable was added in 4.95: message_linelength_limit > > This defaults to RFC spec which is 998 characters, but that's not where the > conversation should end. Absolutely no one out there is creating software > that adheres to the RFC standard. You can send an email from Outlook, > Roundcube, Thunderbird, or whatever which violates this standard and it will > be accepted by all major email providers with no issue. It should therefore > be expected that exim admins will not demand everyone suddenly adopt this > old standard, but instead that they'll increase the value of this variable > in their configs to compensate. Personally, I set my servers to 52428800 for > it. I was surprised that a value of 0 didn't completely disable this check. So I changed src/transports/smtp.c: -if (max_received_linelength > ob->message_linelength_limit) +if (ob->message_linelength_limit > 0 && max_received_linelength > ob->message_linelength_limit) and "set message_linelength_limit = 0" on all of my systems, which is what I would have liked to see as Exim's default. I see the good intention of enforcing RFCs, but it should be limited to things that really make sense and not enforce otherworldly limits. And to which - for good reason - no other software sticks. Heiko Heiko SchlichtingFreie Universität Berlin heiko.schlicht...@fu-berlin.de Zentraleinrichtung für Datenverarbeitung Telefon +49 30 838-54327 Fabeckstraße 32 Telefax +49 30 838454327 14195 Berlin -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
On Tue, May 31, 2022 at 11:32 AM Gedalya wrote: > On 5/31/22 16:21, Odhiambo Washington via Exim-users wrote: > > I checked https://github.com/Exim/exim/blob/master/doc/doc-txt/ChangeLog > > and did not find it. > > https://github.com/Exim/exim/blob/master/doc/doc-txt/NewStuff#L48 > > > https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_smtp_transport.html#SECID146 > > Thank you. This issue has been biting me once in a while with one Outlook user. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
On 5/31/22 16:21, Odhiambo Washington via Exim-users wrote: > I checked https://github.com/Exim/exim/blob/master/doc/doc-txt/ChangeLog > and did not find it. https://github.com/Exim/exim/blob/master/doc/doc-txt/NewStuff#L48 https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_smtp_transport.html#SECID146 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] message has lines too long for transport
Is the variable really named so - message_linelength_limit? I checked https://github.com/Exim/exim/blob/master/doc/doc-txt/ChangeLog and did not find it. On Tue, May 31, 2022 at 2:43 AM Jarland Donnell via Exim-users < exim-users@exim.org> wrote: > A new variable was added in 4.95: message_linelength_limit > > This defaults to RFC spec which is 998 characters, but that's not where > the conversation should end. Absolutely no one out there is creating > software that adheres to the RFC standard. You can send an email from > Outlook, Roundcube, Thunderbird, or whatever which violates this > standard and it will be accepted by all major email providers with no > issue. It should therefore be expected that exim admins will not demand > everyone suddenly adopt this old standard, but instead that they'll > increase the value of this variable in their configs to compensate. > Personally, I set my servers to 52428800 for it. > > On 2022-05-28 13:24, Randy Bush via Exim-users wrote: > > Exim version 4.95 #5 (FreeBSD 13.0) > > > > rancid is an automaton sweeping hardware devices and sending emails of > > any diffs. > > > > ra...@psg.com > > (generated from rancid-psg...@work0.psg.com) > > message has lines too long for transport > > > > uh, how do i whack it? > > > > randy > > -- > ## List details at https://lists.exim.org/mailman/listinfo/exim-users > ## Exim details at http://www.exim.org/ > ## Please use the Wiki with this list - http://wiki.exim.org/ > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
