smpt relaying

Hi,

This is my first time posting here, and I hope I'm in the right place.

I'm running a private mailserver for my small company and its working fine. But I've got 2 concerns/questions.

First, it receives mail no problem, and while I do have a "static" ip address and am "allowed" to run servers, its still served by telus' DHCP and is on a number of "dynamic black lists" So I have it set up to relay outgoing mail originating on the LAN through the ISPs mail server. Are there any issues with this configuration that I should be aware of? Does it violate any rules, standards, or rfcs?

Second, while it seems to be working, I recently got a few bounces and I'm not entirely sure why, the message is as follows:


Final-Recipient: RFC822;
Action: failed
Status: 5.1.8
Remote-MTA: dns; mx2.prserv.net (12.154.55.40)
Diagnostic-Code: smtp; 556-204.209.205.55 blocked by mx.rbl
556 RBL block by MX.RBL - Bad Domain (20060722)

-----------
The 204.209.205.55 address is the ISPs smtp server it got relayed through. (telus)
But I can't find anything about MX.RBL, who runs that list, or what "Bad Domain" means.

I don't even know if its an issue with my domain/my mailserver? or is the telus mail server for whatever reason been blacklisted by someone?

Any suggestions or insight would be appreciated!

-regards,
Dave

Re: smpt relaying

D-42 wrote:
> Hi,
>
> This is my first time posting here, and I hope I'm in the right place.
>
> I'm running a private mailserver for my small company and its working fine. But I've got 2 concerns/questions.
>
> First, it receives mail no problem, and while I do have a "static" ip address and am "allowed" to run servers, its still served by telus' DHCP and is on a number of "dynamic black lists" So I have it set up to relay outgoing mail originating on the LAN through the ISPs mail server. Are there any issues with this configuration that I should be aware of? Does it violate any rules, standards, or rfcs?
>
> Second, while it seems to be working, I recently got a few bounces and I'm not entirely sure why, the message is as follows:
>
>
> Final-Recipient: RFC822;
> Action: failed
> Status: 5.1.8
> Remote-MTA: dns; mx2.prserv.net (12.154.55.40)
> Diagnostic-Code: smtp; 556-204.209.205.55 blocked by mx.rbl
> 556 RBL block by MX.RBL - Bad Domain (20060722)
>

As a "guess", based on the wording of the diagnostic code, the server
administrator of the receiving server has either a private DNS blocklist
they are using, or has setup a manual access list entry, or has a
sendmail filter (milter) program running that compares the incoming
domain stamped on the envelope sender or the From: header vs the domain
that owns the connecting IP. If they mismatch, then their mail filter
rejects the mail. That is what SPF does, but usually an SPF reject will
say that the failure was due SPF. Without more specific information and
knowledge of how the receiving server is setup guessing is about all
anyone on the outside can do.

So, unfortunately in this case, the diagnostic code given will only have
meaning to the administrator of the system that is generating the
bounce. No one else on the outside will be able to decipher it beyond
knowing that the mail was rejected for "some" reason.

> -----------
> The 204.209.205.55 address is the ISPs smtp server it got relayed through. (telus)
> But I can't find anything about MX.RBL, who runs that list, or what "Bad Domain" means.

IMO (as a guess) that is most likely a private blocklist. Because of
that you are unlikely to find any publicly available information on it.

>
> I don't even know if its an issue with my domain/my mailserver? or is the telus mail server for whatever reason been blacklisted by someone?
>
> Any suggestions or insight would be appreciated!
>

You could try using your account on telus? to try to mail the
administrator of the problem system and ask if s/he can punch a hole
through their blocks for you. I suspect that if the system sees the
domain in the From: header match with the owner of the MX, then it would
be accepted. That's more likely to happen if it's one of their customers
that makes the request rather than someone on the outside.

Otherwise, you are probably out of luck.

As a side note, presuming you haven't done so already, you might want to
setup SPF records for your domain such that they show telus's mail
servers as authorized output mail servers for your domain.

--
Garen

Re: smpt relaying

On Tue, 25 Jul 2006 16:41:36 -0600
Garen Erdoisa wrote:

> As a side note, presuming you haven't done so already, you might want to
> setup SPF records for your domain such that they show telus's mail
> servers as authorized output mail servers for your domain.

Yes, that was something I do plan to do; although I'm still a little grey on what it needs to say; but I'm hoping to have that in place by the end of the week.

Thanks for the rest of your comments as well. I think your guess was right on the money. Fortunately, today it seems mail to the same address is getting through so it might just have been a temporary misconfig at their end instead of a deliberate block.

Your note about the possibility of them using a "sendmail filter (milter) program running that compares the incoming domain stamped on the envelope sender or the From: header vs the domain that owns the connecting IP." worries me though.

Is that (becomming?) a common anti-spam tactic? It seems a bit draconian, given that so many domains are virtual. Even if I wasn't running my own mailserver and had the isp host my domain instead - wouldn't I still show as sending from telus' server, with a the mismatch between the from domain and the mailserver domain??

-thanks again,
Dave

Re: smpt relaying

D-42 wrote:
> On Tue, 25 Jul 2006 16:41:36 -0600
> Garen Erdoisa wrote:
>
>> As a side note, presuming you haven't done so already, you might want to
>> setup SPF records for your domain such that they show telus's mail
>> servers as authorized output mail servers for your domain.
>
> Yes, that was something I do plan to do; although I'm still a little grey on what it needs to say; but I'm hoping to have that in place by the end of the week.

Easy enough. The DNS record should say something like the following in
your DNS zone file for your domain:

@ IN TXT "v=spf1 include:telus.net -all"

That will tell any program that queries your SPF record, to go look at
the SPF record for telus.net, and use that record. Then reject anything
coming from anywhere else that is using your domain name as a forgery.

You can check an SPF record manually using the "host" command on
(Unix(TM)/Linux)

For example:

host -t txt telus.net

telus.net text "v=spf1 ip4:199.185.220.0/24 ip4:198.161.157.0/24
ip4:198.161.156.0/24 ip4:204.209.205.0/26 mx ?all"

The "?all" in the above tells SPF to softfail rather than hard fail any
mismatches, however that default policy would be overridden by your
record since it would take precedence for your domain name. "-all" means
fail anything that doesn't match.

>
> Thanks for the rest of your comments as well. I think your guess was right on the money. Fortunately, today it seems mail to the same address is getting through so it might just have been a temporary misconfig at their end instead of a deliberate block.
>
> Your note about the possibility of them using a "sendmail filter (milter) program running that compares the incoming domain stamped on the envelope sender or the From: header vs the domain that owns the connecting IP." worries me though.
>
> Is that (becomming?) a common anti-spam tactic? It seems a bit draconian, given that so many domains are virtual. Even if I wasn't running my own mailserver and had the isp host my domain instead - wouldn't I still show as sending from telus' server, with a the mismatch between the from domain and the mailserver domain??

Common - yes, draconian - depends on your political point of view I
guess. Their server, their rules.

One of the original goals of SPF was the suggestion by it's author that
eventually mail administrators would want to reject mail from servers
that had no SPF record, as such servers became more associated with
unwanted mail. He calls it "Gorilla adoption [of SPF]". In practice I
don't think that is happening as he envisioned it would. There are
competing/complementary protocols out there now such as DKIM-Signature:
headers where the mail server cryptographically signs all outbound
mail in such a way as the signature can be verified by the receiving
server on the fly.

In any case, enough mail administrators use SPF now that it can cause
problems here and there if you don't publish an SPF record.

SPF is somewhat flexible, and even for virtual hosts the domain owner
can set their SPF record to allow an upstream ISP's outgoing mail
servers as part of their own SPF records.

If you plan to publish an SPF record and want to allow others to forward
mail through your server, you'll also need to re-write the envelope
sender address on the fly when forwarding. This is necessary for mailing
lists running on servers that publish SPF records, and is one of the
major hassles of implementing SPF.

So, it just depends on the administrator. Based on what I've read over
the last couple of years, I think that most of the major ISP's don't
bother checking SPF records, but do publish them for their own domains
due to the fact that many smaller ISP's or mail servers do check SPF
records and reject mail based on SPF results. Some spam filter software
will do a client side check of SPF records to use as part of their email
scoring.

Mail servers can be configured to reject mail that fails an SPF check
during the SMTP transaction.

Here's some links with more info on SPF:

http://www.ietf.org/rfc/rfc4408.txt
http://www.openspf.org/

--
Garen

Re: smpt relaying

D-42 wrote:
> Final-Recipient: RFC822;
> Action: failed
> Status: 5.1.8
> Remote-MTA: dns; mx2.prserv.net (12.154.55.40)
> Diagnostic-Code: smtp; 556-204.209.205.55 blocked by mx.rbl
> 556 RBL block by MX.RBL - Bad Domain (20060722)

I would question what the value of "Reporting-MTA" was. This will tell us what server issued the DSN message.

Seeing as how the Final-Recipient was an AT&T Global Net customer and the Remote-MTA was mx2.prserv.net on what appears to be a cable modem IP of 12.154.55.40 which interestingly enough does not reverse resolve to mx2.prserv.net but rather mx1.prserv.net. Wow! AT&T Global Net uses mx1.prserv.net and mx2.prserv.net as their MX not attglobal.net servers. That also explains why the MX is on a cable modem IP. This being the case, your ISPs mail server was black listed by AT&T for a while. Here's the KY, that's about all that I can offer. As you indicated in a later email, this problem cleared it's self up. Rather AT&T removed your ISP's mail server from their black list. AT&T is notorious for using names like mx.rbl too. Sucks to be an client of your ISP or any other ISP that AT&T does not like for a day.



Grant. . . .

Re: smpt relaying

On Tue, 25 Jul 2006 18:20:34 -0600
Garen Erdoisa wrote:

> D-42 wrote:
> > On Tue, 25 Jul 2006 16:41:36 -0600
> > Garen Erdoisa wrote:
> >
> >> As a side note, presuming you haven't done so already, you might want to
> >> setup SPF records for your domain such that they show telus's mail
> >> servers as authorized output mail servers for your domain.
> >
> > Yes, that was something I do plan to do; although I'm still a little grey on what it needs to say; but I'm hoping to have that in place by the end of the week.
>
> Easy enough. The DNS record should say something like the following in
> your DNS zone file for your domain:
>
> @ IN TXT "v=spf1 include:telus.net -all"

Thanks again.

> > Is that (becomming?) a common anti-spam tactic? It seems a bit draconian, given that so many domains are virtual. Even if I wasn't running my own mailserver and had the isp host my domain instead - wouldn't I still show as sending from telus' server, with a the mismatch between the from domain and the mailserver domain??
>
> Common - yes, draconian - depends on your political point of view I
> guess. Their server, their rules.


>
> In any case, enough mail administrators use SPF now that it can cause
> problems here and there if you don't publish an SPF record.

I think there has been a misunderstanding. I think spf seems quite reasonable. My concern about draconian policy was about your comment about the possibility of them using a "sendmail filter (milter) program running that compares the incoming domain stamped on the envelope sender or the From: header vs the domain that owns the connecting IP."

Or is that just "SPF"?

I gathered you were suggesting that it was actually comparing my domain name directly with the domain name of the outgoing server, irresepective of spf. Meaning they would only accept email from "people"@telus.net" from smtp1.telus.net. That sort of policy, if its becoming common, would seem to be draconian.

SPF at least lets me delegate who is authorized.

Re: smpt relaying

D-42 wrote:
> I think there has been a misunderstanding. I think spf seems quite reasonable. My concern about draconian policy was about your comment about the possibility of them using a "sendmail filter (milter) program running that compares the incoming domain stamped on the envelope sender or the From: header vs the domain that owns the connecting IP."
>
> Or is that just "SPF"?

No, this is not what SPF does. However, there are a few mail servers out there that do check the envelope from and / or From: header with the FQDN of the sending host. I personally have not run in to these servers, but they do reportedly exist.

> I gathered you were suggesting that it was actually comparing my domain name directly with the domain name of the outgoing server, irresepective of spf. Meaning they would only accept email from "people"@telus.net" from smtp1.telus.net. That sort of policy, if its becoming common, would seem to be draconian.

*nod*

> SPF at least lets me delegate who is authorized.

*nod*



Grant. . . .

Re: smpt relaying

D-42 wrote:
> On Tue, 25 Jul 2006 18:20:34 -0600
> Garen Erdoisa wrote:
>
>> D-42 wrote:
>>> On Tue, 25 Jul 2006 16:41:36 -0600
>>> Garen Erdoisa wrote:
>>> [snip]
>>[snip]
>[snip]
> I think there has been a misunderstanding. I think spf seems quite reasonable. My concern about draconian policy was about your comment about the possibility of them using a "sendmail filter (milter) program running that compares the incoming domain stamped on the envelope sender or the From: header vs the domain that owns the connecting IP."
>
> Or is that just "SPF"?
>
> I gathered you were suggesting that it was actually comparing my domain name directly with the domain name of the outgoing server, irresepective of spf. Meaning they would only accept email from "people"@telus.net" from smtp1.telus.net. That sort of policy, if its becoming common, would seem to be draconian.

That is what I was suggesting as a possibility. Some mail administrators
do that among other things in an attempt to block unwanted senders.
It's a practice that will often break mailing lists. Some some mail
administrators will block mail from connections from IP's that have no
reverse DNS record, or show that any kind of a webmail interface was
being used.

SPF at least provides a mechanism to work around some of these issues,
but even that requires that the receiving mail administrator sets up
their server to honor published SPF records. It's an additional step
that many don't care to take unfortunately. SPF normally runs on a
sendmail milter when it's enabled in the server itself. Otherwise SPF
records can be checked by an MDA and used in scoring a message if the
administrator doesn't want to do outright rejection of an SPF failure.

I do that sort of thing myself on email that is retrieved using
fetchmail from accounts on systems that do not support SPF. It helps a
lot with sorting the mail into various folders and with bayesian filtering.

>
> SPF at least lets me delegate who is authorized.
>

Yep, and that will solve a lot of issues, particularly with domain
forgery, but not all. As I said, if you run a mailing list on a server
with SPF records, you are still going to have to re-write the envelope
sender on the fly when forwarding to the list, or the list will be
broken in many cases due to SPF issues.

Fortunately most mailing list software presently available will re-write
the envelope sender address while leaving most other headers intact.
It's more likely to affect custom forwarding recipes.

--
Garen