MM1 and MM7 client comforting steps

Since MM1 and MM7 messages use HTTP, MM1 and MM7 client comforting operates like HTTP client comforting.

The following steps show how client comforting works for a download of a 1 Mbyte file with the client comforting interval set to 20 seconds and the client comforting amount set to 512 bytes.

1. The client requests the file.

2. The Carrier-enabled FortiGate unit buffers the file from the server. The connection is slow, so after 20 seconds about one half of the file has been buffered.

3. The Carrier-enabled FortiGate unit continues buffering the file from the server, and also sends 512 bytes to the client.

4. After 20 more seconds, the FortiGate unit sends the next 512 bytes of the buffered file to the client.

5. When the file has been completely buffered, the client has received the following amount of data:

ca * (T/ci) bytes == 512 * (40/20) == 512 * 2 == 1024 bytes,

where ca is the client comforting amount, T is the buffering time and ci is the client comforting interval.

6. If the file does not contain a virus, the Carrier-enabled FortiGate unit sends the rest of the file to the client. If the file is infected, the FortiGate closes the data connection but cannot send a message to the client.

 

Server comforting

Server comforting can be selected for each protocol.

Similar to client comforting, you can use server comforting to prevent server connection timeouts that can occur while waiting for FortiOS Carrier to buffer and scan large POST requests from slow clients.

The Interval is the time in seconds before client and server comforting starts after the download has begun, and the time between sending subsequent data.

The Amount is the number of bytes sent by client or server comforting at each interval.

 

Handling oversized MMS messages

Select Block or Pass for files and email messages exceeding configured thresholds for each protocol.

The oversize threshold refers to the final size of the message, including attachments, after encoding by the client. Clients can use a variety of encoding types; some result in larger file sizes than the original attachment. As a result, a file may be blocked or logged as oversized even if the attachment is several megabytes smaller than the oversize threshold.

 

MM1 sample messages

Internet Protocol, Src Addr: 10.128.206.202 (10.128.206.202), Dst Addr: 10.129.192.190 (10.129.192.190)

Transmission Control Protocol, Src Port: 34322 (34322), Dst Port: http (80), Seq: 1, Ack:

1, Len: 1380

Source port: 34322 (34322) Destination port: http (80) Header length: 20 bytes Flags: 0x0010 (ACK)

Window size: 24840

Checksum: 0x63c1 (correct)

 

HTTP proxy

Hypertext Transfer Protocol

POST / HTTP/1.1\r\n Request Method: POST Request URI: /

Request Version: HTTP/1.1

Host: 10.129.192.190\r\n

Accept: */*, application/vnd.wap.sic,application/vnd.wap.mms-message,text/x- hdml,image/mng,image/x-mng,video/mng,video/x-mng,image/bmp\r\n

Accept-Charset: utf-8,*\r\n Accept-Language: en\r\n Content-Length: 25902\r\n

Content-Type: application/vnd.wap.mms-message\r\n

User-Agent: Nokia7650/1.0 SymbianOS/6.1 Series60/0.9 Profile/MIDP-1.0

Configuration/CLDC-1.0 UP.Link/6.2.1\r\n x-up-devcap-charset: utf-8\r\n

x-up-devcap-max-pdu: 102400\r\n

x-up-uplink: magh-ip.mi.vas.omnitel.it\r\n

x-wap-profile: “http://nds.nokia.com/uaprof/N7650r200.xml“\r\n x-up-subno: 1046428312-826\r\n

x-up-calling-line-id: 393475171234\r\n x-up-forwarded-for: 10.211.4.12\r\n

x-forwarded-for: 10.211.4.12\r\n

Via: 1.1 magh-ip.mi.vas.omnitel.it\r\n

\r\n

 

Scan engine

MMS Message Encapsulation, Type: m-send-req

X-Mms-Message-Type: m-send-req (0x80) X-Mms-Transaction-ID: 1458481935

X-Mms-MMS-Version: 1.0

From: <insert address> To: 3475171234/TYPE=PLMN

X-Mms-Message-Class: Personal (0x80)

X-Mms-Expiry: 21600.000000000 seconds

X-Mms-Priority: Normal (0x81)

X-Mms-Delivery-Report: No (0x81) X-Mms-Read-Report: No (0x81)

Content-Type: application/vnd.wap.multipart.related; start=<1822989907>;

type=application/smil Start: <1822989907> Type: application/smil

Data (Post) Multipart body

Part: 1, content-type: text/plain

Content-Type: text/plain; charset=iso-10646-ucs-2; name=Ciao.txt

Charset: iso-10646-ucs-2

Name: Ciao.txt

Headers

Content-Location: Ciao.txt

Line-based text data: text/plain

\377\376C\000i\000a\000o\000 [Unreassembled Packet: MMSE]

 

Sender notifications and logging

In most cases you will notify the sender that they are causing problems on the network — either by sending malware content, flooding the network, or some other unwanted activity. The notification assumes the sender is unaware of their activity and will stop or correct it when notified.

However, senders who are notified may use this information to circumvent administration’s precautions. For example if flood notification is set to 1000 messages per minute, a notified user may simply reduce their message to 990 messages per minute if this flood is intentional. For this reason, not all problems include sender notifications.

There are two methods of notifying senders:

• MMS notifications
• Replacement messages

And three details to consider for logging and notifying administrators:

• Logging and reporting
• MMS logging options
• SNMP