Backscatterer - can I get more detail on why my IP which does not allow incoming SMTP connections is blacklisted?
aldiyen
Our IP address, 66.150.201.227, is blacklisted with backscatterer.org.
I am hoping to get more details about the event which caused this,
because our SMTP configuration should not allow either email
backscatter or any sender callouts.
The configuration is like this:
Incoming SMTP connections on this IP are totally blocked by our
firewall. This IP represents the outside gateway for some of our
application servers, which do sometimes send outbound mail, but there
is no computer which will receive an inbound connection on port 25.
There is no MX record or server for the domain this IP represents;
none of the computers behind the firewall would consider themselves to
be authoritative mail servers for any domain whatsoever.
Even if a connection were to somehow make it past the firewall, none
of the servers behind said firewall accept incoming mail of any sort
for any domain (they will deny any RCPT TO immediately), and they do
not allow sending of mail to any outside domains from any IP other
than 127.0.0.1.
I double checked just to be sure, and we definitely do not send any
VRFY requests under any conditions.
Given the aforementioned configuration, I am confused and somewhat
concerned about having this IP blacklisted for either backscatter or
sender callouts. Is there any way we could get more information on the
cause of the blacklisting?
Thanks very much,
-Matt
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
D. Stussy
news:6eafc35c-6516-4b12...@v25g2000yqk.googlegroups.com...
> Our IP address, 66.150.201.227, is blacklisted with backscatterer.org.
>
> I am hoping to get more details about the event which caused this,
> because our SMTP configuration should not allow either email
> backscatter or any sender callouts.
>
> The configuration is like this:
> Incoming SMTP connections on this IP are totally blocked by our
> firewall. This IP represents the outside gateway for some of our
> application servers, which do sometimes send outbound mail, but there
> is no computer which will receive an inbound connection on port 25.
> There is no MX record or server for the domain this IP represents;
If a host doesn't receive mail, some may say that you should have an "MX"
record in the DNS for it pointing at "localhost" (or anything else that
resolves to the loopback IP addresses). That will guarentee that no
properly operating server will even attempt to send to you, and it tells
everyone else that such a host doesn't receive mail at all.
Apparently, you're sending outbound mail directly to the spamtrap mailboxes
with a null envelope sender. If a message is not an NDR or DSN, it
shouldn't have a null sender.
MrD
> Hello,
>
> Our IP address, 66.150.201.227, is blacklisted with
> backscatterer.org.
>
> I am hoping to get more details about the event which caused this,
> because our SMTP configuration should not allow either email
> backscatter or any sender callouts.
>
> The configuration is like this: Incoming SMTP connections on this IP
> are totally blocked by our firewall. This IP represents the outside
> gateway for some of our application servers, which do sometimes send
> outbound mail, but there is no computer which will receive an inbound
> connection on port 25. There is no MX record or server for the domain
> this IP represents; none of the computers behind the firewall would
> consider themselves to be authoritative mail servers for any domain
> whatsoever. Even if a connection were to somehow make it past the
> firewall, none of the servers behind said firewall accept incoming
> mail of any sort for any domain (they will deny any RCPT TO
> immediately),
...unless the incoming connection comes from localhost?
> and they do not allow sending of mail to any outside domains from any
> IP other than 127.0.0.1.
The loopback address can only connect to itself; so it's hard to see how
you could send to an outside domain using loopback. So I guess these
servers *do* allow RCPT TO, as long as it arrives on the loopback adaptor.
[Trying to grok...] I guess you mean that the mailservers behind the
router only accept mail for forwarding from processes running on the
localhost; and none of them accept mail for final delivery. So they are
all relay-only servers, such as you might find on certain Linux desktop
setups; and they are configured without a smarthost, that is they
forward direct to the internet. Right?
> I double checked just to be sure, and we definitely do not send any
> VRFY requests under any conditions.
What you seem to have described is a system that doesn't accept incoming
mail, but does allow outgoing mail. Incoming mail presumably gets to
your users via one of the paytronix.com MXs. Those MX servers can't be
forwarding using SMTP, since you've said that inbound SMTP is banned by
the firewall; so I guess users must collect their mail using POP or IMAP
(or perhaps some Microsoft mail thingie).
Under normal circumstances, an NDR is generated by a submission server
(such as the local-only forwarders behind your firewall, I suppose) when
a user (on the local machine, in this case) submits mail for forwarding
that subsequently can't be delivered. It should go to the
envelope-sender of the undeliverable mail (hopefully that local user).
Right?
For the sake of argument, suppose a NDR *was* sent from behind your
firewall to a backscatterer spamtrap. Suppose it did in fact come from
one of your local-only forwarders. That would imply that the forwarder
had accepted a message for forwarding (to somewhere undeliverable) which
had the envelope-sender set to a backscatterer spamtrap mailbox. How
could that happen?
Presumably (still considering this hypothetical scenario) the
undeliverable message was some kind of spam; backscatterer spamtraps
apparently don't send mail, so the envelope sender on the undeliverable
message must have been forged. How could it have been accepted by the
forwarder?
The forwarder (per your assertion) only accepts submissions from
localhost, so the spam must have been submitted by some process on
localhost. A web-server script? A trojan? Are the local-only forwarders
configured to check that the envelope sender is a known local user, or
are you relying for your mail security on the fact that submissions are
only accepted from localhost?
For that matter, does your system include any such concept as a "known
local user"?
Could it be that one of your users generates late/bogus bounces using
some kind of challenge-response software? The challenge is sent to the
forwarder, which forwards it to the spamtrap. Bang - you're listed.
Anyway, it's easy enough to check; search the mailserver logs (on all
the local-only forwarders) for mail to <postmaster@> or <>. Of course,
you'll have to check *each* of the local-only forwarders; if you used a
smarthost (with the forwarders submitting all outbound mail to the
smarthost) then you could firewall outbound SMTP from the local-only
forwarders, and control/check outbound mail in just one place.
Of course, you could have got listed the way I did: a user behind the
firewall connects to the backscatterer.org MX using telnet (for whatever
reason), says "quit", then disconnects.
>
> Given the aforementioned configuration, I am confused and somewhat
> concerned about having this IP blacklisted for either backscatter or
> sender callouts. Is there any way we could get more information on
> the cause of the blacklisting?
As far as I can tell, there's no good reason for your forwarders to be
sending NDRs to any user outside of localhost; so there's no reason for
the router to be emitting NDRs. Therefore a backscatterer listing
*should* be completely harmless (it should only prevent delivery of
NDRs). In practice cluelessness is rather common, and non-NDR mail seems
to have a relatively good chance of being interfered with by a
backscatterer listing.
--
MrD.
http://ipquery.org
Rob
> Given the aforementioned configuration, I am confused and somewhat
> concerned about having this IP blacklisted for either backscatter or
> sender callouts. Is there any way we could get more information on the
> cause of the blacklisting?
The people at bacscatterer do not really check if your server is sending
backscatter or sender callouts. They just see that some server sends
mail with an empty from address or from postmaster, and they declare it
a backscatterer.
So if your application sends such mail, it is sufficient to get listed.
Your server does not need to be a mailserver at all...
MrD
>
> So if your application sends such mail, it is sufficient to get
> listed. Your server does not need to be a mailserver at all...
>
If the server sends NDRs to a domain that didn't send it mail in the
first place, then it's a backscatterer - whether or not it's whatever
you mean by a "mailserver".
--
MrD.
http://ipquery.org
Shmuel (Seymour J.) Metz
11/22/2009
at 02:08 AM, aldiyen <ald...@gmail.com> said:
>which do sometimes send outbound mail,
Then you should have working abuse, postmaster and security mailboxes,
although that shouldn't be related to a backscatterer listing.
>I double checked just to be sure, and we definitely do not send any VRFY
>requests under any conditions.
What about RCPT used as an ersatz VRFY for SAV?
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
aldiyen
Thanks for taking the time to thoroughly think through the scenario. I
apologize if I was not clear enough in my description of the setup.
There are a few application servers which are NATted through the one
address on the firewall. They should only accept mail from localhost,
although they don't do any validation of the target address. They may
also accept mail from eachother, although I'm not certain offhand. The
actual paytronix.com MX server is an Exchange server which doesn't
communicate with the application servers, so I don't have to worry
about people having to check for mail on 66.150.201.227 / fw.prod-
bos1.paytronix.com.
The most likely scenario, from the sound of it, is that the
applications which do the mailing from this address messed up mail
sending, or maybe some other process on one of the systems did
something they shouldn't have. That still leaves the question of how
the heck it would get to backscatterer -- even in the event of a
hypothetical exploit, that seems like an odd target.
I'll have to comb through the mail server's logs, try to see what
happened.
Thanks again,
-Matt
DevilsPGD
<nom...@example.com> was claimed to have wrote:
>aldiyen <ald...@gmail.com> wrote:
>> Given the aforementioned configuration, I am confused and somewhat
>> concerned about having this IP blacklisted for either backscatter or
>> sender callouts. Is there any way we could get more information on the
>> cause of the blacklisting?
>
>The people at bacscatterer do not really check if your server is sending
>backscatter or sender callouts. They just see that some server sends
>mail with an empty from address or from postmaster, and they declare it
>a backscatterer.
Think of it as a list of IPs that are attempting to backscatter rather
than those that managed to do it successfully.
Put another way, once you have a MAIL FROM: <> and RCPT TO that hasn't
ever sent out a message, what more information do you need?
The headers and body aren't relevant, the reason for the backscatter
isn't relevant, the simple fact is that the sender has told the
recipient that they intend to send a bounce which cannot possibly be
valid. Why waste additional resources when there is already enough
information available to blacklist?
Shmuel (Seymour J.) Metz
at 11:09 AM, Rob <nom...@example.com> said:
>The people at bacscatterer do not really check if your server is sending
>backscatter or sender callouts. They just see that some server sends
>mail with an empty from address or from postmaster, and they declare it a
>backscatterer.
So they should put those mail clients in the main UCEPROTECT list instead
of segregating them in backscatterer? I could live with that, but I doubt
that it would make you happy.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--
Rob
> The headers and body aren't relevant, the reason for the backscatter
> isn't relevant, the simple fact is that the sender has told the
> recipient that they intend to send a bounce which cannot possibly be
> valid. Why waste additional resources when there is already enough
> information available to blacklist?
Because that would help people to debug their systems.
We all know that backscatterer.org is not interested in helping
people. They think everyone is against them, so when they would
be helping people they think they are helping their enemy.
D. Stussy
news:hee39v$21k$1...@news.eternal-september.org...
> Rob wrote:
> > So if your application sends such mail, it is sufficient to get
> > listed. Your server does not need to be a mailserver at all...
>
> If the server sends NDRs to a domain that didn't send it mail in the
> first place, then it's a backscatterer - whether or not it's whatever
> you mean by a "mailserver".
As NDRs can only go back to a message's identifed sender, the above is
nonsense.
Either the mail really was sent by the mailbox claimed as sender, or
the mail was sent by someone else and NO restrictions or protections on use
were imposed by the sending mailbox's owner, which means it's sent with his
permission. (If it weren't with his permission, he'd have a protection or
restriction in place, such as SPF or DK). Not all mail is sent from the
mailbox in the "From:" header - see the "Sender:" header for details.
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"MrD" <mrdem...@jackpot.invalid> wrote in message
>news:hee39v$21k$1...@news.eternal-september.org...
>> If the server sends NDRs to a domain that didn't send it mail in the
>> first place, then it's a backscatterer - whether or not it's whatever
>> you mean by a "mailserver".
>
>As NDRs can only go back to a message's identifed sender, the above is
>nonsense.
What is "a message's identifed[sic] sender"? In which RFC is that
defined?
>Either the mail really was sent by the mailbox claimed as sender, or
it wasn't, so the NDR is backscatter. Those are the two possibilities.
>the mail was sent by someone else and NO restrictions or protections on use
>were imposed by the sending mailbox's owner,
There is nothing I can do that prevents you on your computer from
telneting to port 25 on any arbitrary computer and typing whatever you
want. Therefore, you can forge my email address no matter what I do.
That doesn't mean there are no restrictions: I do not permit anybody
else to use my email address. There are many criminals who violate
that restriction. They are the guilty ones, not me.
> which means it's sent with his permission.
No, it's sent without my permission. I did not grant permission. I
deny permission.
> (If it weren't with his permission, he'd have a protection or
>restriction in place, such as SPF or DK).
Can you provide any proof of or even evidence for that claim?
"If he didn't want me to beat him up he'd have studied karate/hired a
bodyguard/run away/brought a gun." Who is the guilty party, the
attacker or his victim (who failed to take whatever steps you claim he
should have in order not to be attacked)?
> Not all mail is sent from the
>mailbox in the "From:" header - see the "Sender:" header for details.
Not all mail is sent from any mailbox it claims to be sent from, no
matter which header (or envelope header) you look at.
Seth
Fred Mobach
> DevilsPGD <Death...@crazyhat.net> wrote:
>> The headers and body aren't relevant, the reason for the backscatter
>> isn't relevant, the simple fact is that the sender has told the
>> recipient that they intend to send a bounce which cannot possibly be
>> valid. Why waste additional resources when there is already enough
>> information available to blacklist?
>
> Because that would help people to debug their systems.
... and disclose spamtraps. So that should not be done.
> We all know that backscatterer.org is not interested in helping
> people. They think everyone is against them, so when they would
> be helping people they think they are helping their enemy.
We? Please talk only for yourselve, I disagree with you on this point.
You think to know what backscatterers.org think, I'm limited to what
they have published on their website and what Claus has stated in this
newsgroup.
--
Fred Mobach - fr...@mobach.nl
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..
Shmuel (Seymour J.) Metz
at 04:13 AM, Rob <nom...@example.com> said:
>Because that would help people to debug their systems.
It's your responsibility to debug your own system. Nobody is paying
UCEPROTECT for debugging assistance, AFAIK.
>We all know that backscatterer.org is not interested in helping people.
Liar. We know that they aren't interested in helping *you*; they do help
their users.
>They think everyone is against them,
Sorry, Uri Geller, try a different spoon.
--
Shmuel (Seymour J.) Metz, truly insane Spews puppet
<http://patriot.net/~shmuel>
I reserve the right to publicly post or ridicule any abusive
E-mail. Reply to domain Patriot dot net user shmuel+news to contact
me. Do not reply to spam...@library.lspace.org
--