Boston Hosting

The SMTP logs contain information about messages that are delivered to our mail server for local delivery or relay to other mail servers.

Information about each message is logged on multiple lines, and the lines pertaining to the same message are grouped together.

SMTP logs are split by the incoming port. Our servers accept SMTP connections on ports 25, 465, and 587. Email is almost always delivered between servers on port 25. Ports 465 and 587 are mostly used by email programs (such as Outlook, for example) to connect to the mail server and relay email through it.

If you are looking for messages that have been delivered from the Internet to your mailboxes, they will be recorded in the SMTP log for port 25.

Here are a couple of examples:

2021-03-09 11:10:37, from, spam@mail.spam-source.net  2021-03-09 11:10:37, resp, 250 ok  2021-03-09 11:10:37, to, <recipient@example.com>  2021-03-09 11:10:37, resp, 554 "Refused. You have no reverse DNS entry. Contact abuse@hosting_server.com for details."    2021-03-09 12:43:51, from, correspondent@elsewhere.example.net  2021-03-09 12:43:51, resp, 250 ok  2021-03-09 12:43:51, to, <recipient@example.com>  2021-03-09 12:43:51, check, accepted rcpt, h:198.51.100.25, recipient@example.com, found existing recipient  2021-03-09 12:43:51, resp, 250 ok  2021-03-09 12:43:51, size, 23533  2021-03-09 12:43:51, resp, 250 ok 1615286631 qp 15309  

For these examples, we assume that our server handles email for example.com, and email for all other domains is hosted elsewhere.

In the first group, a message was sent from spam@mail.spam-source.net. Our server initially responded with an "OK" (response codes in the 200-299 range mean "request was accepted").

The sending server then indicated that the message was addressed to recipient@example.com. Again, our server responded with "OK".

However, when our server was done examining the sender and the message, it responded that the delivery was rejected (response codes 500-599 mean "request was denied"). The reason for the failure is given after the response code. In this case, the message was rejected because it was most likely coming from a spam source.

The second message was sent from correspondent@elsewhere.example.net (our server responded "OK") to recipient@example.com, a local mailbox. Our server checked the mailbox and responded "OK" again. The message had a size of 23533 bytes and our server finally responded that it had been accepted for delivery. The "ok 1615286631 qp 15309" part contains information about the mail server process that took over the delivery.

On ports 465 and 587, you are most likely going to see outgoing messages. The following log entries describe a message that was sent from sender@example.com and delivered to recipient@example.com:

2021-03-10 14:17:33, from, sender@example.com  2021-03-10 14:17:33, resp, 250 ok  2021-03-10 14:17:33, to, <recipient@example.com>  2021-03-10 14:17:33, check, accepted rcpt, unknown:127.0.0.1, recipient@example.com, found existing recipient  2021-03-10 14:17:33, resp, 250 ok  2021-03-10 14:17:33, size, 620  2021-03-10 14:17:33, resp, 250 ok 1615205853 qp 5665  

Note that the recipient@example.com email address points to a local mailbox on the server. This means that the message never left our server.

However, the message is still considered to be "outgoing" from the point of view of the sending mailbox, sender@example.com.

Delivery Logs

The delivery logs contain information about the actions taken by our mail server after accepting a message for delivery.

The message from correspondent@elsewhere.example.net would appear here as well:

2021-03-09 12:43:51, init, <correspondent@elsewhere.example.net>  2021-03-09 12:43:51, try, 114878, local, recipient@example.com  2021-03-09 12:43:51, result, 114878, success, did_0+0+1/  

Here, our server initiated the delivery of the message from correspondent@elsewhere.example.net by trying to deliver it to the local mailbox recipient@example.com. The result was that the message was delivered successfully.

There are three possible delivery outcomes:

  • success, when the message is delivered successfully;
  • deferral, when delivery of the message is delayed temporarily and the message remains in the queue waiting for another delivery attempt;
  • failure, when the message cannot be delivered and the mail server stops trying.

The delivery log of the message from sender@example.com to recipient@example.com tells a similar story. The message was successfully delivered to the local mailbox recipient@example.com:

2021-03-10 14:17:33, init, <sender@example.com>  2021-03-10 14:17:33, try, 90352, local, recipient@example.com  2021-03-10 14:17:33, result, 90352, success, smtp_auth/did_0+0+1/  

Interesting to note here is that the sender (sender@example.com) authenticated to the mail server before sending (the smtp_auth part). This is required when relaying email through our servers.

Spamdyke Logs

Spamdyke is an anti-spam system running on our servers. Each line in the Spamdyke log corresponds to one handled message.

Here are two examples:

Mar  9 11:10:37 server spamdyke[29207]: DENIED_RDNS_MISSING from: spam@mail.spam-source.net to: recipient@example.com origin_ip: 203.0.113.66 origin_rdns: (unknown) auth: (unknown) encryption: (none) reason: (empty)  Mar  9 12:43:51 server spamdyke[15280]: ALLOWED from: correspondent@elsewhere.example.net to: recipient@example.com origin_ip: 192.0.2.12 origin_rdns: elsewhere.example.net auth: (unknown) encryption: (none) reason: 250_ok_1615286631_qp_15309  

Delivery of the first message was denied because the reverse DNS (RDNS) record of the source IP address was missing. This is the same message as the very first example above (from spam@mail.spam-source.net).

The second message was OK, and it was allowed to be delivered.

hosting_server