[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Настройка почты (sendmail, postfix, qmail)" / Оглавление документа

6. Другая Конфигурация

Эти параметры предназначены для описания среды компиляции, а не правил узла, и обычно должны быть определены в конфигурационном файле для данной операционной системы. Вообще-то этот раздел нужно полностью переписать.

Есть также несколько флагов компиляции для указания среды, например "_AIX3" и "_SCO_unix_". Смотри файл src/READ_ME, содержащий самое свежее описание собрание этих флагов.

Параметры и опции компиляции определяются в conf.h. Большинство из них обычно не трогают; все общие параметры находятся в sendmail.cf. Однако, размеры конкретных простейших векторов и т.д., включены в этот файл. Числа, стоящие после параметров означают их значения по умолчанию.

Этот документ не лучший источник информации о флагах компиляции в conf.h - лучше смотреть src/READ_ME или сам src/conf.h.

Существует множество других опций компиляции. Они определяют включать или нет в компиляцию определенные части кода. Отмеченные знаком | имеют значения 0/1.

Следующие опции обычно включаются в описаниях операционных систем в conf.h.

Существует несколько встроенных способов подсчета средней загрузки. Sendmail пытается автоматически сконфигурировать их на основе несовершенных догадок; вы можете выбрать один из них используя опцию cc -DLA_TYPE=type, где type - это:

Если определен тип LA_INT, LA_SHORT, или LA_FLOAT, вам также может понадобиться определить _PATH_UNIX (путь к вашим системным бинарникам) и LA_AVENRUN (имя переменной, содержащей среднюю загрузку в ядре; обычно "_avenrun" или "avenrun").

В conf.c могут быть сделаны следующие изменения.

Не все семантики заголовков определяются в файле конфигурации. Строки заголовков, которые могут быть включены только определенными почтовыми программами (так же как и другие более скрытые семантики) могут быть определены в таблице HdrInfo в conf.c. Эта таблица содержит имя заголовка (которое должно быть в символах нижнего регистра) и набор управляющих флагов заголовка (описанных ниже). Флаги таковы:

Давайте взглянем на пример спецификации HdrInfo:

	struct hdrinfo				HdrInfo[] =
	{
		/* originator fields, most to least significant */
		"resent-sender",		H_FROM,
		"resent-from",			H_FROM,
		"sender",     			H_FROM,
		"from",	       			H_FROM,
		"full-name",			H_ACHECK,
		"errors-to",			H_FROM|H_ERRORSTO,
		/* destination fields */
		"to",       			H_RCPT,
		"resent-to",			H_RCPT,
		"cc",       			H_RCPT,
		"bcc",      			H_RCPT|H_STRIPVAL,
		/* message identification and control */ 
		"message",			H_EOH,
		"text",				H_EOH,
		/* trace fields */
		"received",			H_TRACE|H_FORCE, 
		/* miscellaneous fields */ 
		"content-transfer-encoding",	H_CTE, 
		"content-type",			H_CTYPE,
		NULL,				0,
	};

Эта структура показывает, что поля "To:", "ResentTo:", и "Cc:" - все они определяют адреса получателей. Любое поле "Full-Name:" будет удалено, пока требуемый флаг почтовой программы (указанный в файле конфигурации) не будет определен. Поля "Message:" и "Text:" будут заканчивать заголовок; они используются различными несогласными протестантами в сетевом мире. Поле "Received:" всегда будет добавлено, и может быть использовано для трассировки сообщений.

Здесь имеется большое количество важных точек. Во-первых, поля заголовка не добавляются автоматически просто потому, что они имеются в структуре HdrInfo; для того, чтобы они добавлялись в сообщение, они должны быть определены в файле конфигурации. Ко всем полям, упомянутым в файле конфигурации, но не упомянутым в структуре HdrInfo применяется обработка по умолчанию; то есть, они добавляются, если их еще нет в сообщении. Во-вторых, структура HdrInfo всего лишь определяет банальную обработку; конкретные заголовки обрабатываются отдельно, специальным кодом, вне зависимости от статуса, определенного в HdrInfo. Например, поля "Sender:" и "From:" всегда просматриваются в почте ARPANET для определения отправителя¹; это используется для выполнения функции "вернуть отправителю". Поля "From:" и "Full-Name:" используются для определения полного имени отправителя, если это возможно; оно сохраняется в макросе $x и используется во многих случаях.

Если существует необходимость ограничить прохождение почты через ретранслятор (relay), может быть изменена подпрограмма checkcompat. Эта подпрограмма вызывается для каждого адреса получателя. Она возвращает статус выхода, показывающий статус сообщения. Статус EX_OK принимает адрес, EX_TEMPFAIL ставит сообщение в очередь для более поздней попытки, а другие значения (обычно EX_UNAVAILABLE) отвергают сообщение. При отвержении сообщения checkcompat выдается сообщение об ошибке (используя usrerr). Например, checkcompat может быть такой:

	int
	checkcompat(to, e)
		register ADDRESS *to;
		register ENVELOPE *e;
	{
		register STAB *s;

		s = stab("private", ST_MAILER, ST_FIND);
		if (s != NULL && e->e_from.q_mailer != LocalMailer && 
			to->q_mailer == s->s_mailer)
		{
			usrerr("No private net mail allowed through this machine"); 
			return (EX_UNAVAILABLE);
		}
		if (MsgSize > 50000 && bitnset(M_LOCALMAILER, to->q_mailer))
		{
			usrerr("Message too large for non-local delivery");
			e->e_flags |= EF_NORETURN;
			return (EX_UNAVAILABLE);
		}
		return (EX_OK); 
	}

Такая конструкция будет отвергать сообщения размером более 50000 байт, если они не локальны. Для подавления возврата тела сообщения при ошибке, в e->e flags может быть выставлен флаг EF NORETURN. Конкретное использование этой подпрограммы очень зависит от реализации, и должно быть ограниченным.

Новые ключевые преобразования могут быть добавлены созданием функции инициализации класса и функции просмотра. Они потом добавляются в подпрограмму setupmaps.

Функция инициализации вызывается так:

xxx map init(MAP *map, char *args)

где map является внутренней структурой данных; args - это указатель на кусок строки файла конфигурации с последующим именем класса преобразования; флаги и имена файлов могут быть взяты из этой строки. Функция инициализации должна возвращать TRUE, если она успешно открыла преобразование, и FALSE в другом случае.

Функция просмотра вызывается так:

xxx map lookup(MAP *map, char buf[], char **av, int *statp)

где map внутренне определяет преобразование; buf имеетв входной ключ; Он может быть (и даже очень часто так оно и есть) использован разрушающе; av - список аргументов, передаваемых внутрь из переписываемой строки. Функция просмотра должна возвращать указатель на новое значение. Если просмотр преобразования не успешен, *statp должен быть выставлен на код статуса выхода; в частности, если была произведена попытка восстановления кодом более высокого уровня, он должен быть выставлен в EX_TEMPFAIL,.

Для определения того, должно ли быть сообщение поставлено в очередь, или обработано немедленно, используется подпрограмма shouldqueue. Обычно она сравнивает приоритет сообщения с текущей средней загрузкой. Определение по умолчанию таково:

	bool
	shouldqueue(pri, ctime)
		long pri;
		time_t ctime;
	{
		if (CurrentLA < QueueLA)
			return (FALSE);
		return (pri > (QueueFactor / (CurrentLA - QueueLA + 1))); 
	}

Если текущая средняя загрузка (глобальная переменная CurrentLA, определяемая до вызова функции) меньше, чем нижний порог средней загрузки (опция x, переменная QueueLA), shouldqueue немедленно возвращает FALSE (то есть, оно не должно быть поставлено в очередь). Если текущая средняя загрузка превышает верхний порог средней загрузки (опция X, переменная RefuseLA), shouldqueue немедленно возвращает TRUE. В других случаях, она подсчитывает функцию основанную на приоритете сообщения, коэффициенте очереди (опция q, глобальная переменная QueueFactor), и текущей и пороговой средней загрузке.

Реализация, которая берет в рассмотрение настоящий возраст сообщения, может также использовать параметр ctime, который является временем первого представления сообщения в sendmail. Заметьте, что параметр pri уже учтен в количестве попыток отсылки сообщения (хотя, со временем это приводит к понижению приоритета сообщения); в ожидании того, что ctime будет использован как "оператор выхода" для гарантии того, что сообщение, в конце концов, обработано.

Если входящее соединение SMTP должно быть отвергнуто, функция refuseconnections возвращает TRUE. Текущая реализация основана исключительно на текущей средней загрузке и опции средней загрузки отказа (опция X, глобальная переменная RefuseLA):

	bool
	refuseconnections()
	{
		return (CurrentLA >= RefuseLA);
	}

Более умная реализация должна смотреть на большее количество системных ресурсов.

Подпрограмма getla возвращает значение текущей средней загрузки (Округленное до целого). Пакет поставки включает несколько возможных реализаций. Если вы портируете в новую среду, вам может понадобиться добавить некотрые новые вещи².

Файл src/daemon.c содержит большое количество подпрограмм, зависящих от локальной сетевой среды. Поставляемая версия подразумевает, что вы имеете сокеты в стиле BSD.

В предыдущих выпусках, если вы хотели обобщить просмотры $[ ... $], мы рекомендовали вам изменить подпрограмму maphostname. Теперь, вместо этого, мы рекомендуем вам создавать новое ключевое преобразование.

1. На самом деле, в SMTP такого больше нет; эта информация содержится на конверте. Старые протоколы ARPANET не полностью отличали заголовок от конверта. [назад]

2. Если вы это сделаете, пожалуйста, присылайте изменения по адресу sendmail@Sendmail.ORG. [назад]

Партнёры:

Хостинг: