DevHeads.net

SMTP client host name spoofing

Received: from mail-iw0-f176.google.com (biz88.inmotionhosting.com
[66.117.14.32])
by greer.hardwarefreak.com (Postfix) with ESMTP id F297D6C12E
for < ... at hardwarefreak dot com>; Thu, 31 Mar 2011 06:29:19 -0500

biz88.inmotionhosting.com is the reverse name and
mail-iw0-f176.google.com is the forward name, correct? How is this VPS
hosted snowshoe spammer spoofing a forward host name of google.com?

I'm no DNS expert but I didn't think spoofing a forward lookup was
possible, as one must control the DNS servers (or a zone) for that
domain. What am I missing?

Comments

Re: SMTP client host name spoofing

By mouss at 03/31/2011 - 17:38

Le 31/03/2011 17:52, Stan Hoeppner a écrit :
they are spoofing HELO. if you feel motivated, contact InMotion.
otherwise, block list
66.117.14.0 - 66.117.15.255

or block

/\d\.inmotionhosting\.com$/ REJECT

and complain to "Corporate Colocation Inc.". if no answer, block:
66.117.0.0 - 66.117.15.255

Re: SMTP client host name spoofing

By Stan Hoeppner at 03/31/2011 - 19:25

mouss put forth on 3/31/2011 4:38 PM:
Which is the answer to my question.

You should know me well enough by now mouss to realize that I'd already
blocked the parent /20, and Corporate-Colocation's other 19 netblocks,
after some investigation, before I sent my question to the list. ;)

Re: SMTP client host name spoofing

By mouss at 04/01/2011 - 17:33

Le 01/04/2011 01:25, Stan Hoeppner a écrit :
yep. but in a public list, "you" is "others" ;-p

as usual, thanks for reporting offenders...

Re: SMTP client host name spoofing

By Wietse Venema at 03/31/2011 - 12:42

Stan Hoeppner:
The format is:

Received: from helo-hostname (verified-reverse-name [ip-address])

This is also useful when setting up backscatter filters: all mail with
a helo-hostname of "porcupine.org", "postfix.org", etc. is a forgery.

Wietse

Re: SMTP client host name spoofing

By Stan Hoeppner at 03/31/2011 - 13:41

Wietse Venema put forth on 3/31/2011 11:42 AM:
Thanks Wietse. So, answering my own previous question to Viktor, this
is defined in the docs in the backscatter readme, like so:

Although my email address is " ... at porcupine dot org", all my mail systems
announce themselves with the SMTP HELO command as
"hostname.porcupine.org". Thus, if returned mail has a Received: message
header like this:

Received: from porcupine.org ...

Thus one should deduce that the first hostname in the first received
line is the HELO/EHLO hostname. Not quite the direct definition I
anticipated finding in the docs, or in a location I'd have expected, but
nonetheless the information is present.

I just read (again) the backscatter page. I've never actually
implemented such measures as backscatter has never been a problem here.
I'm thinking I'll go ahead and do so as a preemptive measure..

Re: SMTP client host name spoofing

By Jeroen Geilman at 03/31/2011 - 15:16

On 03/31/2011 07:41 PM, Stan Hoeppner wrote:
HELO checks are the primary defense against backscatter of this sort; I
use a simple subset of the available options:

smtpd_helo_restrictions = reject_invalid_helo_hostname,
reject_unknown_helo_hostname, reject_non_fqdn_helo_hostname,
check_helo_access hash:/etc/postfix/helo_access, permit

Where helo_access contains my own IPs and hostnames.

This setup will reject an AMAZING amount of spam.
Fair warning: it may also yield the occasional false positive due to a
misconfigured client mail system!
The usual warn_if_reject will help out with that.

Re: SMTP client host name spoofing

By Vincent Lefevre at 04/01/2011 - 03:47

On 2011-03-31 21:16:16 +0200, Jeroen Geilman wrote:
I really think it is a bad idea to use reject_unknown_helo_hostname.
Some machines sending mail are on a local network, so that resolving
their hostname doesn't make sense outside this network. The main
goal of the EHLO hostname being for logging purpose (to identify
the machine), the easiest solution may be to give the hostname (the
alternate solution of giving the local IP address isn't a good idea
if the address is dynamical).

Re: SMTP client host name spoofing

By mouss at 04/01/2011 - 17:51

Le 01/04/2011 09:47, Vincent Lefevre a écrit :
we're not asking them to resolve their hostname. we're only asking them
to use a "real" name. it's as easy as
myhostname = joe.example.com

with a "joe.example.com" that exists in DNS.

I don't use reject_unknown_helo_hostname. however, I watch my dog^W log,
and I blocklist an IP that uses a "dumb" helo if it ever gets under my
attention (mostly in the case of a rejection such as "user unknown", but
also if spam filter says it is probably spam...).

let me state this differently:

- there are people who are cooperative. they do everything to look good.
they work "with us". these people are welcome, and if we ever block
them, we'll apologize and whitelist them on demand

- there are the "uncooperative" people. most of these don't know how
smtp works. we will happily accept their mail as long as it goes to
valid recipients and is not caught by filters. as soon as they trigger a
filter (including "user unknown"), there is no merci.

I don't care for the helo name. the "machine" is identified by its IP.
helo only shows "some" stupid systems. I'm only using it to reject
zombies.

if you have a dynamic IP, it is still a good idea to use a "static"
helo. even if it doesn't resolve to your IP. I know some other people
may say the opposite (require helo to resolve to IP), but I won't go
that far (I accept mail from dynamic IPs if the "owner" does some
efforts...).

Re: SMTP client host name spoofing

By Vincent Lefevre at 04/03/2011 - 19:27

On 2011-04-01 23:51:39 +0200, mouss wrote:
But the purpose of having a host in DNS is to be able to resolve it.
I mean: you can't have a real hostname in the DNS if it is on a private
network (unreachable because of NAT), can you? Well... I'm not sure.
See below.

Using a private IP (which doesn't even break a SHOULD in the RFC's)
is IMHO as dumb as a hostname that isn't in DNS.

IMHO, that's fine.

Well, this doesn't make sense since a machine can have several
IP addresses (e.g. because it has several physical or virtual
interfaces and one doesn't necessarily know which one will be
used). Now, the question is more: if the hostname is resolved,
should it neccessarily correspond to the machine? More precisely,
if I use host-for-smtp-only.mydomain.tld, which resolves to
127.0.0.1 (the IP address should not be used to contact the
machine anyway), is it OK?

Note: this hostname would be used *only* for EHLO. So, there's
no risk for other protocols.

Re: SMTP client host name spoofing

By Reindl Harald at 04/03/2011 - 19:53

Am 04.04.2011 01:27, schrieb Vincent Lefevre:
why not?

* you have a public ip
* make a a-record in some domain to this ip
* your isp have a ptr for this ip
* myhostname = your a-record

EHLO/HELO, A, PTR are matching
where is the problem?

Re: SMTP client host name spoofing

By Vincent Lefevre at 04/03/2011 - 20:22

On 2011-04-04 01:53:15 +0200, Reindl Harald wrote:
Because strictly speaking, due to NAT, the DNS would lie. I mean that
the address would not be the address of the machine sending the mail,
but the address of the router.

They won't even necessarily match for some machines. For instance,
one of them is a laptop, which is not always on the same network.
I suppose that should not be a problem, but who knows...

Even an address literal in square brackets isn't reliable: I had been
testing this for a couple of weeks and I got a reject a few minutes
ago:

Helo command rejected: IP literal in HELO hostname (in
reply to RCPT TO command)

Re: SMTP client host name spoofing

By Reindl Harald at 04/03/2011 - 20:38

Am 04.04.2011 02:22, schrieb Vincent Lefevre:
nobody out there is interested on your NAT

the server on the other side is seeing only your public address
and your public adress have a hostname / ptr and your postfix should
match this hostname

the dns do not lie, you never connect outside with anything of your
NAT because the nature of NAt is to be transparent

that is why you should NOT direct mail from every single machine
and setup ONE LAN-Relay which normally use a clean relay-host and
does NOT direct send mails as long it is not needed

so you can comment out realy-host temorary, restart postfix
and all other machines in your LAN are working as expected

now you come even with "direct send from a notebook"
jesus christ this is really ignorant!

that is why i said "do not send directly" unless your whole
configuration is clean (dns, HELO,...) and as long you want
that your messages are received and not rejected or even
silently dropped

Re: SMTP client host name spoofing

By Sahil Tandon at 04/03/2011 - 21:08

[ .. ]

Please, this is a technical mailing list; let's all try to minimize the
editorializing and insults.

Re: SMTP client host name spoofing

By Reindl Harald at 04/04/2011 - 00:38

Am 04.04.2011 03:08, schrieb Sahil Tandon:
i know, but somewhere sgould be a point where peopole try to understand
things they are told tem over and over or do what they want and stop
questions if the answers do not interest them

Re: SMTP client host name spoofing

By Reindl Harald at 04/01/2011 - 04:03

Am 01.04.2011 09:47, schrieb Vincent Lefevre:
your users has to use SASL and are not affected as long your machine
is useable configured, every other out there dealing directly
as MTA has to have a PTR, A-Record and correct HELO(EHLO

RE: SMTP client host name spoofing

By Murray S. Kucherawy at 04/01/2011 - 04:01

Those machines should be talking to a public-facing MTA that tolerates unqualified names; they shouldn't be talking to the public Internet with an unqualified name.

But even then, sending a hostname without a domain name violates the SMTP RFC. In the face of such widespread abuse, I'm a fan of being as strict as possible.

The RFCs also make specific admonitions against making filtering decisions based on HELO/EHLO, but a lot of people do it anyway (and for good reason).

Re: SMTP client host name spoofing

By Vincent Lefevre at 04/01/2011 - 05:15

On 2011-04-01 01:01:34 -0700, Murray S. Kucherawy wrote:
The main smarthost of my ISP gets blacklisted by some lists each time
someone sends spam (this is a small ISP, so that it gets blacklisted
much easier than large ISP's, which are probably whitelisted). There's
also a smarthost that checks incoming messages with an antispam
software, but false positives would be dropped without notice, which
is unacceptable.

Actually mine has a resolvable domain name after the first dot (only
the full hostname isn't resolvable).

Well, it violates only a SHOULD (because I should send an IP address
while I don't). In practice, not so many people reject messages with
unresolvable hostnames. So, currently, that's better than using one
of my ISP's smarthost.

I could now use SASL (this wasn't possible in the past because I didn't
have my own server), but there would still be problems to solve: how
can I use a fallback (on the client side) to the direct method when for
some reason, the server is not reachable?

Re: SMTP client host name spoofing

By Reindl Harald at 04/01/2011 - 05:31

Am 01.04.2011 11:15, schrieb Vincent Lefevre:

if your MTA is not reachable you can not send mail at this moment
so simple it goes in days of SPF/DKIM no MUA there is really no
reason for any workaround

if your internet-connection is broken the MUA holds back the mail
and if your server down you should get him up and will not die
if you can not send a message now . how often this happens really?

Re: SMTP client host name spoofing

By Vincent Lefevre at 04/01/2011 - 11:07

On 2011-04-01 11:31:43 +0200, Reindl Harald wrote:
Perhaps in your case, but when sending mail directly (i.e. without
using SASL), I get a reject only once every few weeks. So, yes,
there is a reason for a fallback to direct SMTP to the destination.

That's not the MUA, but the local server that holds back the mail.

If my server is down, I may need to send mail (e.g. messages with
logs) to solve the problem and bring it up again.

Not very often, but this happens. And after having one problem
(relay server down), I don't want to solve another problem
(trying to send mail).

Re: SMTP client host name spoofing

By Reindl Harald at 04/01/2011 - 11:15

Am 01.04.2011 17:07, schrieb Vincent Lefevre:

if you send mail directly you have to make
sure a static-ip, ptr, matching HELO

if this is not possible simply send not mails directly

ok you can, but do not wonder if mails are dropped

if the local server doe not have static-ip, ptr etc. it has to
use a relay-server and can send messages authenticated to the relay

use a relay server

Re: SMTP client host name spoofing

By Vincent Lefevre at 04/01/2011 - 11:32

On 2011-04-01 17:15:41 +0200, Reindl Harald wrote:
This is not (always) possible, and I have no choice to send mail
directly when the relay server is down.

Experience shows that most mail won't be dropped.

Still, the question holds: how do I use SASL, with direct SMTP
as a fallback?

I can't use it because it is down!!!

Re: SMTP client host name spoofing

By Reindl Harald at 04/01/2011 - 11:45

Am 01.04.2011 17:32, schrieb Vincent Lefevre:
when the server is down you can not send mails
and you really will not die, if it would be so imortant
you need redundancy on the relay-server

(failover, clustering...) all the things are available and
costs some money, but again - is it important you will bring
back the money over the infrastructure or it's not important

and that is why so many spam is flying around
would no host accept mails where PTR, A-Record, HELO not
match, respect SPF and drop mails from dial-up ranges
spam would dramatically go back

you can't

so you must wait until is up, bring it up by your self
or use any freemail-account if you need to send amil
to solbe the problem

Re: SMTP client host name spoofing

By Vincent Lefevre at 04/03/2011 - 18:50

On 2011-04-01 17:45:01 +0200, Reindl Harald wrote:
I repeat: When the server is down, I may *NEED* to send mail
(for various reasons, e.g. to send logs so that things can be
fixed, to warn some people that I can no longer receive mail,
and so on). It is certainly not you to decide whether I wish
to send mail or not.

As you say, it costs money (but also more time for maintenance),
so this is out of the question.

It would be better to close the account of spammers, but I don't
think that's the right place to discuss these things.

OK, so I'll continue to use direct SMTP, as long as it works quite
reliably (for me).

Re: SMTP client host name spoofing

By Stan Hoeppner at 03/31/2011 - 17:19

Jeroen Geilman put forth on 3/31/2011 2:16 PM:

Spammers don't send backscatter bounces. The victim MX hosts do, by
definition. In this case I've not seen any for many years.

Backscatter once was a HUGE problem, but not today. As most, if not
all, forged sender address spam comes from bots, and most MXen on the
planet today are far better equipped to reject bot spam, the rest of us
don't suffer the backscatter as we once did.

In the case of spammers directly sending spam disguised as fake
mailer-daemon messages, those are dealt with here via the same methods I
use against all other spam, which is probably why I never see them these
days--blocked at SMTP time.

Finally, snowshoe spammers don't bother to forge valid sender addresses,
as that requires extra work--most spammers are lazy. Snowshoe spammers
use throw away domains, and simply make up random sender addresses in
that domain.

Re: SMTP client host name spoofing

By Victor Duchovni at 03/31/2011 - 11:57

No, the "google" name is just the EHLO parameter sent by the client,
it is not derived from DNS lookups and not verified.

This question is moot.

Re: SMTP client host name spoofing

By Stan Hoeppner at 03/31/2011 - 13:20

Victor Duchovni put forth on 3/31/2011 10:57 AM:
Thanks for the clarification Viktor. I can't seem to locate any
documentation on the official Postfix website that defines what Postfix
inserts in the first received line. I'm sure I'm simply search
handicapped. Can you point me the relevant docs?

Thanks.

Re: SMTP client host name spoofing

By Victor Duchovni at 03/31/2011 - 13:44

The syntax of Received lines is specified in RFC 821/2821/5321:

<a href="http://tools.ietf.org/html/rfc5321#section-4.4" title="http://tools.ietf.org/html/rfc5321#section-4.4">http://tools.ietf.org/html/rfc5321#section-4.4</a>

When an SMTP server receives a message for delivery or further
processing, it MUST insert trace ("time stamp" or "Received")
information at the beginning of the message content, as discussed in
Section 4.1.1.4.

This line MUST be structured as follows:

o The FROM clause, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP
address of the source, determined from the TCP connection.

the details are at the bottom of page 58/top of 59:

Time-stamp-line = "Received:" FWS Stamp <CRLF>

Klensin Standards Track [Page 59]

RFC 5321 SMTP October 2008

Stamp = From-domain By-domain Opt-info [CFWS] ";"
FWS date-time
; where "date-time" is as defined in RFC 5322 [4]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.

From-domain = "FROM" FWS Extended-Domain

By-domain = CFWS "BY" FWS Extended-Domain

Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( address-literal FWS "(" TCP-info ")" )

TCP-info = address-literal / ( Domain FWS address-literal )
; Information derived by server from TCP connection
; not client EHLO.

Re: SMTP client host name spoofing

By Stan Hoeppner at 03/31/2011 - 14:01

Victor Duchovni put forth on 3/31/2011 12:44 PM:
No wonder I didn't find it--looking in the wrong place.

So the verified reverse DNS data Postfix inserts in front of the address
literal would be the "Domain folded whitespace" mentioned above or
"address-literal FWS"? I assume the IP address in the received line
falls under "TCP-info" above.

Thanks again Viktor.

Re: SMTP client host name spoofing

By Victor Duchovni at 03/31/2011 - 14:17

Postfix takes either (really they are the same) of the

Domain FWS "(" TCP-info ")"
address-literal FWS "(" TCP-info ")"

branches of the spec, where the Domain or address-literal is the
EHLO name as stated earlier in 4.4. The TCP-info comment is then
of the:

Domain FWS address-literal

variety, and this time the Domain is the verified DNS name of the
address literal.