Skip to main content

Exim options

exiqgrepto obtain a queue listing, and then greps the output to select messages that match given criteria. The following selection options are available:

-f Match the sender address using a case-insensitive search. The field that is tested is enclosed in angle brackets, so you can test for bounce messages with exiqgrep -f '^<>$'

 -r Match a recipient address using a case-insensitve search. The field that is tested is not enclosed in angle brackets.

-s Match against the size field.

-y Match messages that are younger than the given time.

-o Match messages that are older than the given time.

-z Match only frozen messages.

-x Match only non-frozen messages.

The following options control the format of the output:
#############################################


-c Display only the count of matching messages.

-l Long format – display the full message information as output by Exim. This is the default.

-i Display message ids only.

-b Brief format – one line per message.

-R Display messages in reverse order.

-a Include delivered recipients in queue listing.

-h, which outputs a list of options.

<=Indicates the arrival of a message for incoming mail
=>Shows a normal message delivery for outgoing mail
->Additional address for the same delivery, i.e. an Email forwarder.
>>cutthrough is a router precondition This option requests delivery be attempted while the item is being received. It is usable in the RCPT ACL and valid only for single-recipient mails forwarded from one SMTP connection to another. If a recipient-verify callout connection is requested in the same ACL it is held open and used for the data, otherwise one is made after the ACL completes.
*>delivery suppressed by -N
**delivery failed; address bounced
==delivery deferred; temporary problem
<>For "<>" from the exim manual; Additionally, you will often find A bounce message is shown with the sender address “<>”, and if it is locally generated, this is followed by an item of the form R=

You will also find entries like the below table in the main log such as:

R=The address immediately following “<=” is the envelope sender address. A bounce message is shown with the sender address “<>”, and if it is locally generated, this is followed by an item of the form R=
T=The relay used to transmit the message. Example: T=remote_smtp T=local_delivery
H=Represents the host: H=localhost (10.5.40.204) [127.0.0.1]:39753 5.1) H=mail.fictional.example [192.168.123.123] U=exim 6) I=[127.0.0.1]:25
U=The MTA used.
I=Followed by a colon and the port number, the I= is the local interface on which the mail was received.
P=This is the return_path_on_delivery: The return path that is being transmitted with the message is included in delivery and bounce lines, using the tag P=. This is omitted if no delivery actually happens, for example, if routing fails, or if delivery is to /dev/null or to :blackhole:.
A=If A= is present, then SMTP AUTH was used for the delivery.
S=Is the delivery size of the message
M8S=8bitmime: This causes Exim to log any 8BITMIME status of received messages, which may help in tracking down interoperability issues with ancient MTAs that are not 8bit clean. This is added to the “<=” line, tagged with M8S= and a value of 0, 7 or 8, corresponding to "not given", 7BIT and 8BITMIME respectively.
ID=Represents the incoming message ID
T=Topic
fromFrom whom the mail was received
forWho the email is for

We can also use a few other commands from the exim command line to help read some of the messages. The next set of commands we will look at will be built into exim directly:
exim -bpcPrint a total count of messages in the queue
exim -bpPrint a listing of the messages including time queue, size, message-ID, sender, and recipient
exim -bp |exiqsumPrints a summary of the exim mail queue. -bash-4.1# exim -bp | exiqsumm Count Volume Oldest Newest Domain ----- ------ ------ ------ ------ 7 39KB 71h 71h nt10598.os.cpanel.vm 3 19KB 14h 78m nt12664.product.cpanel.vm --------------------------------------------------------------- 10 58KB 71h 78m TOTAL
exim -bt user@domain.comThis will test how an email is routed through exim
exim -bh Run a pretend SMPT transaction from the CLI. The purpose of this is to check exims ACLs and filters.
exim -q -vStart a queue run
exim -ql -vStart a queue run for local mail only
exim -Mrm [ ... ]Remove a message from the queue
exim -Mvb View the body of a message
exim -Mvh View the header of a message
exim -Mvc Provides the whole email and body


Other exim configuration files and folder structure:

/etc/mailheloThis file is the configuration file for Exim's HELO command. Records should be represented as: addonor.subdomain.com: maindomain.com
/etc/mailipsThis file specifies the IP addresses from which Exim should send email.
/etc/mail_reverse_dnsThis file specifies the domains that are associated with the IP addresses from which Exim should send email.
/etc/remotedomainsSends out an email to an internet address.
/etc/localdomainsSends out an email to a local address.
dig mx Dig a domain and pull MX records only




Comments

Popular posts from this blog

K8s External Secrets integration between AWS EKS and Secrets Manager(SM) using IAM Role.

What is K8s External Secrets and how it will make your life easier? Before saying about External Secrets we will say about k8s secrets and how it will work. In k8s secrets we will create key value pairs of the secrets and set this as either pod env variables or mount them as volumes to pods. For more details about k8s secrets you can check my blog http://jinojoseph.blogspot.com/2020/08/k8s-secrets-explained.html   So in this case if developers wants to change the ENV variables , then we have to edit the k8s manifest yaml file, then we have to apply the new files to the deployment. This is a tiresome process and also chances of applying to the wrong context is high if you have multiple k8s clusters for dev / stage and Prod deployments. So in-order to make this easy , we can add all the secrets that is needed in the deployment, in the AWS Secret Manager and with the help of External secrets we can fetch and create those secrets in the k8s cluster. So what is K8s external Secret? It i...

Password reset too simplistic/systematic issue

Some time when we try to reset the password of our user in linux it will show as simple and systematic as below: BAD PASSWORD: it is too simplistic/systematic no matter how hard password you give it will show the same. Solution: ######### Check if your password is Ok with the below command, jino@ndz~$ echo 'D7y8HK#56r89lj&8*&^%&^%#56rlKJ!789l' | cracklib-check D7y8HK#56r89lj&8*&^%&^%#56rlKJ!789l: it is too simplistic/systematic Now Create a password with the below command : jino@ndz~$ echo $(tr -dc '[:graph:]' 7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K; You can see that this password will be ok with the cracklib-check. jino@ndz~$ echo '7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K;' | cracklib-check                 7\xi%!W[y*S}g-H7W~gbEB4cv,9:E:K;: OK Thats all, Thanks.

Setting /etc/hosts entries during the initial deployment of an Application using k8s yaml file

Some times we have to enter specific hosts file entries to the container running inside the POD of a kubernetes deployment during the initial deployment stage itself. If these entries are not in place, the application env variables mentioned in the yaml file , as hostnames , will not resolve to the IP address and the application will not start properly. So to make sure the /etc/hosts file entries are already there after the spin up of the POD you can add the below entries in your yaml file. cat > api-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: spec:   template:     metadata:     spec:       volumes:       containers:       - image: registryserver.jinojoseph.com:5000/jinojosephimage:v1.13         lifecycle:           postStart:             exec:               command:...