Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Temporary failing connection in milter's connection callback

49 views
Skip to first unread message

Alexander Yegorov

unread,
Oct 20, 2014, 9:42:23 AM10/20/14
to
Hi comp.mail.sendmail community,

I am trying to temp fail connection through milter connect callback by either:
smfi_setreply(ctx, "421", NULL, "Deferred due to too many connections.");
or
mfi_setreply(ctx, "421", "4.7.0", "Deferred due to too many connections.");

Need milter specifically to keep track of connection since it can interact with realtime counting engine from each MTA server in a cluster.

However, sendmail logs are showing that hard bounce occurs : dsn=5.0.0 Service unavailable.

Can please anyone point me to correct direction to solve this issue?

Claus Aßmann

unread,
Oct 20, 2014, 2:02:22 PM10/20/14
to
Alexander Yegorov wrote:

> I am trying to temp fail connection through milter connect callback by either:
> smfi_setreply(ctx, "421", NULL, "Deferred due to too many connections.");

You checked the fine documentation, right?
smfi_setreply may be called from any of the xxfi_ callbacks other
than xxfi_connect.

What is the return value that you use?

> However, sendmail logs are showing that hard bounce occurs : dsn=5.0.0 Service unavailable.

What is in the DSN?

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Alexander Yegorov

unread,
Oct 21, 2014, 5:59:12 AM10/21/14
to
понедельник, 20 октября 2014 г., 21:02:22 UTC+3 пользователь Claus Aßmann -no-copies-please написал:
Right, I've checked that documentation page.
However we were able to achieve the following result: dsn=4.0.0 with stat=Deferred: 421 4.7.0 xxxxxx.com closing connection, by using smfi_setreply(ctx, "421", NULL, "Deferred due to too many connections.") and returning SMFI_TEMPFAIL from _connect callback.
So, this means that smfi_setreply should be still called to set desired rcode (421), however *message cannot be set - it reverts to default "message("421 4.7.0 %s closing connection", MyHostName);"

Thank you for your attention to this thread, Claus.
0 new messages