You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Paul Hammant <ha...@apache.org> on 2002/03/21 20:04:12 UTC
SPAM #3
/. -> http://slashdot.org/articles/02/03/21/1733224.shtml?tid=111
dosten <ma...@osten.net> sent us a link to a story running on
Cnet about the spam epidemic
<http://news.com.com/2009-1023-864815.html>. My favorite stat is that by
2006, we'll be getting 1400 spam a /day/. Of course, I get that every
/week/. Talks about foreign spam relays, block lists, and so on. Decent
piece explaining a huge problem that's only getting worse.
Addendum - 2002 JAMES coders formulate plan for phasing out of
unaccountable mail servers and upgrade JAMES itself to be compliant with
their new RFC.
-PH
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3
Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Danny Angus" <da...@thought.co.uk>
> with the twist of faked headers, to stop them being traced.
It would get harder to detect with spoofed IP Headers. Something could be
learned from intrusion detection systems. Brightmail idea of seeding
addresses is similar to having a honeypot and collecting intruder
information.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3 (ORBZ.org)
Posted by Paul Hammant <Pa...@yahoo.com>.
Harmeet,
>Their approach seems to be that SMTP is abused, let us compile a list of
>servers that can be abused. In some sense it is a public service, but to me
>it is a bit like, let us collect information on vulnerable machines by
>exploiting the vulnerabilitues and then as a public service, publish the
>list of machines. Seems like an odd approach, but maybe an effective one to
>fight against spam.
>
Yes it is a controvercial way of gathing facts.
>I detected their probes on my mail server in January. Attaching the
>conversation. You may find it interesting.
>
It is easy to see (lookng at that email) why they get in trouble, They
are very evasive to simple questions from a concerned sysop.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spam spam spam spam ... to coin a phrase
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>>OK, so 194.172.112.34 is open relay. You know because it is apparent in
>>the header or you have checked?
>>
>
>checked.
>
I used to use Amnesi, but it is down nowadays.
>>( I duck again as I await the flames again. Seriously I was not going to
>>say another word on spam, but you guys raised it again)
>>
>
>Although I may not agree with the detail of your idea, there's no getting
>away from the fact that spam is an issue, and we're well situated to explore
>new possibilities. I hope you dont think our "robust responses" are flames..
>
:-)
>>If it is that the mail server accepts the incoming because it is
>>apparently from another server it trusts, maybe the second part of the
>>RFC could be used to tackle that. It reaches back, post connection, to
>>the mail server that was proportedly the sender, and checks the message
>>ID and a digest of the message with it. If that mail server replies
>>"whatare you on about?" then the mail was very craftily faked.
>>
>
>This is a sensible approach, but it would increase server workloads, as they
>would have to maintain lists of message_id's that they sent.
>
True, but should not worry about workload of mail servers, if the end
point will be a reduction of spam we will recieve (you have seen the
projections?)
>>It is also apparent (as Harmeet says) that if open relays close, then
>>the spammer still get through by really spending time faking headers.
>>
>
>I'm beginning to wonder if we shouldn't be looking at this from the point of
>view of "trust", and whether any trust mechanisms that exist would be
>appropriate to adapt for creating chains of trust amongst mailservers.
>
I'll come back to this.
>On the other hand its all a bit of a vicious circle, because spammers abuse
>one of the fundamental features of email, that you can initiate an email and
>send it to anyone with no prior agreement.
>
Yes, that will never be closed. However, if they have to use legitimate
mail servers and chains of contract ( ISP to ISP, ISP to customer) and
acceptible use policies mean that if they have to use real accounts to
send spam, they will be closed down quickly.
>>Thus this RFC I talk of is two fold. 1) RUOR and 2) say "DYST" (Did You
>>Send This).
>>
>
>I still maintain that if IP faking is within the remit of spammers, then
>faking RUOR is too.
>
You're missing the central point of RUOR. It is a not mail header. A
server can be asked at any time by any server (by it's alleged recipient
mail server in this case). The dialog goes HELO, RUOR, <bye>.
Anything in an incoming mail header could be faked, all RUOR is about is
an RFC sponsored way of allowing machines to ask mail servers if they
are open relay without being deemed as a hack attempt.
>I quite like DYST as a principle, particularly if you can have verified
>trust, however if you send my account holders lots of email that they don't
>want to receive *directly*, and thereby comply with RUOR and DYST I still
>have to blacklist you, but at least now I know who you really are.
>
Yes. And they will be closed, after some delay, by their ISP who is in
contracts or AUPs with larger backbones etc.
Spam is not killed by RUOR or DYST, but is made accountable.
<fx>Pauls loosens flame retardant jacket a little</fx>
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spam spam spam spam ... to coin a phrase
Posted by Paul Hammant <Pa...@yahoo.com>.
Harmeet, Danny,
Good I see that you guys have the idea now. Given your more advanced
SMTP knowledge, you can take it way further than I can.
I'd like to say one more thing in the defence of RUOR. Before I do that
I'd like to remind you both that RUOR is also a reach-back query (it is
not mail-header element):
If all the differnet servers implemented it truthfully, then it would be
good, we can all agree that. I think this is likely to be the massive
majority case, because the open relay SMTP servers on the net are not
there because the administrator is a malicious person, they are there
because of ignorance and poor configuration. Hackers do not currenly
mount trojan horse SMTP servers, they take advantage of other poorly
configured ones.
If we had a situation where one SMTP server could ask another RUOR, we
have a simple RFC endorsed, if a little brute-force, way of rejecting
incoming mail from servers that are possibly open relay. It is up to the
administrator of the querying mail server to decide what to do with the
mail item from non-RUOR servers. Email extremists could silently reject
all email from non-RUOR mail servers. The overly trusting could accept
all and perhaps not even do the RUOR query. Somewhere in the middle the
attitude might be to accept it but email the sender back again with a
warning about non RFC compilance and future blocking of their sending of
email.
Now I am sure that new techniques would be used once these holes are
closed, but is that not the nature of hacking? We all think it weird
that all other servers are given massive attention and their holes
closed rapidly, but SMTP seems to have been given up on years ago.
Regards,
- Paul
>>>If it is that the mail server accepts the incoming because it is
>>>apparently from another server it trusts, maybe the second part of the
>>>RFC could be used to tackle that. It reaches back, post connection, to
>>>the mail server that was proportedly the sender, and checks the message
>>>ID and a digest of the message with it. If that mail server replies
>>>"whatare you on about?" then the mail was very craftily faked.
>>>
>>This is a sensible approach, but it would increase server workloads, as
>>
>they
>
>>would have to maintain lists of message_id's that they sent.
>>
>
>
>DYST seems like a good idea.
>
>One thing to remember though is that a message could be recieved from
>MUA(Client) or fowarded from an MTA(Server). The 'Did you send this' cannot
>be sent to clients.
>
>This combination should help out:
>- SMTP Auth,
>- Close Relay
>- (DYST) Did You Send This. This command could be sent to servers with 2
>options (a) Message ID or (b) Message Digest.
>
>Some issues could be
>Mail Servers need to remember the messages sent. This may be not that easy
>to add to existing mail servers. Mail servers may need to mentain history of
>messages sent for a guaranteed and agreed upon time span. 6 hours or 1
>day could be the timeout for sent messages.
>If the recieving server has not been able to check a set of messages for
>DYST
>within the set time, the recievrng server must assume mail message has
>passed DYST test.
>
>I will do a writeup on this over the weekend and send it to the list. It can
>then be ignored/expanded/implemented as you all like.
>
>Harmeet
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spam spam spam spam ... to coin a phrase
Posted by Danny Angus <da...@thought.co.uk>.
> One thing to remember though is that a message could be recieved from
> MUA(Client) or fowarded from an MTA(Server). The 'Did you send
> this' cannot
> be sent to clients.
The rule for *not* asking DYST is "is there already a recieved: header in
the message" this would imply it had been relayed by an MTA
However.. imagine the situation where we have one SMTP listener dumping all
of its reciepts into storage, and another spooling agent processing the
storage and sending it on, the sending agent may not be listening on port 25
to recieve the DYST request...
Perhaps we should draft an RFC after all and call it DYST for sending MTA's
whereby we can disregard the fact that a sending MTA may not also be
listening because we can say "implementing transport agents SHOULD listen on
port 25 for the DYST command irrespective of whether or not they recieve
SMTP email on this port" which would also cover the bases for one-way
outbound gateways from private networks or other protocols.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spam spam spam spam ... to coin a phrase
Posted by Harmeet Bedi <ha...@kodemuse.com>.
> > If it is that the mail server accepts the incoming because it is
> > apparently from another server it trusts, maybe the second part of the
> > RFC could be used to tackle that. It reaches back, post connection, to
> > the mail server that was proportedly the sender, and checks the message
> > ID and a digest of the message with it. If that mail server replies
> > "whatare you on about?" then the mail was very craftily faked.
>
> This is a sensible approach, but it would increase server workloads, as
they
> would have to maintain lists of message_id's that they sent.
>
DYST seems like a good idea.
One thing to remember though is that a message could be recieved from
MUA(Client) or fowarded from an MTA(Server). The 'Did you send this' cannot
be sent to clients.
This combination should help out:
- SMTP Auth,
- Close Relay
- (DYST) Did You Send This. This command could be sent to servers with 2
options (a) Message ID or (b) Message Digest.
Some issues could be
Mail Servers need to remember the messages sent. This may be not that easy
to add to existing mail servers. Mail servers may need to mentain history of
messages sent for a guaranteed and agreed upon time span. 6 hours or 1
day could be the timeout for sent messages.
If the recieving server has not been able to check a set of messages for
DYST
within the set time, the recievrng server must assume mail message has
passed DYST test.
I will do a writeup on this over the weekend and send it to the list. It can
then be ignored/expanded/implemented as you all like.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spam spam spam spam ... to coin a phrase
Posted by Peter Romianowski <an...@gmx.de>.
Too expensive for you? Hey, just kidding... :)
> -----Original Message-----
> From: Danny Angus [mailto:danny@thought.co.uk]
> Sent: Friday, March 29, 2002 3:54 PM
> To: James Developers List
> Subject: RE: Spam spam spam spam ... to coin a phrase
>
>
> 8,000,000 email addresses for $240...
> the end of the world is nigh
> http://emaildata.51road.com/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spam spam spam spam ... to coin a phrase
Posted by Danny Angus <da...@thought.co.uk>.
8,000,000 email addresses for $240...
the end of the world is nigh
http://emaildata.51road.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spam spam spam spam ... to coin a phrase
Posted by Danny Angus <da...@thought.co.uk>.
> OK, so 194.172.112.34 is open relay. You know because it is apparent in
> the header or you have checked?
checked.
> ( I duck again as I await the flames again. Seriously I was not going to
> say another word on spam, but you guys raised it again)
Although I may not agree with the detail of your idea, there's no getting
away from the fact that spam is an issue, and we're well situated to explore
new possibilities. I hope you dont think our "robust responses" are flames..
> If it is that the mail server accepts the incoming because it is
> apparently from another server it trusts, maybe the second part of the
> RFC could be used to tackle that. It reaches back, post connection, to
> the mail server that was proportedly the sender, and checks the message
> ID and a digest of the message with it. If that mail server replies
> "whatare you on about?" then the mail was very craftily faked.
This is a sensible approach, but it would increase server workloads, as they
would have to maintain lists of message_id's that they sent.
> It is also apparent (as Harmeet says) that if open relays close, then
> the spammer still get through by really spending time faking headers.
I'm beginning to wonder if we shouldn't be looking at this from the point of
view of "trust", and whether any trust mechanisms that exist would be
appropriate to adapt for creating chains of trust amongst mailservers.
On the other hand its all a bit of a vicious circle, because spammers abuse
one of the fundamental features of email, that you can initiate an email and
send it to anyone with no prior agreement.
> Thus this RFC I talk of is two fold. 1) RUOR and 2) say "DYST" (Did You
> Send This).
I still maintain that if IP faking is within the remit of spammers, then
faking RUOR is too.
I quite like DYST as a principle, particularly if you can have verified
trust, however if you send my account holders lots of email that they don't
want to receive *directly*, and thereby comply with RUOR and DYST I still
have to blacklist you, but at least now I know who you really are.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spam spam spam spam ... to coin a phrase
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny, Harmeet,
OK, so 194.172.112.34 is open relay. You know because it is apparent in
the header or you have checked?
The shot-down-in-flames RUOR could detect that, or go part way to
detecting that. There would be three types of mail servers:
1) Pre RUOR
2) RUOR compatible and reporting correct policy
3) RUOR compatible, incorrectly replying "No I am not" (and in breach of
the RFC associated with RUOR).
Blacklists, if they were built, would not be needed to list open relays,
but mail servers that did (3) above. A smaller list one would assume.
( I duck again as I await the flames again. Seriously I was not going to
say another word on spam, but you guys raised it again)
It is also apparent (as Harmeet says) that if open relays close, then
the spammer still get through by really spending time faking headers. I
do not really understand the insertion point of the mail, but I guess it
is something to do with IP origin faking that hacker use and was talked
about a lot in a few years ago ususally in the context of IPv6 etc.
If it is that the mail server accepts the incoming because it is
apparently from another server it trusts, maybe the second part of the
RFC could be used to tackle that. It reaches back, post connection, to
the mail server that was proportedly the sender, and checks the message
ID and a digest of the message with it. If that mail server replies
"whatare you on about?" then the mail was very craftily faked.
Thus this RFC I talk of is two fold. 1) RUOR and 2) say "DYST" (Did You
Send This).
( putting on fire retardant suit now).
Regards,
- Paul
>Paul,
>
>Here's an extract from a header from a spam I recieved this a.m. It clearly
>shows how the information describing each host it passed through has not
>been verified, (each line ought to receive from the recipient of the line
>below) and no action has been taken to block this mail where names and
>addresses don't match.
>
>What I think is important is that the IP address of the top entry is an open
>relay, and the lower ones dont accept connections on port 25 at all. Which
>suggests to me that this is a live example of the scenario you set out a few
>days ago.
>
>I should also point out that it is also clear from a little research that
>this is not connected at all with Edinburgh University (ed.ac.uk) whos name
>has been used maliciously by the spammer.
>
>
>Received: from ed.ac.uk ([194.172.112.34])
> by mx0.dircon.net (8.9.1.Dirconised/8.9.1) with SMTP id AAA13183
> for <da...@thought.co.uk>; Fri, 29 Mar 2002 00:59:01 GMT
>
>Received: from unknown (HELO rly-xr02.nikavo.net) (127.38.79.237)
> by symail.kustanai.co.kr with SMTP; 28 Mar 2002 15:00:03 -0300
>
>Received: from smtp013.mail.yahou.com ([211.199.191.200])
> by rly-xr01.nihuyatut.net with local; 28 Mar 2002 11:55:00 +0100
>
>Received: from unknown (HELO rly-xw01.otpalo.com) (132.118.28.155)
> by n7.groups.huyahoo.com with asmtp; Thu, 28 Mar 2002 12:49:57 +1100
>
>Received: from unknown (HELO q4.quickslow.com) (176.200.210.157)
> by web.mail.halfeye.com with smtp; Thu, 28 Mar 2002 23:44:54 +0100
>
>
>This mail would not have got to me had the open relay been closed, or if it
>had verified the Recieved headers for internal consistency, without recourse
>to any enhanced SMTP functionality, or network services of any kind (DNS
>etc).
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Spam spam spam spam ... to coin a phrase
Posted by Harmeet Bedi <ha...@kodemuse.com>.
From: "Danny Angus" <da...@thought.co.uk>
> PS This makes me look like the kind of sad geek who reads the headers of
his
> spam, God preserve me from myself!
ha ha, I do that too.
I find reading headers intersting in most circumstances. It is of some
practical value because open relays make spam easy. If that ever gets
diffiicult, a real bad guy could craft IP headers.
Want to point out that blocking IP address is only one possible solution and
in some situations it may aid in a denial of service for some innocent
companies outgoing mail.
Harmeet
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
> PS This makes me look like the kind of sad geek who reads the headers of
his
> spam, God preserve me from myself!
> d.
>
> > -----Original Message-----
> > From: Danny Angus [mailto:danny@thought.co.uk]
> > Sent: 29 March 2002 09:33
> > To: James Developers List
> > Subject: Spam spam spam spam ... to coin a phrase
> >
> >
> > Paul,
> >
> > Here's an extract from a header from a spam I recieved this a.m.
> > It clearly
> > shows ...
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Spam spam spam spam ... to coin a phrase
Posted by Danny Angus <da...@thought.co.uk>.
PS This makes me look like the kind of sad geek who reads the headers of his
spam, God preserve me from myself!
d.
> -----Original Message-----
> From: Danny Angus [mailto:danny@thought.co.uk]
> Sent: 29 March 2002 09:33
> To: James Developers List
> Subject: Spam spam spam spam ... to coin a phrase
>
>
> Paul,
>
> Here's an extract from a header from a spam I recieved this a.m.
> It clearly
> shows ...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Spam spam spam spam ... to coin a phrase
Posted by Danny Angus <da...@thought.co.uk>.
Paul,
Here's an extract from a header from a spam I recieved this a.m. It clearly
shows how the information describing each host it passed through has not
been verified, (each line ought to receive from the recipient of the line
below) and no action has been taken to block this mail where names and
addresses don't match.
What I think is important is that the IP address of the top entry is an open
relay, and the lower ones dont accept connections on port 25 at all. Which
suggests to me that this is a live example of the scenario you set out a few
days ago.
I should also point out that it is also clear from a little research that
this is not connected at all with Edinburgh University (ed.ac.uk) whos name
has been used maliciously by the spammer.
Received: from ed.ac.uk ([194.172.112.34])
by mx0.dircon.net (8.9.1.Dirconised/8.9.1) with SMTP id AAA13183
for <da...@thought.co.uk>; Fri, 29 Mar 2002 00:59:01 GMT
Received: from unknown (HELO rly-xr02.nikavo.net) (127.38.79.237)
by symail.kustanai.co.kr with SMTP; 28 Mar 2002 15:00:03 -0300
Received: from smtp013.mail.yahou.com ([211.199.191.200])
by rly-xr01.nihuyatut.net with local; 28 Mar 2002 11:55:00 +0100
Received: from unknown (HELO rly-xw01.otpalo.com) (132.118.28.155)
by n7.groups.huyahoo.com with asmtp; Thu, 28 Mar 2002 12:49:57 +1100
Received: from unknown (HELO q4.quickslow.com) (176.200.210.157)
by web.mail.halfeye.com with smtp; Thu, 28 Mar 2002 23:44:54 +0100
This mail would not have got to me had the open relay been closed, or if it
had verified the Recieved headers for internal consistency, without recourse
to any enhanced SMTP functionality, or network services of any kind (DNS
etc).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3 (ORBZ.org)
Posted by Paul Hammant <Pa...@yahoo.com>.
Serge,
>> * If an ORG like ORBZ.org chooses to query that instead of trying to
>> Spam then they are not in breack of any anti-hacker legislation. *
>> Mail servers recieving mail (and are unsure of origin), can
>> immediately reach back in a new connection and post a RUOR query.
>> The policy of the recipient can be to a) trust the response, b) refer
>> to a compiled by
>
>
> I think this is my gripe about this approach... why in the world would
> I trust the response? I don't see how this approaches creates any
> technical barriers, or legal and economic disincentives to spam.
That is true, but it illustrates at least a version of RFC compatability
that the mail server maker has implemented.
How often is the case that someone mounting a SMTP cooses to make it
vulnerable to spamming? Not often I'd say. It is because the
administrator has used old software, and accepts the defaults on
install. Given the amount of misery they reap after hosting spammers it
is difficult to imagine a mail administrator choosing to make it repoond
'no' when 'yes' is more accurate.
It is a proposition that allows mail servers to determine how smart the
remote mail server's mail administrator is, having just recieved email
from it. A way that is standards compliant, and cannot possiblly be
construed as a hack attempt. A way that allows a policy of not
accepting mail from any server that answers anything other than no to
RUOR.
If solutions are left to probing of mail servers to gather information
*only*, then those doing the probing will find their lives increasingly
difficult since DMCA and other laws.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SPAM #3 (ORBZ.org)
Posted by Danny Angus <da...@thought.co.uk>.
> I think this is my gripe about this approach... why in the world would I
> trust the response?
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3 (ORBZ.org)
Posted by Serge Knystautas <se...@lokitech.com>.
Paul Hammant wrote:
> * If an ORG like ORBZ.org chooses to query that instead of trying to
> Spam then they are not in breack of any anti-hacker legislation. * Mail
> servers recieving mail (and are unsure of origin), can immediately reach
> back in a new connection and post a RUOR query. The policy of the
> recipient can be to a) trust the response, b) refer to a compiled by
I think this is my gripe about this approach... why in the world would I
trust the response? I don't see how this approaches creates any
technical barriers, or legal and economic disincentives to spam.
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3 (ORBZ.org)
Posted by Paul Hammant <Pa...@yahoo.com>.
Serge,
> So, it is a violation of their privacy policy to reveal who asked for
> the intrusive test, but it's not a violation to do the intrusive test
> or publish the results for anyone to see... If something is this
> non-sensical, I generally assume it was the work of lawyers.
>
> On a related note, James out of the box checks 3 blacklists (MAPS,
> ORBL, and ORDB I think), and I found a nice quick list of blacklists
> and other useful anti-spam info here: http://www.rahul.net/falk/ We
> should probably add an anti-spam page to the James site to capture
> useful info and otherwise track useful advice.
OK, Here is something more concrete as a suggestion:
Proposed via RFC, a new SMTP command -> "RUOR" (Are You Open Relay).
If the server does not understand that query, or the server answers
"yes" as opposed to "no", then the machine is potentially open relay.
If this is an RFC, then Lotus, MS etc will implement it and at that
magic point choose to change the defaults on their installations.
* If an ORG like ORBZ.org chooses to query that instead of trying to
Spam then they are not in breack of any anti-hacker legislation.
* Mail servers recieving mail (and are unsure of origin), can
immediately reach back in a new connection and post a RUOR query. The
policy of the recipient can be to a) trust the response, b) refer to a
compiled by abuse blacklist, c) discard all mail from the non-RUOR
compatible mail server. That is up to the policy of the sysop.
* Companies can be compelled by law, or ISP contract to migrate to RUOR
compatible products and to not reply "no" when "yes" is the truth.
Just the first part of the anti-spam RFC?
- Paul
BTW :- Have you folks seen http://eob.sourceforge.net/ ? It is a
Phoenix using app.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SPAM #3 (ORBZ.org)
Posted by Danny Angus <da...@thought.co.uk>.
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: 23 March 2002 00:03
> To: James Developers List
> Subject: Re: SPAM #3 (ORBZ.org)
>
>
> So, it is a violation of their privacy policy to reveal who asked for
> the intrusive test, but it's not a violation to do the intrusive test or
> publish the results for anyone to see... If something is this
> non-sensical, I generally assume it was the work of lawyers.
>
> On a related note, James out of the box checks 3 blacklists (MAPS, ORBL,
> and ORDB I think), and I found a nice quick list of blacklists and other
> useful anti-spam info here: http://www.rahul.net/falk/ We should
> probably add an anti-spam page to the James site to capture useful info
> and otherwise track useful advice.
+1
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3 (ORBZ.org)
Posted by Serge Knystautas <se...@lokitech.com>.
So, it is a violation of their privacy policy to reveal who asked for
the intrusive test, but it's not a violation to do the intrusive test or
publish the results for anyone to see... If something is this
non-sensical, I generally assume it was the work of lawyers.
On a related note, James out of the box checks 3 blacklists (MAPS, ORBL,
and ORDB I think), and I found a nice quick list of blacklists and other
useful anti-spam info here: http://www.rahul.net/falk/ We should
probably add an anti-spam page to the James site to capture useful info
and otherwise track useful advice.
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Harmeet Bedi wrote:
> ----- Original Message -----
> From: "Paul Hammant" <Pa...@yahoo.com>
>
>>Folks,
>> http://www.theregister.co.uk/content/6/24544.html
>>
>>Were they trying to use spamming techniques to compile a list of failing
>>mail servers? And this in breach of DMCA or and hacking legislation?
>> If there were a RFC ilustrating "HELO, RU-AN-OPEN-RELAY, THNX, BYE" ,
>>then it might not have gone to court/lawyers.
>>
>
>
> Their approach seems to be that SMTP is abused, let us compile a list of
> servers that can be abused. In some sense it is a public service, but to me
> it is a bit like, let us collect information on vulnerable machines by
> exploiting the vulnerabilitues and then as a public service, publish the
> list of machines. Seems like an odd approach, but maybe an effective one to
> fight against spam.
>
> I detected their probes on my mail server in January. Attaching the
> conversation. You may find it interesting.
>
> Harmeet
>
> ----------------------------------------------------------------
> From: "ORDB.org" <or...@ordb.org>
> To: Harmeet <ha...@kodemuse.com>
> Cc: ordb@ordb.org
> Subject: Re: [ORDB] Feedback from ORDB (2950991451725002474)
>
> On Sun, Jan 20, 2002 at 01:24:14AM +0100, Harmeet wrote:
>
>>Some has requested Open relay test on my mail server running at
>>63.194.82.242.
>>
>>Your database indicates that it is 12.231.2.113. This is causing your
>>system to ping my server and consuming some processing cycles on my
>>machine.
>>
>>This raises a few questions
>>1. You are using my resources without my knowledge or permission. That is
>>not nice, but ok, because you seem benign and are trying to help.
>
>
> Thanks.
>
>
>>2. Who is trying to know about my system ? You should disclose the email
>>address to me.
>
>
> Unfortunately we can't, since that would be violating our privacy policy.
>
>
>>3. Your system seems to be an open relay of traffic. Basically anyone can
>>request probe on another system, with checking for credentials. This may
>>generate unwellcome traffic.
>
>
> Correct. That is how we expand the size of our database.
>
> --
> ORDB.org support /boll
>
> If you appreciate the work done by ORDB, please leave a donation at
> http://ordb.org/donate/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3 (ORBZ.org)
Posted by Harmeet Bedi <ha...@kodemuse.com>.
----- Original Message -----
From: "Paul Hammant" <Pa...@yahoo.com>
> Folks,
> http://www.theregister.co.uk/content/6/24544.html
>
> Were they trying to use spamming techniques to compile a list of failing
> mail servers? And this in breach of DMCA or and hacking legislation?
> If there were a RFC ilustrating "HELO, RU-AN-OPEN-RELAY, THNX, BYE" ,
> then it might not have gone to court/lawyers.
>
Their approach seems to be that SMTP is abused, let us compile a list of
servers that can be abused. In some sense it is a public service, but to me
it is a bit like, let us collect information on vulnerable machines by
exploiting the vulnerabilitues and then as a public service, publish the
list of machines. Seems like an odd approach, but maybe an effective one to
fight against spam.
I detected their probes on my mail server in January. Attaching the
conversation. You may find it interesting.
Harmeet
----------------------------------------------------------------
From: "ORDB.org" <or...@ordb.org>
To: Harmeet <ha...@kodemuse.com>
Cc: ordb@ordb.org
Subject: Re: [ORDB] Feedback from ORDB (2950991451725002474)
On Sun, Jan 20, 2002 at 01:24:14AM +0100, Harmeet wrote:
> Some has requested Open relay test on my mail server running at
> 63.194.82.242.
>
> Your database indicates that it is 12.231.2.113. This is causing your
> system to ping my server and consuming some processing cycles on my
> machine.
>
> This raises a few questions
> 1. You are using my resources without my knowledge or permission. That is
> not nice, but ok, because you seem benign and are trying to help.
Thanks.
> 2. Who is trying to know about my system ? You should disclose the email
> address to me.
Unfortunately we can't, since that would be violating our privacy policy.
> 3. Your system seems to be an open relay of traffic. Basically anyone can
> request probe on another system, with checking for credentials. This may
> generate unwellcome traffic.
Correct. That is how we expand the size of our database.
--
ORDB.org support /boll
If you appreciate the work done by ORDB, please leave a donation at
http://ordb.org/donate/
----------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3 (ORBZ.org)
Posted by Paul Hammant <Pa...@yahoo.com>.
Folks,
http://www.theregister.co.uk/content/6/24544.html
Were they trying to use spamming techniques to compile a list of failing
mail servers? And this in breach of DMCA or and hacking legislation?
If there were a RFC ilustrating "HELO, RU-AN-OPEN-RELAY, THNX, BYE" ,
then it might not have gone to court/lawyers.
- Paul
> Danny,
>
>>> Spammers use an openrelay SMTP server to post thru. Let's call that
>>> machine A. They make their headers appear to be from elsewhere. Let's
>>> say that is machine B (it might be real or not). When the mail arrives
>>> at machine C (it's desination), that mail server can see evidence of B
>>> (clearly), but also information pertaining to A? Or is it that only
>>> information from some uplink A connects to is evident?
>>>
>>
>> C should append a line a bit like:
>> "received by C[123.123.123.123] from A[432.432.432.432] at 00:00 GMT
>> +0000"
>>
> You mean ...
>
> B should append a line a bit like:
> "received by B[123.123.123.123] from A[432.432.432.432] at 00:00 GMT
> +0000"
>
>>> If C sends a digest (subject of a new RFC) to B of the message through
>>> SMTP saying "did you send this?", then there are two possibilities -
>>> (1)
>>> The answer is "no I did not", or (2) no such mail server. Does A have
>>> record of the email?
>>>
>>
>> pretty much not, once its sent or bounced the MTA is glad to get rid and
>> reclaim the space.
>>
>>> If it does, can it determine that it was from the
>>> real email user?
>>>
>>
>> Possibly yes depending how tightly it is set up itself to prevent
>> relaying,
>> more likely no, if A has faked a message from a real user of B it
>> would be
>> hard to differentiate from a bona fide one.
>>
> OK, here is a lateral question : How if ServerA receives mail from
> ServerB, how does A determine if B is an open-relay type?
>
> 1) Blacklist (checks IP against table centrally maintained).
> 2) Asks it -> Are you open relay? ( reaches back to Server B in
> seperate connection, caches yes/no response for last 1000 mail servers)
> 3) Other ?
>
> Of course I'm eluding to (2) being part of the new RFC.
>
> - Paul
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SPAM #3
Posted by Danny Angus <da...@thought.co.uk>.
Paul,
Read your own scenario mate ;-)
> >>Spammers use an openrelay SMTP server to post thru. Let's call that
> >>machine A. They make their headers appear to be from elsewhere. Let's
> >>say that is machine B (it might be real or not). When the mail arrives
> >>at machine C (it's desination), that mail server can see evidence of B
> >>(clearly), but also information pertaining to A? Or is it that only
> >>information from some uplink A connects to is evident?
Mail originating at A is received by C purporting to have come from B
Machine C should insert the line denominating the hostname and IP address of
the machine it was connected to when the message arrived, and its own
details (for refrence downstream) and the time in the rfc822 format.
Machine A may have spoofed the line suggesting that it originated at B, and
was passed on by A.
> OK, here is a lateral question : How if ServerA receives mail from
> ServerB, how does A determine if B is an open-relay type?
>From 1st principles you could use the same way spammers do, try to deliver a
message to it addressed to somewhere you know it shouldn't accept mail for
(yourself) and wait for the message to be recieved.
(For your curiosity I've attached such a message from my daily harvest of
tests by spammers of one of our James installations)
> 1) Blacklist (checks IP against table centrally maintained).
+1
> 2) Asks it -> Are you open relay? ( reaches back to Server B in seperate
> connection, caches yes/no response for last 1000 mail servers)
If you are running an open relay through ignorance is there any reason to
trust this response?
If you are doing it through mailce this will be worse than unreliable, it
will be actively misleading, unless there's more to your idea..
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>>Spammers use an openrelay SMTP server to post thru. Let's call that
>>machine A. They make their headers appear to be from elsewhere. Let's
>>say that is machine B (it might be real or not). When the mail arrives
>>at machine C (it's desination), that mail server can see evidence of B
>>(clearly), but also information pertaining to A? Or is it that only
>>information from some uplink A connects to is evident?
>>
>
>C should append a line a bit like:
>"received by C[123.123.123.123] from A[432.432.432.432] at 00:00 GMT +0000"
>
You mean ...
B should append a line a bit like:
"received by B[123.123.123.123] from A[432.432.432.432] at 00:00 GMT +0000"
>>If C sends a digest (subject of a new RFC) to B of the message through
>>SMTP saying "did you send this?", then there are two possibilities - (1)
>>The answer is "no I did not", or (2) no such mail server. Does A have
>>record of the email?
>>
>
>pretty much not, once its sent or bounced the MTA is glad to get rid and
>reclaim the space.
>
>>If it does, can it determine that it was from the
>>real email user?
>>
>
>Possibly yes depending how tightly it is set up itself to prevent relaying,
>more likely no, if A has faked a message from a real user of B it would be
>hard to differentiate from a bona fide one.
>
OK, here is a lateral question : How if ServerA receives mail from
ServerB, how does A determine if B is an open-relay type?
1) Blacklist (checks IP against table centrally maintained).
2) Asks it -> Are you open relay? ( reaches back to Server B in seperate
connection, caches yes/no response for last 1000 mail servers)
3) Other ?
Of course I'm eluding to (2) being part of the new RFC.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SPAM #3
Posted by Danny Angus <da...@thought.co.uk>.
> Spammers use an openrelay SMTP server to post thru. Let's call that
> machine A. They make their headers appear to be from elsewhere. Let's
> say that is machine B (it might be real or not). When the mail arrives
> at machine C (it's desination), that mail server can see evidence of B
> (clearly), but also information pertaining to A? Or is it that only
> information from some uplink A connects to is evident?
C should append a line a bit like:
"received by C[123.123.123.123] from A[432.432.432.432] at 00:00 GMT +0000"
>
> If C sends a digest (subject of a new RFC) to B of the message through
> SMTP saying "did you send this?", then there are two possibilities - (1)
> The answer is "no I did not", or (2) no such mail server. Does A have
> record of the email?
pretty much not, once its sent or bounced the MTA is glad to get rid and
reclaim the space.
> If it does, can it determine that it was from the
> real email user?
Possibly yes depending how tightly it is set up itself to prevent relaying,
more likely no, if A has faked a message from a real user of B it would be
hard to differentiate from a bona fide one.
> Does this cover all the bases?
>
> Hmmm, I have half a feeling that this has been explained to me
> already.....
>
> Regards,
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SPAM #3
Posted by Paul Hammant <Pa...@yahoo.com>.
Question,
Spammers use an openrelay SMTP server to post thru. Let's call that
machine A. They make their headers appear to be from elsewhere. Let's
say that is machine B (it might be real or not). When the mail arrives
at machine C (it's desination), that mail server can see evidence of B
(clearly), but also information pertaining to A? Or is it that only
information from some uplink A connects to is evident?
If C sends a digest (subject of a new RFC) to B of the message through
SMTP saying "did you send this?", then there are two possibilities - (1)
The answer is "no I did not", or (2) no such mail server. Does A have
record of the email? If it does, can it determine that it was from the
real email user? Does this cover all the bases?
Hmmm, I have half a feeling that this has been explained to me already.....
Regards,
- Paul
>My favourite quote was "I'd love to turn off China"
>But the point I get from this is that its the same old open-relay problem it
>ever was, with the twist of faked headers, to stop them being traced.
>And the solution is to educate email sysadmins.
>d.
>
>
>
>>-----Original Message-----
>>From: Paul Hammant [mailto:hammant@apache.org]
>>Sent: 21 March 2002 19:04
>>To: james-dev@jakarta.apache.org
>>Subject: SPAM #3
>>
>>
>>/. -> http://slashdot.org/articles/02/03/21/1733224.shtml?tid=111
>>
>>dosten <ma...@osten.net> sent us a link to a story running on
>>Cnet about the spam epidemic
>><http://news.com.com/2009-1023-864815.html>. My favorite stat is that by
>>2006, we'll be getting 1400 spam a /day/. Of course, I get that every
>>/week/. Talks about foreign spam relays, block lists, and so on. Decent
>>piece explaining a huge problem that's only getting worse.
>>
>>Addendum - 2002 JAMES coders formulate plan for phasing out of
>>unaccountable mail servers and upgrade JAMES itself to be compliant with
>>their new RFC.
>>
>>-PH
>>
>>
>>--
>>To unsubscribe, e-mail:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SPAM #3
Posted by Danny Angus <da...@thought.co.uk>.
My favourite quote was "I'd love to turn off China"
But the point I get from this is that its the same old open-relay problem it
ever was, with the twist of faked headers, to stop them being traced.
And the solution is to educate email sysadmins.
d.
> -----Original Message-----
> From: Paul Hammant [mailto:hammant@apache.org]
> Sent: 21 March 2002 19:04
> To: james-dev@jakarta.apache.org
> Subject: SPAM #3
>
>
> /. -> http://slashdot.org/articles/02/03/21/1733224.shtml?tid=111
>
> dosten <ma...@osten.net> sent us a link to a story running on
> Cnet about the spam epidemic
> <http://news.com.com/2009-1023-864815.html>. My favorite stat is that by
> 2006, we'll be getting 1400 spam a /day/. Of course, I get that every
> /week/. Talks about foreign spam relays, block lists, and so on. Decent
> piece explaining a huge problem that's only getting worse.
>
> Addendum - 2002 JAMES coders formulate plan for phasing out of
> unaccountable mail servers and upgrade JAMES itself to be compliant with
> their new RFC.
>
> -PH
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>