{= include("docs.util"); start_docs_page(docs.technical_manual.page_titles.newsletters); =}

Sawmill Newsletter

  March 15, 2007



Welcome to the Sawmill Newsletter!


 You're receiving this newsletter because you purchased Sawmill ; or, during the downloading of Sawmill, you checked the box to join our mailing list. If you wish to be removed from this list, please send an email, with the subject line of "UNSUBSCRIBE" to newsletter@sawmill.net .


News

This issue of the Sawmill Newsletter discusses sending reports by email using Sawmill, when the local SMTP server requires authentication.

We are currently shipping Sawmill 7.2.9. You can get it from http://sawmill.net/download.html .

Tips & Techniques: Emailing Reports From Environments with SMTP Authentication

Sawmill emails reports using unauthenticated SMTP; it does not provide a username or password when communicating with the SMTP server (i.e., it does not use SMTP AUTH). In environments where the primary SMTP server requires authentication, this can cause an error when attempting to email a report, because the SMTP server will not accept the mail for delivery, because Sawmill has not authenticated.

There are several possible solutions to this:

  1. Reconfigure the SMTP server.
  2. Use an SMTP proxy or forwarding script.
  3. Use the MX address of the recipient as the SMTP server.

These options are discussed in detail below:


1. Reconfigure the SMTP Server

One option is to configure the SMTP server to allow Sawmill to access it without authentication. This could be as simple as allowing anyone to access it without authentication, which might be a reasonable solution if the SMTP server is on an internal network. However, a completely open SMTP server, even behind a firewall, could be used by a spammer (perhaps using a compromised system), and is not the most secure choice.

A more secure choice is to configure the SMTP server to allow only Sawmill to access it without authentication, by adding a rule to the SMTP server specifying that the IP address of the system where Sawmill is running may send email without authentication. This still opens up a small potential vulnerability, since the IP address could be spoofed, or the Sawmill system itself could be compromised, but it is more secure than opening unauthenticated SMTP access to the entire internal network.


2. Use an SMTP Proxy or Forwarding Script

Another option is to run an SMTP proxy or script which does not require authentication, but which uses SMTP authentication when forwarding the mail to the SMTP server. For instance, you could run sendmail on a local system, and all messages sent to a particular email address on that system would automatically be forwarded to the "real" SMTP server, but with a specific username and password provided (i.e., with SMTP AUTH added). Sawmill could then be configured to send to the proxy, without authentication, by providing the proxy's address as the SMTP server in Sawmill; the proxy would add authentication when passing the message on to the main SMTP server; and the message would be delivered.

This is a good option when the SMTP server cannot be reconfigured; it allows the SMTP server to remain configured securely, to require SMTP AUTH in all cases, while still allowing Sawmill to send through it without needing to include SMTP AUTH information in its original message.


3. Use the MX Address of the Recipient as the SMTP Server

A third option, and often the easiest one, is to use the MX address of the recipient as the SMTP server, instead of using the usual internal SMTP server. This works because every domain has an MX record in its DNS record, and every MX record points to an SMTP server which does not require authentication when delivering email to its own domain. So by looking at the DNS record of the recipient's domain, you can find an SMTP server which will allow Sawmill to talk unauthenticated SMTP directly to it, to deliver mail to the recipient.

For example, suppose you wanted to email a report to support@sawmill.net . The domain is sawmill.net, so we can get the MX record by running dig:


 % dig sawmill.net mx

 ; <<>> DiG 9.2.2 <<>> sawmill.net mx
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61374
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

 ;; QUESTION SECTION:
 ;sawmill.net.                   IN      MX

 ;; ANSWER SECTION:
 sawmill.net.            3600    IN      MX      10 mail.sawmill.net.

 ;; AUTHORITY SECTION:
 sawmill.net.            3600    IN      NS      dns.flowerfire.com.
 sawmill.net.            3600    IN      NS      dns2.flowerfire.com.

 ;; ADDITIONAL SECTION:
 mail.sawmill.net.       3600    IN      A       208.46.200.50
 dns.flowerfire.com.     3600    IN      A       209.254.132.239
 dns2.flowerfire.com.    3600    IN      A       208.46.200.50

 ;; Query time: 7 msec
 ;; SERVER: 10.0.1.1#53(10.0.1.1)
 ;; WHEN: Mon Mar  5 13:57:40 2007
 ;; MSG SIZE  rcvd: 149

The MX record in this case is mail.sawmill.net (above, in bold). Therefore, you can use mail.sawmill.net as the SMTP server in Sawmill without authentication. For instance in the SMTP Server field of the Scheduler, when emailing a report, together with the recipient support@sawmill.net, and it will accept the SMTP connection from Sawmill, and deliver the report message to support@sawmill.net.

MX records can also be looked up at http://www.mxtoolbox.com/, and similar web sites.




[Article revision v1.1]
[ClientID: ]


{= end_docs_page() =}