[exim] Configuration progress.
From: Peter via Exim-users Date: Thu, 13 Apr 2023 13:28:07 -0700 Better to test with a distinct domain. gmail.com for example. The result from exim -d+all+noutf8 -odf petereasth...@gmail.com &1 | tee ~/NY/ex1 | less is in http://easthope.ca/ex1 . 17:31:09 8486 easthope.ca in "imager.hitronhub.home"? no (end of list) That is to determine whether the destination is local? Subsequently, 17:31:09 8491 no message retry record 17:31:09 8491 retry time not reached: checking ultimate address timeout Why is a retry time evaluated? Why not try authentication? Thx, ... P. -- ## 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] From header with encoding not parsed?
On 13/04/2023 23:24, Martin D Kealey via Exim-users wrote:
On Thu, 13 Apr 2023 at 19:36, Slavko wrote in
exim-users@exim.org:
Dňa 12. apríla 2023 16:50:29 UTC používateľ MRob via Exim-users <
exim-users@exim.org> napísal:
Hi, I have a variable to extract the email address in from header set
like this:
${lc:${address:$h_From:}}
Header is valid, but after decoding it contains comma without
qoutes, the comma is address separator and thus results in
list of two "addresses", first without valid address, thus empty...
My take on this is that Exim is wrong there.
Anywhere else, splitting addresses on commas happens before decoding, and
this should be no different.
Uh, it's only a list if and when you use that string (the result of that
expansion)
where a list is expected. And the list separator is also defined
by the context.
I don't agree with "Exim is wrong there".
--
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] From header with encoding not parsed?
On Thu, 13 Apr 2023 at 19:36, Slavko wrote in
exim-users@exim.org:
> Dňa 12. apríla 2023 16:50:29 UTC používateľ MRob via Exim-users <
> exim-users@exim.org> napísal:
> > Hi, I have a variable to extract the email address in from header set
> like this:
> >
> > ${lc:${address:$h_From:}}
>
> Header is valid, but after decoding it contains comma without
> qoutes, the comma is address separator and thus results in
> list of two "addresses", first without valid address, thus empty...
>
My take on this is that Exim is wrong there.
Anywhere else, splitting addresses on commas happens before decoding, and
this should be no different.
One way to do that would be to treat encoded characters as if they were
quoted.
-Martin
--
## 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] Configuration progress; was Re (2): Configuring exim to use an non-TLS connection to port 587.
From: Andrew C Aitchison via Exim-users Date: Thu, 13 Apr 2023 11:06:24 +0100 (BST) Jeremy's last message mentioned that this failure was correct given the content of /etc/exim4/passwd.client I think that means you need a line for easthope.ca in /etc/exim4/passwd.client - a line for mail.easthope.ca is not the same thing. According to https://islandhosting.com/knowledgebase/21/How-do-I-configure-my-email-client.html my target smarthost is mail.easthope.ca. Confirmed when I log in to my Island Hosting account and see the instructions adapted to the specific account. Therefore according to the comment providing internal documentation, /etc/exim4/passwd.client has this. $ tail -n 2 /etc/exim4/passwd.client ### target.mail.server.example:login:password mail.easthope.ca:pe...@easthope.ca: I acknowledge what you say about easthope.ca but haven't found documentation suggesting easthope.ca accompany mail.easthope.ca. More about easthope.ca below. After the tests yesterday, noticed the following in https://manpages.debian.org/testing/exim4-config/exim4_passwd_client.5.en.html "Please note that target.mail.server.example is currently the value that exim can read from reverse DNS: It first follows the host name of the target system until it finds an IP address, and then looks up the reverse DNS for that IP address to use the outcome of this query (or the IP address itself should the query fail) as index into /etc/exim4/passwd.client." Documentation afterthought? "dpkg-reconfigure exim4-config" ignores it? =8~/ Incidentally, if my niece wrote the paragraph as homework and asked for feedback, I'd explain how to make it more understandable with fewer words. =8~) $ nslookup mail.easthope.ca Server: 192.168.0.1 Address:192.168.0.1#53 Non-authoritative answer: mail.easthope.cacanonical name = easthope.ca. Name: easthope.ca Address: 158.69.159.172 $ host 158.69.159.172 172.159.69.158.in-addr.arpa domain name pointer hornby.islandhosting.com. $ nslookup hornby.islandhosting.com Server: 192.168.0.1 Address:192.168.0.1#53 Non-authoritative answer: Name: hornby.islandhosting.com Address: 158.69.159.172 Name: hornby.islandhosting.com Address: 2607:5300:203:66b5:: So the content of /etc/exim4/passwd.client stated above is WRONG! Should be this. ### target.mail.server.example:login:password hornby.islandhosting.com:pe...@easthope.ca: **BUT** do not do this until tls is working, otherwise you will ** *** send your password across the internet in plain text. ** Acknowledged. Now that permissions on passwd.client might be OK(?) and the target smarthost might be OK(?), I should think about TLS again. ANOTHER FOOTNOTE The smarthost being mail.easthope.ca and test recipient pe...@easthope.ca is a source of confusion. "easthope.ca" appears in too many places. Better to test with a distinct domain. gmail.com for example. Thx, ... P. -- ## 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] Re (2): Configuring exim to use an non-TLS connection to port 587.
On Wed, 12 Apr 2023, Peter via Exim-users wrote: From: Graeme Fowler via Exim-users Date: Tue, 11 Apr 2023 18:44:22 +0100 ... problem is on your filesystem rather than on-the-wire. Another helpful tip is in https://wiki.debian.org/Exim4Gmail. /etc/exim4/passwd.client had permissions 600. Now 640. $ ls -ld /etc/exim4/passwd.client -rw-r- 1 root Debian-exim 249 Apr 12 06:35 /etc/exim4/passwd.client Then created a fresh debug output which is here. http://easthope.ca/ex1 It has these lines. 08:33:42 4098 internal_search_find: file="/etc/exim4/passwd.client" 08:33:42 4098 type=nwildlsearch key="easthope.ca" opts=NULL 08:33:42 4098 file lookup required for easthope.ca 08:33:42 4098 in /etc/exim4/passwd.client 08:33:42 4098 easthope.ca in "mail.easthope.ca"? no (end of list) 08:33:42 4098 lookup failed /etc/exim4/passwd.client can be read by Debian-exim and has only one active line beginning with mail.easthope.ca. This is the same snag as mentioned by Jeremy, Tue, 11 Apr 2023 18:56:10 +0100? "- they presented a server certificate that we don't like; specifically, the list of systems that are supposed to use the cert did not include the name we think the server has (the one we made a TCP connection to)." Jeremy's last message metioned that this failure was correct given the content of /etc/exim4/passwd.client I think that means you need a line for easthope.ca in /etc/exim4/passwd.client - a line for mail.easthope.ca is not the same thing. --- I am concerned about this line: 08:33:42 4098 158.69.159.172 in hosts_require_auth? no (option unset) I think your smtp transport needs a line something like hosts_require_auth = * or hosts_require_auth = hornby.islandhosting.com (since 158.69.159.172 is hornby.islandhosting.com). **BUT** do not do this until tls is working, otherwise you will ** *** send your password across the internet in plain text.** IIRC you want to force TLS on this connection. If so you should also have hosts_require_tls = hornby.islandhosting.com A little further down. 08:33:43 4098 SMTP(closed)<< 08:33:43 4098 Remote host closed connection in response to pipelined DATA The smarthost refused to continue the conversation? Command options are explained fairly well. I'm not clear about the command and argument. exim -d+all -odf pe...@easthope.ca ... Exim is invoked to send a test message to pe...@easthope.ca? Similar to the Swaks autocreated test message? Exim attempts to send the messages in the spool addressed to peter? Yes, I opened https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_exim_command_line.html Under heading "1. Setting options by program name" are five cases not including exim. Thanks, ... P. -- ## 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/ -- 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] From header with encoding not parsed?
On 13/04/2023 09:54, Victor Ustugov via Exim-users wrote: I'm not talking about what should be encoded, but about what can be received in a real email from a spammer, some kind of script or something like that. A mail sender could send you *anything*. -- 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] From header with encoding not parsed?
Slavko via Exim-users wrote on 12.04.2023 22:38:
Hi, I have a variable to extract the email address in from header set like
this:
${lc:${address:$h_From:}}
>>>
>>> Header is valid, but after decoding it contains comma without
>>> qoutes, the comma is address separator and thus results in
>>> list of two "addresses", first without valid address, thus empty...
>>>
>>> Use raw header for address extracting -- $rh_From: that works
>>> for both, quoted and encoded content...
>>
>>
>> What about the colon without encoding?
>>
>> From: =?utf-8?Q?My=20Bizness:=20Inc.?=
>
> AFAIK colon have to be encoded, quote from by RFC 2047, section
> 5 (the From: and similar):
>
> characters that may be used in a "Q"-encoded 'encoded-word' is
> restricted to: "!", "*", "+", "-", "/", "=", and "_">
I'm not talking about what should be encoded, but about what can be
received in a real email from a spammer, some kind of script or
something like that.
--
Best wishes Victor Ustugov
mailto:vic...@corvax.kiev.ua
public GnuPG/PGP key: https://victor.corvax.kiev.ua/corvax.asc
--
## 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] From header with encoding not parsed?
Jasen Betts via Exim-users wrote on 13.04.2023 10:07:
> On 2023-04-12, Victor Ustugov via Exim-users wrote:
>> Slavko via Exim-users wrote on 12.04.2023 20:42:
>>> Dňa 12. apríla 2023 16:50:29 UTC používateľ MRob via Exim-users
>>> napísal:
Hi, I have a variable to extract the email address in from header set like
this:
${lc:${address:$h_From:}}
>>>
>>> Header is valid, but after decoding it contains comma without
>>> qoutes, the comma is address separator and thus results in
>>> list of two "addresses", first without valid address, thus empty...
>>>
>>> Use raw header for address extracting -- $rh_From: that works
>>> for both, quoted and encoded content...
>>
>>
>> What about the colon without encoding?
>>
>> From: =?utf-8?Q?My=20Bizness:=20Inc.?=
>
> yes, the colon breaks it. it's not a valid from header.
I know. But email clients correctly display the From header shown above.
And it is quite possible to get such a header in an incoming email.
> RFC5322 is a bit of a rabbit hole to dive into.
>
> but the short story is none of these should be used in "bare" names
>
> specials= "(" / ")" /; Special characters that do
> "<" / ">" /; not appear in atext
> "[" / "]" /
> ":" / ";" /
> "@" / "\" /
> "," / "." /
> DQUOTE
>
> except where there is specific permission given
>
>
> Easiest fix for the sender is to use quotes.
>
> From: "=?utf-8?Q?My=20Bizness:=20Inc.?="
in order to insert double quotes, I need to separate the From header
into the address and the part of the header that comes before it. Why do
I need to add quotes if I have already determined which part of the
header is the address?
--
Best wishes Victor Ustugov
mailto:vic...@corvax.kiev.ua
public GnuPG/PGP key: https://victor.corvax.kiev.ua/corvax.asc
--
## 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] From header with encoding not parsed?
On 2023-04-12, Victor Ustugov via Exim-users wrote:
> Slavko via Exim-users wrote on 12.04.2023 20:42:
>> Dňa 12. apríla 2023 16:50:29 UTC používateľ MRob via Exim-users
>> napísal:
>>> Hi, I have a variable to extract the email address in from header set like
>>> this:
>>>
>>> ${lc:${address:$h_From:}}
>>
>> Header is valid, but after decoding it contains comma without
>> qoutes, the comma is address separator and thus results in
>> list of two "addresses", first without valid address, thus empty...
>>
>> Use raw header for address extracting -- $rh_From: that works
>> for both, quoted and encoded content...
>
>
> What about the colon without encoding?
>
> From: =?utf-8?Q?My=20Bizness:=20Inc.?=
yes, the colon breaks it. it's not a valid from header.
RFC5322 is a bit of a rabbit hole to dive into.
but the short story is none of these should be used in "bare" names
specials= "(" / ")" /; Special characters that do
"<" / ">" /; not appear in atext
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
except where there is specific permission given
Easiest fix for the sender is to use quotes.
From: "=?utf-8?Q?My=20Bizness:=20Inc.?="
--
Jasen.
Слава Україні
--
## 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] OT: are BCC header lines legitimate ?
On 2023-04-12, Olaf Hopp (SCC) via Exim-users wrote:
> Sorry for being a bit off topic:
> recently we had incoming phishing mails which all had a BCC header line.
> So I thought, that's easy to defend and I introduced a data ACL
>
> deny condition = ${if def:h_BCC: {yes}{no}}
>
> My logs revealed a lot of them and I was afraid of doing some overblocking.
> So I changed the "deny" into a "warn", shifted the ACL further down below spam
> and virus scan and added some logging.
>
> The outcome is that there are really a bunch of incoming mails
> with a BCC header, which seems to be no spam.
>
> And forthermore about 90% are coming from Google hosts like e.g.
> mail-qk1-x742.google.com
>
> So my question for discussion here:
> is there any legitimate use to have a BCC header present
> or is this all crap and can be rejected ?
https://www.rfc-editor.org/rfc/rfc5322#section-3.6.3
The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
addresses of recipients of the message whose addresses are not to be
revealed to other recipients of the message. There are three ways in
which the "Bcc:" field is used. In the first case, when a message
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
removed even though all of the recipients (including those specified
in the "Bcc:" field) are sent a copy of the message. In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, but the
recipients on the "Bcc:" line get a separate copy of the message
containing a "Bcc:" line. (When there are multiple recipient
addresses in the "Bcc:" field, some implementations actually send a
separate copy of the message to each recipient with a "Bcc:"
containing only the address of that particular recipient.) Finally,
since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
sent without any addresses indicating to the recipients that blind
copies were sent to someone. Which method to use with "Bcc:" fields
is implementation dependent, but refer to the "Security
Considerations" section of this document for a discussion of each.
So, sometimes BCC recipients do see the Bcc header.
--
Jasen.
Слава Україні
--
## 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/
