[exim] 'Tis time to say Farewell

[Mike Brudenell via Exim-users]

Dear all,

The time has come for me to say farewell to the list, which I'll be doing
on Thursday. I handed over running our university's email service to a team
last year but stayed on the list to keep my hand in. But I'll soon be
taking early retirement and, with annual leave, my last effective working
day is Thursday this week.

Thank you all for your help and support over the years and, especially, to
everyone who has helped and still helps develop Exim. It's a fantastic MTA
and has served us very well indeed since we switched to it from Sendmail. I
still remember with great pleasure the week-long workshop at Cambridge that
Philip Hazel led before his own retirement: really useful, and the first
time I'd been on a punt!

Keep up the wonderful work!

Cheers,
Mike B-)

-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Email Disclaimer: www.york.ac.uk/about/legal-statements/email-disclaimer/

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Help to logical OR two conditions

[Mike Brudenell via Exim-users]

Having had a chat with Victor off-list, I think the thing he's curious
about is why *or* *requires* strict true/false values as its arguments, but
the *condition* condition *doesn't* — instead *condition* effectively
performs a *bool_lax* on the expression evaluated on its right hand side.
This difference is documented within the description of bool_lax in the
String Expansions chapter, but is easy to miss for people new to Exim

I suggested that strictly requiring true/false within an *or* is likely a
safety measure, otherwise it's very easy to write expressions that appear
to work but don't in all situations because of the lenient interpretation.

I think there was also some confusion over the Expansion Items, Expansion
Operators, Expansion Conditions and Combination Conditions. From the
developers perspective these are different types of thing, that are can be
used in different ways/places. But for a newcomer to Exim it can be
confusing. For example,

   - A *condition* condition wants a true/false value
   - An *or* returns a Boolean true/false value
   - But (if memory serves, I no longer run the mail service here so don't
   have access now to the test system) you can't write
   condition = or{ {} { wrote:

> On 04/10/2020 08:30, Victor Sudakov via Exim-users wrote:
> > Jeremy Harris via Exim-users wrote:
> >> On 03/10/2020 15:18, Victor Sudakov via Exim-users wrote:
> >>> And why did they call bool{...} and friends "Expansion conditions"
> >>> while they are clearly not conditions, but operators?
> >>
> >> The operate on things and result in conditionals.  Have to call
> >
> > What you do mean by "result in conditionals" ? They result in boolean
> > values.
>
> Those are the same.
> --
> 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/
>


-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Email Disclaimer: www.york.ac.uk/about/legal-statements/email-disclaimer/

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Remove & Replace Message Body Content

[Mike Brudenell via Exim-users]

Hi, Patrick -

I'll chip in with my usual caution of: Be careful! Doing this will
invalidate any digital signatures that the incoming message has been signed
with.

If you're planning to do this only for locally originated messages being
created by MUAs, or for messages for local delivery that have already
passed your anti-spam measures, then you might get away with it. But if
they're messages your other MTAs have created and signed, or are messages
you might be forwarding on to one of your user's onward addresses, then
you're going to cause problems — by  breaking its digital signature you
could make the onward copy undeliverable as many sites check DKIM
signatures now as they receive an email.

Cheers,
Mike B-)

On Fri, 2 Oct 2020 at 17:34, Patrick Porteous via Exim-users <
exim-users@exim.org> wrote:

> Hello,
>
> I would like to create a filter that removes and replaces all HTML
> hyperlinks in received messages.  In doing some initial testing, I made
> the following conditional filter to test how Exim processes the
> $message_body variable:
>
> *if $message_body contains "href="**
> **then**
> **headers add "X-Links: Yes"**
> **endif*
>
> However, it appears that the $message_body variable doesn't analyze the
> source HTML of the message, but instead just looks at the plain text
> produced by the HTML output.  Is Exim capable of analyzing the source
> HTML of a message and then when certain criteria is matched, replacing
> those parts of the message before delivery?
>
> HTML Message Example:
>
> ***
> 
> 
> **Untitled Document**
> 
> **
> 
> **http://www.example.com;>my-link**
> 
> ***
>
> Thanks for any guidance,
>
> Patrick
>
>
> --
> ## 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/
>


-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Email Disclaimer: www.york.ac.uk/about/legal-statements/email-disclaimer/

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] rewrite envelope from when forward

[Mike Brudenell via Exim-users]

Hi, Johannes -

Firstly, don't change the contents of the To or CC headers! The message
might have been digitally signed and authenticated using a technology such
as DKIM. This protects various key headers as well as the message body and
the attachments. If you change any of them you will break the signature and
cause further delivery problems.

Instead you just want to change the MAIL FROM (sender) address in the SMTP
envelope so it uses an email address within your own domain. The best way
of doing this is *not* to set it to one of your user's email addresses.
Instead use SRS (Sender Rewriting Scheme) to encode the original sender's
address into a specially formatted address that ends with "@' and your own
domain name. The site you forward the message onward to will then check the
MAIL FROM address against your SPF policy instead of that belonging to the
original sender.

SRS is good because if there's a problem delivering the message further on
it will come back to your mail service (because your domain is now in the
MAIL FROM of the envelope). You'll then be able to undo the SRS-rewritten
address to retrieve that of the original sender so you can relay the
delivery failure back to them.

Something to watch out for…

If the original sender's email domain is protected using DMARC then you
might still hit problems. This is because whilst SPF now passes, it'll
still fail DMARC's tighter SPF requirements — that the domain name in the
MAIL FROM address aligns with ("is similar to") that in the "From" header.

Hopefully the original sender's site won't just be relying on their SPF
record though, but also DKIM-signing their messages. So as long as you
don't break that signature (by altering the Fro/To/Cc headers!) things will
likely be OK and your relayed message will get through.

As for how to use the *return_path* — just assign the email address you
want to become the new MAIL FROM in the envelope to it. It's all described
in Exim's extensive documentation. :-)

Cheers,
Mike B-)

On Wed, 9 Sep 2020 at 15:38, Johannes Vogel via Exim-users <
exim-users@exim.org> wrote:

> Hi
>
> Am 07.09.20 um 13:23 schrieb Jeremy Harris via Exim-users:
> > On 06/09/2020 21:04, Johannes Vogel via Exim-users wrote:
> >> When I forward an address to an @bluewin.ch address, they bring back an
> >> error like this:
> >>
> >> SMTP error from remote mail server after end of data:
> >> 554 5.2.0 sc971: SPF hard fail
> > Yes, SPF breaks forwarding.
> >
> > Option "return_path" on the transport:
> >
> >
> http://exim.org/exim-html-current/doc/html/spec_html/ch-generic_options_for_transports.html
>
> Thank you for the hint! But I don't know what content I should assign.
>
> In my example I'd like to set the to address of the forwarded mail.
>
> original message: m...@gmail.com --> l...@mydomain.tld
> new envelope: l...@mydomain.tld --> l...@otherhoster.tld
> new mail header: m...@gmail.com --> l...@otherhoster.tld
>
> Is the information of the original to address at this moment available?
> Does this solve my problem with SPF?
>
> Best regards,
> Johannes
>
> --
> ## 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/
>


-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Email Disclaimer: www.york.ac.uk/about/legal-statements/email-disclaimer/

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Full SPF/DKIM/DMARC validation policies for Exim on CentOS 8 (feedback please)

[Mike Brudenell via Exim-users]

Hi, Adrian -

Looking at the extract you posted, I think you are denying (rejecting)
messages for which either SPF or DKIM verification fails? (For example,
you're using *deny* used in the acl_check_mail ACL to refuse the MAIL FROM.)

If so (it's late, and my tired eyes might be misreading things!), you may
want to review and reconsider this as it is working against the ethos of
DMARC, which passes if either SPF, DKIM or both pass. That is, DMARC passes
even if one (bot not both) of SPF or DKIM fail.

For example, our University is very selective about which external service
providers we add to our SPF record because of the risk changes they make
could invalidate it. Instead we tend to rely solely on messages third-party
service providers send out on our behalf being correctly DKIM-signed. That
is fine and perfectly allowable under a DMARC policy. However I think your
configuration is going to reject such messages because it sees SPF fail,
without then going on to also check DKIM.

Cheers,
Mike B-)

On Sun, 12 Jul 2020 at 23:09, Adrian (Aad) Offerman via Exim-users <
exim-users@exim.org> wrote:

> Hello all,
>
> I've been working on the implementation of SPF/DKIM/DMARC policies in
> the configuration of Exim on CentOS 8 (8.1). It turns out that
> everything is there (i.e. all functionality is compiled in in the
> package that comes with the repository), but there are no policies at
> all defined in '/etc/exim/exim.conf'.
> (there are some 'dkim_disable_verify' and 'dmarc_disable_verify'
> statements where DKIM/DMARC-validation should not take place, i.e. for
> local/relayed/authenticated hosts; and SPF and DKIM are validated as
> part of the (external) spam scan)
>
> Please find below the policies that I've created and tested (checking
> logs and headers of validating and non-validating messages in a test
> environment that is, not in a volume/operational environment yet).
>
> Any feedback on the polices themselves would be great. And maybe these
> would be a good starting point to get some policies into the Exim
> configuration that comes with CentOS, probably best with an on/off
> switch variable.
>
> Tnx, Adrian
>
> 
>
>
> For SPF validation:
>
> acl_check_mail:
>
>   # Hosts are required to say HELO (or EHLO) before sending mail.
>   # So don't allow them to use the MAIL command if they haven't
>   # done so.
>
>   deny condition = ${if eq{$sender_helo_name}{} {1}}
>message = Nice boys say HELO first
>
>   # reject messages from senders listed in these DNSBLs
>   deny dnslists = zen.spamhaus.org
>
>   # SPF validation
>   deny spf = fail : softfail
>   message = SPF validation failed: \
>   $sender_host_address is not allowed to send mail from \
>   ${if def:sender_address_domain \
>   {$sender_address_domain}{$sender_helo_name}}
>   log_message = SPF validation failed\
>   ${if eq{$spf_result}{softfail} { (softfail)}{}}: \
>   $sender_host_address is not allowed to send mail from \
>   ${if def:sender_address_domain \
>   {$sender_address_domain}{$sender_helo_name}}
>   deny spf = permerror
>   message = SPF validation failed: \
>   syntax error in SPF record(s) for \
>   ${if def:sender_address_domain \
>   {$sender_address_domain}{$sender_helo_name}}
>   log_message = SPF validation failed (permerror): \
>   syntax error in SPF record(s) for \
>   ${if def:sender_address_domain \
>   {$sender_address_domain}{$sender_helo_name}}
>   defer spf = temperror
>   message = temporary error during SPF validation; \
>   please try again later
>   log_message = SPF validation failed temporary; deferred
>   # Log SPF none/neutral result
>   warn spf = none : neutral
>   log_message = SPF validation none/neutral
>
>   # Use the lack of reverse DNS to trigger greylisting. Some people
>   # even reject for it but that would be a little excessive.
>
>   warn condition = ${if eq{$sender_host_name}{} {1}}
>set acl_m_greylistreasons = Host $sender_host_address \
>lacks reverse DNS\n$acl_m_greylistreasons
>
>   accept
>   # Add an SPF-Received header to the message
>   add_header = :at_start: $spf_received
>   logwrite = SPF validation passed
>
> 
>
>
> For DKIM validation:
>
> acl_smtp_dkim = acl_check_dkim
>
> acl_check_dkim:
>   deny dkim_status = fail
>   message = DKIM validation failed: $dkim_verify_status
>   log_message = DKIM validation failed: $dkim_verify_status \
>   (address=$sender_address, domain=$dkim_cur_signer), \
>   signature is bad
>   defer dkim_status = invalid
>   message = DKIM signature invalid: $dkim_verify_status
>   log_message = DKIM signature invalid: $dkim_verify_status \
> 

Re: [exim] 'verify=helo' and strange warning...

[Mike Brudenell via Exim-users]

Yup, I think that's correct behaviour for what you're telling Exim to do.
You don't explain clearly what it is you're asking, but I'm guessing you're
seeing the header added all the time and wondering why? If so…

When you read the documentation for *Access Control Lists* you'll see in
section *24. Adding header lines in ACLs
*
that it says:

The *add_header* modifier acts immediately as it is encountered during the
processing of an ACL. Notice the difference between these two cases:

accept add_header = ADDED: some text
   

accept 
   add_header = ADDED: some text

In the first case, the header line is always added, whether or not the
condition is true. In the second case, the header line is added only if the
condition is true. Multiple occurrences of *add_header* may occur in the
same ACL statement. All those that are encountered before a condition fails
are honoured.


So in your ACL you are telling Exim to *always* add the header, and
*then* apply
the test to verify the HELO.

Cheers,
Mike B-)

On Thu, 11 Jun 2020 at 12:44, Marco Gaiarin via Exim-users <
exim-users@exim.org> wrote:

>
> I've a simple 'warn' ACL:
>
>   warn
> add_header = X-HELO-Warning: Remote host $sender_host_address ${if
> def:sender_host_name {($sender_host_name) }}incorrectly presented itself as
> $sender_helo_name
> log_message = Remote host presented unverifiable HELO/EHLO greeting
> hosts = !+relay_from_hosts
> !verify = helo
>
> but emits warning like:
>
> X-HELO-Warning: Remote host 89.185.230.205 (smtp5.mailing.easy.cz)
> incorrectly presented itself as smtp5.mailing.easy.cz
>
> that seems a bit strange to me. Why?
>
>
> Thanks.
>
> --
>   Mi piaccion le fiabe
>   raccontane altre  (F. Guccini)
>
>
>
> --
> ## 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/
>


-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Weirdness when forcing TLS and checking that its working in ACLs

[Mike Brudenell via Exim-users]

Hi, Mike -

If you look up the description of the *logwrite* modifier in Exim's
documentation, you'll see that it says (emphasis mine):

This modifier writes a message to a log file as soon *as it is encountered*
when processing an ACL. (Compare log_message, which, except in the case of
warn and discard, is used only if the ACL statement denies access.)


That is, as soon as logwrite is reached then it performs its action and
writes out its text.

In this case you've placed the logwrite line before your *! encrypted* line,
so the logwrite is encountered first and therefore actioned (before the
encrypted test). It's therefore incorrectly logging there's a problem
with the encryption when, as you note, there isn't and so the deny
statement doesn't trigger and the message is accepted.

Try swapping the two lines, or switch to using *log_message* instead, which
doesn't do anything immediately but instead sets up a message that's used
if the ACL denies access (or a *warn* statement's conditions are true). But
do read the description of both logwrite and log_message, as there are a
few other differences: particularly in the area of logging multiple copies
of some text whilst receiving a single email.

Cheers,
Mike B-)

On Thu, 13 Feb 2020 at 14:01, Mike Tubby via Exim-users 
wrote:

> All,
>
> Some government departments that we work with asked us to increase email
> security via "forced TLS" for which I developed a solution for:
>
>  a) our public email relay servers (with upstream/downstream and
> local/remote hosts - 4 legs) - this is moderately complex but all worked
> first time
>
>  b) our private email server/endpoint (with Exim+Dovecot and just in
> and out) - should have been simpler but was weird
>
> and on this journey I observed some strange behaviour.
>
> Running Exim 4.93.04 compiled on AMD64 (Dell R320) with Devuan 3.0 Beowulf.
>
>
> On our internal server I added the following at the top of the
> acl_check_mail:
>
> acl_check_mail:
>
>  #
>  # refuse all connections that are not TLS
>  #
>  denymessage = Connection not secure. You must use STARTTLS
> to send to this server!
>  logwrite = MAIL: Denied host
> $sender_host_address:$sender_host_port not using TLS secure connection!
>  ! encrypted = *
>
>
> and it produced the following result:
>
> 2020-02-13 09:36:51 CONNECT: New connection from 195.171.43.2 port:
> 63615 -> 195.171.43.20 port: 587
> 2020-02-13 09:36:51 CONNECT: Accept connection from host: 195.171.43.2
> in whitelist +relay_from_hosts
> 2020-02-13 09:36:51 HELO: Could not verify HELO/EHLO: [192.168.1.107]
> from remote host: 195.171.43.2 (gate.thorcom.com)
> 2020-02-13 09:36:51 HELO: Accepted HELO/EHLO [192.168.1.107] from remote
> host: 195.171.43.2 (gate.thorcom.com)
> 2020-02-13 09:36:51 CRYPTO: Client 195.171.43.2 port: 63615 issued STARTTLS
> 2020-02-13 09:36:51 HELO: Client 195.171.43.2:63615 using SSL/TLS
> cipher: TLS1.3:TLS_AES_256_GCM_SHA384:256
> 2020-02-13 09:36:51 HELO: Could not verify HELO/EHLO: [192.168.1.107]
> from remote host: 195.171.43.2 (gate.thorcom.com)
> 2020-02-13 09:36:51 HELO: Accepted HELO/EHLO [192.168.1.107] from remote
> host: 195.171.43.2 (gate.thorcom.com)
> 2020-02-13 09:36:51 MAIL: Denied host 195.171.43.2:63615 not using TLS
> secure connection!
> 2020-02-13 09:36:51 MAIL: Accept from gate.thorcom.com ([192.168.1.107])
> [195.171.43.2] as in +relay_from_hosts
> 2020-02-13 09:36:51 RCPT: Accept non-local domain for outbound delivery
>
>
> Which confused me for two reasons:
>
>  1. It says 'deny' when the connection is, infact, secure - you can
> see the TLS
>  2. It says 'deny' and then carries on to the next rule and accepts
> the MAIL command
>
> Changing the acl to read:
>
> acl_check_mail:
>
>  #
>  # report/check/deny TLS as approriate
>  #
>  warncondition = ${if def:tls_in_cipher {1}{0}}
>  logwrite = MAIL: Client
> $sender_host_address:$sender_host_port using SSL/TLS cipher: $tls_in_cipher
>
>  denycondition = ${if def:tls_in_cipher {0}{1}}
>  message = Connection not secure. You must use STARTTLS
> to send mail to this server.
>  logwrite = MAIL: Client
> $sender_host_address:$sender_host_port NOT using TLS connection
>
>
> gives consistent results as expected and either logs the cipher in use
> or denies the connection.
>
> What did I miss?
>
>
> Mike
>
>
> --
> ## 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/
>


-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## List details at 

Re: [exim] Ratelimit doesn't work as expected

[Mike Brudenell via Exim-users]

Hi, Sebastian -

I'm wracking my memory here as I had the exact same problem when setting up
a very similar mechanism. If memory serves, the trick is to change the
*leaky* to instead be *strict*: certainly that's what we're using now and
it's working.

When using the leaky setting the computed rate never seemed to go over the
threshold but just hover slightly under it. This is probably described in
the *Specification* where it says:

The *leaky* (default) option means that the client’s recorded rate is not
updated if it is above the limit. The effect of this is that Exim measures
the client’s average rate of successfully sent email, which cannot be
greater than the maximum allowed. If the client is over the limit it may
suffer some counter-measures (as specified in the ACL), but it will still
be able to send email at the configured maximum rate, whatever the rate of
its attempts. …


Cheers,
Mike B-)

On Fri, 9 Aug 2019 at 14:40, Sebastian Arcus via Exim-users <
exim-users@exim.org> wrote:

> I have a set of ACL's in place to ban connections from IP's after a
> number of retries. The first one checks if connections from an IP
> address have already been rejected 5 times or more in 24 hours and drops
> them, while the second one just adds to the count (up to 10 max) every
> time we reject a connection:
>
> acl_check_connect:
>
> drop  message  = Temporary ban - too many retries
>ratelimit= 5 / 24h / per_conn / readonly
>
>
> drop  message  = PTR record check failed
> ! condition  = ${lookup
> dnsdb{defer_never,ptr=$sender_host_address}{yes}{no}}
> ! ratelimit  = 10 / 24h / per_conn / leaky
>
>
> However, the above doesn't seem to work - the second acl matches 10
> times, and after that exim just accepts the connection - the first acl
> never kicks in:
>
> 
>
> 2019-07-29 06:39:12 H=[185.208.211.29] rejected connection in "connect"
> ACL: "Reject: PTR record check failed (185.208.211.29)"
> 2019-07-29 06:39:12 no host name found for IP address 185.208.211.29
> 2019-07-29 06:39:27 H=[185.208.211.29] rejected connection in "connect"
> ACL: "Reject: PTR record check failed (185.208.211.29)"
> 2019-07-29 06:39:27 no host name found for IP address 185.208.211.29
> 2019-07-29 06:39:33 1hryNd-0003te-FT <= tran...@ourdomain.co.uk
> H=(WIN-JOFTN72POB6) [185.208.211.29] P=esmtp S=1309
> 2019-07-29 06:39:34 1hryNd-0003te-FT => spam_vic...@gmail.com
> R=send_direct T=remote_smtp H=gmail-smtp-in.l.google.com [64.233.184.26]
> X=TLSv1.2:ECD>
> 2019-07-29 06:39:34 1hryNd-0003te-FT Completed
>
>
> It is possible that I am misunderstanding how ratelimit works though.
> Any helps would be appreciated.
>
>
>
>
>
> --
> ## 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/
>


-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] The most used Exim version is the vulnerable one

[Mike Brudenell via Exim-users]

On Tue, 11 Jun 2019 at 17:24, Niels Dettenbach (Syndicat IT & Internet) via
Exim-users  wrote:

> If i read right, the most major distributors (as exim maintainers too)
> backported any patch or solution at least to the most used earlier versions
> (still provided in their patches / sec updates - so the "90% of vulnerable"
> may be way to high att. But 90% sound "more impressive"...ß).
>
> just my .02$
>
> niels.
>

I can confirm that the patch was backported/applied to Ubuntu 18.04LTS.
Their updated package for that distribution is called "Exim
4.90.1-1ubuntu1.2". However the greeting string Exim returns to a client on
connection (which is where I think the stats will have been gathered from)
is unchanged from before the patch. So yes, I suspect that 90% is on the
high side, or more accurately should be described as servers needing/that
needed the patch.

Cheers,
Mike B-)

-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] exim-users list and replies

[Mike Brudenell via Exim-users]

On Sun, 19 May 2019 at 17:17, Jeremy Harris via Exim-users <
exim-users@exim.org> wrote:

> I don't need a copy sent direct; I read the mailinglist.
> Please use some basic mail etiquette.  If Icloud is incapable
> of doing that, or makes it hard, you need to consider using
> a better provider.


If the desired behaviour for the list is for people to reply to the list as
a whole rather than the individual author perhaps the settings for the list
need reviewing and correcting. For example, Jeremy's reply to the list
includes

From: Jeremy Harris via Exim-users 
Reply-To: Jeremy Harris 


then, on hitting *Reply*, most people's email clients will construct a
private reply to Jeremy's address alone. The alternative is to use *Reply
to all* which then includes the exim-users address but also retains the
Reply-to address, thereby incurring the Wrath of Jeremy.

Given that most email clients only offer *Reply* or *Reply to all* then if
we do want people to reply to the list perhaps the Reply-to header should
be set to the list's address?

Just a thought…
Mike B-)

-- 
*My normal working days are Tuesdays, Wednesdays and Thursdays.*

Systems Administrator working in Teaching & Learning
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Relay prevention in old config

[Mike Brudenell via Exim-users]

Hi, Kai -

Dredges the memory… Those characters weren't just about relaying protection:

   - % explicitly requested routing/relaying through intermediate systems
   - ! was used in UUCP addresses and so could be used for relaying (does
   UUCP still exist? :-)
   - @ is obviously the separator between local part and domain, and was
   sometimes used by spammers to foll people into thinking the message was
   from somewhere else — eg, f...@example.net@example.com was shown by some
   email clients to be from "f...@example.net" when in fact it is an "@
   example.com" address
   - / starts file paths on Unix and could sometimes be used to deliver the
   content of the message to a file — eg, perhaps over the content of your
   password file?
   - local parts starting with a "." could also refer to files — eg, ./name
   in the current directory or ../name in the parent directory
   - | piped the incoming message to a program so could be used on some
   systems to do nefarious things
   - ; separates Unix commands in a list, and is often used as a separator
   or terminator in other types of database lookup.

Many of these might be less/no longer dangerous in well-configured systems.
But given the history email used to have of attack vectors using such
characters being used it's arguably playing it safe to disallow them still
(assuming you don't need them) to help protect your setup … just in case!
:-)

Cheers,
Mike B-)

On Wed, 6 Mar 2019 at 08:36, Kai Bojens via Exim-users 
wrote:

> I recently found this in an old exim config:
>
> ###
> # Deny if the local part contains @ or % or / or | or !. These are
> # rarely found in genuine local parts, but are often tried by people
> # looking to circumvent relaying restrictions.
> # Also deny if the local part starts with a dot. Empty components aren't
> # strictly legal in RFC 2822, but Exim allows them because this is
> # common.
> # However, actually starting with a dot may cause trouble if the local
> # part is used as a file name (e.g. for a mailing list).
> denylocal_parts = ^.*[@!/|] : ^\\.
>
>
> Is this config still relevant? I couldn't think of any way of how to
> circumvent relaying restrictions by using special characters.
>
> --
> ## 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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] ${address: foo(comment)@bar.org}

[Mike Brudenell via Exim-users]

>
> But you're not dealing with a From: header.  You're only doing
> a ${address:foo} expansion with a literal string for foo,
> in this test.  And "foo" gets string-processed, which means
> backslash-interpretation for escaping.
>

Doh! I've got it now. So if it had instead been ${address:$h_from:} (syntax
probably wrong, but you get my drift) then it would have worked even though
the $h_from: contained only a single \ in its value.

Thanks for the explanation!

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] ${address: foo(comment)@bar.org}

[Mike Brudenell via Exim-users]

On Wed, 13 Feb 2019 at 12:10, Jeremy Harris via Exim-users <
exim-users@exim.org> wrote:

> On 13/02/2019 11:07, Mike Brudenell via Exim-users wrote:
>
> > exim -v -be '${address:Pete(A nice \) chap) }'
> > gives the empty string, suggesting Exim thinks it's a parse error
>
> You'd be needing to double the backslash, for the string-parsing
> stage of the 822 address there, to actually get a backslash as
> part of the 822 address.  Do that, and it's fine and gets
> the right result for the expansion.
>

Umm… That address string is taken straight out of the RFC, which states it
is a perfectly valid address for a header as it is:

https://tools.ietf.org/html/rfc5322#appendix-A.5

From: Pete(A nice \) chap) 
…

The above example is aesthetically displeasing, but perfectly legal.
Note particularly (1) the comments in the "From:" field (including
one that has a ")" character appearing as part of a quoted-pair);


Or would Exim, on encountering that particular From header, have not
assigned "Pete(A nice \) chap) " to $h_from: but instead
have itself spotted and doubled up the \ when assigning the value? I
confess I haven't tried it to check, but it seems unlikely; I'd have
expected it to copy the value verbatim?


> Incidentally, the first couple of times I tried the above I forget to wrap
> > the address within ${address: … } and the result was Exim generating a
> > PANIC:
>
> (note, an entry in the panic-log.  Not a process panic like a SEGV.)
>
> > exim -v -be 'Pete(A nice chap) '
>
> The string starts with a capital, so Exim thinks it's a macro
> (they recently became supported by "-be").
> We might do better with the error location given, but calling
> it an error is correct.
>

Ah! That would explain it. I hadn't spotted that and, as I don't make much
use of macros, had forgotten about their capital letters.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] ${address: foo(comment)@bar.org}

[Mike Brudenell via Exim-users]

Hmm… There does seem to be an oddity. Jasen gave a link to an "extreme
example" included in the RFC:

https://tools.ietf.org/html/rfc5322#appendix-A.5


Trying this in various forms using Exim 4.90.1 on Ubuntu shows up some
interesting things:

exim -v -be '${address:Pete(A nice chap) }'

gives p...@silly.test

exim -v -be '${address:Pete(A nice \) chap) }'
gives the empty string, suggesting Exim thinks it's a parse error

exim -v -be '${address:Pete(A nice chap) }'

gives pete(his account)@silly.test(his host)


From the RFC's description I think it's expecting all to yield
p...@silly.test
The same "extreme example" has some even more fiendish addresses in the
samples To and Cc headers which I've not tried.

Incidentally, the first couple of times I tried the above I forget to wrap
the address within ${address: … } and the result was Exim generating a
PANIC:

exim -v -be 'Pete(A nice chap) '
gives

LOG: PANIC
  Exim configuration error in line 1590 of /etc/exim4/exim4.conf:
  malformed macro definition


where line 1590 is the final line of my exim4.conf file (a comment). Trying
this again with the -d+all option reveals nothing helpful. Is this another
issue?

Cheers,
Mike B-)


On Wed, 13 Feb 2019 at 10:23, Jeremy Harris via Exim-users <
exim-users@exim.org> wrote:

> On 13/02/2019 05:41, Jasen Betts via Exim-users wrote:
> > the string expansion operator ${address:
> >
> >  doesn't seem to strip RFC5322 comments (described in section 3.2.2)
> >
> >  https://tools.ietf.org/html/rfc5322#section-3.2.2
> >
> > An extreme example:
> >
> >  https://tools.ietf.org/html/rfc5322#appendix-A.5
> >
> >  Should it be doing that?
>
> My reading of the docs says "yes, it should".
> An example for me to feed to "exim -be" ?
> --
> Thanks,
>   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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] exim spfquery config

[Mike Brudenell via Exim-users]

Hi, Emanuel -

On Tue, 12 Feb 2019 at 15:42, Emanuel Gonzalez via Exim-users <
exim-users@exim.org> wrote:

> Hi, compile exim with support for spfquery, but not work.
>
> I read this documentation:
> https://github.com/Exim/exim/wiki/SPF


The above documentation says that the right hand side of Exim's "spf"
keyword can be "pass", "fail", "softfail" and so on.


spfquery --sender=soys...@gmail.com --ip=200.58.112.191
> softfail
> domain owner discourages use of this host
>

The output above says that the result of the SPF test for your message is
"softfail".



> deny message = $sender_host_address is not allowed to send mail from
> $sender_address_domain
>  spf = fail
>

But here you are saying that if the SPF result is "fail" then deny the
message.

Perhaps you should use "softfail" instead?
Or, if you want to deny messages that fail or softfail, use a list of
values as per the documentation? Eg,

spf = softfail:fail


However do please be cautious about denying messages that only softfail.
This result is often used by organisations who are still working on
transitioning to a strong SPF policy of fail, and are still working on
identifying sending sources. Generally a softfail should be interpreted as
"accept, but treat with extra caution" (eg, change the thresholds at which
you consider a message to be spam).

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] cut subjects that are too long + delete emojii from subject lines...

[Mike Brudenell via Exim-users]

Hi, Sebastian -

What you suggest doesn't sound to be a good idea to me, unless you're
planning to do it *only* at the point of final delivery into the
recipient's mailbox. (You saying you'll make the change then "send the
message along" suggests you're not thinking of doing this though, but
applying it to all messages as they pass through.)

I say this because of the message has been digitally signed using DKIM
altering the Subject line will invalidate the signature and possibly cause
problems at any downstream mail servers the message is transmitted to:
possibly causing the message to be marked as spam or rejected.

If the problem lies in certain IMAP clients your users use wouldn't it be
better to report the bug in them and get them fixed? It sounds like they're
broken!

Cheers,
Mike B-)

On Wed, 28 Nov 2018 at 07:04, Sebastian Nielsen via Exim-users <
exim-users@exim.org> wrote:

> How can I reliably cut subjects that are too long, without breaking
> for example quoted-printable encodings and such?
>
> Ergo, if the subject line exceeds X characters (where X characters are
> a limit I as system administrator decides) it should just truncate the
> decoded subject line, reencode it, and then send the mail along.
>
> The reason I want to do it, is because some IMAP clients do crash when
> it tries to export/backup email with too long subject lines as it
> tries to write the subject as a filename, and the operating system
> returns a error code the IMAP client don't understand = crash.
>
> Also I want in the same way, filter away all and any emojii (for
> example the truck in Ebay's "Order is now being delivered" emails)
> from subject lines because emojii also causes these IMAP clients im
> talking about to crash (because obviously emojii can't be used as
> filenames), and emoji in email subjects are so useless so im
> speakless...
>
> Any ideas?
>
> --
> ## 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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Help extracting From-Address

[Mike Brudenell via Exim-users]

Hi, Lena -

On Sat, 24 Nov 2018 at 12:17, Lena--- via Exim-users 
wrote:

> In messages from mailing lists (such as this [exim-users])
> the domain in "From:" header fails SPF.
>

SPF checks should be performed on the domain of the RFC5321.MailFrom
address, not the RFC5322.From header.

(If you're also doing DMARC checks and the domain of the address in the
RFC5322.From header published a DMARC record you then need to check whether
the domains  of the RFC5321.MailFrom and RFC5322.From "align", as per the
aspf tag of the DMARC policy.)

Cheers,
Mike B-)
-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Outstanding problems with Exim 4.90.1?

[Mike Brudenell via Exim-users]

Hi, Andreas -

Technically: Yes (probably).
Politically: I'm going to talk it over with my boss later in the week.
I'll let the list know what the outcome is.

Many thanks,
Mike B-)

On Thu, 27 Sep 2018 at 18:18, Andreas Metzler via Exim-users <
exim-users@exim.org> wrote:

> Jeremy Harris via Exim-users  wrote:
> > On 9/27/18 9:59 AM, Mike Brudenell via Exim-users wrote:
> >> Thanks, Andreas, but I think this is a different problem…
>
> > But it does match the first problem you described, where you got
> > a duplicate delivery (and a msglog unlink error).  The reporter
> > of it also saw the unlink error.
>
> > Does your Ubuntu version carry that fix Andreas noted?
> > It was cfbb0d24e8 in the Exim master branch; 56b566daa2
> > in exim 4.91+fixes, dated 2018/05/05.
>
> Hello,
>
> it won't be included. Are you able run packages from Debian backports?
>
> cu Andreas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>
>
> --
> ## 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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Outstanding problems with Exim 4.90.1?

[Mike Brudenell via Exim-users]

I've managed to unpack the .xz archive files (Tip: just use GNU tar and it
recognises/unpacks it) for the source and patches and it doesn't appear to
have been applied. I'm not overly surprised as they'll have been working
towards the release of Ubuntu 18.04 LTS (Long Term Stable) which happened
in April 2018.

However the next release of Ubuntu 18.10 (cosmic) will contain Exim 4.91
and checking its source code shows that patch has indeed been applied to it.

Sadly our current policy is to only use LTS releases of Ubuntu, so unless
this changes I guess I'm stuck with 18.04 LTS and the unpatched Exim 4.90.1
for the next 18 months: hence no cutthrough still. (I've just asked, and
our policy is unlikely to be changed. Hey-ho.)


On Thu, 27 Sep 2018 at 12:26, Evgeniy Berdnikov via Exim-users <
exim-users@exim.org> wrote:

> On Thu, Sep 27, 2018 at 11:04:46AM +0100, Mike Brudenell via Exim-users
> wrote:
> >- We're using Ubuntu 18.04.1 LTS (bionic) with the
> >package exim4-daemon-heavy 4.90.1-1ubuntu1.
>
>  On Debian/Ubuntu look into /usr/share/doc/exim4-base/changelog.gz.
>  As Andreas wrote, the patch was for 4.91+.


I'd noticed that,  but Jeremy asked me to check the Ubuntu distribution of
the 4.90.1 we're using: I guess just in case it had been backported.

Cheers,
Mike B-)

On Thu, 27 Sep 2018 at 12:06, Jeremy Harris via Exim-users <
exim-users@exim.org> wrote:

> On 9/27/18 11:04 AM, Mike Brudenell via Exim-users wrote:
> ><
> http://changelogs.ubuntu.com/changelogs/pool/main/e/exim4/exim4_4.90.1-1ubuntu1/changelog
> >
> >to their *Ubuntu Changes* page listing changes.
>
> From the dates, that runs up to mid-February. So, no - it seems
> unlikely.  Is that Ubuntu's most recent?
> --
> 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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Outstanding problems with Exim 4.90.1?

[Mike Brudenell via Exim-users]

Ah-ha! My apologies: I'd forgotten that was causing duplicate deliveries
too. (I've not had my first cup of coffee here yet!)

I'm not brilliant at checking whether a specific patch has been included
within a Ubuntu-distributed package…

   - We're using Ubuntu 18.04.1 LTS (bionic) with the
   package exim4-daemon-heavy 4.90.1-1ubuntu1.
   - The page at the Ubuntu packages site is here
   .
   - It has an onward link
   

   to their *Ubuntu Changes* page listing changes.

Sadly I get stuck there, not being able to figure out from that Change Log
whether the patch has been backported from 4.91 to 4.90.1 and applied or
not. I've tried downloading the source code from there but can't get it
unpacked; bring back straightforward .tar.gz files!

However I do see Andres' name many times in the Ubuntu package's Change
Log… :-)
Andreas, do you know if that patch has been backported/applied?

Cheers,
Mike B-)
-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Outstanding problems with Exim 4.90.1?

[Mike Brudenell via Exim-users]

Thanks, Andreas, but I think this is a different problem…

On my Exim I see either:

   - the message is accepted into the queue then successfully delivered
   onward and removed from my queue, but the sending MTA doesn't see the SMTP
   2xx response so *it* retains the message in *its* queues, or
   - the message does not arrive into my queue completely, with each end
   sitting there waiting for something, before eventually one end times out
   and the connection closes again leaving the message in the *far end's*
queue.

It's this first that's giving rise to duplicate transmissions from the far
MTA and deliveries, and the latter to repeated attempts to transmit the
message in to us and having it fail.

There must be something odd somewhere if others are using cutthrough
successfully, as these servers only relay a small amount of incoming mail
to a couple of local servers plus virtual host some legacy domains. It's
not exactly busy! Strange…

Cheers,
Mike B-)

On Wed, 26 Sep 2018 at 19:00, Andreas Metzler via Exim-users <
exim-users@exim.org> wrote:

> Mike Brudenell via Exim-users  wrote:
> [..]
> > The sad news is that I've had to give up on cutthrough_delivery and turn
> it
> > off. The problems we were seeing:
> [...]
> >- Duplicate deliveries when our Exim sometimes received enough of the
> >message to spool into the queue but the far end didn't get the SMTP
> >acknowledgement because the connection had "stuck", so held the
> message in
> >their queues to retry later;
>
> Sounds like this change in exim 4.91+fixes:
>
> JH/05 Bug 2273: Cutthrough delivery left a window where the received
> messsage
>   files in the spool were present and unlocked.  A queue-runner could
> spot
>   them, resulting in a duplicate delivery.  Fix that by doing the
> unlock
>   after the unlink.  Investigation by Tim Stewart.
>
> cu Andreas
>
>
> --
> ## 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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Outstanding problems with Exim 4.90.1?

[Mike Brudenell via Exim-users]

I've got the OK to share the anonymised logs with Jeremy and will try and
get them prepared and sent to him tomorrow.

The sad news is that I've had to give up on cutthrough_delivery and turn it
off. The problems we were seeing:

   - Errors going to paniclog about failing to unlink msglog files
   (although could be muted from nightly reports by changing
   the E4BCD_PANICLOG_NOISE variable in etc/default/exim4 to a suitable
   pattern);
   - A variety of client systems suffering from "stuck" connections:
   waiting for a response over the TCP/IP connection but not getting it, and
   one end or the other eventually timing out;
   - Duplicate deliveries when our Exim sometimes received enough of the
   message to spool into the queue but the far end didn't get the SMTP
   acknowledgement because the connection had "stuck", so held the message in
   their queues to retry later;
   - Unusually high numbers of active Exim processes as reported by exiwhat
   and confirmed by high TCP/IP counts logged in mainlog (caused by the
   "stuck" connections).

We believe we've confirmed that cutthrough_delivery is the cause:

   - Checking historic connection counts show they started climbing within
   a minute of enabling cutthrough. (Not noticed because our test messages all
   went through. Sigh!)
   - After disabling cutthrough today connection counts (reported by
   exiwhat and logged in mainlog) immediately started returning to the normal
   levels or just 1 or 2 at any given time. After 10 minutes (the timeout for
   stuck jobs) all was back to blissful normality.

Cheers,
Mike B.
-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Outstanding problems with Exim 4.90.1?

[Mike Brudenell via Exim-users]

Hi, Jeremy -

Proxies seem to have been introduced sometime between Exim 4.86.2 which we
were running before and 4.90.1 so I don't know it's significance. What does
it imply/in what way is it worrying? In case it's relevant, our mail
gateways sit behind an LVS load balancer so that incoming connections go to
that, which then uses ARP mangling to send traffic onward to a gateway in
the pool, with return traffic going direct to the client system. Could this
be causing Exim to see/log a proxy being used?

I'm trying to contact the user to get his OK to share the logs he sent in.
If he gives the OK would you mind me sending them direct to yourself
instead of the exim-users list? Or would you prefer them to go to the list
(in which case I'll need to also let him know they'll effectively be
publicly visible and I'll need to do some light redaction on them)?

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Outstanding problems with Exim 4.90.1?

[Mike Brudenell via Exim-users]

A little more information gleaned from the logs here…

I'm only seeing the "failed to unlink" errors in paniclog on our gateways
which receive email from the outside world. It's only these that use
cutthrough at all, so it seems to be linked to that.

I can see from the logs that we were receiving messages using chunking into
all the gateways: those handling mail arriving from the outside world, and
also the ones handling locally created emails. I've not had any reports of
problematic deliveries from these yet, but they might not show as they'd
likely be going to Gmail which de-duplicates multiple copies of the same
message with the same Message-ID.

Is cutthrough still not ready for primetime use?
Any ideas why a remote server might be seeing an SMTP timeout instead of
the acknowlegement return code?

Cheers,
Mike B-)


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] DKIM signing options - specially list of headers

[Mike Brudenell via Exim-users]

Hi, Sebastian -

You didn't tell us the version of Exim you're running so I can't give you
the exact chapter/section names, but if you look in the *Specification* for
the chapter on DKIM, in the section called something like *Signing outgoing
messages* you'll find the description of dkim_sign_headers.

However I'd have thought that the defulat set of headers should be OK as
the *Specification* does explain:

When unspecified, the header names listed in RFC4871 will be used, whether
or not each header is present in the message. The default list is available
for the expansion in the macro "_DKIM_SIGN_HEADERS".


I
n particular that RFC's *Recommended Signature Content
* explicitly recommends
DKIM-signing various List-* headers. I'd be tempted to point this out to
the people complaining and suggests they look elsewhere for the cause of
their problems.

Cheers,
Mike B-)

On Tue, 31 Jul 2018 at 09:51, Sebastian Arcus via Exim-users <
exim-users@exim.org> wrote:

> I post messages from time to time to Spamassassin mailing list, and
> several members have been complaining about my DKIM setup - they say
> they can't receive my emails because of it. Specifically, the complaint
> is that my Exim signs the List-* headers. Now I can't really figure this
> one out. There don't seem to be any fine-grained DKIM signing options in
> Exim. My messages to the list arrive looking like this:
>
>
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=open-t.co.uk; s=20170820;
> h=Content-Transfer-Encoding:Content-Type:
>
> MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:
>
> Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
>
> :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
> List-Subscribe:List-Post:List-Owner:List-Archive;
> bh=d0g337Alhc+FWBBtMm7w/Hn67G4jbr0RsFSBcWDK2fc=;
> b=Nhn9sI6K1G8+vOfCsguSXGA8+6
>
> 0Aap3I3NcIZ3F21rrGivbp2eS+Gz42GAn/NvYrrz9RkYL5/PIqr5a6v8QhEio6KGSO1d/RIZVQMaf
>
> V7qqFyvU8GB3MAYavZa+MsLAOmVgxSk3rSAbE+Bk2RER08QGjwLKxEOotKSy6vXzF25s=;
>
>
> (sorry for the odd line breaks - it looks ok in the actual header of the
> email)
>
> My question is, the list of headers -
> "h=Content-Transfer-Encoding:Content-Type:MIME-Version " - where
> does that get generated? Is it on my Exim box - or further down the
> line? Also, why is that preventing users of the mailing list from
> receiving my messages?
>
> My setup is fairly simple - Thunderbird -> Exim -> and then direct
> sending to the recipient server.
>
> Any hints or pointers to reading material would be much appreciated
>
> --
> ## 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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Smarthost condition by h_From header variable

[Mike Brudenell via Exim-users]

Hello,

Others on the list have pointed out that you might not actually be wanting
to use the value of the $h_From variable but instead the domain of the
envelope.

If you do decide to use the domain of the From header itself you might want
to do some additional testing, or write your test defensively… The
*Specification*  does not state in its description of the
"${domain:}" string expansion that the letters in its value are
converted to lower case. Therefore I'd be minded either to test the
expression when the From header contains a domain name in capital or mixed
case letters, or write the expression defensively and use "eqi" to compare
the two strings instead of "eq".

(In contrast the *Specification* does explicitly state that when Exim
assigns the value to the "$domain" variable it is first converted to lower
case.)

Cheers,
Mike B-)

On Thu, 21 Jun 2018 at 12:11, Gallai János via Exim-users <
exim-users@exim.org> wrote:

> Dear Users,
>
> I am trying to create a smarthost manualroute route depending on From:
> header. Here is my router:
>
> smarthost:
>driver = manualroute
>domains = ! +local_domains
>condition = ${if eq{${domain:$h_From:}}{domain.com}}
>transport = remote_smtp
>route_data = XXX.XXX.XXX.XXX
>no_more
>
> What have I done wrong? Why is $h_From: variable empty in manualroute
> driver?
>
> How to make a correct condition to check the From header?
>
> Thanks in advance,
>
> János
>
>
>
> --
> ## 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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Apple + Outlook - Exim on 587 does not work - Solutions

[Mike Brudenell via Exim-users]

If I remember rightly Outlook tends to want to connect to port 465
using Implicit TLS. (Which RFC 8314 now makes the preferred choice,
reversing the previous recommendation. So anyone running AuthSMTP on port
587 only might want to review their setup and add 465 to it.)

Cheers,
Mike B-)

On Sat, 9 Jun 2018 at 15:10, Jeremy Harris via Exim-users <
exim-users@exim.org> wrote:

> It doesn't say whether it means STARTTLS or SSL-on-connect.  In case
> it's the latter, port 465 is the usual place for that; keep STARTTLS
> on 587.
> --
> Cheers,
>   Jeremy


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Help with dropping spam e-mail.

[Mike Brudenell via Exim-users]

On Mon, 14 May 2018 at 11:32, Jasen Betts via Exim-users <
exim-users@exim.org> wrote:

> On 2018-05-14, Mark Elkins via Exim-users  wrote:
> > Someone is using "ple...@help.co.za" as the source of spam e-mail. The
> > address does not exist...
>
> step 0: publish an SPF record.
>

Umm… This would help authenticate *outgoing* mail, but from the sound of it
(here and in a later message) Mark is seeing *incoming* Non-Delivery
Reports coming back *into* his  address. So an SPF
record isn't likely to help block these as his domain won't be in the
RFC5321.MailFrom address or the HELO string (used, if memory serves, when
the RFC5321.MailFrom is <> such as for Non-Delivery Reports).

You're perhaps looking at BATV
 instead so
you can discard invalid NDRs coming back as backscatter spam. But that
would be a longer term solution rather than a quick fix to address (if
you'll pardon the bijou pun-ette) the current address problem he's seeing.

Cheers,
Mike B-)
​
-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Help with dropping spam e-mail.

[Mike Brudenell via Exim-users]

Hi, Mark -

It's a little unclear from your message whether:

   - you've got an influx of messages arriving *from* ple...@help.co.za
   that you want to block, or
   - you've got an influx of messages *to* ple...@help.co.za that you want
   to block.

As you mentioned one possibility might be to create a local user of the
appropriate name I'll assume it's mail *to* that address you wish to
block/get rid of.

If you have some sort of aliasing/user mapping that you use in a redirect
router one way might be to 'alias' your ple...@help.co.za address to one of
the special recipients ":blackhole:" or "/dev/null". See the chapter *The
Redirect Router* in the *Special items in redirection lists*

 section.

Alternatively you could add an ACL to your Exim configuration that either
rejects the recipient address ple...@help.co.za when an incoming message
says it wants to go to that recipient, or you could instead accept the
recipient but then silently discard the message instead of delivering it.
For example, something like this (CAUTION: UNTESTED!) in your
acl_check_rcpt ACL:

deny recipients = ple...@help.co.za


Put this before any "accept" ACL statements. Then, when an incoming SMTP
connection sends a :RCPT TO: ple...@help.co.za", your system will reject
that recipient address with a 5xx SMTP response code so the message doesn't
get into your system but stays on the remote server (which hopefully then
won't try and deliver it again as it got a 5xx code rather than a 4xx code).

Alternatively use "discard" instead of "deny" and your server will accept
the message, send a 2xx code back to the sending server, but then discard
that recipient address. If the message was destined for several of your
users then the others will still get a copy; you can avoid this by moving
the discard into the acl_check_data ACL, as explained in the *Specification*
.

See the *Access Control Lists* chapter in the *ACL verbs*

section for more about the deny and drop verbs and their effect when in the
rcpt or data ACLs.

Those are just quick thoughts to hlep you combat the immediate problem;
others might be able to offer more insightful responses. Good luck and let
us know how you get on!

Cheers,
Mike B-)

On Mon, 14 May 2018 at 09:28, Mark Elkins via Exim-users <
exim-users@exim.org> wrote:

>
> I need help. (pun included)
>
> Someone is using "ple...@help.co.za" as the source of spam e-mail. The
> address does not exist...
>
> delivering 1fI8dS-0008Pd-DC (queue run pid 700)
> LOG: MAIN
>   ** ple...@help.co.za: Unknown user
>
> ...but I do manage the domain "help.co.za"
>
> I also allow wildcards in addresses - so "*@help.co.za" could be
> forwarded to a single "catchall" account and some customers use this to
> "fetch" all their e-mails
>
> I'm getting a few 100 per minute which upsets the Load Average - which
> stops local delivery. What would be the most appropriate means to
> /dev/null this crap. I'm running my users from a MySQL database and
> serve a few hundred domains - each with multiple email users. I'm
> running a pretty new version of exim and do this on a Gentoo machine.
>
> Either - create a user by the appropriate name and forward it to what???
>
> or - somehow tell exim when it gets an unknown user to /dev/null it ???
>
> Second would be better - as long as its logged - How do I do this?
>
> --
> Mark James ELKINS  -  Posix Systems - (South) Africa
> m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>
>
> --
> ## 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/
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exim DKIM: exim<->Exim verifies but not on Gmail or Office 365

[Mike Brudenell via Exim-users]

Hi, Robert -

I'm using 2048-bit keys here: both on our on-site mail gateways running
Exim (version 4.86.1 at present un Ubuntu) and at Google. That setup is
working OK re DKIM verification.

If you'd like to do an extra check, I find this DKIM validation site very
useful:

http://www.appmaildev.com/en/dkim/


​Click the *Next Step* button to get a temporary address​, send your test
message to it, and as soon as it arrives the page fills in with details
about whether SPF, DKIM and DMARC tests pass or fail.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exim regex limit length

[Mike Brudenell via Exim-users]

Hi, Emanuel -

I'm not quite sure what you mean by "create it in more directions" but from
the example you give afterwards I'm guessing you're wanting to match
Subject text when:

   - there are between 0 and 20 characters, and then
   - the string "Unlock Your Account" with exactly those upper and lower
   case letters, and then
   - between 0 and 20 characters to the end.

If that's the case then you're almost right with your second example, but
not quite. Try this instead:

${if match{$header_subject:}{\N^.{0,20}Unlock Your Account.{0,20}$\N}}


I'll take the time to talk you through this, but really you need to read
and learn about PCRE regular expressions — that is, the sequences of
special characters you can put into a pattern to make it match against what
you want. Please take the time to do so.

But for this time…

   - The "match" expansion condition takes two arguments: the first is the
   text string you want checking, and the second the regular expression to
   compare it again. Each of these in enclosed within braces ("curly
   brackets").
  - The first argument is therefore the value of the Subject header
  — $header_subject:
  - The second argument is the regular expression you're wanting to
  match against — \N^.{0,20}Unlock Your Account.{0,20}$\N

  - Breaking the second argument down, you'll see it is enclosed within
   "\N" at its start and end. These tell Exim that the content within these
   markers is a regular expression and not to expand it further. So that
   leaves us with the regular expression itself, which is
   ^.{0,20}Unlock Your Account.{0,20}$

Looking at each element of this in turn:

   1. The "^" at the start means "the start of the text string". (That's
   what Jeremy was referring to when he was talking about the search in your
   original question not being anchored to the start of the string. Without
   this the next bit wouldn't achieve anything useful.)

   2. "." means "any one character" — this can be anything: letter, digit,
   punctuation character.

   3. Then comes "{0,20}" which means "between 0 and 20 instances of the
   thing just before". In this case the thing just before the "{0,20}" is the
   "." — so altogether we have ".{0,20}" which means "between 0 and 20
   characters".

   4. Next we've got the exact string "Unlock Your Account" which must
   appear exactly like that, including the right mix of upper and lower case
   characters. So, for example, "Unlock your account" would NOT match the
   pattern whilst "Unlock Your Account" would.

   5. Next we have the same ".{0,20} as before — meaning "between 0 and 20
   characters".

   6. Finally there is a "$", which means "the end of the text string" (in
   effect it's the opposite of "^").

So putting all that together, "^.{0,20}Unlock Your Account.{0,20}$" means
"The start of the string, followed by between 0 and 20 of any characters,
followed by the exact string 'Unlock Your Account', followed by between 0
and 20 of any characters, followed by the end of the string."

If you wanted to also match "Unlock your Account", "Unlock your account",
"unlock your account" and so on then you can add in "(?i)" which makes the
rest of the regular expression match content without worrying about whether
letters are upper or lower case:

${if match{$header_subject:}{\N^.{0,20}(?i)Unlock Your Account.{0,20}$\N}}



*Where next…*
You can probably track down a tutorial on the web for regular expressions,
but be careful as there are lots of 'flavours' of regular expression, with
slightly different syntaxes: regular expressions, extended regular
expressions, and so on. Exim uses PCRE (Perl Compatible Regular
Expressions), which is generally a superset of most other forms. (I'm sure
I'll be lambasted for saying that, but it's largely true.)

So even if you just start by learning about basic regular expressions
you'll be on the right path. Maybe somewhere
https://www.regular-expressions.info/index.html will get you going. Someone
else might know of a better tutorial though.

It's important that you have a read and learn about regular expressions if
you're going to be using them. You can't rely on us creating or correcting
them for you all the time.

Cheers,
Mike B-)

On 23 April 2018 at 13:41, Emanuel Gonzalez via Exim-users <
exim-users@exim.org> wrote:

> Hello.!!
>
>
> This rule is work fine:
>
>
> ${if match{$header_subject:}{\N^.{0,20}Unlock Your Account$\N}}
>
> Is it possible to create it in more directions?
>
>
> ${if match{$header_subject:}{\N^.{0,20}Unlock Your Account{0,20}.\N^}}
>
>
> I await the final instructions to close the case, thanks to all
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: 

Re: [exim] Logging used port

[Mike Brudenell via Exim-users]

Read the description of *log_selector* in the *Exim Specification* chapter
on Log Files, and the options you can set with it. :-)

Be careful when thinking about what you're wanting to achieve. The "H="
field logs the IP address (and optionally port) of the remote server,
whereas the "I=" field records the IP address (and optionally port) of the
interface on your own server. In your example you indicate you're expecting
something like ":25" to be logged, which suggests you're possibly
interested the port number your Exim has received the connection on rather
than the port at the far server that sent you the message.

Cheers,
Mike B-)

On 20 April 2018 at 10:58, Luca Bertoncello via Exim-users <
exim-users@exim.org> wrote:

> Hi list!
>
> Is it possible to log the used port for the incoming E-Mail in the mainlog?
> Currently I have something like:
>
> 2018-04-20 11:57:02 1f9Sms-wer857-24 <= b...@blah.de H=(mail.blah.de)
> [1.2.3.4] P=esmtps X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 S=4980 id=
> kcim.5ad9b96d.3343.319236551223c...@mail.blah.de
>
> And I'd like to have:
>
> 2018-04-20 11:57:02 1f9Sms-wer857-24 <= b...@blah.de H=(mail.blah.de) [
> 1.2.3.4:25] P=esmtps X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 S=4980 id=
> kcim.5ad9b96d.3343.319236551223c...@mail.blah.de
>
> How can I do that?
>
> Thanks a lot
> Luca Bertoncello
> (lucab...@lucabert.de)
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] ACL verb "reject" - An error in the Specification?

[Mike Brudenell via Exim-users]

Am I going mad?

Section 43.36 *Detailed information from merged DNS lists*

in
the Specification has two examples, such as:

reject message  = \
 rejected because $sender_host_address is blacklisted \
 at $dnslist_domain\n$dnslist_text
   dnslists = \
 sbl.spamhaus.org,sbl-xbl.spamhaus.org=127.0.0.2 : \
 dul.dnsbl.sorbs.net,dnsbl.sorbs.net=127.0.0.10

But section 43.18 *ACL verbs*

doesn't
list "reject" as a valid verb.

An error in the Specification text?
Or are my tired eyes missing something glaringly obvious?

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Filter for Conditional Header Removal

[Mike Brudenell via Exim-users]

On 12 April 2018 at 10:05, Ajay Kajla via Exim-users 
wrote:

> Hi,
>
> We have following requirement any mail coming from a...@abc.com and subject
> contains "SomeThing" to go to x...@mydomain.com With complete headers and
> to
> a...@mydomain.com without Cc and From headers.
>
> I tried following filter but it's removing headers for both
> x...@mydomain.com
> & a...@mydomain.com.
>
> =
>
> if ("$h_from:" contains "a...@abc.com" and "$header_subject:" contains
> "SomeThing")
> then
> deliver "x...@mydomain.com" (should go to x...@mydomain.com With complete
> headers )
> endif


I can't help with the why headers are being removed for both. However my
thought is that you might want to be a bit careful with

"$h_from:" contains "a...@abc.com"


as I'm pretty sure it will also match when $h_from is, say, "z...@abc.com"
(because this also *contains* "a...@abc.com").

Mind, I might well be wrong as I've only used a system filter in one
situation, and that was about 10 years ago! :-)

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] NDN, Mailer-Daemon, DSN - EXIM

[Mike Brudenell via Exim-users]

On 11 April 2018 at 19:43, Jeremy Harris via Exim-users  wrote:

> That would be incorrect per standards.  The HELO name should identify
> the sending system.
>

Umm… Agreed, but what if this mysterious and obfuscated organisation has
multiple A records under different domain names pointing at the system Exim
is running on? Wouldn't it then be valid to use any of those in the
HELO/EHLO command? E.g.,

   - a.example.com is an A record pointing at ww.xx.yy.zz
   - b.example.net is an A record pointing at ww.xx.yy.zz

Wouldn't it then be permissible to use a.example.com in the HELO/EHLO when
sending from an "@a.example.com" address, but b.example.net when sending
from an "@b.example.net" address?

RFC 5321 section 4.1.1.1 states: "The argument clause contains the
fully-qualified domain name of the SMTP client, if one is available." which
both of the above examples would fit. (The RFC doesn't explicitly state it
has to be the rDNS name of the server, although one could argue the
following sentence — "In situations in which the SMTP client system does
not have a meaningful domain name (e.g., when its address is dynamically
allocated and no reverse mapping record is available), the client SHOULD
send an address literal" — might be taken to imply it.)

If it is the case that the primary host name of the server MUST be used,
I'm struggling to think of a use-case when Exim's helo_data could be used
validly; I'd (possibly incorrectly?) assume it was for the above type of
scenario. Is it instead, say, only for use when sending out from Exim
running on a server with multiple interfaces?

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] NDN, Mailer-Daemon, DSN - EXIM

[Mike Brudenell via Exim-users]

Hello,

Be careful: it might not be 65*3 = 195 new SPF records that you need. It
might only be three! Remember that it is whatever your Exim (in this case I
think the Exim running on the server known as corp17.company.com) puts into
its HELO/EHLO command when it connects to another server.

By default this is the primary host name of your server, as set with
primary_hostname (or if you don't set it with this then the DNS name of the
server).

Looking back at your original question you say:

The Internal server for mass mailing:
primary_hostname = corp17.company.com and the qualify_domain = company.com


That means you're setting the primary hostname to "corp17.company.com" and
it's this that Exim always use in its HELO/EHLO when it connects to another
mail server. (But see the note below!)

That means you only need a new SPF record for the *corp17.company.com
* domain name to correct that problem for that
entire mail server. You *don't* need one for every domain it happens to
send out emails from.

*Note:* The exception is if you use a *helo_data* command within your Exim
transport to set the HELO/EHLO string for each connection to, say, reflect
the domain name of the sender of the outgoing message instead of the
default action of always using the primary hostname. If you're changing the
value of the domain name in the HELO/EHLO greeting in this way then yes,
you'll need an SPF record for each domain name. (But then it would only be
65, not 3*65)

I suspect you'll only need 3 new ones in all, as most people don't use
helo_data to alter the HELO/EHLO greeting.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] NDN, Mailer-Daemon, DSN - EXIM

[Mike Brudenell via Exim-users]

Hello,

I've read through your question a few times and have a feeling I know what
might be wrong. If I'm right then it's not a problem with Exim, but that
you're missing one or more SPF records.

I think you're saying that:

   1. Someone sends a message to the non-existent email address <
   www...@gmail.com>
   2. This message goes out via the mail service running on
   corp17.company.com
   3. The server finds the recipient email address is not valid so creates
   a Non-Delivery Notification (NDN) to send back to the person who wrote the
   original email.
   4. This NDN is then either rejected, or received with a warning, by the
   Cisco ESA because SPF failed as shown in the "Received-SPF:" header you
   quoted.

Is that correct?

If it is, then check you have got an SPF record set up for the name that
the mail server running on corp17.company.com.

*Explanation:*
When you send a normal message the sender address in the SMTP envelope (the
"MAIL FROM" address) is usually that of the person sending the message.
When the receiving mail server performs an SPF check it gets the domain
name of this email address and looks up its SPF record in the DNS, then
checks the IP address of the transmitting server against that record.

However a Non Delivery Notification is different; its sender address in the
SMTP envelope is the special empty address "<>". As you can see, being
empty it has no domain name. So a mail server receiving an NDN can't get a
domain name form there to look up an SPF record.

Instead it uses the string the server used to identify itself in the
HELO/EHLO command it issued when it connected and uses that as the domain
name to look up an SPF record for.

So if your corp17.company.com mail server:

   - generates an NDN (ie, a message with an empty MAIL FROM address in the
   SMTP envelope), and
   - connects to the mail service on a system that checks SPF records, and
   - identifies itself in the HELO/EHLO string as "corp17.company.com", then
   - the receiving mail system will look for a TXT record in the DNS named "
   corp17.company.com" to get the SPF record to check against.

I made exactly the same mistake when I first set up SPF here, not realising
I had to set up an SPF record in the DNS for each of our outgoing mail
servers. (Or, more accurately, the domain name they identify themselves as
in their HELO/EHLO greeting: which happens to also be their actual host
name.)

So here I have:

   - an SPF record for our "york.ac.uk" domain so that normal emails have
   their MAIL FROM address checked against this record, and
   - an SPF record for each mail server that might generate an NDN so that
   NDNs (ie, messages with "<>" as the MAIL FROM address) are authenticated
   with SPF

For example:

   - york.ac.uk. IN TXT "v=spf1 ..."
   - mailgw0.york.ac.uk. IN TXT "v=spf1 a -all"
   - mailgw1.york.ac.uk. IN TXT "v=spf1 a -all"
   - and so on

The individual SPF records for each mail server only need to identify
themselves (by using the "A" mechanism) and no others (by using the "-all"
mechanism).

To confirm this you can read the FAQ/Common Mistakes page at the OpenSPF
web site, in particular the question entitled *Publish SPF records for HELO
names used by your mail servers*:

http://www.openspf.org/FAQ/Common_mistakes#helo


You can also find the recommendations in the RFC for SPF:

   - For the HELO identity: https://tools.ietf.org/html/rfc7208#section-2.3
   - For bounces (NDNs): https://tools.ietf.org/html/rfc7208#section-10.1.3

*The First Step You Should Do*
The very first thing you should do is check your Exim logs to make sure
what I've written applies to you. That is, that the Non-Delivery
Notification is going out with a MAIL FROM address of "<>" in its SMTP
envelope. If your Exim logs show it it really does have "
postmas...@corp17.company.com" in the MAIL FROM address instead then:

   - the solution I describe above doesn't apply to you, and
   - your "NDN" isn't actually an NDN! (Those should have an empty "<>"
   address as the MAIL FROM in the SMTP envelope.)

Cheers,
Mike B-)

On 10 April 2018 at 16:51, Nazarevych Ol via Exim-users  wrote:

> Hello, we have an issue with Non-Delivery Notification NDN in Exim 4.90_1
> There are 2 mail servers Exim and one as Email Spam Filtering - Cisco
> Ironport (ESA)
>
> The Primary Mail server:
> primary_hostname = main1.company.com, qualify_domain = company.com
>
> The Internal server for mass mailing:
> primary_hostname = corp17.company.com and the qualify_domain = company.com
>
> As MX server for domain company.com acts Cisco ESA so the all
> correspondence goes thru for a spam filtration.
> SPF, DKIM, and DMARK records configured correctly and everything works as
> well expect NDN Notification
>
> For SPF used rule for example:
> v=spf1 a mx ip4:1.1.1.1 ip4:2.2.2.2 ip4:3.3.3.3 -all
>
>
> But when someone try to sending an email through Internal server
> corp17.company.com to non existing email address for 

Re: [exim] Change attached file extension

[Mike Brudenell via Exim-users]

Hi, Dmitriy -

Jeremy's already answered saying it's not possible to change the file
extension. I'll chip in with my usual waving of a warning flag to say you
need to be very careful when thinking about altering the headers and/or
content of a message (which includes its attachments) and the message is
digitally signed with DKIM.

If you had managed to find a way of changing the filename you would have
invalidated any DKIM signature the message might have. OK, so this isn't a
problem if the message is genuinely spam, but if there's a chance it might
be legitimate you'll have just broken its authentication.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list

[Mike Brudenell via Exim-users]

Could I ask a possibly radical question of the list?

Firstly, I fully appreciate that a number of older encryption protocols and
ciphers are very weak. So *preferring* stronger ones over the weaker ones
has a clear benefit.

But given that most MTA to MTA traffic uses *opportunistic* encryption,
falling back to cleartext transfers if no encryption can be agreed between
the servers, isn't it better to continue to offer and use in such
situations a weak cipher than none at all? That is, weak encryption of a
message is better than none at all?

The exceptions being, of course, scenarios like:

   - you require your incoming MTA to MTA traffic to arrive over an
   encrypted connection and reject messages arriving in cleartext, or
   - for MUA to MSA submissions as authentication credentials are usually
   involved.

Cheers,
Mike B-)

On 28 March 2018 at 08:10, Konstantin Boyandin via Exim-users <
exim-users@exim.org> wrote:

> Hello,
>
> After having scanned 4.90.1 installation with OpenVAS, the below was
> reported:
>
> 'Weak' cipher suites accepted by this service via the
> TLSv1.0/TLSv1.1/TLSv1.2 protocols: TLS_RSA_WITH_SEED_CBC_SHA
>
> Default settings (no explicit "tls_require_ciphers", "openssl_options")
> are in use.
>
> Can someone recommend simplest ciphers selection for Exim, to exclude the
> mentioned cipher? The settings present on cipherli.st:
>
> tls_require_ciphers = AES128+EECDH:AES128+EDH
> openssl_options = +no_sslv2 +no_sslv3
>
> seem kind of too strict, there were reported problems receiving email
> after the above were put in effect.
>
> Sincerely,
> Konstantin
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] How to rewrite From: header of offsite forwards only to prevent Amazon SES 554 error

[Mike Brudenell via Exim-users]

Hi, Pete -

On 20 March 2018 at 22:04, Pete Schaefers via Exim-users <
exim-users@exim.org> wrote:

> Mike, thanks for taking the time to detail that! I guess I assumed (maybe
> wrongly) that when EXIM forwards a message that the SPF and DKIM of the
> domain on the EXIM server would apply and be in the sent forward. In that
> case wouldn't all entities align?
>

I don't think I can help with the SES side of things, but here we've got
full DKIM-signing in place along with tight SPF and DMARC policies in place
so might be able to help with that side of things a bit.

Going off memory the default Exim configuration didn't do any DKIM signing,
or rewriting of envelope or sender addresses. So if it has to forward on a
message then both the RFC5321.MailFrom envelope and RFC5322.From header
addresses are left entirely untouched; the incoming message is relayed
onward with the originals.

That means at the mail server you're relaying onward to:

   - if it checks SPF and there's a policy published for the domain of the
   RFC5321.MailFrom then this will fail in the general case — your servers
   won't be listed in the SPF policy;
   - if it checks DKIM and the original sender added a DKIM signature then
   this will pass — because the body and signed headers haven't been altered
   the message's DKIM signature will still verify.

If there's a DMARC policy for the domain of the RFC5322.From address then
this will pass because, although the SPF test has failed, the DKIM test
still passes and will (should!) have the domain of the signature align with
that in the RFC5322.From.

If you decide to rewrite the RFC5322.From without taking further measures
you will invalidate the message's original DKIM signature. That means with
neither the SPF nor DKIM tests passing the onward server may well be more
suspicious of the message and could end up marking it as spam or take other
measures. For example, Gmail usually puts a warning "Red Question Mark of
Gloom" (my name for it!) next to a message someone arrives that lacks both
SPF and DKIM passes.

The "further measures" would involve things like you adding your own DKIM
signature to the relayed message as you send it out, with its "d=
*domainname*" aligning with the domain you use in the rewritten
RFC5322.From header. Here you're effectively adding your own signature to
the message (which will should pass further down the line) even though
you've invalidated the original sender's DKIM signature.

You can add further authenticity to the message by using ARC (which I admit
freely that I don't fully understand!). I think this is a way of you
indicating to an onward mail server that when you received this message you
were able to verify its authenticity using SPF/DKIM/DMARC and so are adding
a signed header to indicate that, even though those measures might no
longer verify further down the line because you've rewritten headers and/or
changed body content (eg, by adding a "To leave this mailing list…" type of
footer). You can find a nice summary in the "Overview" section of this
document:

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-12


ARC doesn't have a formal RFC yet but is certainly used by Google for one.

As you hadn't mentioned doing DKIM signing yourself I was erring on the
side caution and alerting you to possible problems. If you want to talk
further drop me a line direct, as this has veered away from Exim itself and
the mechanics of doing things.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] How to rewrite From: header of offsite forwards only to prevent Amazon SES 554 error

[Mike Brudenell via Exim-users]

Be careful if you plan to start rewriting the RFC5322.From header. If the
message has had a DKIM signature applied to it that header's content will
almost certainly be covered by the signature to detect
tampering/alterations such as you're proposing, and you'll be invalidating
it; this might give you problems delivering to sites that validate DKIM
signatures. So you'll likely have to sign it again yourself, possibly also
using ARC to confirm the authenticity chain.

Without knowing your situation it sounds like you're trying to do the same
sort of thing as mailing lists do: send out messages originating from
senders (list contributors) from arbitrary domains? You have to be careful
with these, especially if the sender's domain has a DMARC policy other than
"none" in place. This requires the one or both of the standard SPF and DKIM
tests to pass *and* for the domain being considered to align with that in
the RFC5321.From header in order for DMARC to consider it an acceptable
pass. Modern mailing list manager software handles this by rewriting the
RFC5322.From header to use its own domain, which it can then DKIM-sign it
using its own keys.

In passing, SRS rewrites the RFC5321.MailFrom address (sender address in
the SMTP envelope) not the RFC5322.From or Sender headers. Any change to
the Sender header will likely be a byproduct, I think.

Cheers,
Mike B-)

On 18 March 2018 at 19:21, Pete Schaefers via Exim-users <
exim-users@exim.org> wrote:

> When Amazon SES receives mail is validates the From: against verified
> domains and addresses. If it does not find it valid it drops the mail and
> returns error 554. (See last couple posts in this thread for more info if
> desired: https://forums.aws.amazon.com/message.jspa?messageID=745028#
> 745028 )
>
> I am running a hosting server with cPanel and EXIM. I had hoped that SRS
> would fix this denial by changing the Sender: header and SES would accept
> it, but apparently SES ignores that, and still rejects. Amazon seems
> hesitant to address this, so I'm looking for other ways to address it.
>
> The one that seems best to me would be to rewrite the From: header to one
> that will validate (that of on sending server rather than the off server
> original). I would only want to do that when the mail is a forward,
> original sender is off server, and the recipient is off server. This would
> also mean making sure the Replyto: was set to the original sender, I would
> think.
>
> I have only a little experience with EXIM rewrites, and the syntax of the
> config file, so I'm looking for some help in programming the logic of this
> rewrite.
>
> Does this seem like a good approach, or am I missing something easier,
> such as re-configuring something already built in to EXIM about how it
> treats forward From: addresses?
>
> Thanks in advance for anyone's contribution.
>
> -Pete
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Why "blackhole"?

[Mike Brudenell via Exim-users]

On 12 March 2018 at 15:59, Luca Bertoncello via Exim-users <
exim-users@exim.org> wrote:

>
> Yes! Kaspersky. And I must say, that I already had some suspect on that...
>
> If local_scan says to accept the message but it has no recipients left it
>> is blackholed.
>>
>
> OK, thanks.
> But I really can't find any place in my configuration to delete the
> recipients...
>

The sample configuration you posted is just a set of ACLs entries. The
*Specification* seems to be saying that when Exim calls the function
specified by *local_scan* then that function itself can delete recipients
from the list. If so and *that* is removing all the recipients but then
tells Exim to accept the message it ends up getting blackholed.

However I've never used local_scan so might be entirely wrong. Can someone
who knows more about it confirm?

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Why "blackhole"?

[Mike Brudenell via Exim-users]

Have you added a local_scan function to your configuration?

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-adding_a_local_scan_function_to_exim.html


If so, then it sounds like it has decided to discard all the recipients for
that incoming message. If you read the *Specification* it says (emphasis
mine):

The list of accepted recipients, held in a vector of length
recipients_count. The recipient_item structure is discussed below. You can
add additional recipients by calling receive_add_recipient() (see below). *You
can delete recipients by removing them from the vector and adjusting the
value in recipients_count. In particular, by setting recipients_count to
zero you remove all recipients. If you then return the value
LOCAL_SCAN_ACCEPT, the message is accepted, but immediately blackholed.* To
replace the recipients, you can set recipients_count to zero and then call
receive_add_recipient() as often as needed.


If local_scan says to accept the message but it has no recipients left it
is blackholed.

Cheers,
Mike B-)

On 12 March 2018 at 15:30, Luca Bertoncello via Exim-users <
exim-users@exim.org> wrote:

> Hi list,
>
> I recently discovered this very curiously message in the mainlog:
>
> 2018-02-28 00:56:11 1eqp6G-0004wp-IR DKIM: d=email.microsoftemail.com
> s=102420140131 c=relaxed/relaxed a=rsa-sha1 b=1024 [verification succeeded]
> 2018-02-28 00:56:12 1eqp6G-0004wp-IR LMS check accept: 250 OK
> 2018-02-28 00:56:12 1eqp6G-0004wp-IR <= bounce-866153_HTML-528534629-5
> 439879-228974-...@bounce.e-mail.microsoft.com H=(
> mta28.email.microsoftemail.com) [66.231.92.214] P=esmtps
> X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 S=69286
> id=df627243-be0d-4776-9939-7408baf52...@xtinmta177.xt.local
> 2018-02-28 00:56:12 1eqp6G-0004wp-IR => blackhole (local_scan discarded
> recipients)
> 2018-02-28 00:56:12 1eqp6G-0004wp-IR Completed
>
> I really can't understand why the E-Mail will be discarded.
> Can someone help me?
>
> Thanks
> Luca Bertoncello
> (lucab...@lucabert.de)
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Router testing with "source port"

[Mike Brudenell via Exim-users]

Hi, Luca -

Take a look at the *The Exim command line* section in the *Exim
Specification*. In there you'll find many options beginning with "-oM" that
can be used to set all sorts of things. For example, you might find the
-oMa option useful.

You can use these with -bt, or you can do other types of testing such as
running a fake Exim session using the -bh option (or -bhc if your
configuration uses callouts to verify addresses and you want these
performed as well).

If you've not already done so it's well worth sitting down and reading all
the way through *Specification* as it gives a lot of insights into things.
(I'm about due to read it through yet again at our next upgrade as things
do evolve as new features are introduced over the years.)

Cheers,
Mike B-)

On 12 March 2018 at 08:14, Luca Bertoncello via Exim-users <
exim-users@exim.org> wrote:

> Hi list!
>
> I have in my exim configuration many routers depending from the port used
> to send the E-Mail.
> Now I need to test them and I really don't know how... :(
>
> To test a router I usually use exim -bt b...@blah.de, but so exim use
> ignore the source port.
> Is there any option for "exim -bt" to specify the source port of the
> E-Mail?
> Otherwise I really don't know how to test the routers...
>
> Thanks a lot for your help!
> Luca Bertoncello
> (lucab...@lucabert.de)
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exim, ClamAV and AllowSupplementaryGroups being deprectaed

[Mike Brudenell via Exim-users]

Ah-ha! Thank you, Andrew! I hadn't spotted any mention of it becoming the
default.
That's a relief.

Cheers,
Mike B-)

On 7 March 2018 at 16:24, Andrew C Aitchison  wrote:
>
> I'm running bleeding edge ClamAV on my home machine, but not in anger or
> connected to exim.
>
> The Changelog for v0.100.0-beta includes the following:
>
> Thu Dec 21 17:00:37 2017 -0500 (Steven Morgan)
> --
>  * bb11996 - deprecate AllowSupplementaryGroups more gracefully.
>
> Thu, 2 Jun 2016 11:54:01 -0400 (Mickey Sola)
> --
>  * bb11557 - drop AllowSupplementaryGroups option and make it default,
> patch by Sebastian A. Siewior
>
> It seems that the feature is staying and it is just the option that will
> go away.


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exim, ClamAV and AllowSupplementaryGroups being deprectaed

[Mike Brudenell via Exim-users]

Dear all,

For our Central Mail Gateways we run Exim on an LTS (Long Term Stable)
release of Ubuntu: currently 16.04 LTS. In April this year the next LTS
release will be coming out with updated Exim and ClamAV packages.

When we moved to the 16.04 release ClamAV stopped working with Exim, until
we found we had to explicitly add back an "AllowSupplementaryGroups: true"
setting to ClamAV's configuration file.

I keep reading things that newer versions of ClamAV have removed, or at
least severely deprecated, the AllowSupplementaryGroups setting, and am
feeling some trepidation.

Does anyone here use a recent version of ClamAV with their Exim, especially
on Ubuntu? How are you dealing with ClamAV having a group of clamav but
also needing to be in the Debian-exim group so it has access to the mail
spool for scanning? Or does AllowSupplementaryGroups now default to true
and I'm worrying unnecessarily?

I can only find web pages saying its deprecated, and nothing saying how to
let the ClamAV daemon belong to multiple groups in the Brave New World of
not having this setting.

With many thanks,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] rate limit for maximum outgoing emails to mail-relay

[Mike Brudenell via Exim-users]

Hi, Jeremy -

Sadly we're not building from source, but our policy is to use the package
that comes with the LTS (Long Term Stable) release of Ubuntu on which we
run the service. The next LTS release is due in April, at which point I
leapfrog from 4.86 + security fixes to 4.90.1. (Yay!) A shame, as I'm
pretty sure being able to detect the pass number would be a quick fix for
the router/ACL combo.

By the way, having played with this now I'm beginning to come around to it
being a powerful and flexible way of managing rate limiting for outgoing
mail… well, if it worked with our -qq runners! :-) Maybe the way forward is
to flesh out the Wiki page you started: something I'm happy to try and do
if you/others would then check it and correct/improve any mistakes etc I
make.

I'm going to check whether the hosts I used to have to try and limit
connections to still have that restriction; I know there have been some
changes made to them. If so, I might be able to use the -q option to spark
queue runners instead of -qq as a workaround.

As for top-posting, that's a habit brought about by many modern email
programs. My preference used to be for interleaved (back in the days of
Pine!), then top-posting, followed by bottom-posting (wading through tons
of old stuff to reach the new is a pain). With G Suite's mail it not only
creates your reply to top-post but also conveniently hides all the included
content, making it easy to overlook and trim. As it hides included content
by default on received messages, us Gmail/G Suite users are now all used to
not having to see/worry about it. :-)

I'll try to remember, but it's already a faff replying to the list as it is:

   - Hitting Reply would send my message to you personally and not the list.
   - So to get the list's address included I have to change to Reply To All.
   - But that includes your own individual address too, which I know you
   also dislike, so then I have to edit your address out of the TO, and move
   the list address from CC to TO.
   - Manually trimming out included text is then yet another step:
   difficult to remember when (a) it's hidden from sight below a faint grey
   ellipsis character, (b) I'm used to not having to do it for the bulk of
   emails I send and (c) my mind is focussed on the problem/solution.

But I'll try… :-)

(And indeed have just managed to stop my fingers from clicking Send before
actually doing the trimming this time!)

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] rate limit for maximum outgoing emails to mail-relay

[Mike Brudenell via Exim-users]

I think I can see what's happening now, but not how to fix it…

   1. I have 5 test messages in the queue going to my mailbox.
   2. I delete the ratelimit and retry hints databases so I'm starting from
   a clean base.
   3. I do an "exim -d+all -qq"
   4. The first routing run of the -qq option activates and accepts the
   first couple of messages, increasing the computed ratelimit as it does so.
   This reaches the limit I've set, so the remaining messages are then
   deferred. So far so good.
   5. The second routing run of the -qq option then activates to perform
   deliveries. This routes each message *again*, uses the ratelimiting
   router and in doing so sees the high computed ratelimit so now *all* of
   the messages now get deferred.

There might also be an (as yet unconfirmed) problem with my setup in that
if the first pass didn't reach the rate limit then the second pass might
when it re-routes the messages: effectively counting each message twice
towards the computed rate (once in the first pass, once in the second). If
so, then some or all of the messages in the second pass might be deferred
when really they should be delivered.

I think I need to stop the second pass of the -qq queue runner from using
this router again? Is there a way of doing that? Or have I got the
fundamental design of router and ACL wrong?

Cheers,
Mike B-)

On 28 February 2018 at 17:06, Mike Brudenell <mike.bruden...@york.ac.uk>
wrote:

> Bug/RFE: I'll have a think about whether I can phrase something.
>
> In the meantime, I've been playing around with the outline Jeremy
> suggested on the Wiki and thought I had it working. Indeed my testing with
> an artificially low rate of 2 messages per 1 minute showed:
>
>- submitting several messages to Exim let the first few through, then
>kept the rest in the queue marked "deferred"
>- running "exim -q" periodically allowed more to be delivered whenever
>the calculate rate dropped sufficiently
>
> So far so good.
> *But…* then I let my test server do its own thing and messages didn't go
> out from the queue! :-(
>
> After a lot of digging I discovered that the problem lies with my queue
> runners being launched using Exim's "-qq2m" option rather than "-q2m",
> which I do for efficiency purposes as some hosts I deliver to limit the
> number of concurrent connections.
>
> Peering closely at the debugging output from "exim -qq -d+all" it appears
> that the double queue run the -qq option triggers is doing something odd:
> possibly updating the ratelimit database twice, causing my artificially low
> rate limit to be reached before a single message is actually delivered. As
> the Specification says,
>
>
> In the first stage, the queue is scanned as if the queue_smtp_domains
> option matched every domain. Addresses are routed, local deliveries happen,
> but no remote transports are run.
>
> The hints database that remembers which messages are waiting for specific
> hosts is updated, as if delivery to those hosts had been deferred. After
> this is complete, a second, normal queue scan happens, with routing and
> delivery taking place as normal.
>
>
> I have no_verify set on my router, but of course this only stops it
> activating during address verification. With the -qq option Exim is
> actually doing two full routing runs.
>
> *Question:* Is there some option I've not spotted that says something
> along the lines of "update the ratelimit database for the first run of the
> -qq option but not the second"?
>
> In case it helps, here is my ACL:
>
> acl_ratelimit_outbound:
>   accept  message = :defer: Sending messages to $acl_arg1 too fast:
> deferred \
> [$sender_rate/$sender_rate_period (max
> $sender_rate_limit/$sender_rate_period)]
>   ratelimit = $acl_arg2 / readonly / outbound:${lc:$acl_arg1}
>
>   warnratelimit = $acl_arg2 / strict / outbound:${lc:$acl_arg1}
>
>   accept  message = $acl_arg1
>
>
> and my router:
>
> ratelimit_outbound:
>   driver  = redirect
>   no_verify
>   allow_defer
>   condition   = ${if exists {CFG_D/ratelimit-table}}
>   data= ${lookup {$local_part@$domain} lsearch*@
> {CFG_D/ratelimit-table} \
>  { ${acl {acl_ratelimit_outbound} 
> {$local_part@$domain}
> {$value}} } \
>  fail}
>
>
> Cheers,
> Mike B-)
>
> On 28 February 2018 at 10:34, Jeremy Harris via Exim-users <
> exim-users@exim.org> wrote:
>
>> On 28/02/18 10:17, Mike Brudenell via Exim-users wrote:
>> > So despite being a profound advocate of Exim, it is a little
>> embarrassing
>> > to tell people who ask me about outbound rate limiti

Re: [exim] rate limit for maximum outgoing emails to mail-relay

[Mike Brudenell via Exim-users]

Bug/RFE: I'll have a think about whether I can phrase something.

In the meantime, I've been playing around with the outline Jeremy suggested
on the Wiki and thought I had it working. Indeed my testing with an
artificially low rate of 2 messages per 1 minute showed:

   - submitting several messages to Exim let the first few through, then
   kept the rest in the queue marked "deferred"
   - running "exim -q" periodically allowed more to be delivered whenever
   the calculate rate dropped sufficiently

So far so good.
*But…* then I let my test server do its own thing and messages didn't go
out from the queue! :-(

After a lot of digging I discovered that the problem lies with my queue
runners being launched using Exim's "-qq2m" option rather than "-q2m",
which I do for efficiency purposes as some hosts I deliver to limit the
number of concurrent connections.

Peering closely at the debugging output from "exim -qq -d+all" it appears
that the double queue run the -qq option triggers is doing something odd:
possibly updating the ratelimit database twice, causing my artificially low
rate limit to be reached before a single message is actually delivered. As
the Specification says,


In the first stage, the queue is scanned as if the queue_smtp_domains
option matched every domain. Addresses are routed, local deliveries happen,
but no remote transports are run.

The hints database that remembers which messages are waiting for specific
hosts is updated, as if delivery to those hosts had been deferred. After
this is complete, a second, normal queue scan happens, with routing and
delivery taking place as normal.


I have no_verify set on my router, but of course this only stops it
activating during address verification. With the -qq option Exim is
actually doing two full routing runs.

*Question:* Is there some option I've not spotted that says something along
the lines of "update the ratelimit database for the first run of the -qq
option but not the second"?

In case it helps, here is my ACL:

acl_ratelimit_outbound:
  accept  message = :defer: Sending messages to $acl_arg1 too fast:
deferred \
[$sender_rate/$sender_rate_period (max
$sender_rate_limit/$sender_rate_period)]
  ratelimit = $acl_arg2 / readonly / outbound:${lc:$acl_arg1}

  warnratelimit = $acl_arg2 / strict / outbound:${lc:$acl_arg1}

  accept  message = $acl_arg1


and my router:

ratelimit_outbound:
  driver  = redirect
  no_verify
  allow_defer
  condition   = ${if exists {CFG_D/ratelimit-table}}
  data= ${lookup {$local_part@$domain} lsearch*@
{CFG_D/ratelimit-table} \
 { ${acl {acl_ratelimit_outbound} {$local_part@$domain}
{$value}} } \
 fail}


Cheers,
Mike B-)

On 28 February 2018 at 10:34, Jeremy Harris via Exim-users <
exim-users@exim.org> wrote:

> On 28/02/18 10:17, Mike Brudenell via Exim-users wrote:
> > So despite being a profound advocate of Exim, it is a little embarrassing
> > to tell people who ask me about outbound rate limiting that it's so
> > difficult in it
> Perhaps you could come up with a clean set of requirements?
> In a bug/RFE, so that others could chip in, and the need
> wouldn't be forgotten?
> --
> 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/
>

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811 <01904%20323811>

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] rate limit for maximum outgoing emails to mail-relay

[Mike Brudenell via Exim-users]

Of course the need for outbound rate limiting is not confined to sending to
Gmail/G Suite recipients. For example we see problems when a group here has
a fault with one of their software systems and it triggers umpteen emails
to their alerts/support address. This is *not* hosted at Gmail/G Suite but
the hosting service nevertheless employs rate limiting of incoming messages.

So despite being a profound advocate of Exim, it is a little embarrassing
to tell people who ask me about outbound rate limiting that it's so
difficult in it, but simple in other MTAs. But I guess it stems from a
design decision made early on and hence is difficult to address.

Mike B.

On 28 February 2018 at 09:59, Jeremy Harris via Exim-users <
exim-users@exim.org> wrote:

> On 28/02/18 09:33, Jasen Betts via Exim-users wrote:
> > there may be better solutions but this is the easiest.
>
> I've put a skeleton description on
>   https://github.com/Exim/exim/wiki/RatelimitOutbound
>
> Filling out the detail will required perusing of multiple
> separate parts of the manual.  (Translation: I haven't
> the time or the interest.  Dump Gmail.)
> --
> 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Wildcards in aliases

[Mike Brudenell via Exim-users]

Please forgive me veering off topic a little for a moment, but in case it
helps you Hardy I find these two web sites really useful for testing
various flavours of regular expressions. (I think Exim uses PCRE if memory
serves?)

   - https://www.debuggex.com/?flavor=pcre
   - https://www.regextester.com/

The first one even draws the expression's pattern matching so you can
visually check what's happening. They both let you try various test strings
or parts thereof to see where your pattern is going wrong.

Cheers,
Mike B-)

On 13 February 2018 at 10:40, Hardy via Exim-users 
wrote:

> Thank you Heiko and Merlin,
>
> lookups are my really weak point ;-) and my lack on a grasp on regex
> hampers me even more. I know I should change this on the long run, but for
> now your short term help is very much appreciated...
>
> A one-time change to the conf is acceptable, of course.
>
> I had hope for a solution to keep my alias file the single point of
> maintenance AND keep it compilable by exim_dbmbuild. I would like to stick
> with the simple
>
> require verify = recipient
>
> for validation. My lookup now is
>
> data = ${lookup{$local_part}dbm{/etc/exim/$domain.aliases.db}}
>
> Can I still do what I want with dbm, and how would I write the alias file
> for entries meaning
>
> myname[digits]: myname
>
> Thanks
> Hardy
>
>
>
> On 13.02.2018 11:12, Merlin Hartley via Exim-users wrote:
>
>> Or even full expansion options - which puts huge power into the aliases
>> file:
>>data = ${expand:${lookup{$local_part}lsearch{/etc/aliases}}}
>>
>> Hope this is useful!
>>
>>
>> Merlin
>> --
>> Merlin Hartley
>> Computer Officer
>> MRC Mitochondrial Biology Unit
>> University of Cambridge
>> Cambridge, CB2 0XY
>> United Kingdom
>>
>> On 13 Feb 2018, at 09:38, Heiko Schlittermann via Exim-users <
>>> exim-users@exim.org> wrote:
>>>
>>> Hardy via Exim-users  (Di 13 Feb 2018 09:44:38
>>> CET):
>>>
 Hi folks,

 my aim is to have something in the way of

 myname.*: myname

 for the local user myname, if this is possible to do in the alias file.
 I
 would rather like to have it here than to change the conf. Possible?

>>>
>>> You need to modify the config anyway, to allow for patterns in your
>>> alias file.
>>>
>>>
>>> data = ${lookup{$local_part}nwildlsearch{/etc/aliases}}
>>>
>>> With entries like:
>>>
>>> hans:   literal
>>> hans*:  literal
>>> *hans:  pattern
>>> ^hans:  regexp
>>>
>>>
>>> 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 -
>>> ! key id 7CBF764A and 972EAC9F are revoked since 2015-01  -
>>> --
>>> ## 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/
>>>
>>
>>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] ACL to early reject connections from hosts which keep on retrying after a permanent reject

[Mike Brudenell via Exim-users]

Hi, Sebastian -

You might want to try the *strict* ratelimit option instead of *leaky*…

When I was setting something up here I seem to remember that using leaky
ended up with the ratelimit value capping out at around its limit, meaning
my defence measure never kicked in. Changing to strict meant the actual
rate was recorded so clients that were hammering us were now detected and
appropriate measures taken.

(There's an explanation in the *Specification*

about
leaky *v* strict, but I confess I don't find it terribly clear.)

Cheers,
Mike B-)

On 25 January 2018 at 10:24, Sebastian Arcus via Exim-users <
exim-users@exim.org> wrote:

> On 25/01/18 09:20, Jeremy Harris wrote:
>
>> On 25/01/18 05:56, Sebastian Arcus via Exim-users wrote:
>>
>>>   I can see in the ratelimit db quite a few hosts
>>> which have reached the 5/24h limit. But strangely in the Exim log I
>>> can't see the appropriate reject messages - although I can see reject
>>> messages for various other ACL's I've set up. Searching by the offending
>>> IP addresses in the logs, I can see them retrying over and over again -
>>> and yet my initial connect ACL never seems to kick in and deny the
>>> connection. I can't really think of a reason for this.
>>>
>>
>> Test with -bh and -d
>>
>>
> I tried running a connection test on one of the IP addresses which show as
> having reached 5.0 in the ratelimit database, and I get:
>
> ratelimit computed rate 4.6
>
> I suppose this is because some time has passed since their last connection
> - and I think that's why it doesn't work as expected. I think I need to
> have the first ACL - on connect, which is read-only in my case - check for
> 5, but the others, check for a higher number. It seems that the ratelimit
> in other ACL's increase the counter to 5, but then, by the time the client
> connects again, the counter in the db is just below 5 (for example 4.9) -
> the ratelimit condition in the connect ACL is never true - but at the same
> time, the later ACL's which are supposed to increase the counter, don't do
> it any more, as it would take it past 5.0. I will try something like below,
> to see if it works:
>
> acl_check_connect:
>
> drop  message   = Temporary ban - too many retries
>   ratelimit = 5 / 24h / per_conn / readonly
>
>
> acl_check_helo:
>
> deny  message= "Bad HELO (impersonates our host)"
>   condition  = ${if match{$sender_helo_name}{$primary_hostname}}
>   !ratelimit = 10 / 24h / per_conn / leaky
>
> acl_check_rcpt:
>
> deny  message= Relay is not permitted
>   !domains   = +local_domains : +relay_to_domains
>   !ratelimit = 10 / 24h / per_conn / leaky
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Bounce router based on both sender and recipient

[Mike Brudenell via Exim-users]

 rouHi, Jarle -

Because Exim is very flexible there are usually many ways of achieving the
same effect. I'll leave it to others to comment on whether your ideaof
using a router for this is "bad", but to me it seems overly complex and
"less good" :-) As a general rule of thumb I think of

   - ACLs as determining *whether* something (a connection, a sender
   address, a recipient address, some particular content, etc) should be
   accepted, rejected, or deferred to be tried again later;
   - Routers as usually determining *how* to handle the message (implement
   forwarding, expand aliases, deliver to a local mailbox, transmit over SMTP,
   etc)
   - Transports to do the nitty gritty of the actual delivery,
   transmission, etc

(Others may dispute some aspects of that mental model, but as a general
rule of thumb it works for me.)

When I think through your router I confess it makes me brain ache slightly
with its effective double-negatives about accepting and rejecting:

   1. The sender address and recipient addresses have been accepted by your
   ACLS, suggesting you're happy with the message, and
   2. This router accepts and handles the recipient of the message if the
   sender address is in ses-senders, the recipient domain is non-local and the
   recipient address is listed in ses-suppress, but
   3. When the router decides to handle the recipient's copy its only
   possible action is to reject it. (Brain aches then explodes.)

I confess that the way my mind works I see it as simpler and more logical
to:

   1. Use an ACL to impose a *deny* policy when the sender and current
   recipient address meet your criteria. (This rejects that one recipient
   address, leaving any others to continue to be tested and be accepted as
   appropriate.) This leaves you to…
   2. Use a router that then focuses on how to actually route the message
   to each of the (remaining, accepted) recipients.

So I'd write it more along the lines of this in my *acl_smtp_rcpt* ACL (at
which point the MAIL FROM sender address is already known and is available
for testing, and each recipient address is being presented/considered in
turn):

deny message= Address is known to bounce. We cannot attempt to send to
this address. (Local suppression list)
 senders= lsearch;/etc/exim4/ses-senders
 ! domains  = +local_domains
 recipients = lsearch;/etc/exim4/ses-suppress

This is much simpler to code, and therefore less confusing/error-prone now
and when revisiting it in the future. It can also do its work very early on
in the ACLs phase without needing to fire up routers. Indeed, depending on
whether you use *verify* in your ACLs it could make the difference between
rejecting the recipient at SMTP time and accepting the message into your
queues only to later reject it, possibly causing backscatter.

Some notes/observations:

   - When all of its conditions are met this ACL statement will deny the
   recipient currently being considered, returning a 5xx SMTP response. That's
   tell the sending server this recipient has been rejected but it can carry
   on supplying other recipient addresses (if any).
   - Using the *recipients* condition to test the full recipient address is
   easier than the somewhat convoluted *condition* condition.
   - As you're searching for the *full* recipient address in the
   ses-suppress file I'm not convinced as to the benefit of first using
   *domains* to check that the domain of the recipient address isn't in
   *local_domains*. (I'm assuming, possibly incorrectly, that you don't
   list local_domain addresses in your ses-suppress file. If you do then yes,
   you'd want the *domains* condition for my version to match yours.)

But if you've got your version working and are happy with it then that's
the main thing.

Cheers,
Mike B-)

On 23 January 2018 at 17:49, Jarle Hammen Knudsen via Exim-users <
exim-users@exim.org> wrote:

> Hi, Mike!
>
> In my original mail I mistakenly referred to the same file twice .
> Correction:
>
> What I am trying to do is define a router which bounces the message if
> both these conditions are true:
>
> 1. sender is listed in /etc/exim4/ses-senders
> 2. recipient is listed in /etc/exim4/ses-suppress
>
> I do want per recipient filtering on this. Only recipients listed in
> ses-suppress should be bounced. Messages with multiple recipients should be
> delivered to the other recipients.
>
> The reasoning behind looking at a router to do this was because it was a
> router I wanted to restrict.
>
> Anyway, this seems to to the trick:
>
>send_via_ses_block:
>   driver = redirect
>   debug_print = "R: send_via_ses_block"
>   domains = ! +local_domains
>   senders = lsearch;/etc/exim4/ses-senders
>   condition = ${lookup {$local_part@$domain} lsearch
>{/etc/exim4/ses-suppress} {1} {0}}
>   allow_fail
>   data = :fail: Address is known to bounce. We cannot attemt to
>send to this address. (Local suppression list)
>
> Is 

Re: [exim] Selecting rewriting flags based on a condition

[Mike Brudenell via Exim-users]

On 11 January 2018 at 21:37, Jeremy Harris <j...@wizmail.org> wrote:

> On 11/01/18 17:53, Mike Brudenell via Exim-users wrote:
> > I'd like to rewrite both Envelope and header addresses if the connection
> is
> > from an on-site IP address, but only the Envelope otherwise.
>
> Since you have adopted the Mortal Sin (per Chapter 31, Section 1)...
>

Yup, terrible isn't it… :-)

I've given up trying to get people to use our one true "Do Not Reply" email
address, them ignoring me, then complaining because their messages don't
get through because the sender address isn't valid. So the most common
variants are being rewritten.  (I'd therefore argue this is actually a
venial sin, not a mortal one.)



> Two separate rewrite rules; for E and h.  Make the latter have a pattern
> which expands to something that will only match for an on-site source;
> never for off-site.
>

Ah-ha! I should have thought to split it into two rules!

I wasn't sure I could think of a pattern that only matches on-site sources
though; potentially an external sender could set/forge anything. So what
I've done instead is have two rules with identical patterns: the first
rewrites Eh and the second E only.

The cunning bit is putting the conditional test in the first rule and have
it either expand to the replacement value or *fail*. If the expansion *fail*s
no rewriting is done, it passes on to the second rule, which matches and
unconditionally rewrites (but only the envelope).

#   Rewrite incorrect forms of our <do-not-re...@york.ac.uk> address,
but only for
#   locally originated messages.
\N^(?i)(?:donotreply|do_not_reply|no-?reply)@york\.ac\.uk$\N\
"${if or{ \
 {def:authenticated_id} \
 {! def:sender_host_address} \
 {match_ip {$sender_host_address} {CAMPUS_IP_ADDRS}} \
   } \
 {do-not-re...@york.ac.uk} \
 fail}" \
Eh

\N^(?i)(?:donotreply|do_not_reply|no-?reply)@york\.ac\.uk$\N
do-not-re...@york.ac.uk E

Thanks, Jeremy, for the clue as to the two-rule direction!
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Selecting rewriting flags based on a condition

[Mike Brudenell via Exim-users]

Hi, all -

I can't spot an elegant (or indeed any) way of doing this at the moment;
can anyone help? …

I have a rewriting rule in the *begin rewrite* section:

nore...@york.ac.uk  no-re...@york.ac.uk  Eh


I'd like to rewrite both Envelope and header addresses if the connection is
from an on-site IP address, but only the Envelope otherwise.

I assumed I could just change the Eh flags to something like

${if match_ip{$sender_host_address}{144.32.0.0/16} {Eh} {E}}

But

   - Trying this gives an error in the panic log as Exim starts up saying
   "$" is an unknown flag;
   - Enclosing the expression within double quotes also fails, this time
   saying '"' is an unknown flag.

So it looks like that whilst the pattern and replacement strings are
expanded the flags aren't. (The documentation says that the pattern and
replacement strings are expanded, but doesn't mention this for the flags.
I'd lived in hope! :-)

Does anyone know a way (ideally simple/elegant!) of achieving this
selective rewriting? (I'll probably want to extend the test to include
authenticated connections as well, but am starting just with IP addresses.)

*Use-case:* After having problems delivering mail to another is which is
rewriting headers of incoming messages form off-site and thereby breaking
DKIM signatures I thought I should get my own house in order too and only
rewrite the headers for messages coming from on-site systems.

With many thanks,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Bounce router based on both sender and recipient

[Mike Brudenell via Exim-users]

Hi, Jarle -

Am I missing something, but why do you need a *router* to do this? Couldn't
you do it in an *acl_smtp_rcpt ACL* instead? You can test the sender and
recipient address easily then rejects the message with a *deny* if met.
Something like this, perhaps (untested!)…

deny senders= lsearch;/etc/exim4/ses-suppress
 recipients = lsearch;/etc/exim4/ses-suppress
 message= …some suitable rejection response text…

When the ACL spots a recipient address listed in ses-suppress *and* also
has a sender address listed there then the recipient is rejected. (By the
way, did you mean to use "ses-suppress" for both senders and recipients
there, by the way? Not "ses-senders" for the sender?)

However think carefully if this is what you want for the "edge cases"…

For example, suppose a sender listed in ses-suppress tried to send a
message to *two* recipients, *only one* of which is listed in ses-suppress?

   - Do you want just the listed recipient to be rejected and the message
   still to be delivered to the other (unlisted) recipient?
   - Or do you want the entire message to be dropped to *all* recipients if
   *any* recipient is listed in ses-suppress?

As it stands my suggestion above does the former, not the latter.

Cheers,
Mike B-)

On 8 January 2018 at 19:08, Jarle Hammen Knudsen via Exim-users <
exim-users@exim.org> wrote:

> I have the following router:
>
> send_via_ses:
>   driver = manualroute
>   debug_print = "R: send_via_ses"
>   domains = ! +local_domains
>   transport = ses_smtp
>   route_list = * email-smtp.eu-west-1.amazonaws.com;
>   senders = lsearch;/etc/exim4/ses-senders
>
> If the sender is listed in /etc/exim4/ses-senders the mail is sent via the
> smarthost.
>
> I also have a list of recipient addresses known to bounce in
> /etc/exim4/ses-suppress.
>
> What I am trying to do is define a router which bounces the message if
> both these conidtions are true:
>
> 1. sender is listed in /etc/exim4/ses-suppress
> 2. recipient is listed in /etc/exim4/ses-suppress
>
> If the sender is not listed in /etc/exim4/ses-suppress these two routers
> should be skipped.
>
> I have worked on this for quite some time without success so any help is
> very much appreciated.
>
> --
> Jarle Hammen Knudsen
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exim header check and mailsploit?

[Mike Brudenell via Exim-users]

It's one of the things that annoys me about the dumbed down nature of many
modern MUAs: their habit of showing only the display name rather than also
including the email address. For example here Gmail is showing me a
previous message as being fromjust "Adrian Zaugg" unless I actively click a
small drop-down menu to see more details.

This can lead to people embedding a valid-looking email address in the
display name, the recipient seeing that and being fooled into thinking the
address is the sender when it isn't.

Bring back dumb terminals, the CLI and the Pine MUA! :-)

Cheers,
Mike B-)

On 7 December 2017 at 19:33,
=?utf-8?B?0JLQuNC60YLQvtGAINCU0YPRhdC+0LLQvdGL0LkgPGV4aW0tdXNlcnNAZHVraG92?=
=?utf-8?B?bmkub3JnPiwgQWxzbyBLbm93biBBcyBWaWt0b3IgRHVraG92bmkgPGV4aW0tdXNl?""=
=?utf-8?B?cnNAZHVraG92bmkub3JnPgo=?=  wrote:

> On Thu, Dec 07, 2017 at 11:14:12AM +0100, Adrian Zaugg wrote:
>
> > The mailsploit attack is not only going to the "free-form phrase", it's
> > also affecting the from-address.
>
> Actually, no.  A correct implementation of RFC 2047 will not
> interpret anything in the encoded phrase as being part of the
> mailbox address, the entire content of the encoded phrase is part
> of the "display name", no matter what it decodes to.  To be more
> specific, the parsing of a structured address header as:
>
> From: phrase one , phrase two 
>
> must happen first, *before* any decoding of "phrase one" and
> "phrase two".  While "phrase one" might be some encoding of:
>
> phrase three , phrase four 
>
> that string must not be parsed as though it appeared unencoded in
> the From: header.  Parsing into display names and addresses must
> happen *first* and decoding of display names *second*.  Not the
> other way around.
>
> How to sanitize and present potentially misleading display names
> to the user in a non-confusing way is up to the MUA.  The MTA's
> job is to transmit the message.
>
> The only rope for enforcement by the MTA is the text that says that
> such encodings SHOULD only be for printable text, not arbitrary
> binary data.  So ASCII control characters (other than TAB), inside
> the encoded phrase, are potentially something that an MTA could be
> configured to enforce.  That would still leave plenty of room for
> confusing the recipient when the MUA does a sloppy job of presenting
> the From: header.
>
> --
> 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] List of DNSBL's anywhere?

[Mike Brudenell via Exim-users]

Exim is probably flexible enough to work with most DNSBLs. One way of
finding out ones that exist is to use a lookup tool such as

https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3aexample.com


You can also find a list of DNSBLs (with onward links to more information
about them) at

https://www.dnsbl.info/dnsbl-list.php


There'll be other DNSBLs and lists of DNSBLs too I'm sure. You'll need to
decide which, if any, meet your needs with sufficiently good quality data
and lack of false positives.

Cheers,
Mike B-)

On 5 December 2017 at 21:21, Sebastian Arcus via Exim-users <
exim-users@exim.org> wrote:

> Is there anywhere a (semi)authoritative list of DNSBL's which can be used
> with Exim? I see various examples including some DNSBL's - but I was
> wondering if there is a complete(ish) -and preferably up-to-date list of
> DNSBL's which can be used?
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Routing email to different smarthosts accordin to a "percentage"

[Mike Brudenell via Exim-users]

I love the way that, despite having (quite a while ago now) read the
*Specification* from cover to cover I still learn new things about Exim
that hadn't sunk in or I'd glossed over! :-)

Cheers,
Mike B-)

On 4 December 2017 at 16:41, Viktor Dukhovni 
wrote:

>
>
> > On Dec 4, 2017, at 11:27 AM, Felix Schwarz via Exim-users <
> exim-users@exim.org> wrote:
> >
> >> Smarthost0 receives all the emails and then routes, let say, the 10
> percent of the emails via smarthost1 and the 90 percent via smarthost2
> >>
> >> There is a way to do this with exim?
> >>
> >> I would like to implement something like this as a way to warm up/or
> keep warm an IP
> >
> > There is (almost) always a way with exim:
> > https://lists.exim.org/lurker/message/20170215.104521.
> 34635a7a.pt-BR.html
>
> My recollection is that Exim supports routing via SRV records, and
> SRV records support "weights".  If Exim implements SRV records per
> the specification and honours the weights, you get to publish weight
> 10 for one server and weight 90 for another at the same precedence.
>
> You would then just need to enable SRV-based routing.
>
> --
> 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Routing email to different smarthosts accordin to a "percentage"

[Mike Brudenell via Exim-users]

Hi, Diego -

I'm assuming you're using a *manualroute* router to select the smarthost to
send your outgoing message to?

I so and you are happy with a fairly even spread between the onward
smarthosts then the simplest solution might be to just add *hosts_randomize*
to your router on smarthost0 — something like this:

hosts_randomize = true

route_data = smarthost1 : smarthost2


As it explains in the *Specification*, this randomises the list of target
hosts each time the list is used. (You can also split this into groups
which are randomised within each group but not between if you have fallback
hosts only used when the primaries aren't available.)

If you instead want an uneven spread of load over the backend servers — you
mentioned a 90-10 split — then you can almost certainly do what you want
using *route_data*. The value of this is expanded so you can construct an
*if* expression that uses *randint* to generate a random number and, if
this is less than a threshold select one backend smarthost else the other.

For example, something like this (untested, and possibly syntactically
invalid! :-) …

route_data = ${if <= {${randint:100}} {10} \
  {smarthost1} \
  {smarthost2}}


Cheers,
Mike B-)

On 1 December 2017 at 17:46, Diego Bellini 
wrote:

> Hi all,
> I have been using exim for a long time but it is my first time that I am
> posting here
>
> I am writing to ask for any suggestion in relation to this
>
> Let say I have 3 smarthosts: smarthost0, smarthost1, smarthost2
>
> Smarthost0 receives all the emails and then routes, let say, the 10
> percent of the emails via smarthost1 and the 90 percent via smarthost2
>
> There is a way to do this with exim?
>
> I would like to implement something like this as a way to warm up/or keep
> warm an IP
>
> Anyone's got an idea?
>
> Cheers,
> Diego
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] DKIM pubkey_dns_syntax

[Mike Brudenell via Exim-users]

Strictly speaking the RFC says that the tag name ("v") MUST be compared
case-insensitively, and its value compared case-sensitively unless the
specific description for the tag says otherwise.

The description for "v" doesn't mention allowing case-insensitive
comparisons for its value, but does say the value MUST be "DKIM1". (Hence
we're being generous (and non-conformant) by comparing the tag's value case
insensitively.

A couple of other points though:

   - We should perhaps have the pattern anchored to the end of the string
   with a "$" as the RFC explicitly says a string comparison myst be done, and
   that "DKIM1" is *not* the same as "DKIM1.0" (which the current pattern
   would allow)?

   - The "v" tag doesn't appear to be mandatory, but only recommended, and
   if omitted should default to "DKIM1". So strictly speaking if we're
   insisting on the presence of "v=DKIM1" to consider the DNS record to be
   valid we're being overly restrictive. If it's missing the "v" tag but is
   otherwise a syntactically correct DKIM record it should have its value used.

Cheers,
Mike B-)

On 4 December 2017 at 14:38, Heiko Schlittermann via Exim-users <
exim-users@exim.org> wrote:

> Wolfgang Breyha  (Mo 04 Dez 2017 15:15:45 CET):
> …
> > 6.1.2.  Get the Public Key
> > [...]
> >
> > ... The Verifier MUST validate the key record and MUST
> >ignore any public-key records that are malformed.
> …
> >
> >
> > I think your patch does exactly that;-)
>
> As we do not *validate* the key record, we just check if it
> looks like a key record (matching /^v=dkim/i), I'd say that we do not
> follow the RFC strictly.
>
> --
> Heiko
>
> --
> ## 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/
>
>


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] redirect suspicious messages to special postmaster accounts

[Mike Brudenell via Exim-users]

I'm confused… From what Marco posted it looks like the "continue" line is
commented out? If so, why is it being seen and causing the error?
(Assuming, of course, that line 329 refers to the line given in the sample!
:-)

Cheers,
Mike B-)

On 1 December 2017 at 12:10, Jeremy Harris  wrote:

> On 01/12/17 11:17, Emanuel Gonzalez wrote:
> > #continue = ${run{SHELL -c 'echo Subject: $sender_host_address
> blocked | $exim_path -f root WARNTO' }}
> > data = :blackhole:
> >
> >
> > I receive the following error
> >
> > Starting exim: 2017-12-01 08:14:23 Exim configuration error in line 329
> of /etc/exim/configure:
> >   option "continue" unknown
>
> "continue" is not a router option.
>
> Hint: you are not specifying a "rule" here, you are specifying a router.
> Read the documentation on routers.
> --
> 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Again nested LDAP queries...

[Mike Brudenell via Exim-users]

Sorry, Marco, you've just exceeded my own abilities; I've never had to use
either listextract or extract myself. Hopefully someone who has done might
give you some idea, or else point you to a way of doing it by some other
means.

Cheers,
Mike B-)

On 30 November 2017 at 21:46, Marco Gaiarin <g...@lilliput.linux.it> wrote:

> Mandi! Mike Brudenell via Exim-users
>   In chel di` si favelave...
>
> > If you're trying to get to values within a list, try using the
> *listextract*
> > expansion item:
> > https://www.exim.org/exim-html-current/doc/html/spec_
> html/ch-string_expansions.html#SECTexpansionitems
>
> > There's a bit more on it in the *File and database lookups* chapter in
> > the *Format
> > of data returned by LDAP* section, which talks about needing to use
> > *listextract* to parse returned LDAP data as it understands the doubling
> of
> > embedded commas within values:
> > https://www.exim.org/exim-html-current/doc/html/spec_
> html/ch-file_and_database_lookups.html#SECID71
>
> OK, read both. But still i've no clue how to use that... 'listextract'
> extract only ONE field, and DN can have a variable set of comma-separated
> parts, not fixed ones...
>
> Eg, i can do:
>
> ${listextract{'odd'}{<, CN=sir,,OU=Users,,OU=FVG,,DC=
> ad,,DC=fvg,,DC=lnf,,DC=it}{$value}}
>
> but there's no 'odd' in listextract number field, only a integer...
>
>
> Sorry, but really i don't understood how listextract can help me
>
>
> Thanks.
>
> --
>   La BBS e' come il mio frigorifero... da tanti anni fa in silenzio un
> ottimo
>   lavoro, al punto tale che mi accorgo della sua utilita' solo quando
> manca la
>   corrente e tutto quello che contiene diventa inutilizzabile. (E.
> Margelli)
>
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Again nested LDAP queries...

[Mike Brudenell via Exim-users]

If you're trying to get to values within a list, try using the *listextract*
expansion item:
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html#SECTexpansionitems

There's a bit more on it in the *File and database lookups* chapter in
the *Format
of data returned by LDAP* section, which talks about needing to use
*listextract* to parse returned LDAP data as it understands the doubling of
embedded commas within values:
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-file_and_database_lookups.html#SECID71

(And in passing, there's also the *extract* expansion item which parses
space-separated *keyword=value* pairs, although this isn't what you need
for this situation.)

Cheers,
Mike B-)

On 29 November 2017 at 14:58, Marco Gaiarin  wrote:

>
> >>> What i'm missing?!
> >> quote_ldap_dn   ?
> > No, seems no. Same result.
>
> Boh. I've done some more tests, but insted of using:
>
> exim -be
>
> i've used:
>
> exim -d+deliver -v -bt test@domain
>
> and my LDAP query, as expected, work. The query finally is:
>
> ${lookup ldapm {user=LOCAL_AD_BIND_DN pass=LOCAL_AD_PASS
> ldap:///LOCAL_AD_BASE_DN?uid?sub?(&(|(objectClass=user)(
> objectClass=group))(memberOf=\
> ${quote_ldap:${sg {${lookup ldap {user=LOCAL_AD_BIND_DN
> pass=LOCAL_AD_PASS ldap:///LOCAL_AD_BASE_DN?distinguishedName?sub?(&(
> objectClass=group)(mail=${quote_ldap:${local_part}}@${quote_ldap:${domain}}))}}}
> {,,} {,}}}\
> ))}}
>
> and using '|(objectClass=user)(objectClass=group)' i can also ''expand''
> correctly nested group memberships; clearly exim do some loops, but finally
> get the result.
>
>
> >> Also, your sg's are problematic in the face of fields containing commas.
> > Some more hint? Thanks.
>
> Still i'm seeking feedback on 'sg', i don't see alternatives
>
>
> Thanks.
>
> --
>   Errare è umano, ma per fare veramente casino
>   ci vuole la password di root  (Zio Budda)
>
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Block tld

[Mike Brudenell via Exim-users]

Hi, Emanuel -

The problem is that you are making a huge assumption: that all emails from
any something@*.bid sender address will be spam.

If you're really sure you want to assume this and that there will never be
any legitimate email from such an address then it is better do deny rather
than discard the message. Discard informs the sending machine that their
message was delivered successfully, even though you've actually thrown it
away. This is not good because:

   - if a message did happen to be legitimate then the sender is left
   thinking their message has reached the recipient when in fact it hasn't;
   - if the message is some sort of probe or general spam it can lead to
   more messages being sent to your server and wasting your bandwidth and
   resources because the spamming software things the address was valid.

In contrast denying a message returns a 5xx "permanent failure" back to the
sender, so:

   - a legitimate sender gets to see a response that tells them their
   message failed and hasn't reached the recipient, and
   - spamming software might (although it's probably unlikely!) give up on
   that address in the future.

Rather than making wild assumptions about something@*.bid address all being
spammers, it might be better to use an analysis tool with many weighted
rules such as SpamAssassin. If you're having a particular problem with spam
from *.bid domains add a rule to it with a positive weighting to mark the
message as spam, with at least the chance that the OK characteristics of
legitimate messages might outweigh the spammy bias and allow them through.

Cheers,
Mike B-)

On 24 November 2017 at 12:45, Emanuel Gonzalez  wrote:

> Hello.! thanks for your reply.
>
>
> I do not want to block local users but incoming spam.
>
>
> Regards,
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Weird error showing up in mainlog

[Mike Brudenell via Exim-users]

"The Doctor",

Pulling together bits and pieces, and trying to add something of my own;
see if this makes sense…

The log entry for Exim message id 1eIGVs-000Ntb-OB shows the incoming
message has an RC5321.MailFrom address of ,
but either the "for" recipient list has been edited out of the log entry or
the logging level isn't high enough to show it. However these can be
inferred from the log lines that follow.

The SMTP rejection error issued by impactofficeservices.ca
[173.254.28.40] clearly says that it's the RFC5321.MailFrom address that it
is unhappy with, which it is seeing as being the unqualified address
. It is stating that it wants a fully qualified email address.

This implies that something within the Exim configuration is altering the
RC5321.MailFrom address from the original  to
.

This is unlikely to be the aliases file as that is generally applied to
*recipient* addresses within your own domain: not applied to *sender*
addresses. (Although you can configure and set up pretty much anything!)

So it could be something in Exim's rewrite section, or there might be some
other magic going on. For example I learned recently that some systems have
a /etc/email-addresses file set up to modify the sender address. We're
looking at using this to locally rewrite local accounts on end-nodes into
centrally recognisable email addresses, However this is *not* something
built into the standard Exim setup; it's either something you configure in
yourself, or might possibly be present in some Linux distros'
configurations, in which case it's really a question to ask that distro's
community.

The key thing is to be methodical and get more information. This doesn't
mean just copying and pasting chucks of logfiles, but to make sure that the
logging level is set to get relevant information — see log_selector.

I useful technique I use on my test server is to stop the running Exim
daemon and instead invoke it manually with

exim -v -d+all -bd


This starts Exim in daemon mode with verbose logging at all levels coming
out on my terminal. I then send a test message through it — either crafted
manually or by using the swaks utility — from another window, then read
through the very verbose logging. This lets you see exactly what's
happening, being rewritten, ACLs and routers that are firing, and so on. It
should help you locate what is changing the sender address between the
message arriving and it going out again.

An alternative approach is to use Exim's "-bhc" command line to fake up a
message complete with setting the IP address of the sending host: useful if
your configuration file's logic does different things based on the source
IP address.

Basically you need a good knowledge of your Exim configuration file in
order to work out what might be happening, and the above detailed logging
will help you work through it and confirm it's as you intend. We here in
the community can't do much to help without that intimate knowledge of your
configuration: both file and support files. I'd suggest rolling up your
metaphorical sleeves and use the debugging options and log levels.

Mike B.

On 24 November 2017 at 17:35, The Doctor  wrote:

> On Fri, Nov 24, 2017 at 07:03:03AM -0700, The Doctor wrote:
> > On Fri, Nov 24, 2017 at 10:18:29AM +, Jeremy Harris wrote:
> > > On 24/11/17 03:30, The Doctor wrote:
> > > > 2017-11-23 13:00:00 1eHxbt-0008Sf-2W ** {legit e-mail address}
> R=dnslookup T=remote_smtp H=doctor.nl2k.ab.ca [204.209.81.1]
> X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no: SMTP error from remote
> mail server after pipelined MAIL FROM: SIZE=13880523: 501 :
> sender address must contain a domain
> > > >
> > > > What is happening?
> > >
> > > A remote system that you are trying to send a mail to, is rejecting
> that
> > > message.  The tail end of that log line, starting "501", is what they
> > > said.
> > >
> > > My interpretation of what they said is that they don't like one of
> > > - the envelope from
> > > - the header From: (or possibly Sender:)
> > > but you'd need to verify their policies by asking them.
> > > --
> > > Jeremy
> > >
> >
> >
> > Al right  subsequent discoveries of followups of the symptoms were
> ignored.
> >
> > Let me describe step by step what is happening.
> >
> > 1) In order to bypass the annoying on behalf of header placed by
> > exim
> >
> > no_local_from_check
> > untrusted_set_sender = *
> >
> > 2)
> >
> > REmote non-LAN users can use either PLAIN or LOGIN without on the behalf
> of
> > and send through and is logged accordingly
> >
> > UNLESS
> >
> > 3)
> >
> > you show up as i...@dom.ain   then instead of i...@dom.ain
> > something in exim says you are "root" without any domain and
> >
> > the info account trying to pass an e-mail gets
> >
> > This message was created automatically by mail delivery software.
> >
> > A message that you sent could not be delivered to one or more of its
> > 

Re: [exim] Sender Name & Email

[Mike Brudenell via Exim-users]

You might be thinking of the ${address:} expansion operator, which
interprets the string as an RFX 2822 address, as it might appear in a
header line, and the effective address is extracted from it. If the string
does not parse successfully, the result is empty. See the *String
Expansions* chapter in the *Specification* for more details.

I don't think there's an expansion operator to get the name part but might
be wrong.

Remember that if the string isn't valid then the result is empty. Remember
too to convert it to lowercase if you need, otherwise you'll get whatever
capitalisation it was supplied in.

Cheers,
Mike B-)

On 17 August 2017 at 16:07, Rob Gunther via Exim-users 
wrote:

> I thought I had in the past seen variables where Exim exposed the header
> From: data of the sender.
>
> Specifically breaking it down into an email address and name parts.
>
> I see the $sender_address which exposes the envelope address, but I'm
> looking for the header parts.
>
> Of course, I can access the header directly with $h_from: but if Exim is
> splitting out the header that would be much more reliable for my purposes.
>
> Anyone know if those variables really exist, or did I dream I read it
> before?
>
>
> Regards,
>
>
> Rob
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] PLAIN authenticator that checks against two data sources

[Mike Brudenell via Exim-users]

Dear all,

Just to wind this up and record the outcome for anyone now or in the future
searching for a solution to a similar problem…

Our underlying problem was that when Exim tries to bind using ldapauth to
our LDAP server to verify a username/password combination it's getting
an LDAP_NO_SUCH_OBJECT (32) return code instead of LDAP_INVALID_CREDENTIALS
(49) when the username doesn't exist.

My colleagues here wonder if this might be because we're using the Sun LDAP
server instead of OpenLDAP and its behaviour is different. I confess I'm
disappointed that Exim only returns a FAIL for the LDAP_INVALID_CREDENTIALS
error; when the username doesn't exist in our LDAP server, so its object
isn't present and can't possibly bind successfully, Exim instead gives an
expansion error.

Sadly getting an expansion error from ldapauth in server_condition causes
the authenticator to defer. This means a different SMTP response code and
textual string is returned to the client from the one returned when the
username exists but the password supplied is incorrect. Therefore the
technique suggested in the *Specification* to use ldapauth alone to
validate username/password pairs leaks information to the client with some
LDAP servers/setups about whether the username exists or not. I and others
consider this a security concern so should be avoided.

Thankfully Jeremy suggested I explicitly check for a valid username before
checking the password. At first I thought this was a non-starter as it
would require a service account on our LDAP server to search the username
tree, and the team who manage the service diligently guard such accounts.
Fortunately a colleague reminded me that our usernames are valid on our
mail gateways: their accounts just can't get sessions. This let me use
Exim's passwd lookup to check whether the username exists and then, only if
it does, validate the password using ldapauth. My revised server_condition
for the LOGIN authenticator now looks like this:

server_condition = ${if and{ \
 { def:auth1 } \
 { def:auth2 } \
 { bool{ \
 ${lookup {$auth1} lsearch
{/etc/exim4/cfg.d/passwords-for-auth-smtp} \
{ ${if crypteq {$auth2}
{\{sha1\}$value}} } \
{ ${if and{ \
{ bool_lax{ ${lookup
passwd {${quote_passwd:$auth1}}} } } \
{ ldapauth \

{user="uid=${quote_ldap_dn:$auth1},ou=this,ou=that,ou=other,dc=york,dc=ac,dc=uk"
\

pass=${quote:$auth2} \
nettime=10 \
time=7 \
ldap://
ldap.york.ac.uk/} } \
  }}} \
  } \
   }} \
   }}

As usual, my apologies about the long lines: I'm using a 27 inch screen so
have a big terminal window!

I appreciate the suggestions people made to use BlockCracking
 and it looks wonderful,
although perhaps over complex for our legacy mail gateways. However I'm
also not sure it would be suitable in our current environment. We have some
legitimate users here who are using external service providers who relay
the outgoing messages through our gateways using AuthSMTP. Unfortunately
their data is not very "clean" at the moment and can include syntactically
incorrect, invalid or obsolete addresses. As I understand it this would
trigger the BlockCracking defences because they try to send to more
than *N* bad
addresses within a time period: something that would impact the messages to
the valid addresses. (Yes, they're working on cleaning the data now I've
brought the problem to their attention! :-)

Many thanks to all who contributed their thoughts!
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] PLAIN authenticator that checks against two data sources

[Mike Brudenell via Exim-users]

On 9 August 2017 at 16:15, Jeremy Harris  wrote:

> It's explicitly how it's coded.
>

Agreed: I believe I've tracked down the relevant bit of code,
in src/lookups/ldap.c

  /* Invalid credentials when just checking credentials returns FAIL. This
  stops any further servers being tried. */

  if (search_type == SEARCH_LDAP_AUTH && rc == LDAP_INVALID_CREDENTIALS)
{
DEBUG(D_lookup)
  debug_printf("Invalid credentials: ldapauth returns FAIL\n");
error_yield = FAIL;
goto RETURN_ERROR_NOMSG;
}

  /* Otherwise we have a problem that doesn't stop further servers from
being
  tried. */

  if (rc != LDAP_SUCCESS)
{
*errmsg = string_sprintf("failed to bind the LDAP connection to server "
  "%s%s - LDAP error %d: %s", host, porttext, rc, ldap_err2string(rc));
goto RETURN_ERROR;
}

If you're doing an auth-only to check credentials it only yields a FAIL if
the return code is LDAP_INVALID_CREDENTIALS (49). Any other return code
falls through to put the error string into errmsg and return without
indicating a FAIL. And from the logs I'm getting error code 32 back, which
is LDAP_NO_SUCH_OBJECT.

The weird thing is that the help page for LDAP_INVALID_CREDENTIALS
 (49) at Ldapwiki says:

LDAP_INVALID_CREDENTIALS, which is LDAP Result Code 49, implies an
Authentication Failure. Typically, the Distinguished Name (DN) or the
password is *invalid*.


Whilst the help page for LDAP_NO_SUCH_OBJECT
 (32) at Ldapwiki says:

LDAP_NO_SUCH_OBJECT is *NOT* returned on following operations:


   - Search operations that find the search base but cannot find any
   entries that match the search filter.
   - Bind operations

Together these seem to suggest I should be getting LDAP_INVALID_CREDENTIALS
back from our LDAP server if the DN or password are invalid, and that
should never be returned for a bind operation. I might mention it to the
LDAP guys here, who are in another team, and try to engage their interest.


Possible workaround, then: check explicitly for a valid username
> before checking the password?
>

Unfortunately I don't believe I have a way of doing this, being unable to
search the LDAP repository without first binding/authenticating, and
credentials to do such searches are guarded by leopards.


(It is possible to code a test for a "defer" explicitly in ACLs, but
> it's a trifle complex.  If you prefer that route, ask and I'll look it
> up)
>

Many thanks for the offer but I think I'll quit worrying, leave the setup
as-is with a deferral response to the AUTH, and move on.

This all came about because I was starting to look at rate limiting failed
attempts to AUTH along these lines
.
(Although I have my suspicions as to whether it will work as the author of
that post says after a failed authentication attempt Exim will go straight
to the check_quit or check_not_quit ACLs, whereas I see it happily letting
the client try to authenticate again down the same connection. I'll keep
playing.)

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] PLAIN authenticator that checks against two data sources

[Mike Brudenell via Exim-users]

Hi, Jeremy and Nigel -

On 9 August 2017 at 13:39, Jeremy Harris <j...@wizmail.org> wrote:

> On 09/08/17 12:58, Mike Brudenell via Exim-users wrote:
> > 12:36:39 23140 LDAP parameters: user=uid=baduser,ou=blah,dc=uk
> > pass=badpassword size=0 time=0 connect=0 dereference=0 referrals=on
>
> Does the ou=blah exist?  This might be a factor, presenting an invalid
> query not just an invalid user.
>

Yes, the ou does; I've just double-checked by authenticating with a valid
username/password. (I wasn't sure how sensitive it was revealing the full
ou/dc string as I'm not an LDAP guru so redacted it from the log extracts.)

I've made an interesting discovery which might help identify the problem:

   - Supply a valid username and valid password: Authentication succeeds
   - Supply a valid username and invalid password: Authentication fails
   with "535 Incorrect authentication data"
   - Supply an invalid username and a password: Authentication fails with
   "435 Unable to authenticate at present"

With the second the log shows

Invalid credentials: ldapauth returns FAIL

This doesn't cause an expansion error, so the server_condition ends up
correctly generating the 535 SMTP response. For this the LDAP error is
"LDAP error 49: Invalid credentials"

But with the third the log shows

failed to bind the LDAP connection to server ldap.york.ac.uk:389 - LDAP
error 32: No such object

This does cause an expansion error which then, as documented, causes
server_condition to instead defer with the 435 SMTP response. For this the
LDAP error is "LDAP error 32: No such object"

Maybe the latter isn't being handled properly and so causing the expansion
failure rather than returning a false failure?

>From a security point of view, surely it's not good to return different
responses if the username exists/doesn't exist? It gives an attacker a way
of discovering what usernames actually exist so can then focus on their
password. (cf. The "Invalid username or password" generic login failure
messages.)


(Yeah, I think the book is out-of-date, too)
>

I wasn't accusing the book of being out of date, merely that it explicitly
stated the ldapauth condition should return either true or, for failure
modes, false: something the *Specification* doesn't state explicitly for
false.


On 9 August 2017 at 13:48, Nigel Metheringham <ni...@dotdot.it> wrote:

> I've not been following this in detail, but are you not asking for
> something analogous to the configuration described in this:-
> https://github.com/Exim/exim/wiki/AuthenticatedSmtpUsingPamAndPa
> sswords
>
> Also, if there are multiple auth possibilities I think this can also be
> expressed within PAM.
>

Thanks, Nigel, but I'm effectively doing the multiple check described there
within my authenticator. My problem is that when ldapauth is presented with
an invalid username it generates an expansion error that causes
server_condition to generate a 435 SMTP response, but if the username is
valid (and password invalid) it generates a 535 SMTP response.

To me this seems to be a problem with ldapauth incorrectly causing the
expansion error when presented with an invalid username rather than
returning false. This generates the wrong SMTP response, and potentially
gives an attacker a means of identifying whether a username is valid or not.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] PLAIN authenticator that checks against two data sources

[Mike Brudenell via Exim-users]

Hi,

I'm debugging this again using our Ubuntu packaged Exim version 4.86_2 #1,
and trying to work out what's wrong with my configuration by going back to
a really simple setup that will always fail:

  server_condition = ${if eq{0}{1} {true} {false}}

This correctly gives rise to the SMTP response "535 Incorrect
authentication data".

I now replace the eq condition with an ldapauth condition:

  server_condition = ${if ldapauth \
{user="uid=${quote_ldap_dn:$auth1},ou=blah,dc=uk"
\
 pass=${quote:$auth2} \
ldap://ldap.york.ac.uk/} \
  {true} {false}}

In the *Specification* the description of the ldapauth expansion condition
says this:

The condition is true if the password is not empty, and the user name and
password are accepted by the LDAP server.


And the Exim book says this (emphasis mine) when describing LDAP
authentication in section 20.7.7:

The condition is true if the user name and password are accepted by the
LDAP server, *and false otherwise*.


But when I try to authenticate using a bad username and password I don't
get the 535 SMTP response but "435 Unable to authenticate at present" and
the logs show a "failed to expand" error:

12:36:39 23140 LOGIN authenticator server_condition:
12:36:39 23140   $auth1 = baduser
12:36:39 23140   $auth2 = badpassword
12:36:39 23140   $1 = baduser
12:36:39 23140   $2 = badpassword
12:36:39 23140 expanding: $auth1
12:36:39 23140result: baduser
12:36:39 23140 expanding: $auth2
12:36:39 23140result: badpassword
12:36:39 23140 expanding: user="uid=${quote_ldap_dn:$auth1},ou=blah,dc=uk"
pass=${quote:$auth2} ldap://ldap.york.ac.uk/
12:36:39 23140result: user="uid=baduser,ou=blah,dc=uk" pass=badpassword
ldap://ldap.york.ac.uk/
12:36:39 23140 LDAP parameters: user=uid=baduser,ou=blah,dc=uk
pass=badpassword size=0 time=0 connect=0 dereference=0 referrals=on
12:36:39 23140 perform_ldap_search: ldapauth URL = "ldap://ldap.york.ac.uk/;
server=NULL port=0 sizelimit=0 timelimit=0 tcplimit=0
12:36:39 23140 after ldap_url_parse: host=ldap.york.ac.uk port=389
12:36:39 23140 ldap_initialize with URL ldap://ldap.york.ac.uk:389/
12:36:39 23140 initialized for LDAP (v3) server ldap.york.ac.uk:389
12:36:39 23140 LDAP_OPT_X_TLS_TRY set due to ldap:// URI
12:36:39 23140 binding with user=uid=baduser,ou=blah,dc=uk
password=badpassword
12:36:39 23140 failed to bind the LDAP connection to server
ldap.york.ac.uk:389 - LDAP error 32: No such object
12:36:39 23140 failed to expand: ${if ldapauth
{user="uid=${quote_ldap_dn:$auth1},ou=blah,dc=uk"
pass=${quote:$auth2} ldap://ldap.york.ac.uk/} {true} {false}}
12:36:39 23140error message: failed to bind the LDAP connection to
server ldap.york.ac.uk:389 - LDAP error 32: No such object
12:36:39 23140 expansion failed: failed to bind the LDAP connection to
server ldap.york.ac.uk:389 - LDAP error 32: No such object
12:36:39 23140 expanding: $auth1
12:36:39 23140result: baduser
12:36:39 23140 SMTP>> 435 Unable to authenticate at present

This suggests that ldapauth is not returning false as expected/documented,
but instead causing an expansion failure that then cascades back and ends
up triggering the wrong SMTP response.

   - Is this a bug in Exim, or am I missing/overlooking something?
   - Is there a way of trapping the expansion error and interpreting it to
   false so the expression works properly?

With many thanks,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811 <01904%20323811>

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] PLAIN authenticator that checks against two data sources

[Mike Brudenell via Exim-users]

Thanks, Jeremy… I feared that might be the case but nursed a hope it would
be an easy way out of my problem: having two separate authenticator
mechanisms.

(I've read and re-read the *Specification* but couldn't spot it saying
anywhere that only one authenticator mechanism was permitted for a given
public-name.)

I'm going to do yet more debugging with my two-source check today, but am
still baffled why at one point it seems to correctly generate the 5xx
response but at some point as I tweak the expression it changes to fail
with the string expansion error that leads to a 4xx response.

Has anyone managed to get a two-source check for authentication working
properly, with the second using LDAP?

Cheers,
Mike B-)

On 8 August 2017 at 21:04, Jeremy Harris <j...@wizmail.org> wrote:

> On 08/08/17 19:00, Mike Brudenell via Exim-users wrote:
> > PS: Am I right in thinking you can only have one authenticator for each
> > type: LOGIN, PLAIN, etc?
>
> You can only have one authenticator with a given public-name.
> --
> 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] PLAIN authenticator that checks against two data sources

[Mike Brudenell via Exim-users]

PS: Am I right in thinking you can only have one authenticator for each
type: LOGIN, PLAIN, etc?

Or is it possible to have two LOGIN authenticators and if the first fails
to authenticate Exim continues on to try the second one?

Cheers,
Mike B-)
-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] PLAIN authenticator that checks against two data sources

[Mike Brudenell via Exim-users]

Hi!

I have tried so many ways to get this working and have used Exim 4.86.2 in
debug mode on Ubuntu until I'm going crackers but am stuck…

I'm trying to write a LOGIN authenticator using the plaintext driver that
checks two sources for authentication details:

   1. First it checks a file for the username in $auth1. If present in the
   file the password from the entry in the file is checked against the
   supplied password in $auth2. Success/failure of the authentication is
   determined by whether the passwords match.

   If the username is not present in the file, then…

   2. The authenticator then checks against LDAP by attempting to bind
   using ldapauth to it. Success/failure of the authentication is determined
   by whether bind succeeds or not.

I have got the "check the file first then LDAP" operating (and have done in
many different ways of writing it!) but am having problems getting the
correct final SMTP response when LDAP fails. In particular I'm getting Exim
returning

435 Unable to authenticate at present

instead of

535 Incorrect authentication data


The problem appears to be that when the username/password pair are wrong
then as expected LDAP fails to bind (obviously!) but in the code I've
written this causes a string expansion failure, which eventually leads back
to the 435 SMTP response.

I'm trying hard to get a forced failure to be generated instead — in this
iteration by putting the ldapauth within an if along with a "fail" in
string2 — which I know (from other tests) will give the 535 SMTP response,
but it's flatly refusing to do so; I keep getting the string expansion
error. (I guess it's because the forced-failure happens if the if's
expression evaluates to false, whereas in this case it's having its own
error.)

Can someone help me either debug this, or come up with a different way of
writing it?

Here's my authenticator with apologies: you might need a wide window to
cope with the wrapped lines:

LOGIN:
  driver   = plaintext
  server_set_id= $auth1
  server_prompts   = <| Username: | Password:

  server_condition = ${if and{ \
   { def:auth1 } \
   { bool_lax{ \
   ${lookup {$auth1} lsearch
{/etc/exim4/cfg.d/passwords-for-auth-smtp} \
  { ${if crypteq {$auth2}
{\{sha1\}$value}} } \
  { ${if ldapauth \

 {user="uid=${quote_ldap_dn:$auth1},ou=people,ou=blah,dc=york,dc=ac,dc=uk" \
   pass=${quote:$auth2}
\
   nettime=10 \
   time=7 \
   ldap://
ldap.york.ac.uk/}  \
 {yes} \
 fail }} \
} \
 }} \
 }}

  server_advertise_condition = ${if and{ \
 {def:tls_in_cipher} \
 {!={$received_port}{25}} \
   } }


And here's the relevant extract from an "exim -bd -v -d+all" run when I
attempt to authenticate using a bad username and password:

17:40:32  4741 LOGIN authenticator server_condition:
17:40:32  4741   $auth1 = badusername
17:40:32  4741   $auth2 = badpassword
17:40:32  4741   $1 = badusername
17:40:32  4741   $2 = badpassword
17:40:32  4741 expanding: $auth1
17:40:32  4741result: badusername
17:40:32  4741 expanding: /etc/exim4/cfg.d/passwords-for-auth-smtp
17:40:32  4741result: /etc/exim4/cfg.d/passwords-for-auth-smtp
17:40:32  4741 search_open: lsearch
"/etc/exim4/cfg.d/passwords-for-auth-smtp"
17:40:32  4741 search_find: file="/etc/exim4/cfg.d/passwords-for-auth-smtp"
17:40:32  4741   key="badusername" partial=-1 affix=NULL starflags=0
17:40:32  4741 LRU list:
17:40:32  4741   :/etc/exim4/cfg.d/passwords-for-auth-smtp
17:40:32  4741   End
17:40:32  4741 internal_search_find:
file="/etc/exim4/cfg.d/passwords-for-auth-smtp"
17:40:32  4741   type=lsearch key="badusername"
17:40:32  4741 file lookup required for badusername
17:40:32  4741   in /etc/exim4/cfg.d/passwords-for-auth-smtp
17:40:32  4741 lookup failed
17:40:32  4741 expanding: $auth2
17:40:32  4741result: badpassword
17:40:32  4741 skipping: result is not used
17:40:32  4741 expanding: \{sha1\}$value
17:40:32  4741result: {sha1}
17:40:32  4741 skipping: result is not used
17:40:32  4741 condition: crypteq {$auth2} {\{sha1\}$value}
17:40:32  4741result: false
17:40:32  4741 expanding:  ${if crypteq {$auth2} {\{sha1\}$value}}
17:40:32  4741result:
17:40:32  4741 skipping: result is not used
17:40:32  4741 expanding: $auth1
17:40:32  4741result: badusername
17:40:32  4741 

Re: [exim] conditional break if dnsdb reveals a NXDOMAIN ?

[Mike Brudenell via Exim-users]

But isn't a non-existent domain just a special case of a domain that fails
sender verification? For example as far as my memory goes to pass sender
verification for a remote address you need it to be routeable, which
typically means:

   - the domain has to exist, and
   - has MX, A or  records, and
   - the IP addresses of these aren't listed in *ignore_target_hosts*

Remember that there are some oddities such as creating a TXT entry for
flobble.example.com means you won't get NXDOMAIN back when you query for
it. Likewise if the domain has a wildcard entry such as *.example.com —
instead of getting NXDOMAIN back for flobble.example.com you'd get a
positive response code if just checking whether it exists. (Or something
like that: I forget the details, but I caused problems briefly when I
created a wildcard SPF record for a subdomain and broke some scripts that
relied on getting NXDOMAIN but now weren't.)

As Jeremy says, you need to get very clear in your mind what it is you're
trying to check and why. The chances are that you want to drop or reject
messages not just from a domain name that doesn't exist but perhaps also if
they don't have valid paths back to them: hence sender verification.

Cheers,
Mike B-)

On 2 August 2017 at 14:40, Cyborg  wrote:

> Am 02.08.2017 um 12:43 schrieb Heiko Schlittermann via Exim-users:
> > Cyborg  (Mi 02 Aug 2017 12:30:24 CEST):
> >> Hi,
> >>
> >> how must a ACL look like, if we wanne drop the message, when the domain
> >> in question does not exists ?
> >>
> >> in other words, i wanne check if a domain is registered at all, and
> >> dnsdb looks like the correct approach.
> >>
> >> Any Ideas ?
> > condition = ${lookup dnsdb{$sender_address_domain}{yes}{no}}
> >
> > But isn't for sender verification
> >
> > require verify = sender
> >
> > the better approach? (Of course, if you do not talk about sender
> > verification, then …)
> >
>
> Nope, i don't wanne verify them, i just wanne drop messages from none
> existing domains.
>
> Sender verification is the next step ;)
>
> Best regards,
> Marius
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Bug in Expansion conditions

[Mike Brudenell via Exim-users]

Hi, Karsten -

I can't spot anyone replying to this so, belatedly…

You might be looking at the wrong thing. In your message you seem yo say
that your Exim configuration includes this:

acl_check_data:
  condition = ${if < {$message_size}{1M}}


If so then the error is accurate and is telling you that you've forgotten
to start the statement with a verb. That is, you need something like an
*accept*, *deny* or *warn* before your conditions (such as *condition*).

The verb tells Exim what action to take when all the conditions in the ACL
statement are met.

Cheers,
Mike B-)

On 4 July 2017 at 13:03, Forum  wrote:

> Hello Exim developers,
>
> end of the last year i already have a similar problem.
> (Bug in string expansion of exim configuration?)
> After much work it was possible to get an exim configuration running.
>
> Now i want to migrate from Exim version 4.84.2 to the latest release
> 4.89-2 in Debian
> and i run again into backward compatibility problems. :-(
>
>
> Jul 04 11:59:38 PC7 exim4[13134]: 2017-07-04 11:59:38 Exim configuration
> error in line 401 of /etc/exim4/exim4.conf:
> Jul 04 11:59:38 PC7 exim4[13134]:   error in ACL: unknown ACL verb
> "condition" in "condition = ${if < {$message_size}{1M}}"
> Jul 04 11:59:38 PC7 exim4[13134]: Warning! Invalid configuration file for
> exim4. Exitingfailed.
>
> acl_check_data:
>
>   condition = ${if < {$message_size}{1M}}
>
> This is accepted without problems in Exim version 4.84.2 but not anymore
> after the upgrade.
>
> And this syntax is still in your documentation:
>
> 
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch-
> string_expansions.html
>
> If both strings are omitted, the result is the string |true| if the
> condition is true, and the empty string if the
> condition is false. This makes it less cumbersome to write custom ACL and
> router conditions. For example, instead of
>
> condition = ${if >{$acl_m4}{3}{true}{false}}
>
> you can use
>
> condition = ${if >{$acl_m4}{3}}
>
> 
>
> So how can i migrate my system without getting crazy with the
> configuration?
> Please help.
>
> Best regards
> Karsten
>
>
> Besides some more documentation errors:
>
> 
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch-
> string_expansions.html#SECTexpcond
> There are a number of symbolic operators for doing numeric comparisons.
> They are:
>
> |= |   equal
> |== |   equal
> 
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811 <01904%20323811>

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Router Conditional Lookup Fails

[Mike Brudenell via Exim-users]

Hi, Patrick -

On 14 June 2017 at 22:01, Patrick Porteous 
wrote:

> Here is an example of my router setup with comments on what errors I
> receive in each case:
>
> localuser_filter:
>  driver = accept
>  transport = local_spam_delivery
>  condition = ${lookup {Spam} lsearch{/etc/exim/banned_subjects}{yes}{no}}
> # This works if the word Spam is anywhere in the message.
>  condition = ${if match{$h_Subject:}{[Spam]}{yes}{no}} # This works if
> the word Spam is in the subject.
>  condition = ${lookup {$h_Subject} 
> wildlsearch{/etc/exim/banned_subjects}{yes}{no}}
> #  This fails and gives me the following error.
>

Double-check that the above does what you want as I have a feeling there
might be some problems with it…

   - *condition* is a precondition, and all preconditions listed for a
   router must evaluate to true for the router to run. So with these three
   preconditions you'll therefore need *all three* to pass; is that what
   you're wanting/expecting?

   - I keep looking at the first *condition* wondering if I'm missing
   something… your comment says it matches if the word Spam is anywhere in the
   message. I'm looking at it and thinking it's actually looking for the
   string constant "Spam" to see if it appears in the your
   /etc/exim/banned_subjects file. That is, not consulting the message content
   at all?

   - The second *condition* also seems a bit suspect… the *match* expansion
   condition takes a regular expression as its second argument. Here you have
   "[Spam]" which is a character class that matches a single character drawn
   from the set "S", "p", "a" or "m". So if the subject text contains any one
   of these four characters the condition will match. This doesn't seem to be
   what you want!

   - Also remember that *match* is case-sensitive, so you probably want to
   switch to case-insensitive matching by adding "(?i)" to the start of the
   pattern.

   - The third *condition* also has an error in that you're missing the ":"
   from the end of the "$h_Subject



> Error:
> failed to expand condition "${if and{{bool_lax{NULL}}{bool_lax{${lookup
> {$h_Subject} wildlsearch{/etc/exim/banned_subjects}{yes}{no}}" for
> localuser_filter router: missing lookup type inside "and{...}" condition
> *** The last condition is what I am trying to accomplish.
>

I don't understand how the condition logged as failing to expand matches
what you have in the file, unless it's some sort of internal representation
of yours.

In which case you might find that adding the missing ":" to the end of the
"$h_subject" improves matters: the *Specification* states that (with
emphasis mine):

Note that the name *must be terminated by colon or white space*, because it
may contain a wide variety of characters. *Note also that braces must not
be used*.


So it might be that without the terminating ":" the variable name is
including the final "}" and throwing out your matched braces?


I am doing this on a virtual host with multiple domains without local
> users.  The user accounts are in a database.  I'm trying to avoid filtering
> using the .forward file in each user directory and do this system wide
> instead.
>

It's many years since I've used a system filter but I'd suggest taking
Ian's advice and checking that out as an alternative way of doing this.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] DMARC spf_domain= empty

[Mike Brudenell via Exim-users]

On 5 June 2017 at 07:09, Richard James Salts via Exim-users <
exim-users@exim.org> wrote:

> Was the message a bounce or autoreply with an empty sender? Should the
> behaviour be to fall back to helo domain with spf when
> processing a message from the empty sender? Is that even desirable?
>

If it's any help, section 2.4 of RFC 7208 SPF
 states:

[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
[RFC5321]).  In this case, there is no explicit sender mailbox, and such a
message can be assumed to be a notification message from the mail system
itself.  When the reverse-path is null, this document defines the "MAIL
FROM" identity to be the mailbox composed of the local-part "postmaster"
and the "HELO" identity (which might or might not have been checked
separately before).


and section 3.1.2 of RFC 7489 (DMARC) states:

Note that the RFC5321.HELO identity is not typically used in the context of
DMARC (except when required to "fake" an otherwise null reverse-path), even
though a "pure SPF" implementation according to [SPF] would check that
identifier.


So as I understand it then yes, you fall back to the HELO domain when the
RFC5321.MailFrom is null. (This tallies with what I've observed happening
with Gmail's SPF and DMARC verification.)

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] How do I disable double at sign in message-ID?

[Mike Brudenell via Exim-users]

Hi,

On 30 May 2017 at 13:32, Imri Paloja || De Hosting Makelaar <
i...@dehostingmakelaar.nl> wrote:

> Pardon me asking, but I see the double at sign in the mail log on our
> server, meaning the double at sign is created by EXIM?
>
> How does one disable the double at sign in EXIM?
>

Every email message should have a "Message-ID" header that includes a value
that uniquely identifies the message. It looks a bit like an email address.

Usually the software that creates the message should generate and add the
Message-ID header to it. The mail servers it passes through then log the
message along with its Message-ID to assist with tracing.

However if a message arrives at a mail server without a Message-ID header
then the mail server software itself usually generates one and adds it to
the the message. Later mail servers will then see and log that.

So you need to try and work out what is generating the strange Message-ID
that contains two "@" characters…

Start by looking in your Exim logfiles for the entry that shows the message
*arriving* into your mail server system. This log line will include a " <=
" marker to show its about the message arriving on your system. Does this
log line include an attribute named "id"? For example, something like

… id=*something*@*somethingelse* …


If this is present then it means that there was a Message-ID header already
present in the message your Exim was receiving: that your Exim *did
not* generate
the Message-ID value, but instead some mail software further upstream
produced it.

If there is no "id=" attribute logged on the arrival line then Exim didn't
find a Message-ID header within the incoming message so had to create one
itself. However when it does so it generates a value that has a very
specific format:

*Exx-x-xx*@*your.computer.name *


That is, it

   - begins with the letter "E"
   - is followed by the internal id string Exim uses to track your message
   whilst processing it (the "*x--xx*" part of the example above)
   - has the full hostname of the computer Exim is running on after the
   "@"  (the "*your.computer.name *" part of the
   example above)

The example Message-ID value you gave isn't of this form, which indicates
your Exim didn't generate/add the strange Message-ID.

That's why I think you'll find an "id=" attribute on the "<=" log line
showing your message's arrival into Exim, which will confirm that you need
to look further back at the thing that sent you the email: the problem lies
updstream, either at the software which generated the message, or (if there
are any) in one of the mail servers it flowed through on its way to your
Exim.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Problems with ldap lookup and doubling comma in userPassword field

[Mike Brudenell via Exim-users]

Hi, Daniel -

Is the problem that you've forgotten to use Exim's quoting features on the
username and password when constructing the LDAP lookup?

For example the *Specification* gives examples such as this for ldapauth:

server_condition = ${if and{{ \
  !eq{}{$auth1} }{ \
  ldapauth{\
user="uid=${quote_ldap_dn:$auth1},ou=people,o=example.org" \
pass=${quote:$auth2} \
ldap://ldap.example.org/} }} }

And a later example in the *TLS Authenticator* section implies that an ldap
lookup should also be using quoting:

server_condition =  ${if forany {$auth1} \
  {!= {0} \
  {${lookup ldap{ldap:///\
   mailname=${quote_ldap_dn:${lc:$item}},\
   ou=users,LDAP_DC?mailid} {$value}{0} \
 } } }}

Cheers,
Mike B-)



On 24 May 2017 at 10:58, Daniel Betz  wrote:

> Hello list,
>
> i have an problem, which has to do with the change
> https://bugs.exim.org/show_bug.cgi?id=660
>
> My plan is to reduce LDAP queries and enable an admin password for mail
> accounts.
>
> The userPassword and adminPassword fields in ldap are base64 encoded
> sha512 crypt, which can include ","
> Problem is, that they get doubled by the patch above, although i have
> tried an other seperator like : LDAP_LOOKUP_USER_PLAIN = <\n ${lookup ldap.
> but the doubling of , is hardcoded into the source.
>
> Debug Log shows this:
>
> exim[13496]: 13506 LDAP value loop userPassword:{crypt}$6$,7_X.clF$
> OHzHUqADeV9ijFJn9EsB0LMp7iL7PYVNdjUtLblOvch9lGkv7G9jnvU.
> jUqWL61tg1352IMSVHtdJ0FUA1akT1
> exim[13496]: 13506 lookup yielded: id="4029359"
> objectClass="qmailUser,person" [...] userPassword="{crypt}$6$,,7_X.clF$
> OHzHUqADeV9ijFJn9EsB0LMp7iL7PYVNdjUtLblOvch9lGkv7G9jnvU.
> jUqWL61tg1352IMSVHtdJ0FUA1akT1"
>
> Here you can see the doubling of the ,, in the lookup. Therefore
> authentification with crypteq{} will fail.
>
> It would be nice, when i can change the separator for ldap lookups, so
> that i must noch manually patch the src/lookups/ldap.c
>
>
>
> My config looks like this:
> LDAP_LOOKUP_USER_PLAIN = ${lookup ldap {\
> nettime=3 time=5 user=LDAP_USER
> pass=LDAP_PASS referrals=nofollow \
> ldapi:///LDAP_BASEDN??sub?(&(!
> (accountstatus=inactive))(|(uid=${quote_ldap:$auth2})(
> mail=${quote_ldap:$auth2})))\
>   }}
> LDAP_LOOKUP_USER_LOGIN = ${lookup ldap {\
> nettime=3 time=5 user=LDAP_USER
> pass=LDAP_PASS referrals=nofollow \
> ldapi:///LDAP_BASEDN??sub?(&(!
> (accountstatus=inactive))(|(uid=${quote_ldap:$auth1})(
> mail=${quote_ldap:$auth1})))\
>   }}
>
>
> plain:
>   driver = plaintext
>   public_name = PLAIN
>   server_prompts = :
>   server_condition = ${if or {\
> {crypteq{$auth3}{${extract{
> userPassword}{LDAP_LOOKUP_USER_PLAIN\
> {crypteq{$auth3}{${extract{
> adminPassword}{LDAP_LOOKUP_USER_PLAIN\
>  }{yes}{no}}
>   server_set_id = $auth2
>
>
> login:
>   driver = plaintext
>   public_name = LOGIN
>   server_prompts = Username:: : Password::
>   server_condition = ${if or {\
> {crypteq{$auth2}{${extract{
> userPassword}{LDAP_LOOKUP_USER_LOGIN\
> {crypteq{$auth2}{${extract{
> adminPassword}{LDAP_LOOKUP_USER_LOGIN\
>  }{yes}{no}}
>   server_set_id = $auth1
>
>
>
> Freundliche Grüße,
>
> Daniel Betz
> System Design Engineer / Senior Systemadministration
> ___
>
> domainfactory GmbH
> Oskar-Messter-Str. 33
> 85737 Ismaning
> Germany
>
> Telefon:  +49 (0)89 / 55266-364
> Telefax:  +49 (0)89 / 55266-222
>
> E-Mail:   db...@df.eu
> Internet: www.df.eu
>
> Registergericht: Amtsgericht München
> HRB-Nummer 150294, Geschäftsführer:
> Tobias Mohr, Stephan Wolfram
>
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Retry Rules

[Mike Brudenell via Exim-users]

Hi, Joe -

Just from looking at the rule I believe it will do what you describe, with
the proviso that periods are are measured from the time of the first failed
delivery attempt. (So it would "try every minute for the first hour from
the first failed delivery attempt, then every 30 minutes until 4 hours have
gone by from the first failed delivery attempt")

You're presumably not seeing this happening, but withholding the
information about what you're actually seeing to make us guess.

So if it's the timings being out a bit then the measuring being done from
the first delivery attempt rather than the end of the previous period might
explain it. You can do some testing using Exim's "-brt" command line option.

Or, as Heiko has just said, you're not running queue runner processes at
all/frequently enough. It's the queue runner that does the retry, so
whenever one runs it looks for messages that are ready to be retried and
does so. If you're not running any queue runners at all then there'll be no
retries. If you're only running a queue runner once a day, then that's when
the retried are done.

Here I run a queue runner every 2 minutes, but with a cap on how many can
exist at once using queue_run_max.

Cheers,
Mike B-)

On 22 May 2017 at 16:50, Joseph Kezar via Exim-users 
wrote:

> Heiko + Exim Users,
>   Thank you for providing that link.  I have consulted that link prior to
> my composing my original email to the exim-users group.  I in fact am the
> one who wrote this retry rule based on that exim specification.  My goal
> was to write a rule that retries every 1 min for up to 1 hour.  Then every
> 30 min for up to 4 hours.  Finally every 1 hour for 5 days.  Does my rule
> for vermont.gov recipients appear to behave this way?:
>   vermont.gov  *  F,1h,1m;  F,4h,30m;  F,5d,1h
>
>
>
> Thanks,
> Joe Kezar
>
> On Mon, May 22, 2017 at 10:50 AM, Heiko Schlittermann via Exim-users <
> exim-users@exim.org> wrote:
>
> > Joseph Kezar via Exim-users  (Mo 22 Mai 2017
> > 16:21:22 CEST):
> > > Can someone please explain what this retry rules does?
> > >
> > > vermont.gov  *  F,1h,1m;  F,4h,30m;  F,5d,1h
> >
> >
> > http://www.exim.org/exim-html-current/doc/html/spec_html/ch-
> > retry_configuration.html
> >
> >
> > 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 -
> >  ! key id 7CBF764A and 972EAC9F are revoked since 2015-01  -
> >
> > --
> > ## 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/
> >
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Problems with Smarthost configuration and space in the password

[Mike Brudenell via Exim-users]

Hi, Sebastian -

As far as I know, there is nothing in Exim's standard configuration that
creates/uses passwd.client and so on. Instead it has to be put into the
configuration file by the person looking after the mail service.

However it might be that Debian have "helpfully" provided various standard
setups for mail administrators to "just use". That means whether or not it
works with spaces is determined by the configuration entries they wrote.

So as someone suggested originally, you might get a more definite answer
from a Debian-specific forum as it's a Debian-created add-on to the
standard Exim configuration.

Cheers,
Mike B-)

On 25 April 2017 at 16:29, Sebastian Lorenzen via Exim-users <
exim-users@exim.org> wrote:

> Thanks for the replay!
>
> It tried the following with no success so far:
>
> Username:'passw ord'
> Username:passw^word
> Username:passw\ word
>
> Nothing worked.
> I always did a reload config and a restart of exim service
>
> -Original Message-
> From: Exim-users [mailto:exim-users-bounces+sebastian.lorenzen=outlook.
> c...@exim.org] On Behalf Of George L. Yermulnik
> Sent: Dienstag, 25. April 2017 17:00
> To: exim-users@exim.org
> Subject: Re: [exim] Problems with Smarthost configuration and space in the
> password
>
> Hello!
>
> On Tue, 25 Apr 2017 at 12:34:57 (+), Sebastian Lorenzen via Exim-users
> wrote:
>
> > You are right, it runs on a Debian wheezy.
> > I followed one of the tutorials in the web like this one:
> > http://www.pontikis.net/blog/gmail-smarthost-exim4-debian
> > Very few steps and very simple. Not sure if this is specific to Debian.
>
> http://www.pontikis.net/blog/gmail-smarthost-exim4-debian#
> highlighter_32669
> {quote}
> NOTE: if the password contains special characters ($, \, {}) you have to
> escape them.
> {quote}
>
> Open your /etc/exim4/passwd.client and escape space character with a
> backslash.
>
> > On 25/04/17 12:11, Sebastian Lorenzen via Exim-users wrote:
> > > Is a space in the password supported?
>
> > It depends how you access it and manipulate it in your configuration.
> > Since you refer to "exim4" I'm guessing this means Debian's
> configuration; you need to as in a Deb-specific forum.
> > --
> > 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/
>
> --
> George L. Yermulnik
> [YZ-RIPE]
>
> --
> ## 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/
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exim lsearch lookup in multiple files at the same time

[Mike Brudenell via Exim-users]

Hi, Rustam -

Can I check your setup? Is it that:

   - You have a number of files, one per domain — /etc/exim/d1.example.com
   /etc/exim/d2.example.com /etc/exim/d3.example.com and so on
   - You want to look up the $sender_address to find the value for
   *client_send* to use

Is there a correlation between the domain of $sender_address and the file
its details will be found in?

For example, if the $sender_address value is "m...@d2.example.com" then its
value will always be found in the "/etc/exim/d2.example.com" file?

If so then instead of searching through a list of all the files you could
just extract the domain of $sender_address (it's already in
$sender_address_domain), convert it to lower case, and use that to build
the filename you need to look in using lsearch. For example (untested),

client_send = ${lookup {$sender_address} lsearch \
   {/etc/exim/${lc:$sender_address_domain}}}

If you do this remember to check and see it works OK for the edge cases —
eg, what happens if there's no file for a value of $sender_address_domain
(from memory I think it'll return an empty value), or if
$sender_address_domain is empty (because it's a Non-Delivery Report from
the address "<>").

I use a technique like this to implement aliases for domains we virtual
host, and also to choose DKIM signing keys for domains. To help guard
against empty domain name problems I give each filename a suffix, so it's
always non-empty. For example in the above the filename might instead be
chosen with

{/etc/exim/${lc:${sender_address_domain}-authdatastring}}

Cheers,
Mike B-)

On 18 April 2017 at 19:36, Rustam via Exim-users 
wrote:

> I often need to have exim do a lookup in multiple files at the same time.
> For example, to send a plain auth based on per-domain data:
>
> PLAIN:
>   driver = plaintext
>   client_send = ${lookup{$sender_address}lsearch{/etc/exim/domain1}}
>
>
> The way I solve it for now is to wrap a subsequent lookup into the negative
> case of the preceding lookup like this:
>
>   client_send = ${lookup{$sender_address}lsearch{/etc/exim/domain1}{$
> value}\
>{${lookup{$sender_address}lsearch{/etc/exim/domain2
>
>
> This solution works, but it is hard to maintain (when the number of files
> is large, it becomes very hard to keep track of the ever growing amount of
> closing braces).
>
> So my proposal is to allow a* list of files* as an argument to lsearch. Of
> if there is an easier solution, I'm open to suggestions.
>
> Regards,
> Rustam
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] verify = header_syntax and specific From

[Mike Brudenell via Exim-users]

Hi, Max -

If from your error message you mean that the RFC5322.From header of the
message reads

From: CEX.IO Mailer [nore...@cex.io] 


then yes, I think it is expected behaviour as the header you give is
syntactically invalid according to RFC 5322:

from=   "From:" mailbox-list CRLF

mailbox-list=   (mailbox *("," mailbox)) / obs-mbox-list

mailbox =   name-addr / addr-spec

name-addr   =   [display-name] angle-addr

display-name=   phrase

phrase  =   1*word / obs-phrase

word=   atom / quoted-string

atom=   [CFWS] 1*atext [CFWS]

atext   =   ALPHA / DIGIT /; Printable US-ASCII
   "!" / "#" /;  characters not including
   "$" / "%" /;  specials.  Used for atoms.
   "&" / "'" /
   "*" / "+" /
   "-" / "/" /
   "=" / "?" /
   "^" / "_" /
   "`" / "{" /
   "|" / "}" /
   "~"


Following the above through you can see that the *display-name* (the bit
between the "From:" and the "") is composed of a *phrase*,
which is made up of one or more *words*, each of which is either an *atom* or
a *quoted-string*.

An *atom* is composed of one or mote *atext* characters, and the
*atext* characters
do not include "." or "[" or "@" or "]" — all of which are present in the
sample you give.

Because of this the display-name should instead be a quoted string, meaning
the header should read:

From: "CEX.IO Mailer [nore...@cex.io]" 


So congratulations: your requirement that the RFC5322.From header be
syntactically correct did its job and complained about one that isn't. :-)

(If the From header actually has some other value please post it here so we
can check it, rather than trying to guess it from the error logged.)

Cheers,
Mike B-)

On 13 April 2017 at 14:45, Max Kostikov via Exim-users 
wrote:

> Hi!
>
> I just got negative result on ACL on "verify = header_syntax" check with
> this incoming mail From field
>
>> missing or malformed local part (expected word or "<"): failing address
>> in "From:" header is: CEX.IO Mailer [nore...@cex.io] 
>>
> Is this Exim's behaviour is correct?
>
> --
> With best regards,
> Max Kostikov
>
> BBM: 24CA5DF8 | W: https://kostikov.co
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Problem with Mime attachment checking

[Mike Brudenell via Exim-users]

Hi,

I'm pretty sure it's unrelated to you not getting the warning message, but
there's an error in your *match* pattern: you have two consecutive vertical
bars between the dll and pdf extensions (albeit with a line continuation
inbetween).

In passing, as all the file type patterns begin with "." you could factor
that out to before the list of alternatives:

condition = ${if match {${lc:$mime_filename}} \
   {\N\.(exe|scr|bat|com|lnk|pif|reg|vbs|vb|vbe|dll|
pdf|chm)$\N}}

To see what's in the $mime_filename variable and work out what's going on
it might be an idea to:

   1. Create a test message that exhibits the problem when you send it;
   2. Run up an Exim listener on a test host with debug options turned on;
   3. Send your test message to the test system;
   4. Look through the debugging output of Exim: this contains a wealth of
   information such as what values are being substituted into string
   expansions, tests, etc and lets you see exactly what is being tested where
   and the results.

It can help if you have a second window open to view your configuration
file as you read through the debugging output, following the logic through.

The easiest way is to run Exim with verbose mode and all debugging enabled:
this gives you everything, is very verbose, but can help you trace through
your configuration file. Alternatively be more selective what options you
turn on.

exim -v -d+all -bd


*All:* Is there also a possible problem with the space character before the
"\" continuation character after the dll file type? When I've written LDAP
expressions before I remember having to be very careful not to put spaces
before the continuation character in some places because they didn't get
stripped by Exim's usual leading/trailing whitespace stripper: they were
considered important and part of the pattern.

Cheers,
Mike B-)

On 6 April 2017 at 17:25, Sujit Acharyya-choudhury 
wrote:

> I am having problem with Mime attachment checking with Exim 4.80 on
> Solaris.
> The following code is in place and I am not getting the Warning message:
>
>
>
> in the main settings:
>
>
>
> acl_smtp_rcpt = acl_check_rcpt
>
> acl_smtp_data = acl_check_data
>
> acl_smtp_mime = acl_check_mime
>
>
>
> acl_check_mime:
>
> # pdf is just for test
>
> warn
>
>
>
> condition = ${if match{${lc:$mime_filename}} \
>
> {\N(\.exe|\.scr|\.bat|\.com|\.lnk|\.pif|\.reg|\.vbs|\.vb|\.vbe|\.dll| \
>
> |\.pdf|\.chm)$\N} \
>
> {1}{0}}
>
> message = WARNING: Bad MIME attachment filename ($mime_filename)
>
> log_message = WARNING: Bad MIME attachment filename
> ($mime_filename)
>
> accept
>
>
>
>
>
> # ACL that is used after the DATA command
>
> acl_check_data:
>
>
>
>denymalware= *
>
>message= This message contains a virus ($malware_name).
>
>
>
>
>
> However, If I move the checking in the acl_check_data, then it gives the
> warning message.  Any idea?
>
>
>
>
>
>
>
> Thanks in advance
>
>
>
> Sujit Choudhury | IT Services
>
> Birkbeck, University of London
>
>
>
>
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Discard mail to certain recipients if the subject matches a string

[Mike Brudenell via Exim-users]

Chris' solution seems neater and simpler; I always forget about using
setting variables like that. (Starts musing on how to rewrite a somewhat
convoluted test in my own Exim config!)

On 5 April 2017 at 16:06, Chris Siebenmann  wrote:

> Something like:
>
> warn
> local_parts =  : 
> set acl_m0_nocommit = 1
>

However I'd guess you want to stick with using *recipients* instead of
*local_parts* though to check the full email address rather than just the
local part (to the left of the "@"). Otherwise it would trigger on an
address elsewhere in the world that happened to use the same local part as
one of the recipients you're checking for.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Discard mail to certain recipients if the subject matches a string

[Mike Brudenell via Exim-users]

Hi,

The error message seems pretty clear: you can't use the *recipients* condition
within an *acl_smtp_data* ACL. I assume this is because the recipients
condition tests the recipient currently being considered against the list.
However by the time you've got to an acl_smtp_data ACL there is no longer a
single current recipient; instead you've got the whole lot.

If that's right and I remember rightly, the $recipients variable can be
used in acl_smtp_data and contains a list of all the recipient addresses
form the envelope data, separated from each other with a comma and a space.
You can presumably iterate over this using *forany*, or might be able to do
something clever with *inlist* or *inlisti* instead.

A couple of other things to watch out for:

   - Note that the *Specification* says it isn't possible to discard *some*
   recipients in acl_smtp_data: you have to accept or reject the entire
   message to *all* its recipients. So be aware that if a matching message
   is sent to  and  then neither well receive it
   (because your test says that  mustn't be sent it).

   - Also watch out that the match operator's second argument is a *regular
   expression* and is a *pattern*. In your example you don't tie the
   pattern to the start and/or end of the expression, meaning it will match
   with "Commit" anywhere in the Subject text — or example, "Shall I Commit To
   This?" Are you intending this behaviour, or were you intending only to
   match if the Subject text is exactly that string? (in which case use *eq*
   or *eqi* instead of *match*)

Cheers,
Mike B-)

On 4 April 2017 at 16:11, Александр Кириллов via Exim-users <
exim-users@exim.org> wrote:

> Hi list,
>
> I need to discard mail from a known address to certain recipients IF the
> subject matches a known string. I've tried to add
>
>   discard message = The $sender_address is prohibited to send commit
> notifications to these recipients
>   senders   = 
>   recipients=  : 
>   condition = ${if match{$h_subject:}{Commit}}
>
> to acl_check_data section of exim.conf but got an error:
>
> ... temporarily rejected after DATA: cannot test recipients condition in
> DATA ACL
>
> What would be the correct way to accomplish this?
>
> TIA
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Public key syntax error with some DKIM keys?

[Mike Brudenell via Exim-users]

Hi, Mike -

The value of the TXT record for mysmtp._domainkey.1click-email.com looks a
bit dodgy to me: dig is displaying the value enclose within double-quotes.
If you look at the end you'll see the value (within the double-quotes)
finishes with

\"


I can't remember off the top of my head whether the public key can be
enclosed within double-quotes in the value, but usually it isn't. Certainly
having one double-quote at the end and none at its start is wrong: it's not
balanced!

Try having a look at our key if you like to see how our public key is
listed:

dig 20160523.google._domainkey.york.ac.uk. txt


Note that because we use a 2048-bit key the value is long so is broken into
two parts, each enclosed within double-quotes. However the p= public key
value itself is *not* enclosed in double-quotes within the overall record.

Cheers,
Mike B-)

On 31 March 2017 at 17:20, Mike Tubby  wrote:

> I'm getting DKIM public key parse errors with a few sites such as
> 1click-email.com:
>
>
> 2017-03-31 16:01:25 CONNECT: Accepting connection from: 185.163.190.90 -
> not blocked by any RBL
> 2017-03-31 16:01:25 HELO: Accepted HELO/EHLO relay843.mysmtp3.com from
> remote host: 185.163.190.90 (relay843.mysmtp3.com)
> 2017-03-31 16:01:25 MAIL: SPF Result=pass (1click-email.com /
> relay843.mysmtp3.com [185.163.190.90])
> 2017-03-31 16:01:25 MAIL: Accept from: bounce-a806-20059-20395-96d520
> c8=250090239=8...@1click-email.com host: relay843.mysmtp3.com
> [185.163.190.90]
> 2017-03-31 16:01:25 no IP address found for host localhost.localdomain
> (during SMTP connection from relay843.mysmtp3.com [185.163.190.90])
> 2017-03-31 16:01:25 RCPT: SPF Result2=pass (1click-email.com /
> relay843.mysmtp3.com [185.163.190.90])
> 2017-03-31 16:01:26 1cty3J-0003DR-Ok DKIM: d=1click-email.com s=mysmtp
> c=simple/simple a=rsa-sha256 b=1024 t=1490957772 [invalid - syntax error in
> public key record]
>
>
> Digging into it a bit further ;-)I find:
>
>
> root@relay1:/var/log/exim# dig mysmtp._domainkey.1click-email.com txt
>
> ; <<>> DiG 9.9.5-3ubuntu0.13-Ubuntu <<>> mysmtp._domainkey.1click-email
> .com txt
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5348
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;mysmtp._domainkey.1click-email.com. IN TXT
>
> ;; ANSWER SECTION:
> mysmtp._domainkey.1click-email.com. 3448 IN TXT "v=DKIM1\; k=rsa\;
> p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDjhzHudEPNFL21OHfqaD
> Z6BR2tHdFanOLg/EdFDIXzBGMBdzNPkYIHlsT/Wj+QVwy81k+0VQ+lnHzNpi
> 50R/NE6mzemXTfUROp93iErT8QZsDLCN2Iwyumhh81miit3+362xNgUDF0t3
> C7URff0gsQi61GLsk8JrUuYxvhaDN3AwIDAQAB\""
>
> ;; AUTHORITY SECTION:
> 1click-email.com.   153782  IN  NS ns41.domaincontrol.com.
> 1click-email.com.   153782  IN  NS ns42.domaincontrol.com.
>
> ;; ADDITIONAL SECTION:
> ns41.domaincontrol.com. 65728   IN  2607:f208:206::15
> ns42.domaincontrol.com. 65728   IN  2607:f208:302::15
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Mar 31 17:13:11 BST 2017
> ;; MSG SIZE  rcvd: 419
>
>
>
> ... and over at ProtoDave.com his DKIM public key checker checks out with
> 'success' and says the key is okay.
>
>
> Who to believe?  Is Exim correct or ProtoDave correct or is there a corner
> case and Exim is being a bit too picky?
>
>
>
> Mike
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811 <01904%20323811>

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Block if sender and recipient domain are the same?

[Mike Brudenell via Exim-users]

Hi, Pete -

Assuming by sender and recipient you mean the RFC5321.MailFrom and
RFC5321.RcptTo addresses — ie, those in the envelope — then it should be
straightforward. (You can still do it if you mean the RFC5322.From and
RFC5322.To header addresses, but it's a little more complicated.)

You'll want an entry in your *acl_smtp_rcpt* ACL that uses either the *deny* or
*discard* verb: the former issues an SMTP rejection code back to the
sending server when it needs to reject a recipient address; the latter
pretends to accept the recipient address but then silently discards it.

If this is to apply to a single domain name only then it's probably easiest
to use the *domains* and *sender_domains* conditions to match recipient and
sender domains. For example something like this (untested!):

deny

message = Users in domain-a.com can't send messages to domain-a.com
recipients
domains = domain-a.com

sender_domains = domain-a.com


However if you have two or more domains to apply this to then you instead
need to (1) see if the sender domain is one you're interested in and, if it
is, then (2) check if the sender domain matches the recipient domain. For
example something along these (untested!) lines:

# List of domain names whose users can't send to recipients within the same
domain name.

domainlist blocksamedomainusers = domain-a.com : domain-b.com : domain-c.com


*… Then in your acl_smtp_rcpt ACL …*


deny

message = Users in $sender_address_domain can't send messages to $domain
recipients
sender_domains = +blocksamedomainusers

condition = ${if eqi{$sender_address_domain}{$domain}}


This should work for a message someone in domain-a.com sends to a mix of
recipients: some in the same domain and some in others: the addresses in
the same domain will be rejected/discarded, but the message will still go
through to recipients in other domains.

Cheers,
Mike B-)

On 20 March 2017 at 14:57, Peter Leeman  wrote:

> Hi All
>
> Is it possible to block an email if both the sender and recipient domain
> are the same?
> Example - sen...@domain-a.com to
> recipi...@domain-a.com
>
> The reason I am looking to do this is we are going to be using Exim to
> handle incoming/outgoing mail for a domain hosted on Exchange so any mail
> for domain-a.com being emailed from a mailbox on domain-a.com will never
> leave exchange.  We still want a sender on domain-a.com to be able to
> email external domains, but want to prevent incoming emails destined for
> domain-a.com appearing as if they are coming from domain-a.com.
>
> The only alternative I can see at this stage is to have two Exim boxes,
> one to handle incoming the other to handle outgoing.
>
> Thanks for any help.
>
> Regards,
>
> Pete.
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Rewriting sender based on recipient?

[Mike Brudenell via Exim-users]

Hi, Marco -

I'm not too sure what you're asking… Is it about the *errors_to* option for
routers in Exim? If so, the documentation for errors_to in the
*Specification* shows it is expanded when it is used. That is, you can use
a string expansion expression with the option to choose what value you
should assign it based on other things.

So you can write a string expansion that does whatever you need — for
example, test the domain of the recipient address to see whether they are
one of your local users or not, then do either a file- or LDAP-lookup to
see if there is a value to be sued for them.

If you're instead asking about rewriting the RFC5321.MailFrom,
RFC5322.{From, Reply-to, Sender} headers using the Address Rewriting
section then you can also use string expansions in the replacement value of
rules there so can do the same thing there.

Cheers,
Mike B-)

On 17 March 2017 at 11:45, Marco Gaiarin  wrote:

>
> Supposing to have aliases (strictling speaking: a LDAP query, but also a
> file, is irrilevant) that have as destination local and remote addresses
> (clearly, not only one of them: mixed up).
>
> There's some way to rewrite sender, setting 'errors_to = ', based on the
> recipient address, eg only for nonlocal recipient?
>
>
> Thanks.
>
> --
>   Vendere no, non passa tra i miei rischi,
>   non comprate i miei dischi e sputatemi addosso.   (F. Guccini)
>
>
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] How to permit unqualified senders once authenticated

[Mike Brudenell via Exim-users]

Hi, Adam -

I'm not sure how good an idea it is to accept email addresses not qualified
with a domain name unless, of course, you're going to qualify them by
adding a domain name yourself using *qualify_domain*. For example if you
sent onward an email with the RFC5321.MailFrom set to  how would a
Non-Delivery Report get returned to the sender: a server further along the
delivery chain doesn't know the domain name.

The *sender_unqualified_hosts* and *recipient_unqualified_hosts* configuration
options are both expandable (marked with a "†" in the *Specification* so
you can use string expansion to do tests when assigning their value. This
value is a *host list*, which is not the same as a hostname; instead it can
be a colon-separated list of textual host names, IP addresses, or netblocks.

So you could perhaps try something devious by using a string expansion that
produces the connecting client's IP address (from *$sender_host_address*)
if the connection is authenticated (*$authenticated_id* is defined),
otherwise the empty string. Not sure how this might affect locally
generated, non-SMTP messages though: they have an empty value for
*$sender_host_address*).

If it matches it'll then have the domain set with your *qualify_domain* setting
applied, whose value isn't expandable so you can't select one based on the
authentication credentials. (However I guess there might be other ways to
do that later in Exim handling process.)

Cheers,
Mike B-)

On 20 March 2017 at 10:04, Adam Nielsen  wrote:

> Hi all,
>
> New issue, now I have SMTP AUTH figured out.  When one of my network
> devices sends e-mail, it uses an unqualified name (just the hostname
> with no '@' or domain.)  Exim rejects this as it does not allow
> unqualified addresses from remote hosts.
>
> The debug logs say this:
>
>   SMTP<< mail FROM: size=19029
>   SMTP>> 501 : sender address must contain a domain
>   LOG: smtp_syntax_error MAIN REJECT
> unqualified sender rejected:  H=mydevice.mydomain
>
> It looks like there are two options "sender_unqualified_hosts" and
> "recipient_unqualified_hosts" that could permit this, however from what
> I can make out you can only specify hostnames for both options.  Since
> my troublesome device is behind a dynamic IP, there's no hostname that
> can be specified.
>
> It is of course authenticating with Exim so it is permitted to send
> mail, so I am trying to figure out how to allow unqualified senders
> over authenticated connections.  Either allowing these addresses or
> having Exim qualify them would be fine, but I can't quite see how to
> manage this.
>
> There seems to be a "submission" control option to make Exim behave
> like the connection is coming from an MUA (where unqualified senders
> are apparently permitted), so I tried adding this to my config:
>
>   acl_smtp_mail = acl_check_mail
>   acl_check_mail:
> accept
>   authenticated = *
>   control = submission/domain=mydomain
>
> I figured the MAIL ACL is where it belongs since the Exim logs above
> indicate failure immediately after the SMTP MAIL FROM command.
> Unfortunately, adding this ACL does not do anything and the message is
> still rejected for the same reasons.
>
> What am I missing?
>
> Many thanks,
> Adam.


-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811 <01904%20323811>

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exim Filters Bypass

[Mike Brudenell via Exim-users]

Hi, Usama -

It's not clear what you're asking, so a very general answer…

You can find the documentation for the Exim Filter Specification at

http://www.exim.org/exim-html-current/doc/html/spec_html/filter.html


Section 3.4 says that "A complete list of the available variables is given
in the Exim documentation" so you can presumably use any of the variables
in conditions. You can get the domain of the sender and/or recipient out of
these, and the Message-ID, for your tests.

Later in the specification there are examples of using "and" and "or" to
combine conditions.

Finally, you might want to consider using "matches" instead of "is" or
"contains" to combine some of your expressions using regular expressions.
For example, the following (which are *untested*):

$received_protocol matches "^(?i)smtps?|esmtp(?:s(?:a)?)?$"

or

$h_subject matches "(?i)swiss|sales|marketing|promotions"


Cheers,
Mike B-)

On 16 March 2017 at 07:33, Usama Tariq  wrote:

> Dear Concern,
>
> Is it possible to bypass any specific domain or email id from global exim
> filter:
>
> #cat /usr/local/cpanel/etc/exim/sysfilter/options/cpanel_exim_
> system_filter
>
> if
> ($received_protocol is "local"
> or $received_protocol is "smtp"
> or $received_protocol is "smtps"
> or $received_protocol is "esmtp"
> or $received_protocol is "esmtpa"
> or $received_protocol is "esmtps"
> or $received_protocol is "esmtpsa")
> and ("$h_subject:" contains "swiss")
> or ("$h_subject:" contains "sales")
> or ("$h_subject:" contains "marketing")
> or ("$h_subject:" contains "promotions")
> then
>   logwrite "$tod_full $message_id from $sender_address contained **SPAM**
> $h_subject to $h_to keywords"
> seen finish
> endif
>
>
> With Best Regards,
>
>
> [image: photo]
> *Usama Tariq | NetOps Engineer*
> Websouls
> p:92.423.523.8871-73 | m:92.321.4077991 | e:us...@websouls.com | w:
> http://websouls.com/ | a: Office # 22, 2nd Office Floor, IT Tower,
> Behind Hafeez Center, 73-E-1, Hali Road, Gulberg III, Lahore
> 
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] DKIM outgoing Mail

[Mike Brudenell via Exim-users]

Hi, Basti -

On 2 March 2017 at 11:42, basti  wrote:

>   dkim_domain = ${if match_domain{$sender_address_domain}{+local_domains}\
> {$sender_address_domain}\
> {}\
>   }
>

Remember that you should still lowercase the $sender_address_domain before
assigning it to dkim_domain.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] DKIM outgoing Mail

[Mike Brudenell via Exim-users]

Hi, basti -

You can prevent the error by first checking whether the private key file
exists using the *exists* operator. For example,

dkim_private_key = ${if
exists{/etc/exim4/ssl/dkim.${lc:${domain:$h_from:}}.private.key} \

{/etc/exim4/ssl/dkim.${lc:${domain:$h_from:}}.private.key}}

However you might want to build your selector name into the test too, so
that if you change keys in the future you can switch easily form old to new
(and back again if you discover a problem with the new one!). Foer example,

dkim_private_key = ${if exists{/etc/exim4/ssl/dkim.
${dkim_domain}-${dkim_selector}.private.key} \
  {/etc/exim4/ssl/dkim.
/${dkim_domain}-${dkim_selector}.private.key}}

*But note what James says:* you should really only be DKIM-signing messages
that

   1. use a domain name you control in their RFC5322.From header, *and*
   2. are originating from a source you trust: either a machine in your own
   network, or someone who has authenticated to your service from anywhere.

(2) is important otherwise a spammer could send a message to your server
with a From header forged to be one of your addresses. If you then forward
and DKIM-sign it then you're signing spam.

If you're really cunning and careful you can build all that into your
*dkim_domain* line. For example in ours I use an expression to:

   1. Check its an authorised sender — ie, has authenticated or from a
   machine with an IP address in our netblock, and then
   2. use *lookup* with an *nwildsearch* to look for the domain name in a
   text file, and
   3. if found set *dkim_domain* to the value of the entry found in the
   file (otherwise to the empty string, which suppresses DKIM signing).

Likewise I do an *lsearch* to look up the domain name to find the selector
name I should currently be using to sign with for that domain.

Cheers,
Mike B-)

On 1 March 2017 at 15:58, basti  wrote:

> Hello,
> I do sign outgoing mail with dkim.
> In my config I use
>
> remote_smtp:
>   driver = smtp
>   dkim_domain = ${lc:${domain:$h_from:}}
>   dkim_selector = mx
>   dkim_private_key =
> /etc/exim4/ssl/dkim.${lc:${domain:$h_from:}}.private.key
>   dkim_canon = relaxed
>
> all is fine for my domains I do hosting.
>
> but when i get a mail from facebook and do a redirect to an other
> mailadress I get an error that the private key for facebook does not exist.
>
> 2017-03-01 04:01:22 1ciuVy-0004Hv-Ad <=
> notification+kr4ynkwxk...@facebookmail.com H=(mx-out.facebook.com)
> [69.171.232.172] P=esmtps X=TLS1.0:ECDHE_RSA_AES_128_CBC_SHA1:128 CV=no
> S=20050 id=a7d60ae185f5cf2f9aa2e4db61bfe...@async.facebook.com
> 
> 2017-03-01 04:01:24 1ciuVy-0004Hv-Ad unable to open private key file for
> reading: /etc/exim4/ssl/dkim.facebookmail.com.private.key
>
>
> That's ok. but how do i solve it.
> Should i do only sign my own domains?
>
> best regards,
> basti
>
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Ongoing email issues

[Mike Brudenell via Exim-users]

Including the symbol table makes the binary larger (and so, I guess,
possibly its memory requirements: I can't remember).

Turning off optimisation means the compiler generates less efficient code.

Cheers,
Mike B-)

On 1 March 2017 at 10:30, Odhiambo Washington via Exim-users <
exim-users@exim.org> wrote:

> On 1 March 2017 at 12:01, Jeremy Harris  wrote:
>
> > On 01/03/17 07:22, Odhiambo Washington via Exim-users wrote:
> > > On 1 March 2017 at 01:45, Jeremy Harris  wrote:
> > >
> > >> On 28/02/17 22:16, Daryl Richards via Exim-users wrote:
> > >>> (gdb) bt full
> > >>> #0  0x000802c03b1a in ?? ()
> > >>> No symbol table info available.
> > >>> Cannot access memory at address 0x7fffdfffee20
> > >>>
> > >>> 
> > >>
> > >> Binary distribution or self-built?  If the latter,
> > >> rebuild with  make CFLAGS="-g -O0"
> > >>
> > >
> > >
> > > So, if I may ask, 'make CFLAGS="-g -O0"' builds with debug capability
> or
> > > what?
> >
> > The -g tells the compile/link to add symbols information to
> > the binary; the -O0 turns the compiler optimization all the
> > way down, which makes it easier for a human to understand
> > the relationship of object code to source code.
> >
> > These are compiler things, applicable to any C program not
> > just Exim.
> > --
> > Cheers,
> >   Jeremy
> >
>
>
> Does it then have any penalties on the binary, as in impact on performance,
> so that these should not be everyday options??
>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft."
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] outbound discard all filter for cpanel twisted exim

[Mike Brudenell via Exim-users]

Hi, Brian -

On 17 February 2017 at 00:45, ping murder  wrote:

> re-reading your reply - it looks like an ACL might work (as long as cPanel
> updates don't clear them out) but would you have an example of a discard
> ACL for all mail?


Assuming I'm not going totally crackers (it is Friday, after all!),
wouldn't this ACL do the job?

In your *acl_smtp_mail* ACL put the one line


discard


With no conditions in place it'll always operate. In the *Exim
Specification* section *13. ACL return codes
*
says:

If the ACL for MAIL returns “discard”, all recipients are discarded, and no
ACL is run for subsequent RCPT commands. The effect of “discard” in a RCPT
ACL is to discard just the one recipient address. If there are no
recipients left when the message’s data is received, the DATA ACL is not
run.


Do having the ACL that runs in response the MAIL FROM that selects
*discard* unconditionally
should discard all recipients for that incoming message, meaning the
message won't be delivered.

Using *discard* rather than *deny* means the sending system thinks their
message has been accepted so removes the outgoing message from its queue.
The receiving Exim discards it. Done.

Well, maybe not quite: you probably need an equivalent *acl_not_smtp* ACL
entry to also pick up and discard messages being submitted on the WP server
from the command line — eg, being piped into the exim/mail/sendmail
commands.

However as Chris suggests, you might find it valuable to create an SMTP
server that accepts and silently discards all incoming mail (eg, using the
above) and have your numerous client PHP servers send their email to it.
That would indeed give you a single place where all attempts to send
outgoing message would go so you could monitor its logs and look for
unexpected activity, helping to idnetify WP systems that had been
compromised.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] outbound discard all filter for cpanel twisted exim

[Mike Brudenell via Exim-users]

Hi, PM -

Do your servers send the outbound email direct to the recipient or to a
smarthost? That is, are you wanting to configure the individual servers to
not send out email, or to configure your smarthost to discard mail coming
in from them instead of delivering it onward?

Assuming it's the former…

I don't think you want a "filter" within Exim, but could probably just use
ACLs to deal with the messages. For example there are two ACL that are
likely of interest:

   - *acl_smtp_rcpt* — used for messages that arriving at your Exim over
   SMTP, and
   - *acl_not_smtp* —  used for messages that are locally submitted to your
   Exim directly from the command line (ie, not over SMTP)

Rather than trying to stop mail going out, just deal with it in these ACLs
to prevent it getting in!

   - If you want to inform the sender the message was rejected with a
   refusal code use the *deny* verb.
   - If you want to silently accept the message *discard* verb.

See the Exim Specification to read more about

   - Access Control Lists (ACLs)
   

   in general
   - these ACL verbs and others verbs
   


If you're trying to do this on a central smarthost — to reject or discard
messages arriving from some sources but not others — use the same idea but
with some conditions to only apply the deny or discard to hosts it should
affect.

(An alternative approach would be to accept the incoming message into your
queues and then not have a router that accepts and processes the message,
resulting in it failing with an "Unrouteable message" error. The ACL
approach would seem to be simpler and cleaner though.)

Cheers,
Mike B-)

On 10 February 2017 at 03:04, ping murder via Exim-users <
exim-users@exim.org> wrote:

> Hello,
> I have a large number of servers on which we do not want outbound email,
> however it's pretty much impossible to kill off Exim on cPanel servers
> without creating far worse issues.
>
> What I would like would be to create a discard filter that takes any
> outbound email that hits exim and sends it to the great circular file in
> the sky.
>
> I'm familiar with creating filters for inbound email in exim but can't
> really find much on doing the same for outbound. Do the inbound filters
> also apply vs outbound?
>
> Thanks,
> PM
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] No MAIL verb before RCPT

[Mike Brudenell via Exim-users]

Hi, Phillip -

On 13 February 2017 at 17:44, Phillip Carroll <
postmas...@enablingsimplicity.com> wrote:

> Some questions:
> Should my mta deny RCPT from any host that did not send a MAIL verb? Is
> that sequence even permitted by RFC? Even if not RFC-permitted, is it
> fairly common practice (other than by bad actors)? Should I repeat all the
> MAIL tests in the RCPT ACL, or simply move all the tests to the RCPT ACL?
> It appears that the sample conf file avoids this issue by having no MAIL
> time checking at all. However, checking at MAIL time avoids redundant
> conversations with DNS and ZEN in the case of multiple recipients. Seemed
> to me the logical place for it.
>

Have you tried using Telnet to connect to port 25 on your mail server and
seeing whether it accepts a RCPT TO without a previous MAIL FROM? I ask
because I've just done that here with my test server and Exim rejects the
RCPT TO, complaining no sender has been given yet:

% telnet tmailgw 25
Trying 144.32.129.129...
Connected to tmailgw.york.ac.uk.
Escape character is '^]'.
220 tmailgw.york.ac.uk ESMTP Exim 4.86_2 Ubuntu Mon, 13 Feb 2017 17:57:05
+
helo testmachine
250 tmailgw.york.ac.uk Hello tardis.york.ac.uk [144.32.226.226]
rcpt to: t...@example.com
503 sender not yet given


I've not put any special tests tests into Exim's configuration file to
implement this, so believe it to be Exim's standard behaviour. If your
server is permitting it then you might have accidentally/deliberately put
something into your configuration to cause it.

As for the RFC, you can find RFC 5321 Simple Mail Transfer Protocol at

https://tools.ietf.org/html/rfc5321


Section *3.3 Mail Transactions* states:

If a RCPT command appears without a previous MAIL command, the server MUST
return a 503 "Bad sequence of commands" response.


To debug you might want to run up a test server and run Exim in daemon mode
with debugging options turned on. For example, to go mad and turn
everything on:

exim -v -d+all -bd


(I'm sure you can select fewer options to the "-d" option if you wish!)

Then fake up an SMTP session to that server to mimic the problem you're
seeing, and after entering each SMTP command look through the debugging
output to trace through what tests and actions your configuration file is
causing.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Load balancing between multiple exim servers

[Mike Brudenell via Exim-users]

Hi, John -

You should think about two use cases separately:

   - MSA (Message Submission Agent), as used by your desktop client email
   software etc to submit emails your users send out, and
   - MTA (Message Transfer Agent), as used when another mail server (MTA)
   wants to talk to yours.

For MTAs it's generally fine just to use MX records: it's what they're
designed for! Create one MX record for each of your mail servers. If
they're all to be treated equally give them the same weighting; if some
should only be used as fallback hosts for use when the main one(s) aren't
available give them a lower priority (ie, a higher number in the MX
record). An MTA wanting to transmit email to you will then try each MX
record in turn, starting with the highest priority (lowest value) ones, in
some order.

This approach means your site's email isn't reliant on a load balancer, and
also enables sending MTAs to do clever things if they want — eg, hints
databases that keep notes of whether a host has been tried very recently
and was down.

In contrast MSAs are generally dumber as they're just user/client software.
As such if you use only the DNS to, say, point your "smtp.example.com" DNS
record they're configured to send to at your mail gateways using Round
Robin DNS entries you're assuming:

   - the client software will obtain all of the IP addresses associated
   with the DNS name;
   - will not just try the first of these addresses but will move on to the
   second, third, etc if the earlier ones aren't available — trying a failed
   host can sometimes cause a lengthy delay;
   - the user is doesn't quit out of their email program before it's found
   a working server to transmit the outgoing message to (if it doesn't it'll
   likely remain in the application's Outbox until next time the user happens
   to run the program).

So unless you've got a very small number of users it's probably worth using
some form of load balancer for the MSAs.

(Having said all that about MTAs and MX records, we actually changed to
using a load balancer for that too: mainly to keep our site Firewall rules
simpler, only having to guard the one IP address rather than many and
having to update the rule as we moved service around between servers.)

We have an F5 here but don't use it for SMTP:

   - partly for historical reasons: we were already load balancing with
   something else before we got it;
   - partly because we had some problems with it in the early days;
   - partly because it seems a bit of a sledge hammer to crack a nut —
   instead we use keep it for the heavier weight protocols, particularly where
   its special features like SSL offload or URL rewriting with iRules give a
   significant benefit.

Instead we just use the Linux Virtual Server (LVS) load balancer for SMTP
(and a few other lightweight protocols: DNS and, in the old days, web
caching). This works well so we've stayed with it for these. But if you
have an F5 with plenty of capacity and no LVS then maybe the F5 is the way
to go.

Cheers,
Mike B-)

On 8 February 2017 at 03:32, Tech Gurus via Exim-users 
wrote:

> Hi ,
>
> Looking for best approach to load balance between 4 exim servers .. The
> four servers have same config and relay fro same set of clients.
>
> Do I use F5 or other DNS based LB?
>
> Thanks
>
> John
> --
> ## 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/
>



-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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] Exim 4.89 RC2 uploaded (openssl-only)

[Mike Brudenell via Exim-users]

Hi, Torsten -

On 7 February 2017 at 05:01, Torsten Tributh via Exim-users <
exim-users@exim.org> wrote:

> I assume that an email address constructed like:
>mail+u...@example.org
> is legit.
>

Checking against RFC 5321 , the
RFC5321.MailFrom takes an address that, in the RFC, is defined to be a
"reverse path". Following this through the definitions we have

Reverse-path   = Path / "<>"
Path   = "<" [ A-d-l ":" ] Mailbox ">"
Mailbox= Local-part "@" ( Domain / address-literal )
Local-part = Dot-string / Quoted-string
Dot-string = Atom *("."  Atom)
Atom   = 1*atext


and RFC 5322 defines an *atext* character as follows

atext =   ALPHA / DIGIT /; Printable US-ASCII
  "!" / "#" /;  characters not including
  "$" / "%" /;  specials.  Used for atoms.
  "&" / "'" /
  "*" / "+" /
  "-" / "/" /
  "=" / "?" /
  "^" / "_" /
  "`" / "{" /
  "|" / "}" /
  "~"


So I reckon according to the RFCs the address <+@example.org> should be
syntactically valid. (But there is a "but"… see below.)



> I have a very short DATA ACL
>
> deny
> message = No verifiable sender address in message headers
> !verify = header_sender
>
> which rejected now mails, where the envelope-sender and the from-header
> is only having mail addresses including a "+" before @
>

To be very clear, are you saying:

   - the version of Exim you were using before (what version was it?) *did
   not* complain about the address <+@example.org> in your "!verify =
   header_sender" check, but
   - the Release Candidate version, Exim 4.89 RC2, *is* complaining about
   the exact same address?


As Jeremy says, without knowing the exact unobfuscated address it's
difficult for anyone to confirm the problem: there might be something else
about the actual address that's causing the check to fail, not just it
having only a "+" to the left of the "@".

For example (and I freely admit I might have this wrong), if your routers
are using

local_part_suffix = +*

to allow for so-called "plussed addresses" (a.k.a. "sub-addressing") then
Exim would interpret the address differently: the part to the left of the
"+" being the account's mailbox, and the part between the "+" and "@" being
the sub-mailbox/folder within the account.

I'm not sure what the expected behaviour is in this case, but suspect that
as the address <+@example.org> is effectively stripped down to just <@
example.org> it would then be considered to be invalid — the RFC says there
must be 1 or more *atext* characters in the local part of the address. If
that's the case and Exim didn't used to spot the error but has been
corrected to now do so then that would be a bug being fixed rather than
introduced!


As you can see, people need to know more about your configuration and the
data before anyone can offer any help or advice.

Cheers,
Mike B-)

-- 
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811 <01904%20323811>

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
-- 
## 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/