milter-client-objects 3 MILTER-MANAGER Library
milter-client-objects

## Properties

char * | connection-spec | Read
gpointer | custom-fork | Read / Write
guint | default-packet-buffer-size | Read / Write
MilterEventLoop * | event-loop | Read / Write
MilterClientEventLoopBackend | event-loop-backend | Read / Write
guint | maintenance-interval | Read / Write
guint | max-pending-finished-sessions | Read / Write
guint | n-workers | Read / Write
char * | pid-file | Read / Write
gboolean | remove-pid-file-on-exit | Read / Write
char * | run-as-daemon | Read / Write
gboolean | start-syslog | Write
char * | syslog-facility | Read / Write
char * | syslog-identify | Read / Write
guint | worker-id | Read
MilterClient * | client | Read / Write / Construct Only
MilterMessageResult * | message-result | Read / Write
MilterOption * | option | Read / Write
guint | packet-buffer-size | Read / Write
char * | quarantine-reason | Read / Write
MilterClientContextState | state | Read / Write
MilterStatus | status | Read / Write
gboolean | use-bytes | Read / Write

## Signals

void | connection-established | Run Last
void | event-loop-created | Run Last
void | listen-started | Run Last
void | maintain | Run Last
void | sessions-finished | Run Last
void | worker-created | Run Last
void | workers-created | Run Last
MilterStatus | abort | Run Last
void | abort-response | Run Last
MilterStatus | body | Run Last
MilterStatus | body-bytes | Run Last
void | body-response | Run Last
MilterStatus | connect | Run Last
void | connect-response | Run Last
MilterStatus | data | Run Last
void | data-response | Run Last
void | define-macro | Run Last
MilterStatus | end-of-header | Run Last
void | end-of-header-response | Run Last
MilterStatus | end-of-message | Run Last
MilterStatus | end-of-message-bytes | Run Last
void | end-of-message-response | Run Last
MilterStatus | envelope-from | Run Last
void | envelope-from-response | Run Last
MilterStatus | envelope-recipient | Run Last
void | envelope-recipient-response | Run Last
MilterStatus | header | Run Last
void | header-response | Run Last
MilterStatus | helo | Run Last
void | helo-response | Run Last
void | message-processed | Run Last
MilterStatus | negotiate | Run Last
void | negotiate-response | Run Last
void | timeout | Run Last
MilterStatus | unknown | Run Last
void | unknown-response | Run Last

## Types and Values

| MilterClient
| MilterClientContext

## Object Hierarchy

        GObject
        ├── MilterAgent
        │   ╰── MilterProtocolAgent
        │       ╰── MilterClientContext
        ╰── MilterClient
            ╰── MilterManager

## Implemented Interfaces

MilterClient implements

MilterClientContext implements

## Description

## Functions

## Types and Values

### MilterClient

    typedef struct _MilterClient MilterClient;

`MilterClient` is a front object. It accepts connections from MTA and dispatches it.

MilterClient

### MilterClientContext

    typedef struct _MilterClientContext MilterClientContext;

MilterClientContext

## Property Details

### The `“connection-spec”` property

      “connection-spec”          char *

The connection spec of the client.

Owner: MilterClient

Flags: Read

Default value: NULL

MilterClient:connection-spec

### The `“custom-fork”` property

      “custom-fork”              gpointer

The custom fork.

Owner: MilterClient

Flags: Read / Write

MilterClient:custom-fork

### The `“default-packet-buffer-size”` property

      “default-packet-buffer-size” guint

The default packet buffer size of each client context of the client.

Owner: MilterClient

Flags: Read / Write

Default value: 0

MilterClient:default-packet-buffer-size

### The `“event-loop”` property

      “event-loop”               MilterEventLoop *

The event loop of the client.

Owner: MilterClient

Flags: Read / Write

MilterClient:event-loop

### The `“event-loop-backend”` property

      “event-loop-backend”       MilterClientEventLoopBackend

The event loop backend of the client.

Owner: MilterClient

Flags: Read / Write

Default value: MILTER_CLIENT_EVENT_LOOP_BACKEND_DEFAULT

MilterClient:event-loop-backend

### The `“maintenance-interval”` property

      “maintenance-interval”     guint

Maintenance interval of the client. each 'maintenance-interval' sessions finished 'maintenance' signal is emitted. 0 means 'disabled'.

Owner: MilterClient

Flags: Read / Write

Default value: 0

MilterClient:maintenance-interval

### The `“max-pending-finished-sessions”` property

      “max-pending-finished-sessions” guint

The maximum number of pending finished sessions of the client.

Owner: MilterClient

Flags: Read / Write

Default value: 0

MilterClient:max-pending-finished-sessions

### The `“n-workers”` property

      “n-workers”                guint

The Number of worker processes of the client.

Owner: MilterClient

Flags: Read / Write

Allowed values: <= 1000

Default value: 0

MilterClient:n-workers

### The `“pid-file”` property

      “pid-file”                 char *

The PID file of the client.

Owner: MilterClient

Flags: Read / Write

Default value: NULL

MilterClient:pid-file

### The `“remove-pid-file-on-exit”` property

      “remove-pid-file-on-exit”  gboolean

Whether removing PID file of the client on exist.

Owner: MilterClient

Flags: Read / Write

Default value: TRUE

MilterClient:remove-pid-file-on-exit

### The `“run-as-daemon”` property

      “run-as-daemon”            char *

Whether running the client as a daemon or not.

Owner: MilterClient

Flags: Read / Write

Default value: NULL

MilterClient:run-as-daemon

### The `“start-syslog”` property

      “start-syslog”             gboolean

Start syslog for the client.

Owner: MilterClient

Flags: Write

Default value: FALSE

MilterClient:start-syslog

### The `“syslog-facility”` property

      “syslog-facility”          char *

Syslog facility name of the client.

Owner: MilterClient

Flags: Read / Write

Default value: NULL

MilterClient:syslog-facility

### The `“syslog-identify”` property

      “syslog-identify”          char *

Syslog identify of the client.

Owner: MilterClient

Flags: Read / Write

Default value: NULL

MilterClient:syslog-identify

### The `“worker-id”` property

      “worker-id”                guint

The ID of worker processes of the client.

Owner: MilterClient

Flags: Read

Allowed values: <= 1000

Default value: 0

MilterClient:worker-id

### The `“client”` property

      “client”                   MilterClient *

The client of the context.

Owner: MilterClientContext

Flags: Read / Write / Construct Only

MilterClientContext:client

### The `“message-result”` property

      “message-result”           MilterMessageResult *

The message result of client context.

Owner: MilterClientContext

Flags: Read / Write

MilterClientContext:message-result

### The `“option”` property

      “option”                   MilterOption *

The option of client context.

Owner: MilterClientContext

Flags: Read / Write

MilterClientContext:option

### The `“packet-buffer-size”` property

      “packet-buffer-size”       guint

The packet buffer size of the client context.

Owner: MilterClientContext

Flags: Read / Write

Default value: 0

MilterClientContext:packet-buffer-size

### The `“quarantine-reason”` property

      “quarantine-reason”        char *

The quarantine reason of client context.

Owner: MilterClientContext

Flags: Read / Write

Default value: NULL

MilterClientContext:quarantine-reason

### The `“state”` property

      “state”                    MilterClientContextState

The state of client context.

Owner: MilterClientContext

Flags: Read / Write

Default value: MILTER_CLIENT_CONTEXT_STATE_INVALID

MilterClientContext:state

### The `“status”` property

      “status”                   MilterStatus

The status of client context.

Owner: MilterClientContext

Flags: Read / Write

Default value: MILTER_STATUS_DEFAULT

MilterClientContext:status

### The `“use-bytes”` property

      “use-bytes”                gboolean

Owner: MilterClientContext

Flags: Read / Write

Default value: FALSE

MilterClientContext:use-bytes

## Signal Details

### The `“connection-established”` signal

    void
    user_function (MilterClient        *milterclient,
                   MilterClientContext *arg1,
                   gpointer             user_data)

Flags: Run Last

MilterClient::connection-established

### The `“event-loop-created”` signal

    void
    user_function (MilterClient    *milterclient,
                   MilterEventLoop *arg1,
                   gpointer         user_data)

Flags: Run Last

MilterClient::event-loop-created

### The `“listen-started”` signal

    void
    user_function (MilterClient *milterclient,
                   gpointer      arg1,
                   guint         arg2,
                   gpointer      user_data)

Flags: Run Last

MilterClient::listen-started

### The `“maintain”` signal

    void
    user_function (MilterClient *milterclient,
                   gpointer      user_data)

Flags: Run Last

MilterClient::maintain

### The `“sessions-finished”` signal

    void
    user_function (MilterClient *milterclient,
                   guint         arg1,
                   gpointer      user_data)

Flags: Run Last

MilterClient::sessions-finished

### The `“worker-created”` signal

    void
    user_function (MilterClient *milterclient,
                   gpointer      user_data)

Flags: Run Last

MilterClient::worker-created

### The `“workers-created”` signal

    void
    user_function (MilterClient *milterclient,
                   guint         arg1,
                   gpointer      user_data)

Flags: Run Last

MilterClient::workers-created

### The `“abort”` signal

    MilterStatus
    user_function (MilterClientContext     *context,
                   MilterClientContextState state,
                   gpointer                 user_data)

This signal may be emitted at any time between “envelope-from” and “end-of-message”. This signal is only emitted if the milter causes an internal error and the message processing isn't completed. For example, if the milter has already returned `MILTER_STATUS_ACCEPT`, `MILTER_STATUS_REJECT`, `MILTER_STATUS_DISCARD` and `MILTER_STATUS_TEMPORARY_FAILURE`, this signal will not emitted.

If the milter has any resources allocated for the message between “envelope-from” and “end-of-message”, should be freed in this signal. But any resources allocated for the connection should not be freed in this signal. It should be freed in “finished”.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current message.

`MILTER_STATUS_DISCARD`

  Accepts the current message and discards it silently. “abort” is not emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current message without further more processing. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current message with temporary failure. (i.e. 4xx status code in SMTP) “abort” is not emitted.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “end-of-message-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_abort on milter.org.

#### Parameters

context | The context that received the signal. |
state | The state aborted on. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::abort

### The `“abort-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “abort” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “abort”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::abort-response

### The `“body”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   char                *chunk,
                   guint64              size,
                   gpointer             user_data)

This signal is emitted on body data is received. This signal is emitted zero or more times between “end-of-header” and “end-of-message”.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current message.

`MILTER_STATUS_REJECT`

  Rejects the current message. “abort” is not emitted.

`MILTER_STATUS_DISCARD`

  Accepts the current message and discards it silently. “abort” is not emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current message without further more processing. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current message with temporary failure. (i.e. 4xx status code in SMTP) “abort” is not emitted.

`MILTER_STATUS_SKIP`

  Skips further body processing. “end-of-message” is emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_BODY` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “body-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_body on milter.org.

#### Parameters

context | The context that received the signal. |
chunk | The body chunk. |
size | The size of chunk . |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::body

### The `“body-bytes”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   GBytes              *chunk,
                   gpointer             user_data)

You can use this signal instead of “body-bytes” by calling `milter_client_context_use_bytes(TRUE)`.

#### Parameters

context | The context that received the signal. |
chunk | The body chunk. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

Since: 2.1.6.

MilterClientContext::body-bytes

### The `“body-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “body” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “body”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::body-response

### The `“connect”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   char                *host_name,
                   gpointer             address,
                   guint                address_size,
                   gpointer             user_data)

This signal is emitted on SMTP client is connected to MTA.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current connection.

`MILTER_STATUS_REJECT`

  Rejects the current connection. “finished” will be emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current connection without further more processing. “finished” will be emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current connection with a temporary failure. (i.e. 4xx status code in SMTP) “finished” will be emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_CONNECT` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “connect-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_connect on milter.org.

#### Parameters

context | the context that received the signal. |
host_name | the host name of connected SMTP client. |
address | the address of connected SMTP client. (struct sockaddr) |
address_size | the size of address . (socklen_t) |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::connect

### The `“connect-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “connect” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “connect”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::connect-response

### The `“data”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   gpointer             user_data)

This signal is emitted on SMTP's "DATA" command.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current message.

`MILTER_STATUS_REJECT`

  Rejects the current message. “abort” is not emitted.

`MILTER_STATUS_DISCARD`

  Accepts the current message and discards it silently. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current message with temporary failure. (i.e. 4xx status code in SMTP) “abort” is not emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_DATA` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “data-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_data on milter.org.

#### Parameters

context | the context that received the signal. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::data

### The `“data-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “data” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “data”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::data-response

### The `“define-macro”` signal

    void
    user_function (MilterClientContext *context,
                   MilterCommand        command,
                   gpointer             macros,
                   gpointer             user_data)

This signal is emitted when macro definition is received. Normally, this signal isn't needed to be connected.

#### Parameters

context | the context that received the signal. |
command | the command to be defined macros. |
macros | the macro definitions. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::define-macro

### The `“end-of-header”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   gpointer             user_data)

This signal is emitted on all headers are processed.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current message.

`MILTER_STATUS_REJECT`

  Rejects the current message. “abort” is not emitted.

`MILTER_STATUS_DISCARD`

  Accepts the current message and discards it silently. “abort” is not emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current message without further more processing. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current message with temporary failure. (i.e. 4xx status code in SMTP) “abort” is not emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_END_OF_HEADER` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “end-of-header-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_eof on milter.org.

#### Parameters

context | the context that received the signal. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::end-of-header

### The `“end-of-header-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “end-of-header” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “end-of-header”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::end-of-header-response

### The `“end-of-message”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   char                *chunk,
                   guint64              size,
                   gpointer             user_data)

This signal is emitted after all “body” are emitted. All message modifications can be done only in this signal handler. The modifications can be done with `milter_client_context_add_header()`, `milter_client_context_change_from()` and so on.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current message.

`MILTER_STATUS_DISCARD`

  Accepts the current message and discards it silently. “abort” is not emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current message without further more processing. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current message with temporary failure. (i.e. 4xx status code in SMTP) “abort” is not emitted.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “end-of-message-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_eom on milter.org.

#### Parameters

context | The context that received the signal. |
chunk | The last chunk of the current email. | [nullable]
size | The size of the chunk . |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::end-of-message

### The `“end-of-message-bytes”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   GBytes              *chunk,
                   gpointer             user_data)

You can use this signal instead of “end-of-message-bytes” by calling `milter_client_context_use_bytes(TRUE)`.

#### Parameters

context | The context that received the signal. |
chunk | The last chunk of the current email. | [nullable]
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

Since: 2.1.6.

MilterClientContext::end-of-message-bytes

### The `“end-of-message-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “end-of-message” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “end-of-message”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::end-of-message-response

### The `“envelope-from”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   char                *from,
                   gpointer             user_data)

This signal is emitted on SMTP's "MAIL FROM" command.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current message.

`MILTER_STATUS_REJECT`

  Rejects the current envelope from address and message. A new envelope from may be specified. “abort” is not emitted.

`MILTER_STATUS_DISCARD`

  Accepts the current message and discards it silently. “abort” is not emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current message without further more processing. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current envelope from address and message with temporary failure. (i.e. 4xx status code in SMTP) A new envelope from address may be specified. “abort” is not emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_ENVELOPE_FROM` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “envelope-from-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_envfrom on milter.org.

#### Parameters

context | the context that received the signal. |
from | the envelope from address in SMTP's "MAIL FROM" command. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::envelope-from

### The `“envelope-from-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “envelope-from” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “envelope-from”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::envelope-from-response

### The `“envelope-recipient”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   char                *recipient,
                   gpointer             user_data)

This signal is emitted on SMTP's "RCPT TO" command.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current message.

`MILTER_STATUS_REJECT`

  Rejects the current envelope recipient address. Processing the current messages is continued. “abort” is not emitted.

`MILTER_STATUS_DISCARD`

  Accepts the current message and discards it silently. “abort” is not emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current envelope recipient. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current envelope recipient address with temporary failure. (i.e. 4xx status code in SMTP) Processing the current message is continued. “abort” is not emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_ENVELOPE_RECIPIENT` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “envelope-recipient-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_envrcpt on milter.org.

#### Parameters

context | the context that received the signal. |
recipient | the envelope recipient address in SMTP's "RCPT TO" command. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::envelope-recipient

### The `“envelope-recipient-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “envelope-recipient” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “envelope-recipient”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::envelope-recipient-response

### The `“header”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   char                *name,
                   char                *value,
                   gpointer             user_data)

This signal is emitted on each header. If `MILTER_STEP_HEADER_LEADING_SPACE` is set in “negotiate”, value have spaces after header name and value separator ":".

Example:

    From: from <from@example.com>
    To: recipient <recipient@example.com>
    Subject:a subject

With `MILTER_STEP_HEADER_VALUE_WITH_LEADING_SPACE`:

    "From", " from <from@example.com>"
    "To", " recipient <recipient@example.com>"
    "Subject", "a subject"

Without `MILTER_STEP_HEADER_VALUE_WITH_LEADING_SPACE`:

    "From", "from <from@example.com>"
    "To", "recipient <recipient@example.com>"
    "Subject", "a subject"

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current message.

`MILTER_STATUS_REJECT`

  Rejects the current message. “abort” is not emitted.

`MILTER_STATUS_DISCARD`

  Accepts the current message and discards it silently. “abort” is not emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current message without further more processing. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current message with temporary failure. (i.e. 4xx status code in SMTP) “abort” is not emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_HEADER` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “header-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_header on milter.org.

#### Parameters

context | the context that received the signal. |
name | the header name. |
value | the header value. value may include folded white space. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::header

### The `“header-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “header” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “header”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::header-response

### The `“helo”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   char                *fqdn,
                   gpointer             user_data)

This signal is emitted on SMTP's "HELO"/"EHLO" command.

All available response statuses are the followings:

`MILTER_STATUS_CONTINUE`

  Continues processing the current connection.

`MILTER_STATUS_REJECT`

  Rejects the current connection. “finished” will be emitted.

`MILTER_STATUS_ACCEPT`

  Accepts the current connection without further more processing. “finished” will be emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current connection with a temporary failure. (i.e. 4xx status code in SMTP) “finished” will be emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_HELO` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “helo-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_helo on milter.org.

#### Parameters

context | the context that received the signal. |
fqdn | the FQDN in SMTP's "HELO"/"EHLO" command. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::helo

### The `“helo-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “helo” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “helo”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::helo-response

### The `“message-processed”` signal

    void
    user_function (MilterClientContext *milterclientcontext,
                   MilterMessageResult *arg1,
                   gpointer             user_data)

Flags: Run Last

MilterClientContext::message-processed

### The `“negotiate”` signal

    MilterStatus
    user_function (MilterClientContext  *context,
                   MilterOption         *option,
                   MilterMacrosRequests *macros_requests,
                   gpointer              user_data)

This signal is emitted on negotiate request from MTA. If you want to modify actions (`MilterActionFlags`) and steps (`MilterStepFlags`), you modify option . If you want to add macros that you want to receive, you modify macros_requests .

All available response statuses are the followings:

`MILTER_STATUS_ALL_OPTIONS`

  Enables all available actions and steps.

`MILTER_STATUS_REJECT`

  Rejects the current session.

`MILTER_STATUS_CONTINUE`

  Continues processing the current session with actions, steps and macros requests that are specified by option and macros_requests.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “negotiate-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

See also xxfi_negotiate on milter.org.

#### Parameters

context | the context that received the signal. |
option | the negotiate option from MTA. |
macros_requests | the macros requests. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::negotiate

### The `“negotiate-response”` signal

    void
    user_function (MilterClientContext  *context,
                   MilterOption         *option,
                   MilterMacrosRequests *macros_requests,
                   MilterStatus          status,
                   gpointer              user_data)

This signal is emitted implicitly after “negotiate” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “negotiate” handler, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
option | the negotiate option from MTA. |
macros_requests | the macros requests. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::negotiate-response

### The `“timeout”` signal

    void
    user_function (MilterClientContext *context,
                   gpointer             user_data)

This signal is emitted if MTA doesn't return the next command within `milter_client_context_get_timeout()` seconds. If “timeout” is emitted, the current connection is aborted and “finished” are emitted. “abort” may be emitted before “finished” if the milter is processing a message.

#### Parameters

context | the context that received the signal. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::timeout

### The `“unknown”` signal

    MilterStatus
    user_function (MilterClientContext *context,
                   char                *command,
                   gpointer             user_data)

This signal is emitted on unknown or unimplemented SMTP command is sent.

All available response statuses are the followings:

`MILTER_STATUS_REJECT`

  Rejects the current message. “abort” is not emitted.

`MILTER_STATUS_TEMPORARY_FAILURE`

  Rejects the current message with temporary failure. (i.e. 4xx status code in SMTP) “abort” is not emitted.

`MILTER_STATUS_NO_REPLY`

  Doesn't send a reply back to MTA. The milter must set `MILTER_STEP_NO_REPLY_DATA` in “negotiate” handler.

`MILTER_STATUS_PROGRESS`

  It means that the processing in callback is in progress and returning response status is pending. The main loop for the milter is continued. If you returns this status, you need to emit “unknown-response” signal by yourself with one of the above `MilterStatus`es. This status may be used for a milter that has IO wait. (e.g. The milter may need to connect to the its server like clamav-milter) Normally, this status will not be used.

Note that the unknown or unimplemented SMTP command will always be rejected by MTA.

See also xxfi_unknown on milter.org.

#### Parameters

context | the context that received the signal. |
command | the unknown SMTP command. |
user_data | user data set when the signal handler was connected. |

#### Returns

response status.

Flags: Run Last

MilterClientContext::unknown

### The `“unknown-response”` signal

    void
    user_function (MilterClientContext *context,
                   MilterStatus         status,
                   gpointer             user_data)

This signal is emitted implicitly after “unknown” returns a status except `MILTER_STATUS_PROGRESS`. This signal's default handler replies a response to MTA. You don't need to connect this signal.

If you returns `MILTER_STATUS_PROGRESS` in “unknown”, you need to emit this signal to context by yourself.

#### Parameters

context | the context that received the signal. |
status | the response status. |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

MilterClientContext::unknown-response