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 "Noel J. Bergman" <no...@devtech.com> on 2003/05/21 07:04:01 UTC
Test version for
In http://jakarta.apache.org/builds/jakarta-james/nightly/bin/ is an
unlabeled test build that matches the current CVS.
This build adds support for a new <authorizedAddresses> element in the SMTP
handler section. This element takes a comma separated list of addresses
(probably the same list that you currently have on your
RemoteAddrNotInNetwork matcher). When using SMTP AUTH, connections from
addresses defined in <authorizedAddresses> will be not be subject to SMTP
AUTH. In fact, you will be able to tell via telnet because you won't even
see the SMTP AUTH decorations.
Note, however, that although this will reject addresses such as
frodo@theshire.uk, it will not immediately reject addresses such as
gandalf%isengard.uk@bree.uk. Those are valid localparts, and we cannot
validate local addresses in the handler. One major reason for this in James
v2 is that virtual user tables and other valid names are not present in any
user repository structure. I would expect that to change in James v3.
Authorized addresses can be specified in any of several ways:
- IP address, e.g., 127.0.0.1
- FQDN, e.g., www.apache.org
- network/netmask, e.g., 192.168.0.0/255.255.0.0
- wildcard notation, e.g., 192.168.*
- network/bits, e.g., 192.168.0.0/16
Anywhere that an IP address appears, an FQDN can be substituted, e.g.,
mydomain.tld/27.
NOTE: *NO* addresses are defaulted into the list. My current test system
has:
<authorizedAddresses>127.0.0.0/8,192.168.0.0/16</authorizedAddresses>
Please let me know of any questions, problems, issues, disagreements, etc.
:-) Have fun, but remember: this is ONLY an unreleased test.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Protocol Handler-based rejection
Posted by Serge Knystautas <se...@lokitech.com>.
Hontvari Jozsef wrote:
> Me too. You can believe that I am still very angry. Every 5 minutes somebody
> tried to register with an AOL address.
> But can we force them to behave in a reasonable way? We can't.
Don't feel too bad. :) Here's an interesting report that estimates how
much legitimate spam is getting blocked by some of the major commercial
providers.
http://www.imakenews.com/emailresults/e_article000129752.cfm?x=a1qkGjj,aMNG4\YV
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Every 5 minutes somebody tried to register with an AOL address.
A very high percentage of the spam coming through my system has an @aol.com
address, but the remoteIP is not an AOL server. Apparently, it is a
popularly spoofed domain.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Protocol Handler-based rejection
Posted by Hontvari Jozsef <ho...@solware.com>.
> I don't think I'd be keen to use it. % is a legitimate character in a
> localpart.
Me too. You can believe that I am still very angry. Every 5 minutes somebody
tried to register with an AOL address.
But can we force them to behave in a reasonable way? We can't.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Thursday, May 22, 2003 1:07 AM
Subject: RE: Protocol Handler-based rejection
> > I have a patch for this, it refuses recipient addresses containing %
> > character.
>
> I don't think I'd be keen to use it. % is a legitimate character in a
> localpart.
>
> If AOL is blocking you because you allow a localpart formatted that way,
> they are not in compliance with the RFC. I'd agree with Danny, and raise
an
> issue about it. Please note that unless Microsoft Exchange has changed,
> they too accept those addresses, too, although they apparently will
generate
> a bounce notification after the fact.
>
> > AOL runs its dumb test each day. Tomorrow I will see the result.
>
> Let us know how it goes. AOL hasn't bothered with my server, yet. Which
is
> interesting, since I run a mailing list with more than a few AOL members
on
> it.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I have a patch for this, it refuses recipient addresses containing %
> character.
I don't think I'd be keen to use it. % is a legitimate character in a
localpart.
If AOL is blocking you because you allow a localpart formatted that way,
they are not in compliance with the RFC. I'd agree with Danny, and raise an
issue about it. Please note that unless Microsoft Exchange has changed,
they too accept those addresses, too, although they apparently will generate
a bounce notification after the fact.
> AOL runs its dumb test each day. Tomorrow I will see the result.
Let us know how it goes. AOL hasn't bothered with my server, yet. Which is
interesting, since I run a mailing list with more than a few AOL members on
it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Protocol Handler-based rejection
Posted by Hontvari Jozsef <ho...@solware.com>.
> > Anybody have some information what is the meaning of addresses like
> > gandalf%isengard.uk@bree.uk
> > and why AOL don't like it?
I have a patch for this, it refuses recipient addresses containing %
character. AOL runs its dumb test each day. Tomorrow I will see the result.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Wednesday, May 21, 2003 4:34 PM
Subject: RE: Protocol Handler-based rejection
> [Collected comments from the AOL Blocking James and related threads]
>
> Hontvari Jozsef asked:
> > Anybody have some information what is the meaning of addresses like
> > gandalf%isengard.uk@bree.uk
> > and why AOL don't like it?
>
> It is an anachronism.
>
> See: http://support.microsoft.com/?kbid=304897
>
> Danny Angus opined:
> > I think there is agreement that some 5xx errors should be
> > generated up front
>
> The new patch I submitted should help.
>
> Now that we have the equivalent of RemoteAddrInNetwork accessible in the
> SMTP handler, we could consider using that feature, combined with the
> localServers check, on all messages to implement fast-fail for relay
> requests.
>
> > AOL's ignorant half-arsed arrogance is not alone a good enough reason.
>
> According to the Microsoft document (above), Microsoft's own mail server
> does the same type of delayed processing as James, and for similar
reasons.
>
> > All of the recognised relay testing services accept the blackhole
> > approach to spam, and in fact many commercial firewalls which
> > incorporate SMTP proxying also behave as blackholes.
>
> Jason Webb replied:
> > If the team agree that upfront rejection is required/useful then
> > I'd be more than happy to help write it.
>
> Danny, myself, and others all agree that getting rid of spammers as aoon
as
> possible is a good and reasonable policy. The question is how much to do
in
> the fast-fail filters.
>
> The test version takes advantage of the fact that using SMTP AUTH in the
> code already does fast-fail denial for unauthenticated relay requests.
The
> effect of the <authorizedAddresses> patch is to force SMTP AUTH for
> non-authorized addresses (thus denying them relay permission), and to
allow
> authorized addresses to relay without going through SMTP AUTH.
>
> As I've suggested, another step could be to add isLocalServer (really
> "isLocalDomain") processing into the non-SMTP AUTH path, so that all
> relaying is denied. That would be combined with an extension of the
> <authorizedAddresses> feature so that authorized addresses are permitted
to
> relay. That effectively deprecates the common use of the RemoteAddr*
> matchers.
>
> Beyond that, the IpFilter mechanism previously mentioned would allow
DNSRBL
> behavior to be added as a fast-fail mode.
>
> Are you (a) willing to help work on any of these, and (b) what other
> fast-fail checks to you recommend?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'd like to leave the users with [two] options:
> 1) You want the current behaviour left as-is (silent spam rejection)
> 2) You want 5xx rejection
> I'd probably recommend that option 2 is the default
I believe that we could change the default configuration to specify
fast-fail (5xx) rejection. However, for compatibility with existing
config.xml files, James v2 *code* should default to the current behavior.
> > Beyond that, the IpFilter mechanism previously mentioned
> > would allow DNSRBL behavior to be added as a fast-fail mode.
> I'd like to think very carefully about this as it could have
> performance implications.
No kidding! However, I thought that you were in favor of doing that type of
fast-fail. Also, if you read james-user, you'll see a comment from
yesterday regarding the cost of bandwidth in Brazil, and why that encourages
being able to reject without having to accept traffic.
One of my thoughts related to IP-based rejection was to have a Mailet that
would take the IP address of the sender, do the standard reversal, and add
it to a local DNS zone. My reasoning was that (a) a DNS is likely to be
highly optimized, (b) we would be able to reuse an existing mechanism
familar to many e-mail admins. The DNS zone and TXT record would be used to
provide fine grained control, e.g., 127.255.255.255 might be a whitelist,
127.255.255.254 might be the outright rejection zone. But I would not want
to be doing this sort of check for multiple DNS servers at connection time.
In any event, there are various types of IP filters, and I agree that it
should all be optional and configurable.
I did benchmark the NetMatcher. If you look at the original version of the
code in CVS, you will see the benchmark code. I even benchmarked the
difference between matching against an InetAddress, IP formatted String, and
domain name, e.g.,
Took: 0.003825ms to match /127.0.0.1
Took: 0.008262ms to match 127.0.0.1
Took: 0.009194ms to match 127.0.0.1
----
Took: 0.018096ms to reject /192.168.1.10
Took: 0.021942ms to reject 192.168.1.10
Took: 0.023063ms to reject 192.168.1.10
----
Took: 0.006449ms to match mail.devtech.com/66.112.202.2
Took: 0.012017ms to match 66.112.202.2
Took: 0.0206ms to match mail.devtech.com
Those are measured on a 366mhz PII running JVM 1.4 (JVM 1.3 would be
somewhat slower). The matching algorithm is linear with the number of
network definitions, but I don't expect there to be a large number of
definitions.
Now that there is a bit more overhead in checking authorization status, I
have got a patch I'll submit in a bit that does the check only once per
connection, rather than repeatedly as was in the code previously. So the
network matching check would be done once per connection.
> > Are you (a) willing to help work on any of these, and (b)
> > what other fast-fail checks to you recommend?
> (a) Absolutely!
Care to be more specific? :-)
> (b) The isLocalDomain would be the easiest and most sensible to
> implement as James has some of that info already.
I concur.
For what it is worth, the actual name is isLocalServer, and is tied into the
<servernames> elements in config.xml. I actually have an isLocalDomain
method that is not present in the CVS. It uses the DNS to dynamically
discover domains whose MX records point to the James server's IP address.
That information is dynamically cached, including negative results. The
issue is to be able to distinguish between domains for whom we accept mail,
and those for whom we store mail. In James v2, those two notions are
intermingled, which actually makes some configurations (e.g, secondary mail
servers) more complex than necessary.
At the moment, I have no plans to add this code to James v2.
> if people are happy with this approach I'd come up with a
> proposal to say what would go where, and when a rejection
> would occur
Please do. I am fairly confident that I know how to affect this change, but
I'd like to see your comments, and make sure that we're thinking the same
things.
> I'd also like to see the RemoteAddr remain
Absolutely. Wasn't a question.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Protocol Handler-based rejection
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Sorry, I didn't know of 421 and 554. Having read them, I don't know why
> we would support them.
>
> Because it isn't hard, and provides additional options to the e-mail admin?
>
>>if you send these, you have to keep the connection open and continue to
>>accept commands and return 503 until you get a QUIT.
>
> I'd thought of that, but it is easy to catch at the top of the loop.
In my assumptions of why you would immediately not accept a connection
before any communication (something based solely on IP address or
excessive message rate delivery), very rarely did I care what tailored
message I sent the user (not that they ever read those), and I would
expect you'd want to kill the connections immediately, not wait for a
QUIT. I find the fact that other mail servers do this rather than send
421 evidence that they agree with my use-cases, not that they are too
lazy to provide useful error messages (although that argument could be
made).
Also, I read 421 as for a server that's shutting down. It's a valid
alternative to the 220 greeting, but I read this more because it's valid
at all states (no matter where you are in the protocol, you need to tell
the remote connection you're shutting down). We might want to think
about hooking the shutdown code into the SMTP handler to adopt this notion.
>>What is the deal with this ProtocolResponse class name? These are two
>>very different functions. One addresses a TCP connect request and one
>>is a SMTP command reply.
>
> The "ProtocolResponse" class would be used for returning a [code,
> text]-tuple. It fills the role that you had referred to as a "struct-like"
> class.
Sorry, was cranky with my note and understood your name. I meant I
think you're trying to force fit some inappropriate API and as a result
providing too much information and control in one situation, and not
enough in the other.
We're discussing these two stages, but you're naming and arguments
suggest this is something we be able to insert in ANY protocol response.
I believe you would find this unworkable by examining other cases, as
to generalize to this extreme would be significantly less useful.
I think the choices of where we support hooks are deliberate:
- We want to accept/reject TCP connects because we have a remote server
that's pounding us, it is not in the network we like, or is otherwise a
specific user we want to block or allow.
- We want to accept/reject RCPT specified email addresses because at
this point we will know whether this is someone who is authenticated,
and whether this is someone sending inside-inside, inside-outside,
outside-inside, or outside-outside.
Adding something at MAIL FROM would only tell us "from inside or
outside", not the flow. Adding something after DATA would a) not help
us avoid message traffic b) lead to more complex processing that should
be handled asynchronously (ie., mailets). SMTP AUTH should be
extensible via a account mgmt interface, not via individual protocol
response handlers. Other commands just get much less use and have less
value to expose through an API.
> Because it would make writing these filters more complicated, and less
> modular? My preference is towards smaller bits of specific functionality.
Instead of a very restricted API, why not just provide specific
configuration options for the couple of expected restrictions? What is
less modular about providing more information to this RCPT handler?
Finally, I have to take back the suggested returns. It's much more
complicated than that...
- for accept/reject connections, you might have a specific spammer you
want to always block, and you might have a static IP address DSL home
user you want to always allow. You can't simply AND or OR a bunch of
boolean responses together.
- for accept/reject recipient address, you have similar notions as
above... specific spammers you want to always block, email addresses you
might always want to allow.
Not sure what's the best way to handle these situations.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Sorry, I didn't know of 421 and 554. Having read them, I don't know why
> we would support them.
Because it isn't hard, and provides additional options to the e-mail admin?
> if you send these, you have to keep the connection open and continue to
> accept commands and return 503 until you get a QUIT.
I'd thought of that, but it is easy to catch at the top of the loop.
> What is the deal with this ProtocolResponse class name? These are two
> very different functions. One addresses a TCP connect request and one
> is a SMTP command reply.
The "ProtocolResponse" class would be used for returning a [code,
text]-tuple. It fills the role that you had referred to as a "struct-like"
class.
> > I'm just not sure why acceptRecipient needs to know anything more
> > than the address. For example, it isn't responsible for SMTP AUTH.
> Err, why not?
Because it would make writing these filters more complicated, and less
modular? My preference is towards smaller bits of specific functionality.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Protocol Handler-based rejection
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> That approach doesn't allow the server to return a 421 or (more importantly)
> a 554 reply, e.g.,
>
> 421 - SMTP service temporarily unavailable.
> 554 - SMTP service denied due to block list; see: <text>
>
> The 554 isn't in RFC 821; it was added in RFC 2821. In any event, that's
> why I'd thought to use a ProtocolResponse object, so that the failure reason
> could be reported.
Sorry, I didn't know of 421 and 554. Having read them, I don't know why
we would support them. Sendmail and other mail servers I'm familiar
with just immediately disconnect with no output. Both commands are just
listed as "may" be used. Once more, if you send these, you have to keep
the connection open and continue to accept commands and return 503 until
you get a QUIT. This seems counter to the point of this feature.
> I absolutely agree with this, which is why I had proposed the
> ProtocolResponse class, which would be the return value.
What is the deal with this ProtocolResponse class name? These are two
very different functions. One addresses a TCP connect request and one
is a SMTP command reply.
> Right. I'm just not sure why acceptRecipient needs to know anything more
> than the address. For example, it isn't responsible for SMTP AUTH. That is
> something else.
Err, why not?
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
> a) acceptConnection() happens between accepting the socket and sending
> EHLO/HELO. This has to be a boolean because you either disconnect
> immediately or accept the connection and send EHLO/HELO.
That approach doesn't allow the server to return a 421 or (more importantly)
a 554 reply, e.g.,
421 - SMTP service temporarily unavailable.
554 - SMTP service denied due to block list; see: <text>
The 554 isn't in RFC 821; it was added in RFC 2821. In any event, that's
why I'd thought to use a ProtocolResponse object, so that the failure reason
could be reported.
> b) acceptRecipient() happens between receiving a RCPT TO command and
> sending the response. This has to be a int code and String message
> because that's what SMTP's protocol requires back. We might return a
> boolean, but it seems important to return the specific error code.
I absolutely agree with this, which is why I had proposed the
ProtocolResponse class, which would be the return value.
> To me this is an API where you can list classes that implement each of
> these handlers for each of these accept situations. As these events
> happen, these classes have the appropriate method called.
Seems reasonable.
> For acceptRecipients, the results would be constants (for most cases),
> and as long as the result was positive, it would flow through to the
> next. The first non-positive response would get spit out to the
> connection and the RCPT TO command failed.
Right. I'm just not sure why acceptRecipient needs to know anything more
than the address. For example, it isn't responsible for SMTP AUTH. That is
something else.
> Hmmm, from my perspective, this API would replace nothing we already do
> as we have historically had no fast-fail capabilities (aside from what's
> just been added).
Agreed. The thing that threw me in your reply was the comment about
acceptRecient needing additional context.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Protocol Handler-based rejection
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Why would they be different? acceptConnection() could be backed by a
> DNSRBL, for example, and would want to return the TXT record explaining the
> reason for the block. At least that was my consideration.
Here's where I said I expected these listeners would go as we don't seem
to be on similar pages.
a) acceptConnection() happens between accepting the socket and sending
EHLO/HELO. This has to be a boolean because you either disconnect
immediately or accept the connection and send EHLO/HELO.
b) acceptRecipient() happens between receiving a RCPT TO command and
sending the response. This has to be a int code and String message
because that's what SMTP's protocol requires back. We might return a
boolean, but it seems important to return the specific error code. We
might return just an int error code, but it seems helpful to optionally
let a developer give a more tailored error message.
> Your comments related to acceptRecipient are interesting. It sounds as if
> you interpreted it as being a single call that would handle all cases
> related to RCPT TO.
I don't understand what you think I'm saying. :) To me this is an API
where you can list classes that implement each of these handlers for
each of these accept situations. As these events happen, these classes
have the appropriate method called.
For acceptRecipients, the results would be constants (for most cases),
and as long as the result was positive, it would flow through to the
next. The first non-positive response would get spit out to the
connection and the RCPT TO command failed.
> I had figured that we already had code to check for
> everything except for evaluating the recipient string, so I was just
> supplementing what we already had, rather than replace doRCPT(). I don't
> believe that a single method for checking all conditions would be as
> flexible.
Hmmm, from my perspective, this API would replace nothing we already do
as we have historically had no fast-fail capabilities (aside from what's
just been added).
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
Why would they be different? acceptConnection() could be backed by a
DNSRBL, for example, and would want to return the TXT record explaining the
reason for the block. At least that was my consideration.
Your comments related to acceptRecipient are interesting. It sounds as if
you interpreted it as being a single call that would handle all cases
related to RCPT TO. I had figured that we already had code to check for
everything except for evaluating the recipient string, so I was just
supplementing what we already had, rather than replace doRCPT(). I don't
believe that a single method for checking all conditions would be as
flexible.
Thoughts?
ProtocolResponse could have final int values for protocol responses,
although those probably ought to be in ProtocolResponse subclasses because
they aren't identical across the various protocols.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Tuesday, May 27, 2003 16:39
To: James Developers List
Subject: Re: Protocol Handler-based rejection
I would think these are two different interfaces:
- acceptConnection() could know nothing but an IP address. And I would
see it returning a boolean. This would happen between accepting the
connection and print the HELO/EHLO message.
- acceptRecipient() could know the remote IP address, the send email
address, the SMTP session authentication info (if available), and
whatever else that could be garnered from the SMTP session to date.
This would likely need to return both a error code (550 etc) and a text
message explaining why. What about a struct-like class with these 2
fields, and then a bunch of constant values. (OK is 200, 550 is a
stanard rejection, and whatever else). The user could then return
custom error message if wanted, but otherwise James would it. This
would happen between RCPT TO from the client and defines the message we
send back to the server.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
Noel J. Bergman wrote:
> What I have in mind is a ProtocolResponse class that looks like:
>
> class ProtocolResponse {
> int code;
> String text;
> }
>
> The filter methods would return null if there is no error, or a
> ProtocolResponse. That is ALL that we would permit. No mailets in the
> protocol handler. This is strictly a means to handle protocol responses.
I
> had originally call the class ProtocolError, but it occurs to me that a
> commandmap-based protocol handler could use this generally.
>
> Two new methods would be:
>
> - IP based service check
> ProtocolResponse acceptConnection(String remoteIP);
>
> this is probably the correct way to deal with DNSRBL
> if you don't want to provide any service, rather than
> reject RCPT TO commands, immediately provide a 554.
>
>
> - RCPT TO checking
> ProtocolResponse acceptRecipient(String recipient);
>
> Those would complement the filtering we already support via internal
> mechanisms:
>
> - maximum message size
> - IP based relay denied
> - SMTP AUTH based relay denied
>
> Again, this is not to replace the matcher/mailet pipeline. It is strictly
a
> means to control protocol response to protocol commands. If we like how
> this approach turns out, then we can consider using it more generically in
> later revisions to the handler, and in other protocol handlers.
>
> Thoughts, suggestions, flames?
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Protocol Handler-based rejection
Posted by Serge Knystautas <se...@lokitech.com>.
I would think these are two different interfaces:
- acceptConnection() could know nothing but an IP address. And I would
see it returning a boolean. This would happen between accepting the
connection and print the HELO/EHLO message.
- acceptRecipient() could know the remote IP address, the send email
address, the SMTP session authentication info (if available), and
whatever else that could be garnered from the SMTP session to date.
This would likely need to return both a error code (550 etc) and a text
message explaining why. What about a struct-like class with these 2
fields, and then a bunch of constant values. (OK is 200, 550 is a
stanard rejection, and whatever else). The user could then return
custom error message if wanted, but otherwise James would it. This
would happen between RCPT TO from the client and defines the message we
send back to the server.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
Noel J. Bergman wrote:
> What I have in mind is a ProtocolResponse class that looks like:
>
> class ProtocolResponse {
> int code;
> String text;
> }
>
> The filter methods would return null if there is no error, or a
> ProtocolResponse. That is ALL that we would permit. No mailets in the
> protocol handler. This is strictly a means to handle protocol responses. I
> had originally call the class ProtocolError, but it occurs to me that a
> commandmap-based protocol handler could use this generally.
>
> Two new methods would be:
>
> - IP based service check
> ProtocolResponse acceptConnection(String remoteIP);
>
> this is probably the correct way to deal with DNSRBL
> if you don't want to provide any service, rather than
> reject RCPT TO commands, immediately provide a 554.
>
>
> - RCPT TO checking
> ProtocolResponse acceptRecipient(String recipient);
>
> Those would complement the filtering we already support via internal
> mechanisms:
>
> - maximum message size
> - IP based relay denied
> - SMTP AUTH based relay denied
>
> Again, this is not to replace the matcher/mailet pipeline. It is strictly a
> means to control protocol response to protocol commands. If we like how
> this approach turns out, then we can consider using it more generically in
> later revisions to the handler, and in other protocol handlers.
>
> Thoughts, suggestions, flames?
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
What I have in mind is a ProtocolResponse class that looks like:
class ProtocolResponse {
int code;
String text;
}
The filter methods would return null if there is no error, or a
ProtocolResponse. That is ALL that we would permit. No mailets in the
protocol handler. This is strictly a means to handle protocol responses. I
had originally call the class ProtocolError, but it occurs to me that a
commandmap-based protocol handler could use this generally.
Two new methods would be:
- IP based service check
ProtocolResponse acceptConnection(String remoteIP);
this is probably the correct way to deal with DNSRBL
if you don't want to provide any service, rather than
reject RCPT TO commands, immediately provide a 554.
- RCPT TO checking
ProtocolResponse acceptRecipient(String recipient);
Those would complement the filtering we already support via internal
mechanisms:
- maximum message size
- IP based relay denied
- SMTP AUTH based relay denied
Again, this is not to replace the matcher/mailet pipeline. It is strictly a
means to control protocol response to protocol commands. If we like how
this approach turns out, then we can consider using it more generically in
later revisions to the handler, and in other protocol handlers.
Thoughts, suggestions, flames?
--- Noel
-----Original Message-----
From: Hontvari Jozsef [mailto:hontvari2@solware.com]
Sent: Tuesday, May 27, 2003 3:22
To: James Developers List
Subject: Re: [PATCH] AOL blocking James
The filter is a good solution. I prefer the second configuration style,
because it is similar to most others in James.
I would add one thing, the error message may optionally include the rcpt to
address. Most web servers does this. It is better in the log files and maybe
the user get more information also, which is otherwise unavailable for him.
For example this can be implemented using the java.text.MessageFormat class
and its {0} plcaeholder in the error message text.
Because the filter mechanism will likely change in the future, it would be
useful to prepare for such a change. From this viewpoint the first
configuration is better, we can define an rcpt_to2 filter later if
necessary. So I would replace the command element in the second alternative
with a type element, its value can be "rcpt_to" now.
Something different: the specific example which uses the "aol" string as
criteria is very dangerous, it shouldn't be included in the doc and config
file. I am afraid if aol detects such a customized behaviour they will block
the server once and forever.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, May 26, 2003 11:20 AM
Subject: RE: [PATCH] AOL blocking James
> > > Other than the inappropriately named configuration setting,
> > > does anyone want this, or something like it, included in
> > > the CVS?
>
> > Is this the direction we want to go ??
> > From what I remember, the idea was to accept all and then
> > process (reject, redirect,etc.)
>
> James is certainly not an Open Relay, regardless of AOL foolishness.
>
> I'm not particularly fond of the proposed change. However, a generic
> fails fail solution could involve an acceptRCPT_TO type method. The
> handler would be blind to it, and there could be some minimal plug-in
> support for the server. A hypothetical configuration might look like:
>
> <filters>
> <rcpt_to class="regexfilter" match=".*%aol\.com*@.*"
> error="code" text="..."/>
> <filter command="RCPT TO">
> <class>regexfilter</class>
> <match>".*%aol\.com@.*"</match>
> <error>code</error>
> <text>notice</text>
> </filter>
> </filters>
>
> which does nothing other than illustrate two different ways of expressing
> something. Although I, personally, could use either (or several other
> variants), I'm not entirely happy with the ease of expression. The only
> good ideas, so far, are to hide all details from the handler, and have a
> limited albeit flexible means of filtering on specific items.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
> (b) The isLocalDomain would be the easiest and most sensible to
> implement as James has some of that info already. I think once
> this is done I'll feel a lot happier about this issue.
It is in the CVS for v2.2. If people agree with the approach, I'll start to
move these into HEAD as well.
I've been mulling over the idea to add a few more stub calls that don't
return errors, but provide a framework for eventually doing so, e.g.,
- acceptRCPT_TO(), returns null or an error [code, message]
The acceptance logic would be opaque to the handler. The handler would
simply implement the protocol response. The idea needs to be fleshed out
more.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 21 May 2003 15:34
> To: James Developers List
> Subject: RE: Protocol Handler-based rejection
>
>
> [Collected comments from the AOL Blocking James and related threads]
>
> Hontvari Jozsef asked:
> > Anybody have some information what is the meaning of addresses like
> > gandalf%isengard.uk@bree.uk
> > and why AOL don't like it?
>
> It is an anachronism.
>
> See: http://support.microsoft.com/?kbid=304897
>
> Danny Angus opined:
> > I think there is agreement that some 5xx errors should be
> generated up
> > front
>
> The new patch I submitted should help.
>
> Now that we have the equivalent of RemoteAddrInNetwork
> accessible in the SMTP handler, we could consider using that
> feature, combined with the localServers check, on all
> messages to implement fast-fail for relay requests.
Cool!
>
> > AOL's ignorant half-arsed arrogance is not alone a good
> enough reason.
>
> According to the Microsoft document (above), Microsoft's own
> mail server does the same type of delayed processing as
> James, and for similar reasons.
>
> > All of the recognised relay testing services accept the blackhole
> > approach to spam, and in fact many commercial firewalls which
> > incorporate SMTP proxying also behave as blackholes.
>
> Jason Webb replied:
> > If the team agree that upfront rejection is required/useful
> then I'd
> > be more than happy to help write it.
>
> Danny, myself, and others all agree that getting rid of
> spammers as aoon as possible is a good and reasonable policy.
> The question is how much to do in the fast-fail filters.
>
> The test version takes advantage of the fact that using SMTP
> AUTH in the code already does fast-fail denial for
> unauthenticated relay requests. The effect of the
> <authorizedAddresses> patch is to force SMTP AUTH for
> non-authorized addresses (thus denying them relay
> permission), and to allow authorized addresses to relay
> without going through SMTP AUTH.
>
> As I've suggested, another step could be to add isLocalServer (really
> "isLocalDomain") processing into the non-SMTP AUTH path, so
> that all relaying is denied. That would be combined with an
> extension of the <authorizedAddresses> feature so that
> authorized addresses are permitted to relay. That
> effectively deprecates the common use of the RemoteAddr* matchers.
I'd like to leave the users with both options:
1) You want the current behaviour left as-is (silent spam rejection)
2) You want 5xx rejection
I'd probably recommend that option 2 is the default as it will stop
users have the same issues that Hontvari has.
>
> Beyond that, the IpFilter mechanism previously mentioned
> would allow DNSRBL behavior to be added as a fast-fail mode.
I'd like to think very carefully about this as it could have performance
implications.
>
> Are you (a) willing to help work on any of these, and (b)
> what other fast-fail checks to you recommend?
(a) Absolutely!
(b) The isLocalDomain would be the easiest and most sensible to
implement as James has some of that info already. I think once this is
done I'll feel a lot happier about this issue. I'd also like to see the
RemoteAddr remain, but if people are happy with this approach I'd come
up with a proposal to say what would go where, and when a rejection
would occur
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Protocol Handler-based rejection
Posted by "Noel J. Bergman" <no...@devtech.com>.
[Collected comments from the AOL Blocking James and related threads]
Hontvari Jozsef asked:
> Anybody have some information what is the meaning of addresses like
> gandalf%isengard.uk@bree.uk
> and why AOL don't like it?
It is an anachronism.
See: http://support.microsoft.com/?kbid=304897
Danny Angus opined:
> I think there is agreement that some 5xx errors should be
> generated up front
The new patch I submitted should help.
Now that we have the equivalent of RemoteAddrInNetwork accessible in the
SMTP handler, we could consider using that feature, combined with the
localServers check, on all messages to implement fast-fail for relay
requests.
> AOL's ignorant half-arsed arrogance is not alone a good enough reason.
According to the Microsoft document (above), Microsoft's own mail server
does the same type of delayed processing as James, and for similar reasons.
> All of the recognised relay testing services accept the blackhole
> approach to spam, and in fact many commercial firewalls which
> incorporate SMTP proxying also behave as blackholes.
Jason Webb replied:
> If the team agree that upfront rejection is required/useful then
> I'd be more than happy to help write it.
Danny, myself, and others all agree that getting rid of spammers as aoon as
possible is a good and reasonable policy. The question is how much to do in
the fast-fail filters.
The test version takes advantage of the fact that using SMTP AUTH in the
code already does fast-fail denial for unauthenticated relay requests. The
effect of the <authorizedAddresses> patch is to force SMTP AUTH for
non-authorized addresses (thus denying them relay permission), and to allow
authorized addresses to relay without going through SMTP AUTH.
As I've suggested, another step could be to add isLocalServer (really
"isLocalDomain") processing into the non-SMTP AUTH path, so that all
relaying is denied. That would be combined with an extension of the
<authorizedAddresses> feature so that authorized addresses are permitted to
relay. That effectively deprecates the common use of the RemoteAddr*
matchers.
Beyond that, the IpFilter mechanism previously mentioned would allow DNSRBL
behavior to be added as a fast-fail mode.
Are you (a) willing to help work on any of these, and (b) what other
fast-fail checks to you recommend?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Test version for
Posted by Hontvari Jozsef <ho...@solware.com>.
Anybody have some information what is the meaning of addresses like
gandalf%isengard.uk@bree.uk
and why AOL don't like it?
In the RFC's I haven't found anything which would indicate that % has any
special meaning. Indeed, it seems to me that the original smtp rfc 821
specifies that % _has_no_ special meaning.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James-Dev Mailing List" <ja...@jakarta.apache.org>
Sent: Wednesday, May 21, 2003 7:04 AM
Subject: Test version for <authorizedAddresses>
> In http://jakarta.apache.org/builds/jakarta-james/nightly/bin/ is an
> unlabeled test build that matches the current CVS.
>
> This build adds support for a new <authorizedAddresses> element in the
SMTP
> handler section. This element takes a comma separated list of addresses
> (probably the same list that you currently have on your
> RemoteAddrNotInNetwork matcher). When using SMTP AUTH, connections from
> addresses defined in <authorizedAddresses> will be not be subject to SMTP
> AUTH. In fact, you will be able to tell via telnet because you won't even
> see the SMTP AUTH decorations.
>
> Note, however, that although this will reject addresses such as
> frodo@theshire.uk, it will not immediately reject addresses such as
> gandalf%isengard.uk@bree.uk. Those are valid localparts, and we cannot
> validate local addresses in the handler. One major reason for this in
James
> v2 is that virtual user tables and other valid names are not present in
any
> user repository structure. I would expect that to change in James v3.
>
> Authorized addresses can be specified in any of several ways:
>
> - IP address, e.g., 127.0.0.1
> - FQDN, e.g., www.apache.org
> - network/netmask, e.g., 192.168.0.0/255.255.0.0
> - wildcard notation, e.g., 192.168.*
> - network/bits, e.g., 192.168.0.0/16
>
> Anywhere that an IP address appears, an FQDN can be substituted, e.g.,
> mydomain.tld/27.
>
> NOTE: *NO* addresses are defaulted into the list. My current test system
> has:
>
> <authorizedAddresses>127.0.0.0/8,192.168.0.0/16</authorizedAddresses>
>
> Please let me know of any questions, problems, issues, disagreements, etc.
> :-) Have fun, but remember: this is ONLY an unreleased test.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Test version for
Posted by "Noel J. Bergman" <no...@devtech.com>.
Replaced it already ... I made a couple of dumb last minute typos between
testing and cleanup. Should be good now.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org