Mailing List Archive

Ahoj,

D?a Sat, 27 May 2023 13:37:29 +0300 Victor Ustugov via Exim-users
<exim-users@lists.exim.org> napísal:

> I think checking the headers of emails sent by your users could be
> more strict. Because if ${address:...} returns empty result then
> header is not RFC compliant.

Yes, but i am not sure, if my ACLs are prepared on case, when
${address:} returns nothing, as i rely on header_syntax check for
that...

I have to recheck whole concept, and i am not sure when i will have
time for it. Anyway, it works for months without false positives, my
users are not desperate, it is just prevention in case of compromise
and that doesn't happen yet...

regards

--
Slavko
https://www.slavino.sk

Slavko via Exim-users wrote on 27.05.2023 14:00:
> Ahoj,
>
> D?a Sat, 27 May 2023 13:20:48 +0300 Victor Ustugov via Exim-users
> <exim-users@lists.exim.org> napísal:
>
>> I think that in this case it is not necessary to use a very "horrible
>> complicated" full RFC compliant regexp. It may be sufficient to ignore
>> all parenthesized text after the last ">". Or even ignore all text in
>> parentheses after the last ">".
>>
>> ${if
>> eq{${addresses:$rh_From:}}{}{${sg{$rh_From:}{\N^.*<(\S+?@\S+?)>[^>]*$\N}{\$1}}}{${addresses:$rh_From:}}}
>>
>
> And then you get something as this:
>
> From: "postmaster@your-domain.tld" <charles@example.org> (<confuse@domain.tld>)
>
> :-)))

In this case, everything will be fine, because the address will be
returned by ${addresses:...}

But there will be problems with such header:

From: postmaster@your-domain.tld <charles@example.org>
(<confuse@domain.tld>)

> My point was, that regex can be not reliable too.

Regex is only a workaround. It is needed only because ${address:...} and
${addresses:...} cannot always extract the addresses from the headers.


> I consider the ${address:} expansion as way to prevent needing that
> anyone have to develop own parser, which can end in ugly or even wrong
> way as not all (including me) are regex experts...

> I do not expect, that ${address:} will parse any wrong syntax. I can
> accept, that it can fail in some corner cases of valid syntax. But
> i expect, that when header will pass the header_syntax check, then that
> expansion will be able to parse it, otherwise something is wrong.


--
Best wishes Victor Ustugov
mailto:victor@corvax.kiev.ua
public GnuPG/PGP key: https://victor.corvax.kiev.ua/corvax.asc

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 26/05/2023 13:43, Markus Reschke via Exim-users wrote:
> Hello Sebastian!
>
> On Fri, 26 May 2023, Sebastian Arcus via Exim-users wrote:
>
>> Hello. As so many scams around are based on impersonating someone
>> inside the company, I am wondering if anyone here has considered the
>> more extreme solution of completely removing any name in the From:
>> header for incoming emails? I already have SPF/DKIM/DMARC in place, so
>> the scammers can't actually impersonate the sending email address, but
>> they keep on using the names of people with positions high up in the
>> company. The risks of falling for such emails are much reduced at this
>> stage, but now I'm wondering if the next step would be to just strip
>> all names in the From: field altogether and just leave the email
>> address? Can Exim do that, and has anyone considered it?
>
> Have you heard of IDNs (domain names with unicode characters)? For
> example, your domain is company.com and the bad guy registers c<some
> unicode character looking like an o>mpany.com. Then he sets up
> SPF/DKIM/DMARC for that domain and sends you an email. Could you tell
> just from the email address if it's from your CEO or a scammer?
>
> Removing the names to force users to look at the email address can help
> to the lower the risk of falling for less sophisticated scams, but it
> wouldn't work for more professional frauds.

That is an interesting point - thank you for flagging it. I haven't seen
such a case yet in my setups, but I can see it being perfectly possible.
At the moment we are bombarded with emails of the type

From: Director Name <randomaddress@gmail.com>

Hence why I was considering stripping the name from all incoming From:
headers. In general things are holding out quite well so far, as the
users are constantly reminded to be vigilant and the real domain can't
be spoofed because of DKIM/DMARC/SPF - but I am constantly looking into
ways to strengthen the security.

>
> ciao
>  Markus

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/