Roller Network Help - Outbound Mail Accounts
A Roller Network Outbound Mail Account allows you to send mail using our service. This service is also known as a "smarthost" or "relayhost". We accept mail submissions on ports 25, 2525, 587 with opportunistic TLS. Port 465 is SSL-style (depreciated method). We can also accept TLS/non-TLS on 11923 (random low-number), 61235 (random high-number), and 80 (fake http; most providers shouldn't block this).
If your domain has an SPF record, add "include:auth.spf.rollernet.us" to authorize our Outbound Mail service as a valid mail source.
The following examples are provided for informational purposes only. We are unable to provide technical support for specific mail clients or walk-through setup.
To add an outbound mail account, click on the "Add New Outbound Mail Account" button and select the account type you want to create. There are three account types:
In the case of the single address account, the client's email address is the same as the outbound mail account address. If the client attempts to use a different email address with this type of account, they will be rejected with an address mismatch error. After selecting an account type, you will be prompted for the email address (single address account only) and the domain name. The list of available domain names is derived from the mail services domains. Passwords must be at least five (5) characters long. For "Any Address" accounts, the domain name of the MAIL FROM address must match the domain in the account name. "Mail Server" accounts do not have any MAIL FROM address restrictions, but the domain name must be associated with a mail service domain.
Set the SMTP login name in your mail client or mail server to the same as shown in the "Account" column. For example, if you have an account "@mydomain.com", then the login name is also "@mydomain.com", including the @ symbol. Otherwise, a login error will be returned.
Once an outbound mail account has been added, you may change the password, set IP filters, enable/disable the account, or delete the account. All clients must submit messages to smtpauth.rollernet.us on port 25, 2525, 587, or 465. Port 465 always runs in SSL mode for some clients (such as Outlook Express) which expect unconditional SSL. Ports 25, 2525, and 587 may use TLS or unencrypted connections. We recommend using TLS with port 587 for maximum security and portability.
To view your current usage and outbound mail service limits, see the Resource Access section located under the main menu of the account manager.
To view or change the settings for an outbound account, click on the account name.
Mirroring and BCC Recipients
An outbound mail account may be configured with one or more BCC recipients or mirror destinations. This allows the submission system to send copies of the submitted message elsewhere at submission time.
A BCC recipient is one or more email addresses that will always receive an additional blind copy of the submitted message. The headers will not be altered, however the envelope sender will be set to a unique address to identify the outbound account that submitted the BCC recipient. If a BCC recipient generates errors or bounces it will be automatically removed. The header X-Rollernet-BCC will also be added.
A mirror destination is a selected hosted mail account that a copy of the submitted message will be saved to. The mirror copy is generated separately from the original submission with an additional X-Rollernet-AuthMirror header. This option is useful for eliminating the second upload that IMAP clients typically make to save a message to your "sent" folder. Using the header, you can apply a Sieve rule to automatically move the mirrored message into your "sent" folder. View the full headers of the mirrored message to retrieve its value.
When these options are enabled additional data usage will be applied to the submission account for the extra processing overhead. A large number of mirrors and/or BCC recipients may cause the submission to appear slow since they are processed in real time. Because of this real time processing, BCC recipients and mirrors may still receive a copy of the message even if a queue write error occurs.
Mirroring and BCC Recipient Limitations
Messages submitted with the null envelope sender (MAIL FROM:<>) will not be mirrored or sent to BCC recipients.
Personal and Personal Plus level accounts can only configure one BCC recipient and one mirror destination. If you require multiple BCC or multiple mirror destinations, a Standard or higher level account is required.
Source Connection Filters
By default, any connection from an IPv4 or IPv6 client with the correct login name and password will be authorized to submit a message (except on "Mail Server" account types). You may choose to filter connections by IP address or host name.
To filter by IP address enter a single IP or valid CIDR subnet mask into the IPv4 or IPv6 filter. To enter an IP address the selector must be set to IP and click the submit button. If you wish to disable a certain protocol enter the loop back address (127.0.0.1 for IPv4 and ::1 for IPv6) as the filter value.
To filter by host name, enter a valid FQDN into the IPv4 or IPv6 filter and choose host from the selector. The IPv4 filter will perform a lookup for an A record while the IPv6 filter will use the AAAA record. Please note that DNS caching may negatively affect hostname-based filtering, especially for dynamic DNS names.
An alternate IPv4 or IPv6 filter may be specified on accounts with a service level of Standard or higher. This allows you to specify a second CIDR subnet mask that will be checked if the primary does not match. This option was originally added to address the issue of sites with a separate failover circuit on a different IP, but may be used for any instance where a second CIDR range is required.
When using an Outbound Mail account as a smart host for a mail server it's possible for the mail server to submit messages with a null envelope sender. When this happens, we will rewrite the null sender with the "Postmaster Email Address" configured in your account preferences.
This address should be set to the person or an alias for the person who is responsible for maintaining the mail servers under your account. If the postmaster email address is blank the primary email address will be used.
As a general rule, any account that causes our servers to become blocked, filtered, listed on DNSBL/URIBL services, affects the deliverability or reputation of our services, or any other action which we determine to be harmful at our sole discretion, will have outbound mail permissions revoked. No refunds will be given.
To prevent spam and abuse several restrictions are enforced:
In addition to these requirements, our system will the conencting IP against the Spamhaus XBL and Auth BL block lists. The Spamhaus Exploits Block List (XBL) is a realtime database of IP addresses of hijacked PCs infected by illegal 3rd party exploits, including open proxies (HTTP, socks, AnalogX, wingate, etc), worms/viruses with built-in spam engines, and other types of trojan-horse exploits. The Spamhaus Auth BL is a subset of the XBL which lists IP addresses known to host bots using brute force or stolen SMTP-AUTH credentials to send spam, phishing and malware emails. These lists contain individual IPs (/32s) that are infected with malware, worms, and Trojans; third party exploits, such as open proxies; or devices controlled by botnets.
If you are sending using a subdomain that is not intended to recieve mail (send only), use the "Null MX" record. This is done by adding a single MX record to your subdomain with the content "." to indicate there is no mail exchanger for the domain. For more information on the Null MX record see RFC 7505.
Roller Network mail services are not to be used for large scale one-way mailings, marketing lists, purchased lists, or email marketing software. For these types of mailings we recommend using a separate ESP that specializes in mailing lists. Accounts found in violation will be suspended.
Submissions to Roller Network must remain in good standing and be predominately "clean". In the event that we receive excessive complaints on one or more of our feedback loops or the percentage of error responses versus non-error responses becomes unacceptable, Roller Network will revoke access to the outbound mail account feature. No refunds will be given on disabled accounts.
Filtering of Mail Containing URIs/URLs
Submissions containing a URI classified as black, grey, red, or gold on URIBL will be rejected.
Submissions containing a URI listed on Invaluement's ivmURI list will be rejected.
These categories contain domains that are either actively used by spammers or found in unsolicited bulk mail. The "grey" category is a special case. It contains domains that are used in bulk or commercial mail, which may not be spammers in the strict sense, but are nevertheless against our policy for outbound mail submissions that disallow bulk or marketing mail. If you find you’re having trouble with the "grey" category, contact support so we can investigate. Marketing-type mail should be sent directly to the intended recipient and not rely on forwarding or resending. Replies containing marketing links likewise will be caught and should be edited out of the response.
The primary reason for not allowing URIs/URLs associated with bulk or marketing mail is that if a recipient or an automated system at the recipient's side reports or detects such URIs/URLs as spam, this can result in one or more of our servers ending up on a blacklist which negatively impacts all email.
Sender Address Verification
A simple sender address verification will be performed on the submission's SMTP MAIL FROM command. This is done by connecting to an MX for the sender's domain and processing the result of a SMTP RCPT TO command using the same address in the submission's MAIL FROM. These probes will have a "sender" address of email@example.com and will close the connection before the DATA phase. If it's determined the sender address appears undeliverable the submission will be rejected.
We do not perform this test on recipients (the submission RCPT TO) since it's widely considered abusive, but accounts that submit excessive undeliverable mail into the queue may be disabled. Accounts with excessive sender verification failures may also be disabled to prevent abuse.
When you are using our services for both incoming and outgoing, the valid user table in the account control center is not directly used for validating senders. We will always follow the MX records in DNS for a domain.
This function uses the internal "verify" server in Postfix. For more details see: postfix.org/verify.8.html
Microsoft Exchange DSN Reports
Using our outbound mail service to send non-delivery reports from Microsoft Exchange is a violation of our backscatter prevention policy and is therefore prohibited. To disable Exchange DNS reports see Disabling Non-Delivery Notifications for Exchange.
Null Envelope Senders
Submissions with a null envelope sender or an envelope sender whose domain is not part of the parent account (i.e. not a mail domain), may be rewritten with the account Postmaster Email Address setting or Primary address if Postmaster is not configured.
Acceptance of null envelope senders is not guaranteed and may be blocked at any time.
Filtering on Outbound Mail can not be controlled through the account control center or be bypassed or whitelisted. The scanning performed on messages submitted to our service exists to protect the reputation of our mail servers for other customers that rely on our services to send mail. A poor reputation will impact deliverability on a wider scale, which we avoid by placing restrictions on what can be submitted through our Oudbound Mail service.
Although we understand that some of these make our service appear "strict" compared to competing offerings that allow any outgoing submissions regardless of content; this places the burden of filtering on the recipient or relies on being "too big to block".
We do allow some exceptions intended for reporting abuse, such as to SpamCop or the abuse@ role account.
IP addresses may be blocked or filtered by our submission servers for the following reasons:
Initial blocks may last up to 15 minutes. Repeat blocks may last up to 24 hours. In some cases an IP may be permanently banned. Exact timing and conditions are not published to prevent tuning attacks. If you believe you are affected by an IP block contact technical support.
Action on submission errors
This option allows you to change the default response for certain types of responses. The default setting is automatic (recommended). This setting will allow the system to return the appropriate response for an error (either 4xx or 5xx) depending on RFC and current best practices. For example, DNS errors always return 4xx "defer" as there is no method to distinguish temporary errors in the DNS protocol. This setting can change such responses to 5xx.
In some cases (such as with Exchange servers that don't check DNS before accepting a message into their queue) you may want to always return a 5xx "reject" response. To override the recommended behavior change this option to always return 5xx. However, keep in mind that temporary errors, DNS timeouts, delays due to network congestion, or other temporary errors will now result in a permanent error. You may experience delivery failures to legitimate destinations or loss of mail by using this option. Support is not available outside of automatic mode.
Allow identities on single-user account
By default, single-user type accounts require that the sending address match the login name. By enabling this option, this restriction is relaxed and a named single-user account will be able to submit messages with any "left hand side" name. The most common application for this option is identities. Enabling this option will allow a single-user account to mimic the behavior of an any-user account.
This option will only appear for single-user account types; it has no effect on other types.
Allow any valid subdomain
Both single-user and any-user account types normally require that the "right hand side" domain name match the sending address. By enabling this option any valid subdomain of the configured domain will also be accepted as a valid sender.
This option is available for both single-user and any-user account types.
You can manually test an SMTP AUTH connection by sending our server SMTP commands with a telnet client, however AUTH has one slightly obscure step: you need to Base64 encode your authentication information. We'll show you here how to do that with Perl and the MIME::Base64 module.
Connect to the Server
First, connect to the server. You can do so unencrypted by just using telnet to one of the supported ports (listed above):
% telnet smtpauth.rollernet.us 587
Or using STARTTLS with openssl:
% openssl s_client -starttls smtp -crlf -connect smtpauth.rollernet.us:587
Encode Authentication Information
SMTP AUTH details must be Base64 encoded to be sent to the server. Do not confuse this with encryption - it's not. Anyone can easily decode the encoded string; that's why we use TLS. For this example, the outbound account name is firstname.lastname@example.org with password mypassword :
% perl -MMIME::Base64 -e 'print encode_base64("\000user\@example.net\000mypassword")'
Remember to escape special Perl characters with a backslash, such as the @ sign as shown above. This command should return a value of AHVzZXJAZXhhbXBsZS5uZXQAbXlwYXNzd29yZA== and you can verify it by using the corresponding decode function:
% perl -MMIME::Base64 -e 'print decode_base64("AHVzZXJAZXhhbXBsZS5uZXQAbXlwYXNzd29yZA==")'
The decode should return the same string you encoded, but without the null \000 characters.
Performing the Test
Now that you have the encoded AUTH value, you can perform the manual test:
$ telnet smtpauth.rollernet.us 587 Trying 184.108.40.206... Connected to smtpauth.rollernet.us. Escape character is '^]'. 220 smtpauth.rollernet.us ESMTP Postfix EHLO example.net 250-smtpauth.rollernet.us 250-PIPELINING 250-SIZE 209715200 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN AUTH PLAIN AHVzZXJAZXhhbXBsZS5uZXQAbXlwYXNzd29yZA== 235 2.7.0 Authentication successful MAIL FROM:<email@example.com> 250 2.1.0 Ok RCPT TO:<firstname.lastname@example.org> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> Subject: test test . 250 2.0.0 Ok: queued as XXXXXXXXXXX QUIT 221 2.0.0 Bye