You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@james.apache.org by Miroslav Nachev <mi...@space-comm.com> on 2003/08/06 11:48:15 UTC
SPAM Ideas
Hi,
I am looking for something like that:
1. James will reject the all connections from Mail Servers that are
in the SPAM Server list. This list can be stored in XML or/and
Database, becuase the SPAM Server Database have to be
self-teaching. For example when I recieve some e-mail and I see
that this is a SPAM I will redirect (forward) this message to
the James Server on to service address
"spam-server@mydomain.com". This mail will be served from
service Mailet which will add the Server from which the mail is
received to the SPAM Database List (records).
2. James will reject the all connections from SPAM registered users
that are in the SPAM User List.
The self-teaching mechanism can be the same as previous where
the mail address can be "spam-user@mydomain.com".
I am looking some similar. In case that James doesn't support
similar technology it is good idea for the future releases.
Regards,
Miro.
Re: SPAM Ideas
Posted by Serge Knystautas <se...@lokitech.com>.
James Bucanek wrote:
> I'm a developer, and one thing that I was hoping James could provide was programmatic fast-fail. The reasons listed "for" this feature on the above page seem to miss the most obvious: The ability to return an SMTP error to the sending MTA.
>
> The reason I want this feature is so I can qualify dynamic addresses. I'd like to qualify an address such as <co...@orderprocessing.com> against an algorithm or <vi...@gateway.net> against a dynamic database.
>
> Once the message is accepted, it's impossible to accurately return a bounce message to the sender. Nor can you take advantage of any of the soft or hard bounce processing provided by the sending MTA.
>
> Is this really a James-Dev thread?
This is a great use of James and has nothing to do with fast-fail. When
create the bounce message, the bounce has to go to
confirm-order-id-0123456789@orderprocessing.com. If it didn't, that
would be a bug. You'll see the occasional "I'm on vacation" sent back
to the original poster on listservs, and that's because the mail server
of the person on vacation is buggy (or often the I'm-on-vacation notice
feature).
If the user community came up with some good reasons to add it, it can
move to dev to discuss how to do it, but my point was to explain to the
user community why what they're trying to do doesn't need or relate to
fast-fail, such as the example you've given.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: SPAM Ideas
Posted by "Noel J. Bergman" <no...@devtech.com>.
> one thing that I was hoping James could provide was programmatic
fast-fail.
> The reasons listed "for" this feature on the above page seem to miss the
> most obvious: The ability to return an SMTP error to the sending MTA.
I thought I had listed that; it certainly is one of my reasons. Although a
properly formated (RFC 1894) bounce message works, clients handle protocol
rejection better.
However, your examples sound like a VERP issue.
In any event, if you want to discuss it, server-dev would be the more
appropriate place. And pleas search the archives and wiki for prior
discussion.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: SPAM Ideas
Posted by James Bucanek <su...@gloaming.com>.
Serge Knystautas wrote on Wednesday, August 6, 2003:
>http://nagoya.apache.org/wiki/apachewiki.cgi?NoFastFail
Hi,
First of all, I'm new to the list. I haven't even set up James yet, but I have great plans for it!
I'm a developer, and one thing that I was hoping James could provide was programmatic fast-fail. The reasons listed "for" this feature on the above page seem to miss the most obvious: The ability to return an SMTP error to the sending MTA.
The reason I want this feature is so I can qualify dynamic addresses. I'd like to qualify an address such as <co...@orderprocessing.com> against an algorithm or <vi...@gateway.net> against a dynamic database.
Once the message is accepted, it's impossible to accurately return a bounce message to the sender. Nor can you take advantage of any of the soft or hard bounce processing provided by the sending MTA.
Is this really a James-Dev thread?
______________________________________________________
James Bucanek <ma...@gloaming.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: SPAM Ideas
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>The longer it takes, the more it costs them. Similar notion for
>>spamming... if a spammer has to wait to find an open relay and write
>>extra logic to see if it's found an open relay, then it makes their life
>>harder.
>
> Yes, but outside of so-called "First World" countries, transfer costs money.
> We've had some South American users mention very high rates for traffic, so
> they'd like to kick people of as soon as possible. The same may be true of
> Bulgaria.
>
> For the short term, an effective way to do what they want is to use the same
> approach used to block abusive spiders. You add their IP address to a list
> of rules, and reload the list. It would take about 20 minutes to code the
> thing from start to finish.
Sure, bandwidth cost is the most compeling reason. Meanwhile, I wrote
up the reasons http://nagoya.apache.org/wiki/apachewiki.cgi?NoFastFail
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: SPAM Ideas
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
> When I get a call from a telemarketer, assuming no kids are screaming, I
> try to stay on the phone as long as I can bare, letting them speak their
> full pitch.
> The longer it takes, the more it costs them. Similar notion for
> spamming... if a spammer has to wait to find an open relay and write
> extra logic to see if it's found an open relay, then it makes their life
> harder.
Yes, but outside of so-called "First World" countries, transfer costs money.
We've had some South American users mention very high rates for traffic, so
they'd like to kick people of as soon as possible. The same may be true of
Bulgaria.
For the short term, an effective way to do what they want is to use the same
approach used to block abusive spiders. You add their IP address to a list
of rules, and reload the list. It would take about 20 minutes to code the
thing from start to finish.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: SPAM Ideas
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>> 1. James will reject the all connections from Mail Servers that are
>> in the SPAM Server list.
>
> If you insist on rejecting by IP today, you can have your mailet add the IP
> address to a list, and use ipchains or iptables to block that IP address.
> However, as noted in the above commentary, that is a violation of
> RFC2821/4.5.1, since you are preventing e-mail to the postmaster address.
> It is possibly a sufficient violation to get you block listed on
> rfc-ignorant.org.
When I get a call from a telemarketer, assuming no kids are screaming, I
try to stay on the phone as long as I can bare, letting them speak their
full pitch. I've gotten quite good at saying "uh huh", "yeah", "no"
until they want to take personal info or a signature, and then I just
hang up.
The longer it takes, the more it costs them. Similar notion for
spamming... if a spammer has to wait to find an open relay and write
extra logic to see if it's found an open relay, then it makes their life
harder.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
RE: SPAM Ideas
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 1. James will reject the all connections from Mail Servers that are
> in the SPAM Server list.
At some point, I or someone else will do more with the fast-fail filters.
See the 'Protocol-based "fast-fail"' section of
http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/Plans
If you insist on rejecting by IP today, you can have your mailet add the IP
address to a list, and use ipchains or iptables to block that IP address.
However, as noted in the above commentary, that is a violation of
RFC2821/4.5.1, since you are preventing e-mail to the postmaster address.
It is possibly a sufficient violation to get you block listed on
rfc-ignorant.org.
> 2. James will reject the all connections from SPAM registered users
Again, this would be a fast-fail filter on the MAIL FROM command. Not hard
to do, but easily bypassed. See the "What about allowing developers to
process messages during the SMTP session?" topic here:
http://nagoya.apache.org/wiki/apachewiki.cgi?JamesDocumentationNotes.
Meanwhile, James already has both of these facilities in the mailet
pipeline.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org