Memorise

Last Error: Message deferred by categorizer agent.

Exchange 2013 mail flow issue. It turned out to be the Malware agent causing the issue

Once it is enabled and the Exchange transport service is restarted, all emails are stuck in the submission queue with “Last Error: Message deferred by categorizer agent.”

Check the mail queue

Get-Queue -Identity submission

Get-Transport Agent will list all the transport agents, you can disable one at a time to isolate problematic agents. in my case it was the Malware Agent.

Use the Shell to disable malware filtering on a specific Exchange server

To disable malware filtering, run the following command: PowerShellCopy

& $env:ExchangeInstallPath\Scripts\Disable-Antimalwarescanning.ps1

Note

To re-enable malware filtering, use Enable-Antimalwarescanning.ps1 instead of Disable-Antimalwarescanning.ps1.

How do you know this step worked?

To verify that malware filtering is disabled, run the following command and confirm that it returns a value of False: PowerShellCopy

Get-TransportAgent "Malware Agent"

https://docs.microsoft.com/en-us/exchange/disable-or-bypass-anti-malware-scanning-exchange-2013-help


Exchange ActiveSync iOS Device

Updated: May 2021

iOS devices unfortunately do not register with ActiveSync or other tools with a logical clear human-readable version number. Instead, they show up with strings like “Apple-iPhone3C1/902.206”  

Obviously, this makes discovery and reporting difficult.  To help ourselves, and the community at large, we now maintain this list of hardware and iOS versions for Apple gear.

Hardware Versions:

iPod2C1 = iPod Touch 2
iPod3C1 = iPod Touch 3
iPod4C1 = iPod Touch 4
iPod5C1 = iPod Touch 5

iPad1C1 = iPad 
iPad2C1 = iPad 2 WIFI 
iPad2C2 = iPad 2 WIFI + 3G 
iPad2C3 = iPad 2 WIFI + 3G CDMA 
iPad2C4 = iPad Mini - WIFI 
iPad2C5 = iPad Mini - WIFI + LTE
iPad3C1 = The New iPad (iPad 3)- WIFI
iPad3C2 = The New iPad (iPad 3) - WIFI + LTE 
iPad3C3 = iPad with Retina Display (iPad 4) - WIFI 
iPad3C4 = iPad with Retina Display (iPad 4) - WIFI + LTE  
iPad4C1 = iPad Air - WIFI 
iPad4C2 = iPad Air - WIFI + LTE 
iPad4C4 = iPad Mini with Retina Display - WIFI
iPad4C5 = iPad Mini with Retina Display - WIFI + LTE
iPad4C7 = iPad Mini 3 WIFI
iPad4C8 = iPad Mini 3 WIFI+LTE
iPad5C1 = iPad Mini 4 - WIFI
iPad5C2 = iPad Mini 4 - WIFI + LTE
iPad5C3 - iPad Air 2 - WIFI
iPad5C4 = iPad Air 2 = WIFI + LTE
iPad6C3 = iPad Pro (9.7") - WIFI
iPad6C4 = iPad Pro (9.7") - WIFI + LTE
iPad6C7 = iPad Pro (12.9") - WIFI
iPad6C8 = iPad Pro (12.9") - WIFI + LTE
iPad6C11 = iPad 5th Gen
iPad6C12 = iPad (9.7") 2017 - WIFI
iPad7C1 = iPad Pro (12.9") WIFI 2nd Gen
iPad7C2 = iPad Pro (12.9") WIFI + LTE 2nd Gen
iPad7C3 = iPad Pro (10.5") WIFI 2nd Gen
iPad7C4 = iPad Pro (10.5") WIFI + LTE 2nd Gen
iPad7C5 = iPad 6th Gen
iPad7C6 = iPad 6th Gen
iPad7C11 = iPad (10.2") 7th Gen WIFI
iPad7C12 = iPad (10.2") 7th Gen WIFI+LTE
iPad8C1 = iPad Pro (11")
iPad8C2 = iPad Pro (11")
iPad8C3 = iPad Pro (11")
iPad8C4 = iPad Pro (11")
iPad8C5 = iPad Pro (12.9") 3rd gen
iPad8C6 = iPad Pro (12.9") 3rd gen
iPad8C7 = iPad Pro (12.9") 3rd gen
iPad8C8 = iPad Pro (12.9") 3rd gen
iPad8C11 = iPad Pro - Wi-Fi 12.9", 4th gen
iPad8C12 = iPad Pro - Wi-Fi + Cellular 12.9", 4th Gen
iPad11C1 = iPad Mini 5
iPad11C2 = iPad Mini 5
iPad11C3 = iPad Air 3rd gen
iPad11C4 = iPad Air 3rd gen
iPad11C7 = iPad - WIFI+LTE 10.2", 8th Gen

iPhone1C2 = iPhone 3G 
iPhone2C1 = iPhone 3GS
iPhone3C1 = iPhone 4 GSM
iPhone3C2 = iPhone4 GSM
iPhone3C3 = iPhone 4 CDMA
iPhone4C1 = iPhone 4S
iPhone5C1 = iPhone 5 GSM/LTE
iPhone5C2 = iPhone 5 CDMA USA/China 
iPhone5C3 = iPhone 5C GSM/CDMA/Americas
iPhone5C4 = iPhone 5C Europe/Asia
iPhone6C1 = iPhone 5S GSM/CDMA/Americas
iPhone6C2 = iPhone 5S Europe/Asia
iPhone7C1 = iPhone 6 Plus
iPhone7C2 = iPhone 6
iPhone8C1 = iPhone 6S
iPhone8C2 = iPhone 6S Plus
iPhone8C4 = iPhone SE
iPhone9C1 = iPhone 7
iPhone9C2 = iPhone 7 Plus
iPhone9C3 = iPhone 7
iPhone9C4 = iPhone 7 Plus  
iPhone10C1 = iPhone 8
iPhone10C2 = iPhone 8 Plus 
iPhone10C3 = iPhone X 
iPhone10C4 = iPhone 8 
iPhone10C5 = iPhone 8 Plus 
iPhone10C6 = iPhone X
iPhone11C2 = iPhone XS
iPhone11C6 = iPhone XS Max
iphone11C8 = iPhone XR
iphone12C1 = iPhone 11
iphone12C3 = iPhone 11 Pro
iPhone12C5 = iPhone 11 Pro Max
iPhone12C8 = iPhone SE (Second Generation)
iPhone13C1 = iPhone 12 (?)
iPhone13C2 = iPhone 12 Mini (?)
iPhone13C3 = iPhone 12 Pro
iPhone13C5 = iPhone 12 Pro Max


iPhone OS Versions:

508.11 = 2.2.1
701.341 = 3.0
701.400 = 3.0.1 
703.144 = 3.1 
704.11 = 3.1.2 
705.18 = 3.1.3  
702.367 = 3.2 (original iPad only) 
702.405 = 3.2.1 (original iPad only) 
702.500 = 3.2.2 (original iPad only) 

From this point forward, iPhone OS was renamed iOS.

iOS Versions:

801.293 = 4.0
801.306 = 4.0.1
801.400 = 4.0.2
802.117 = 4.1
802.118 = 4.1 
803.148 = 4.2.1 
803.14800001 = 4.2.1 
805.128 = 4.2.5 
805.200 = 4.2.6 
805.303 = 4.2.7 
805.401 = 4.2.8 
805.501 = 4.2.9 
805.600 = 4.2.10 
806.190 = 4.3 
806.191 = 4.3 
807.4 = 4.3.1 
808.7 = 4.3.2 
808.8 = 4.3.2 
810.2 = 4.3.3 
810.3 = 4.3.3 
811.2 = 4.3.4 
812.1 = 4.3.5
901.334 = 5.0 
901.40x = 5.0.1 
902.17x = 5.1 
902.206 = 5.1.1 
1001.40x = 6.0 
1001.52x = 6.0.1
1002.14x= 6.1 
1002.146 = 6.1.2 
1002.329 = 6.1.3 
1002.350 = 6.1.3  
1101.465 = 7.0 
1101.470=7.0.1 
1101.47000001=7.0.1 
1101.501=7.0.2 
1102.511 = 7.0.3 
1102.55400001 = 7.0.4 
1102.601 = 7.0.5 
1102.651 = 7.0.6 
1104.167 = 7.1 
1104.169 = 7.1 
1104.201 = 7.1.1 
1104.257 = 7.1.2 
1201.365 = 8.0 
1201.366 = 8.0.1 
1201.405 = 8.0.2 
1202.410/411 = 8.1 
1202.435/436 = 8.1.1 
1202.440/445 = 8.1.2 
1202.466 = 8.1.3 
1204.508 = 8.2 
1206.69 = 8.3 
1208.143 = 8.4 
1208.321 = 8.4.1  
1301.4xxxxxx = 9.0 betas 
1301.342 = 9.0 (older devices) 
1301.344 = 9.0 
1301.402 = 9.0.1 (older devices) 
1301.404 = 9.0.1 
1301.452 = 9.0.2 
1302.143 = 9.1 
1303.075 = 9.2 
1304.15= 9.2.1 
1305.5234xxxx = 9.3 betas 
1305.234 = 9.3 
1305.328 = 9.3.1 
1306.69 = 9.3.2 
1306.72 = 9.3.2 (iPad Pro only) 
1307.34 = 9.3.3 
1307.35 = 9.3.4 
1307.36 = 9.3.5 (important security fix)
1305.5xxx = 10.0 betas 
1401.403 = 10.0.1 
1401.456 = 10.0.2 
1402.72 = 10.1 
1402.100 = 10.1.1 
1403.92 = 10.2 
1404.27 = 10.2.1 
1405.277 = 10.3 
1405.304 = 10.3.1 
1406.89 = 10.3.2 
1406.8089 = 10.3.2 (iPad Pro) 
1407.60 = 10.3.3  
1501.5xxx = 11.0 betas 
1501.372 = 11.0 
1501.402 = 11.0.1 
1501.421 = 11.0.2  
1501.432 = 11.0.3 
1502.5xx = 11.1 betas
1502.93 = 11.1 
1502.150 = 11.1.1 
1502.202 = 11.1.2 
1503.5xx = 11.2 betas 
1503.114 = 11.2 
1503.153 = 11.2.1 
1503.202 = 11.2.2 
1504.60 = 11.2.5 
1504.100 = 11.2.6 
1505.216 = 11.3 
1505.302 = 11.3.1  
1506.79 = 11.4 
1507.77 = 11.4.1
1601.5xx = 12.0 betas
1601.366 = 12.0 
1601.405 = 12.0.1
1602.5xx = 12.1 betas
1602.92 = 12.1
1603.50 = 12.1.1
1604.39 = 12.1.3 
1604.57 = 12.1.4
1605.5xx = 12.2 betas
1605.227 = 12.2 
1606.5xx = 12.3 betas
1606.156 = 12.3
1606.203 = 12.3.1
1607.5xx = 12.4 betas
1607.77 = 12.4
1607.102 = 12.4.1
1607.114 = 12.4.2
1607.130 = 12.4.3
1607.140 = 12.4.4
1607.161 = 12.4.5
1607.183 = 12.4.6
1607.192 = 12.4.7
1607.201 = 12.4.8
1608.5   = 12.4.9
1608.20 = 12.5.0

1701.55x = 13.0 betas
1701.577 = 13.0 
1701.58x = 13.1 betas
1701.844 = 13.1
1701.854 = 13.1.2 (latest devices)
1701.86x = 13.1.2
1702.5xx = 13.2 betas
1702.84 = 13.2 
1702.102 = 13.2.2 
1702.111 = 13.2.3 
1703.5xx = 13.3 betas
1703.54 = 13.3
1704.5xx = 13.3.1 beta
1705.255 = 13.4 
1705.262 = 13.4.1
1706.75 = 13.5
1706.80 = 13.5.1 
1707.68 = 13.6
1707.80 = 13.6.1
1708.35 = 13.7
1801.53x = 14.0 betas
1801.373 = 14.0 
1801.393 = 14.0.1
1801.8395 = 14.1
1802.5xxx = 14.2 betas
1802.92 = 14.2
1803.66 = 14.3
1804.52 = 14.4
1804.61 = 14.4.4
1804.70 = 14.4.2
1805.199 = 14.5
1805.212 = 14.5.1
1806.72 = 14.6 
1807.69 - 14.7 (current)

Samsung

Samsung encodes the Android OS version number at the end of their string, with zero paddings.

SAMSUNG-SGH-I337M/101.403 indicates Android 4.3 
SAMSUNG-SGH-I317M/100.40102 indicates Android 4.1.2 etc.

Python3 as a default python version on MacOS?

By default MacOS ships with Python-2.-. But, I guess most of us have long back started to work with Python-3 and it is very irritating to run python3 every time instead of python in terminal. Here is how to do this.

Open the terminal (bash or zsh) whatever shell you are using.

Install python-3 using Homebrew (https://brew.sh).

brew install python

Look where it is installed.

ls -l /usr/local/bin/python*

The output is something like this:

lrwxr-xr-x  1 irfan  admin  34 Nov 11 16:32 /usr/local/bin/python3 -> ../Cellar/python/3.7.5/bin/python3
lrwxr-xr-x  1 irfan  admin  41 Nov 11 16:32 /usr/local/bin/python3-config -> ../Cellar/python/3.7.5/bin/python3-config
lrwxr-xr-x  1 irfan  admin  36 Nov 11 16:32 /usr/local/bin/python3.7 -> ../Cellar/python/3.7.5/bin/python3.7
lrwxr-xr-x  1 irfan  admin  43 Nov 11 16:32 /usr/local/bin/python3.7-config -> ../Cellar/python/3.7.5/bin/python3.7-config
lrwxr-xr-x  1 irfan  admin  37 Nov 11 16:32 /usr/local/bin/python3.7m -> ../Cellar/python/3.7.5/bin/python3.7m
lrwxr-xr-x  1 irfan  admin  44 Nov 11 16:32 /usr/local/bin/python3.7m-config -> ../Cellar/python/3.7.5/bin/python3.7m-config

Change the default python symlink to the version you want to use from above.
Note that, we only need to choose the one that end with python3.*. Please avoid using the ones’ that end with config or python3.*m or python3.*m-config.

Below command shows how it should be done:

ln -s -f /usr/local/bin/python3.7 /usr/local/bin/python

Close the current terminal session or keep it that way and instead open a new terminal window (not tab). Run this:

python --version

You will get this:

Python 3.7.5

WTForms Install email validator for email validation support

PROBLEM

bash-3.2$ export FLASK_APP=flaskblog.py
bash-3.2$ flask runTraceback (most recent call last):
File “/Library/Frameworks/Python.framework/Versions/3.9/bin/flask”, line 8, in
sys.exit(main())
File “/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/flask/cli.py”, line 967, in main cli.main(args=sys.argv[1:], prog_name=”python -m flask” if as_module else None)
File “/Users/shiraj/Documents/GitHub/Python/Flask_blog-complete/forms.py”, line 10, in RegistrationForm validators=[DataRequired(), Email()])
File “/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/wtforms/validators.py”, line 332, in init
raise Exception(“Install ’email_validator’ for email validation support.”)
Exception: Install ’email_validator’ for email validation support.

SOLUTIONS

bash-3.2$ pip install email_validator
Collecting email_validator
Downloading email_validator-1.1.2-py2.py3-none-any.whl (17 kB)
Collecting idna>=2.0.0
Downloading idna-3.1-py3-none-any.whl (58 kB)
|████████████████████████████████| 58 kB 2.8 MB/s
Requirement already satisfied: dnspython>=1.15.0 in /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages (from email_validator) (2.1.0)
Installing collected packages: idna, email-validator
Successfully installed email-validator-1.1.2 idna-3.1
bash-3.2$ flask run


Delete and re-create the default discovery mailbox in Exchange 2013

In Exchange Server 2013, the maximum size of the default discovery mailbox is 50 GB. It’s used to store In-Place eDiscovery search results. Before the size limit was changed, organizations could increase the storage quota to more than 50 GB. As a result, discovery mailboxes could grow to more than 50 GB. There are three issues with a default discovery mailbox that is larger than 50 GB:

It’s not supported.

It can’t be migrated to Microsoft 365 or Office 365.

If it’s the default discovery mailbox in Exchange Server 2010, it can’t be upgraded to Exchange Server 2013.

How you resolve this depends on whether you want to save the search results from a default discovery mailbox that’s exceeded 50 GB.

Use the Exchange Management Shell to delete and re-create the default discovery mailbox

Run the following command to delete the default discovery mailbox.
Remove-Mailbox “DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}”

Run the following command to re-create the default discovery mailbox.
New-Mailbox -Name “DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}” -Alias “DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}” -DisplayName “Discovery Search Mailbox” -Discovery

Run the following command to assign the Discovery Management role group permissions to open the default discovery mailbox and view search results.
Add-MailboxPermission “DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}” -User “Discovery Management” -AccessRights FullAccess -InheritanceType all

source: https://docs.microsoft.com/en-us/exchange/delete-and-re-create-default-discovery-mailbox-exchange-2013-help


Install Software via CLI (from Junos software copied to USB stick)

Follow these steps to install the software via the CLI from a USB stick:

  1. Download the Junos upgrade file to the USB stick. 
  2. Locate the USB device ID that Junos is associating to the USB stick:
    user@srx> start shell
    user@srx% ls /dev/ > /var/tmp/before_USB.txt
  3. Insert the USB device into the USB slot.  For example, slot 0 would return the following:
    root# umass0: USB USBFlashDrive, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <USB USBFlashDrive 0100> Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 980MB (2007040 512 byte sectors: 64H 32S/T 980C)
  4. Run the following command:
    user@srx% ls /dev/ > /var/tmp/after_USB.txt
  5. Locate difference in the “before_USB.txt” and “after_USB.txt” outputs to locate drive label by using the “diff” command. (It will usually be da#s1, i.e. da0s1)
    user@srx% diff /var/tmp/before_usb.txt /var/tmp/after_usb.txt 35a36,37 > da1 > da0s1 58a61 > pass1
    In this example the USB is “da0s1”.
  6. Create a mount directory:
    user@srx% mkdir /tmp/usb
  7. Mount the USB to the directory:
    user@srx% mount -t msdosfs /dev/<drivelabel> /tmp/usb
    Example:user@srx% mount -t msdosfs /dev/da0s1 /tmp/usb (there is a space between the label name and /tmp)
  8. Verify that the USB is mounted to the device:
    root@% pwd /cf/root
    root@% cd /tmp/usb/
    root@% pwd /cf/tmp/usb
    root@% ls junos-srxsme-12.1X46-D40.2-domestic.tgz
  9. Exit shell and install the software:
    user@srx% exit
    user@srx> request system software add /tmp/usb/<upgrade filename> no-copy
    Example:request system software add /tmp/usb/junos-srxsme-12.1X46-D40.2-domestic.tgz no-copy
  10. For additional details regarding software installation, refer to the instructions at Installing the Software.
  11. Upon completion, reboot the SRX:
    user@srx> request system reboot

Enabling advanced CLI on HP v1950 Switches

<HPE>xtd-cli-mode
All commands can be displayed and executed in extended CLI mode. Switch to extended CLI mode? [Y/N] :Y
Password: foes-bent-pile-atom-ship
Warning: Extended CLI mode is intended for developers to test the system. Before using commands in extended CLI mode, contact the Technical Support and make sure you know the potential impact on the device and the network.


Email spoofing

The goal of email spoofing is to trick the user into thinking an email is from a known and trusted source. Spoofing is done through the manipulation of email elements that are visible to the recipient, primarily the “Body From” field.

A spoofed email can be partial or full:

  • Partial Spoof: A partial spoof occurs when only the “Body From” is masked, with the Envelope Sender being set to something else. This spoof type can be managed with Domain-based Message Authentication, Reporting & Conformance (DMARC), which is an email authentication, policy, and reporting protocol.
  • Full Spoof: A full spoof occurs when both the “Body From” and Envelope Sender are spoofed. This spoof type can be managed with Sender Policy Framework (SPF). SPF is an email-validation system designed to detect email spoofing by providing a mechanism to allow mail exchangers to check that incoming mail comes from an authorized host.

However, there are certain technical circumstances where the use of either SPF or DMARC is not possible. This may be due to the number of valid sources extending beyond the capacity of SPF, a technical constraint, or your own DMARC infrastructure. This leaves you exposed to spoofing.

Table: Unknown, untrusted spoof examples

Bad Partial Spoof (unknown or malicious source):Bad Full Spoof (unknown or malicious source):
X-Originating-IP: [123.89.123.12]
X-Env-Sender: badguy@malicious.com
From: <name_1@yourdomain.com>
To: <name_2@yourdomain.com>
X-Originating-IP: [89.123.89.123]
X-Env-Sender: email@yourdomain.com
From: <name_1@yourdomain.com>
To: <name_2@yourdomain.com>

In both spoof examples, the IP addresses are unknown sources, which are not allowed to spoof you). The Body From is masked to look like your domain; the Envelope Sender may or may not be masked to match your domain.

Table: Known, trusted spoof examples

Good Partial Spoof (valid or approved source):Good Full Spoof (valid or approved source):
X-Originating-IP: [13.12.223.123]
X-Env-Sender: business@partner.com
From: <name_1@yourdomain.com>
To: <name_2@yourdomain.com>
X-Originating-IP: [89.123.89.123]
X-Env-Sender: businesspartner@yourdomain.com
From: <name_1@yourdomain.com>
To: <name_2@yourdomain.com>

Spoofed email does not necessarily mean that the email you receive is spam or bad; it can be legitimate and important to you. Today’s businesses rely heavily on legitimate spoofing for their business to function. Common email marketing services like MailChimp, Amazon SES, and Zoho Campaigns are typical mail service providers for sending newsletters.

Table: Ghost spoof examples

Bad Ghost Spoof (unknown or malicious source):Good Ghost Spoof (valid or approved source):
X-Originating-IP: [123.80.123.80]
X-Env-Sender: badguy@malicious.com
From: “name_1@yourdomain.com” <badguy@malicious.com>
To: <name_2@yourdomain.com>
X-Originating-IP: [23.70.123.83]
X-Env-Sender: business@partner.com
From: “name_1@yourdomain.com” <business@partner.com>
To: <name_2@yourdomain.com>

A third type of spoof—which we refer to as a ghost spoof— is not technically spoofing, but it does exploit an element of the Body From. This element is the Display Name field.

A ghost spoof deals with an open text field that is not controlled in any way. Your email client will only show the display when one exists, especially if the display name matches the internal naming scheme. Your users would see the text inside the ” “, but not the Body From email. This varies between email clients.


Email Headers:

  • Check like the forensic investigator.

Email headers contain important information about the origin and path an email took before arriving at its final destination, including the sender’s IP address, internet service provider, email client, and even location. The information could be used to block future emails from the sender (in the case of spam) or to determine the legitimacy of a suspicious email. A review of the headers can also help to identify “header spoofing,” a strong indication the email was sent with malicious intent.

Understanding the Header Fields

Email headers are read chronologically from the bottom up and can be broken down into three main categories: 1) Message Information 2) X-Headers and 3) Server Relay Information. There is a convenient tool for analyzing headers available online at http://mxtoolbox.com/EmailHeaders.aspx. Simply copy and paste the headers into the tool, and it will analyze the server relays and convert the headers into an easy to read format.

Message Information:  Includes commonly recognized email header fields, such as To:, From:, Subject:, Date:, To:, as well as useful fields like Message-ID:, Return-Path:, ReplyTo:, among others. These fields are the most easily spoofed because they are specified by the sender’s mail client. They are usually found near the bottom of the headers as they are the first to be added.

Figure 1: Headers – Message Info

X-Headers:  These fields are added to the email by security devices such as email anti-virus scanners as it traverses the internet and internal networks. The X-Headers may not be in order and are often intermixed within the Message Info and Server Relay headers.  Not all X-Headers will be present in every case. In the example below there is an X-Originating-Email: that reveals the true sender was bad_guy_spammer@spammy.com and not mmcduck***@outlook.com. Sometimes there is an X-Originating-IP as well. The headers below also show that the email was scanned by Agari Email Security and IronPort devices.

Figure 2: Headers – X-Headers

Server Relay Information:  Each time a server relay receives an SMTP message, it will add a new Received: line at the beginning of the header block. A typical email received by a user on a corporate network will show many server relays both before and after being delivered to the corporate email servers (companyserver.com). These will be in chronological order starting from the bottom up.

Figure 3: Headers: Server Relay

Analyzing Headers

By analyzing the server relay information in chronological order from the bottom-up, you can get a picture of where the message travelled. Each receiving mail server adds the name and IP address of the server that delivered the message. The server name may reveal the domain of the sender relay, and a Who-Is lookup of the IP may give you a geographic location. In the case of messages sent via Gmail and other large email service providers, this may only lead you back to the location of the email servers or even the corporate headquarters of the provider (i.e. Mountain View, CA). If you are lucky, the headers will include an X-Originating-IP that may reveal the sender’s internet service provider and narrow down the sender’s location.

If you are looking at spam email headers from a network security perspective, it is important to identify the IP address/domain that delivered the email to your frontline email server, the security device in front of your email server. This is called the “originating IP” (not the same as X-Originating-IP). It is the first field added to the headers that can be 100% trusted because it was added by your own security device/server. The server relay header will read “Received: from some.external.domain ([some.IP]) by your.company.device ([your.IP]).” Potentially, everything before this entry could be spoofed, but, as your server is reporting it received an email from some.external.domain ([some.IP]) and is the one adding it to the headers, you should be able to trust it. Once you know which external IP delivered the message, there is a free reputation service provided by Cisco at https://www.senderbase.org/. The service gives IP addresses and domains a reputation rating (Known spammer IP’s and domains received “Poor” reputations). The originating IPs can be blocked at the externally facing firewalls on a case by case basis, by reputation, or both. Figure 4 shows an email received by msg2.companyserver.com and the originating IP/domain is highlighted. Figure 5 shows the “Poor” rating the IP received from SenderBase.org.

Figure 4: Headers – Originating IP

Figure 5: SenderBase.org – Reputation Rating

It is important to look for evidence of spoofing or alteration of header data in the Message Information headers. The spammer can easily alter these headers within their email client or by using specialized software. The most common field to spoof is the From: field. In the example in Figure 2, the sender changed the From: field to display “Mike McDuck <mmcduck***@outlook.com>” but the true sender was revealed by the X-Originating-Email field. It is not uncommon for spammers to use the recipient’s own name and email address in the From: field in order to increase the chances the recipient will open the email (“Why did I send this email to myself?”). The spammer will use any trick he or she can think of to deceive the recipient. Keep in mind the Return-Path: and Reply-To: can also be spoofed, depending on whether the spammer wants to receive the reply messages or not. Sometimes the To: field will also be altered to hide the intended recipient’s address.

The Message-ID is another good place to identify spoofing. The Message-ID is a unique identifier of digital messages and is difficult to alter as it is added by the mail server that processes the email. Because it has to be unique, it is common for message systems to use a date/time stamp followed by the sender’s domain name (example: CAF4Ths+hsd84G9sedaD@mail.gmail.com). If the sender domain in the From: field does not match the Message-ID, you might be dealing with a spoofed message.

The majority of spam emails are generated by servers capable of producing millions of messages per day. Sometimes those servers are running programs that populate the “X-Mailer” field with the name of the mail client that was used. Legitimate emails will usually include a known mail client (i.e. Microsoft Outlook 16.0, Outlook Express, iPad Mail), but the spammer mail clients may be something less common (see Figure 6) or even obscured through random, nonsense characters.

Figure 6: Headers – Mail Client

Now What?

At first glance, email headers can seem confusing and overwhelming. Once you begin to understand the fields in the headers and what they can reveal about the message, you will find very useful information buried in the seemingly endless lines of text. The next step will be determining what you can do with the evidence you find. Stay tuned to for future blog posts on using the headers to identify/block spam and to detect targeted phishing emails.


Cannot send large messages via ActiveSync, iPhone/iPad

SYMPTOMS

When sending from a Mobile device via the ActiveSync service the device fails to send.

Some devices may return an error indicating that “The message that was sent to the server was rejected because the message was too large”. (Apple iPad iOS). Not all mobile devices behave this way and may just keep the message in the outbox folder and retried until removed from the folder.

CAUSE

Ther are number of reasons, couple of them listed below.

CAUSE 1

First one I have found is ActiveSync limit set to 10MB (%ExchangeInstallPath%ClientAccess\Sync\web.config maxRequestLength=”10240″)

CAUSE 2

A global IIS restriction preventing uploads larger than 49152 Bytes.

IIS 7.5 sets a default value of 49152 Bytes for the “UploadReadAheadSize” value which limits the amount of bytes allowed in the entity body of a request and the number of bytes a Web server will read into a buffer and pass to an ISAPI extension.

Diagnosis:

  • Navigate within IIS to the “Sites” node.
  • Determine the ID for the “MailEnable Protocols” website
  • Next navigate to the IIS log files path: C:\inetpub\logs\LogFiles
  • Locate the W3SVC(ID) folder, where ID is the number of the website ID above in step 2.
  • Sort the log files by “Date Modified’ and then open the latest log files in respect to the date/time you sent the message from the mobile device.
  • Search for lines like the examples below:

2020-03-27 20:33:38 192.168.0.1 POST /Microsoft-Server-ActiveSync User=test@myenroutetest.it&DeviceId=ApplDMRL2W3PF169&DeviceType=iPad&Cmd=SmartForward 443 – 192.168.0.2 Apple-iPad3C4/1102.55400001 413 0 0 6396

2020-03-27 20:33:38 192.168.0.1 POST /Microsoft-Server-ActiveSync User=test@myenroutetest.it&DeviceId=ApplDMRL2W3PF169&DeviceType=iPad&Cmd=SendMail 443 – 1921.68.0.2 Apple-iPad3C4/1102.55400001 413 0 0 6396

The above log snippets report a 413 error in the line which indicates the “Request Entity is too large”.

CAUSE 3

Incorrect authentication settings in Exchange Server Virtual Directory.

RESOLUTION – 1

Change the limit set on web.config, note this settings below for Frontend backed servers with different CAS and Mailbox server. For single server web.config is located in

C:\Program Files\Microsoft\Exchange Server\v14\ClientAccess\Sync\web.config has the following lines of code:

<system.web>
                         <!– Allow maximum 10 megs of content –>
                         <httpRuntime madRequestLength=”10240″ />

v14 is different verions of Exchange.

ActiveSync

Server roleConfiguration fileKeys and default valuesSize
Client Access%ExchangeInstallPath%FrontEnd\HttpProxy\Sync\web.configmaxAllowedContentLength="30000000 bytes"   Not present by default (see comments).bytes
Client Access%ExchangeInstallPath%FrontEnd\HttpProxy\Sync\web.configmaxRequestLength="10240"kilobytes
Mailbox%ExchangeInstallPath%ClientAccess\Sync\web.configmaxAllowedContentLength="30000000 bytes"   Not present by default (see comments).bytes
Mailbox%ExchangeInstallPath%ClientAccess\Sync\web.configmaxRequestLength="10240"kilobytes
Mailbox%ExchangeInstallPath%ClientAccess\Sync\web.config<add key="MaxDocumentDataSize" value="10240000">bytes

Comments on ActiveSync limits

By default, there is no maxAllowedContentLength key in the web.config files for ActiveSync. However, the maximum message size for ActiveSync is affected by the maxAllowedContentLength value that is applied to all web sites on the server. The default value is 30000000 bytes (30 MB). To see these values for ActiveSync on Client Access Servers and Mailbox servers in IIS Manager, perform the following steps:

  1. Do one of the following steps:
    • On Client Access servers, open IIS Manager, navigate to Sites > Default Web Site and select Microsoft-Server-ActiveSync.
    • On Mailbox servers, open IIS Manager, navigate to Sites > Exchange Back End and select Microsoft-Server-ActiveSync.
  2. Verify Features View is selected, and double-click Configuration Editor in the Management section.
  3. Click the dropdown arrow in the Section field, navigate to system.webServer > security and select requestFiltering.
  4. In the results, expand requestLimits, and you’ll see maxAllowedContentLength and the default value 30000000 (bytes).

To change the maxAllowedContentLength value, enter a new value in bytes, and click Apply. You need to change the value on Client Access servers and on Mailbox servers. After you change the value in IIS Manager, a new maxAllowedContentLength key is written to the corresponding web.config file (%ExchangeInstallPath%FrontEnd\HttpProxy\Sync\web.config on Client Access servers, and %ExchangeInstallPath%ClientAccess\Sync\web.config on Mailbox servers).

To change the maximum message size for ActiveSync clients, you need to change the value of maxRequestLength in the web.config file on Client Access servers and Mailbox servers, MaxDocumentDataSize in the web.config file on Mailbox servers, and maxAllowedContentLength in IIS Manager on Client Access servers and Mailbox servers.

  • RESOLUTION – 2
  • Open a Windows command prompt with administrator rights and navigate to the following location: C:\inetpub\AdminScripts
  • Run the following command: cscript adsutil.vbs set w3svc/14/uploadreadaheadsize 51200000

Where “14” in the above command is the website ID

RESOLUTION – 3

Check the virtual directory authentication settings in the Exchange server for
EWS (Default Web Site), it should be
Integrated windows authentication only and for

Microsoft-Server-ActiveSync (Default Web Site) authentication set to
Basic authentication and ignore client certificate