SMTP connection refused/no route and additional catch for deferred messages

[AlexandarY]

Hello,

I've been running the exporter for a while. Looking at the output of --log.unsupported, I have a few questions/suggestions.

1. smtp connection refused / no route

The postfix_smtp_connection_timed_out_total appears to be incrementing if the smtp output line has Connection timed out . I see other reasons for smtp connection errors (the domain and IP were changed for privacy reasons):

postfix/smtp[17813]: connect to domain.com[192.168.0.1]:25: No route to host
postfix/smtp[3517]: connect to domain.com[192.168.0.1]:25: Connection refused

Would it make sense to do one of these:

• adjust the Regex to include those as well
• do a separate metric for each
• rename the postfix_smtp_connection_timed_out_total to something that would be more inclusive to any matter of connection related issues of the smtp service and adjust the Regex to include the examples above as well?

2. deferred messages being missed

I can see that some status=deferred messages are being missed. I believe its due to them being logged under tlsproxy/error rather than postfix/smtp ?

postfix/error[9407]: 4cDCnd66Hyz1XPWFF: to=<user@domain.com>, orig_to=<other-user@other-domain.net>, relay=none, delay=248321, delays=248262/59/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to domain.com[192.168.0.1]:25: Connection timed out)
postfix/error[30919]: 4cClSJ1Jh1z1XPY9b: to=<user3@domain3.net>, relay=none, delay=317055, delays=317055/0.01/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to mail.domain3.net[192.168.0.1]:25: Connection timed out)

Would it make sense to add a parser for postfix/error, but have it use the same Regex as smtpStatusLine and increment the same counter?

[Hsn723]

1. smtp connection refused / no route

The cause is different than a connection timeout, so it would not be appropriate to include it in the postfix_smtp_connection_timed_out_total, having separate metrics for each (ex: postfix_smtp_connection_refused_total, postfix_smtp_no_route_total) would make more sense.

On the other hand, I am not sure providing metrics for connection related issues is helpful as on their own they do not provide much actionable information. For instance, a service provider wanting to investigate no route to host related errors would find the logs more useful as they would get the queue ID and the domain/IP.

That being said, if there are any real world needs for such metrics I'll be happy to take any pull requests.

2. deferred messages being missed

Deferred messages handled by the postfix/error transport are different to postfix/smtp in that in the former case Postfix hasn't initiated any SMTP session yet (due to user configuration or DNS issues making email delivery impossible). It would therefore not make much sense combining those metrics with the postfix_smtp_deferred/bounced metrics.

While those failure cases are unlikely to be actionable (ex: the sending user made a typo), exposing data from postfix/error could be useful, though they should have their own metrics (ex: postfix_error_deferred_...).