Controlling SMTP HELO and MAIL FROM: spoofing
Hector Santos
to trap, control or simply minimize the spoofing of HELO/EHLO and MAIL FROM:
information.
What guidelines can I use without breaking/stopping legitimate mail?
Applying a reverse DNS does not seem to be reliable because of legitimate
mail forwarding or send-only servers.
One thing I noticed is that some spammers will your use dot ip address as
the HELO domain name.
For example, for our MX, mail.winserver.com at 208.247.131.9, they will
issue:
HELO 208.247.131.9
In my logs, you would see something like this:
HELO: Incoming connection: 208.247.131.9 [211.58.35.214]
where the IP inside the brackets is the true IP of the connecting client.
In the month of august only, my logs counted over 1600 connections of this
type of HELO or about 80 per day.
So I updated my SMTP server to compare the client IP address with the HELO
address if it is provided as an dot address. Basically this function was
written:
//-----------------------------------------------------------------
// 450.9b2
// return TRUE if helo is a domain name or as a dot address it is
// equal the connection address.
BOOL CheckHelloAddress(const char *szHelo, const DWORD cip)
{
DWORD addr = INADDR_NONE;
if (szHelo && szHelo[0]) addr = inet_addr(szHelo);
return (addr == INADDR_NONE) || (addr == cip);
}
//-----------------------------------------------------------------
In other words, it will only check if a DOT IP address is provided.
Otherwise it returns true meaning it is ok to continue.
We have optional (commented out) logic does more sophisticated MX, reverse
DNS lookups with logic to check sub domains per the RFC, but we found that a
good portion of the legitimate servers are not prepared correctly and issue
a mis-configured HELO/EHLO domain name. So we don't do any checking when
the HELO is a domain name.
So far, its been 16 hours or so with the new change and its trapped 25-30 of
these fake IP addresses.
I'm wondering if this is a legitimate logic to have?
Or is it technically possible to have a legitimate DOT IP address used for
the HELO?
I've never seen one other than from spammers.
thanks for your input
--
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
Kjetil Torgrim Homme
[Hector Santos]:
>
> Applying a reverse DNS [on HELO argument] does not seem to be
> reliable because of legitimate mail forwarding or send-only
> servers.
how about forward DNS?
> One thing I noticed is that some spammers will your use dot ip
> address as the HELO domain name.
>
> For example, for our MX, mail.winserver.com at 208.247.131.9, they
> will issue:
>
> HELO 208.247.131.9
this is illegal, the address literal must be enclosed in brackets.
see RFC 2821 4.1.1.1 and 4.1.3
ehlo = "EHLO" SP Domain CRLF
helo = "HELO" SP Domain CRLF
Domain = (sub-domain 1*("." sub-domain)) / address-literal
it is OK to block this attempt.
we also block connections which provide a non-FQDN argument to HELO,
unless the connection is from our own network.
--
Kjetil T. | read and make up your own mind
| http://www.cactus48.com/truth.html
pat...@klos.com
In article <C0u1b.1791$lq....@fe04.atl2.webusenet.com>,
Hector Santos <nos...@nospam.com> wrote:
> I'm looking at various ways that some control can be added to my SMTP server
> to trap, control or simply minimize the spoofing of HELO/EHLO and MAIL FROM:
> information.
Hi,
I've just spent a lot of time going through ways to use HELO/EHLO and the
dgrees of RFC violation we would do.
> What guidelines can I use without breaking/stopping legitimate mail?
>
> Applying a reverse DNS does not seem to be reliable because of legitimate
> mail forwarding or send-only servers.
Yes. One cannot trust reverse DNS (or the lack of it). One possible
exception is where a PTR record does exist, and a forward lookup of that
PTR also exists, but they do not match. As I still have a LOT to learn
about sendmail, I have not yet implemented this test. Sendmail currently
sets $&{client_resolve} to FORGED when the forward does not resolve as
opposed to resolves, but does not match, so I won't use
$&{client_resolve}.
> One thing I noticed is that some spammers will your use dot ip address as
> the HELO domain name.
>
> For example, for our MX, mail.winserver.com at 208.247.131.9, they will
> issue:
>
> HELO 208.247.131.9
>
> In my logs, you would see something like this:
>
> HELO: Incoming connection: 208.247.131.9 [211.58.35.214]
>
> where the IP inside the brackets is the true IP of the connecting client.
>
> In the month of august only, my logs counted over 1600 connections of this
> type of HELO or about 80 per day.
>
> So I updated my SMTP server to compare the client IP address with the HELO
> address if it is provided as an dot address. Basically this function was
> written:
>
> //-----------------------------------------------------------------
> // 450.9b2
> // return TRUE if helo is a domain name or as a dot address it is
> // equal the connection address.
> BOOL CheckHelloAddress(const char *szHelo, const DWORD cip)
> {
> DWORD addr = INADDR_NONE;
> if (szHelo && szHelo[0]) addr = inet_addr(szHelo);
> return (addr == INADDR_NONE) || (addr == cip);
> }
> //-----------------------------------------------------------------
>
> In other words, it will only check if a DOT IP address is provided.
> Otherwise it returns true meaning it is ok to continue.
That's a very good idea. I don't know what mail system you're using but
that doesn't look like anything which would fit in sendmail. Regardless,
it's an excellent idea, but could be made a little better.
The thing that stands out is that the RFC specifically forbids rejection
based on HELO/EHLO with ONE exception; that exception is that the
HELO/EHLO must be syntactically correct. However, an IP address is NOT
correct unless it has square brackets [] around it. Most SPAM senders
don't use them, so if you reject all IPs without [], you're not violating
the RFC, nor are you rejecting email from any proper mail server (any REAL
mail server would have a proper name; but even one which uses an IP would
at least have []!) I have scanned hundreds of rejections and have never
found a legitimate server using an IP without [].
Now we get to the RFC breaking. Although some people like to get on
soapboxes about how breaking the RFC is NEVER excusable for ANY reason, we
sysadmins have to be a little more realistic. Do I want to worry about the
poor sysadmin who is behind IP NAT and doesn't know how to properly report
his / her IP? NO! Use the ISP's SMTP server! The Internet should NOT cater
to the lowest common denominator (if they didn't, we'd have a fraction of
the SPAM).
So common sense: Yes, any mail server which is lying about it's IP should
be rejected. Dual homed machine should be set up properly; letting 10,000
SPAMs get by for the one dual homed server which is misconfigured is not
acceptable. So if you get an IP in [], go ahead and compare; any RFC bible
thumper has a very tenuous argument there.
> We have optional (commented out) logic does more sophisticated MX, reverse
> DNS lookups with logic to check sub domains per the RFC, but we found that a
> good portion of the legitimate servers are not prepared correctly and issue
> a mis-configured HELO/EHLO domain name. So we don't do any checking when
> the HELO is a domain name.
I am doing testing, too. I have two levels of tests: one is where the HELO
name is tested to see if it is a FQDN, which the RFCs REQUIRE (RFC defined
MUST). Although we are not supposed to reject based on this, we can make
that decision for ourselves. Or we can tag the email with a warning or
something and let the users decide whether or not to accept it.
The second test is to do an A lookup on the HELO/EHLO name given and see
if it matches the IP of the connecting machine. This works VERY well, and
actually doesn't give as many false positives as I thought. I am not
implementing this on my main server yet, but I do have it on my backup MX
(since SPAMMERs seem to prefer to send email to the lower priority MX
servers anyway so as to get less rejections). It's working wonders there,
because my main server is always up (and on the same ISP as the backup),
so no machine should be delivering there; almost all of the mail going to
the backup is therefore SPAM, and most of it is getting rejected.
> So far, its been 16 hours or so with the new change and its trapped 25-30 of
> these fake IP addresses.
>
> I'm wondering if this is a legitimate logic to have?
>
> Or is it technically possible to have a legitimate DOT IP address used for
> the HELO?
>
> I've never seen one other than from spammers.
Yes. The only acceptable IP, though, is a matching IP in square brackets
[].
I still need to write the rules for IPv6, but that should be similar/ not
hard to do:
relay=reva.sixgirls.org. [IPv6:2001:470:1f00:1272::1]
Sorry for my longwinded reply, but sendmail is a bitch, and many of the
people who know sendmail don't seem all that willing to help newbies. So
after many, many hours of research, I finally got these ideas working
recently, and am very excited to see the amount of SPAM drop.
One final note about the problem of violating the RFCs by rejecting email
based on the HELO/EHLO: it's perfectly fine to use HELO/EHLO to decide
whether to relay email, so a doing HELO/EHLO rejection on a backup MX
seems to be completely legitimate. Just an interesting tidbit for the RFC
bible thumpers.
If anyone is interested in trying these rules, please email me.
John Klos
jo...@sixgirls.org
Sixgirls Computing Labs
RFC 2821:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
(from 4.1.3)
(For) IPv4 addresses, this form uses four small decimal integers separated
by dots and enclosed by brackets such as [123.255.37.2], which
indicates an (IPv4) Internet Address in sequence-of-octets form.
Section 7.7:
When mail
is rejected for these or other policy reasons, a 550 code SHOULD be
used in response to EHLO, MAIL, or RCPT as appropriate.
RFC 1123:
Note also that the HELO argument is still required to have
valid <domain> syntax, since it will appear in a Received:
line; otherwise, a 501 error is to be sent.
Hector Santos
Thanks for your input.
We're using the WINSERVER system (http://www.santronics.com).
Yes, I was reminded of the proper bracketed IP address format. So this
further makes it legit in my view to make the filter available at the
HELO/EHLO stage.
So far since its implementation, it has blocked every attempt and just on
the 24th, over 125 attempts. So the negative side effect has been they are
now retrying more times. The average was about 80 per day. Just before
midnight, one site tried atleast 30 times, once per 3 seconds, before it
gave up.
We also offer RBL filtering which we learned the rejection is best done at
the RCPT stage where you allow the command but provide a rejection response.
We learned if a RBL filtered rejection is done before hand, the spammer will
continue to try over and over again.
So I'll probably add logic to the HELO/EHLO filter to delay the final
rejection at the RCPT stage as well. This should reduce the connection
traffic.
It just seems the spammers just wants to get to the precious RCPT stage
where they can learn so much about the email address. Anything stopping them
before them and try keep trying. :-) In fact, in a recent version of our
software, we added a hooking system to the DATA stage were we can provide a
final accept/reject response.
The DATA stage filtering has been a big positive boom for our customers.
However, the side-effect has been that many are experiencing ever greater
spam attacks. In my view, spammers could care less if the actual mail is
received or not. They want that precious email address which is where the
real money is at. Spammers resell the list their new advertising customers;
"Hey, we don't know if the user has filtering technology but we
know one thing, the mail is
getting to them. These addresses are 100% bonafide legit and
that's really what you are
paying for."
The HELO/EHLO RDNS MX/PTR testing we did was done about 2-3 years ago. It
was pretty deep and originally written by a former engineer (one of the
current maintainers of PHP). I recall going over it, double checking the
logic, with him and doing all kinds of testing following all the possible
sub-domain and MX rules. Unfortunately, the end result we found is that a
good bit of the mail servers used as a "send only system" are mis-configured
according to the RFCs.
Sorry, I can't help you with SendMail. ;-)
---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
<pat...@klos.com> wrote in message news:bia9mr$ibi$1...@pyrite.mv.net...
Hector Santos
news:1rk794r...@glesvat.ifi.uio.no...
> (this is off-topic for comp.protocols.tcp-ip, Followup set)
What are you the traffic cop?
How so? Unless this forum is strictly for network level TCP protocols,
this is all part of application level tcp/ip protocols; SMTP, DNS, etc,
which can have all kinds of possible discussions on how to best handle it,
do you just drop and close the socket? etc, (that's a rhetorical question,
no need to answer)
> this is illegal, the address literal must be enclosed in brackets.
> see RFC 2821 4.1.1.1 and 4.1.3
That should be enough for me to reject non-conforming clients.
Thanks for the reminder.
Barry Margolin
Hector Santos <nos...@nospam.com> wrote:
>"Kjetil Torgrim Homme" <kjet...@yksi.ifi.uio.no> wrote in message
>news:1rk794r...@glesvat.ifi.uio.no...
>
>> (this is off-topic for comp.protocols.tcp-ip, Followup set)
>
>What are you the traffic cop?
>
>How so? Unless this forum is strictly for network level TCP protocols,
>this is all part of application level tcp/ip protocols; SMTP, DNS, etc,
This group (comp.protocols.tcp-ip) is for discussion of the TCP/IP protocol
suite, which includes many common application protocols. There is no
newsgroup specifically for discussion of SMTP, so this is the right place.
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kjetil Torgrim Homme
>
> So I'll probably add logic to the HELO/EHLO filter to delay the
> final rejection at the RCPT stage as well. This should reduce the
> connection traffic.
ah yes, we do the rejection at RCPT-TO, since we allow _anything_
being sent to the postmaster address. (it's really frustrating when
someone blocks you erroneously, and you can't reach the admin since he
blocks _everything_.)
> In my view, spammers could care less if the actual mail is
> received or not. They want that precious email address which is
> where the real money is at. Spammers resell the list their new
> advertising customers;
>
> "Hey, we don't know if the user has filtering technology but
> we know one thing, the mail is getting to them. These
> addresses are 100% bonafide legit and that's really what you
> are paying for."
very good observation!