IP filtering based on corresponding MX records
Alex has a question
How can I implement the following?
Used: Exchange 2003 SP2 in FE/BE configuration;
FE is in perimeter zone (capable to “speak” with DNS, BE, DCs and retrieve
info)
So, somebody connects my FE to sent an e-mail to one of domain users.
I need something like that:
When connecting, see the “mail from: us...@somedomain.xxx”;
Verify if there is a record MX for the IP address from which the connection
was established in DNS for the domain “somedomain.xxx”
If not – drop connection
(attention: MX record, not SPF)
Is it possible with Exchange 2003 SP2 only?
How?
Thank you,
Alex
james chong
lookup during the HELO initiation. I don't think Exchange can do this.
I'm not sure if you're trying to incoporate this as part of your SPAM
solution or trying to explicity block a domain or not, but most people
will tell you that blocking soely on foward on reverse lookups is not a
comprehensive solution. In addition blocking solely on failed forward
lookups does not comply with RFC protocol.
James Chong
Alex has a question wrote:
> Hello Dears,
>
> How can I implement the following?
>
> Used: Exchange 2003 SP2 in FE/BE configuration;
> FE is in perimeter zone (capable to "speak" with DNS, BE, DCs and retrieve
> info)
>
> So, somebody connects my FE to sent an e-mail to one of domain users.
> I need something like that:
>
> When connecting, see the "mail from: us...@somedomain.xxx";
> Verify if there is a record MX for the IP address from which the connection
> was established in DNS for the domain "somedomain.xxx"
> If not - drop connection
Rich Matheisen [MVP]
>I believe you're talking about Exchange trying to perform a forward
>lookup during the HELO initiation. I don't think Exchange can do this.
>I'm not sure if you're trying to incoporate this as part of your SPAM
>solution or trying to explicity block a domain or not, but most people
>will tell you that blocking soely on foward on reverse lookups is not a
>comprehensive solution. In addition blocking solely on failed forward
>lookups does not comply with RFC protocol.
Spam is war. Sometimes you just gotta ignore the RFC's, although I'm
not sure which one you found that in.
If someone's using a phoney domain name to send mail, who cares if you
drop the message? You'd never be able to reply to it, you'll never be
able to send a NDR to it.
I'd agree that reverse lookups are of dubious value. But a failed
forward lookup? Oh, yeah . . . it's junk. Don't send a 250, send a 5xx
or a 4xx (if you think that its just a transient DNS problem) as the
status for the MAIL FROM. Either that or give it a pretty high ranking
in your evaluation of the message's spamminess.
--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:h.p...@getronics.com
Or to these, either: mailto:h.p...@pinkroccade.com mailto:melvin.mcp...@getronics.com mailto:melvin.mcp...@pinkroccade.com
james chong
> not sure which one you found that in.
Agree with you there. Here is the RFC. There are organizations that
have misconfigured settings that introduce themselves as as a domain in
the HELO that do not resolve which would result in the 5xx NDRs from
orgs that reject if the forward lookup failed.
HELO Command: RFC-821 Section 3.5
The sender-SMTP MUST ensure that the <domain> parameter in a
HELO command is a valid principal host domain name for the
client host. As a result, the receiver-SMTP will not have to
perform MX resolution on this name in order to validate the
HELO parameter.
The HELO receiver MAY verify that the HELO parameter really
corresponds to the IP address of the sender. However, the
receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification.
Rich Matheisen [MVP]
>> Spam is war. Sometimes you just gotta ignore the RFC's, although I'm
>> not sure which one you found that in.
>
>Agree with you there. Here is the RFC. There are organizations that
>have misconfigured settings that introduce themselves as as a domain in
>the HELO that do not resolve which would result in the 5xx NDRs from
>orgs that reject if the forward lookup failed.
And rightly so. If you can't follow the accepted norms you don't
deserve to have your mail accepted anywhere. Is that harsh? You bet.
But it's necessary. The Internet ain't what it was in 1982 when that
RFC was accepted.
>HELO Command: RFC-821 Section 3.5
>
> The sender-SMTP MUST ensure that the <domain> parameter in a
> HELO command is a valid principal host domain name for the
> client host. As a result, the receiver-SMTP will not have to
> perform MX resolution on this name in order to validate the
> HELO parameter.
>
> The HELO receiver MAY verify that the HELO parameter really
> corresponds to the IP address of the sender. However, the
> receiver MUST NOT refuse to accept a message, even if the
> sender's HELO command fails verification.
Why bother to refuse a message when you can dump the whole connection?
If the HELO domain/fqdn doesn't exist there's no need to proceed
beyond the HELO! I think you'll find that this part of the RFC is one
that can be safely ignored.
Here's a few you shouldn't accept at all:
HELO 0.0.0.0
HELO 127.0.0.*
HELO ip-address <== should be [ip-address]
HELO <your-ip-addrss>
HELO localhost
HELO loccalhost.localdomain
HELO <your own domain name>
HELO <your own server name>
HELO hostname <== not a domain or fqdn
Alex has a question
Thank you very much for your attention and your replies.
1)
"Rich Matheisen [MVP]" wrote:
> "james chong" <jamest...@gmail.com> wrote:
> >HELO Command: RFC-821 Section 3.5
> >
> > The HELO receiver MAY verify that the HELO parameter really
> > corresponds to the IP address of the sender. However, the
> > receiver MUST NOT refuse to accept a message, even if the
> > sender's HELO command fails verification.
>
> Why bother to refuse a message when you can dump the whole connection?
> If the HELO domain/fqdn doesn't exist there's no need to proceed
> beyond the HELO! I think you'll find that this part of the RFC is one
> that can be safely ignored.
It suits me fine.
How I can implement with Exchange 2003 SP2? Is it possible?
If "no", maybe you can me say about software with the same effects?
2)
>I'd agree that reverse lookups are of dubious value. But a failed
>forward lookup? Oh, yeah . . . it's junk. Don't send a 250, send a 5xx
>or a 4xx (if you think that its just a transient DNS problem) as the
>status for the MAIL FROM. Either that or give it a pretty high ranking
>in your evaluation of the message's spamminess.
...............
> Here's a few you shouldn't accept at all:
>
> HELO 0.0.0.0
> HELO 127.0.0.*
> HELO ip-address <== should be [ip-address]
> HELO <your-ip-addrss>
> HELO localhost
> HELO loccalhost.localdomain
> HELO <your own domain name>
> HELO <your own server name>
> HELO hostname <== not a domain or fqdn
>
How can I configure it in Exchage?
Thank you,
Alex
james chong
accept all connections in the HELO and does not do any verification.
There was a recent thread about this which you can read here. I believe
someone suggested a third party product as well. I'm sure there are a
number of third party SPAM apps that can do this.
James Chong
Alex has a question wrote:
Rich Matheisen [MVP]
wrote:
[ snip ]
>> Why bother to refuse a message when you can dump the whole connection?
>> If the HELO domain/fqdn doesn't exist there's no need to proceed
>> beyond the HELO! I think you'll find that this part of the RFC is one
>> that can be safely ignored.
>
>It suits me fine.
>How I can implement with Exchange 2003 SP2? Is it possible?
>If "no", maybe you can me say about software with the same effects?
For something inexpensive, try ORF (http://www.vamsoft.com/orf).
[ snip ]
>How can I configure it in Exchage?
You can't.
Rich Matheisen [MVP]
>I'm don't think Exchange can do this. I believe Exchange is set to
>accept all connections in the HELO and does not do any verification.
Which is (just) one of the reasons Exchange shouldn't be used as an
inflow server from the Internet.
Alex has a question
Thank you a lot!