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 Serge Knystautas <se...@lokitech.com> on 2004/02/12 21:04:41 UTC
Was: SMTPACL
I got the proposal for SMTPACL and generally think it's very sound. I
like the idea of using the mailet API, with certain restrictions.
There are two things I would suggest changing:
1. The name. ACL doesn't make sense as this isn't a list of anything.
This is specific to SMTP, and in fact I might make it a bit more
specific to SMTP...
2. The class/state structure. You need to be sure that both mailets AND
matchers are aware that this is during an SMTP transaction and we do not
have a MimeMessage. So I would do two changes:
a. class-wise, make an interface (probably empty interface) that
declares that this matcher and mailet can be used in the <rcpt> tag,
i.e., they don't care about the MimeMessage.
b. state-wise, just use the existing state/errorMessage fields.
Instead of SMTPAccept, you just leave getState() as Mail.DEFAULT.
Instead of SMTPReject, you do setState(Mail.ERROR) and
setErrorMessage("550 cannot find MX for your domain").
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Was: SMTPACL
Posted by "Noel J. Bergman" <no...@devtech.com>.
> SMTPACL is attempting to expand the use of mailets, which are already
> heavily tied to SMTP processing, to a faster-fail environment.
Agreed.
> > I would permit something like:
> >
> > <filter event="<event>">
> > </filter>
> This implies there are more protocols and events than we actually have.
No, just more events, e.g, connect, HELO, MAIL FROM, RCPT TO, DATA. I am
not pre-supposing which ones are useful, or even for which ones we will
implement a filter processor. I simply proposed a syntax that would permit
a consistent treatment in the future.
> > <filter event="<CONNECT>">
> > ... DNS RBL checks ...
> > </filter>
> This doesn't really relate to the mailet API, instead to our
> server-container.
Why? We already have a DNS RBL matcher which provides this functionality.
This just permits it to provide it as a fast-fail at the earliest time.
> Are we sure this is legal for a mail server to reject this way,
> except temporarily such as responding to a DOS attack?
Yes. See RFC 2821, section 3.1. We would return a 554 instead of a 220,
return 503 for any commands other than QUIT, and wait for the client to
issue a QUIT before disconnecting.
And if one wants to configure one's system this way, and avoid being listed
in the RFC ignorant RBL, you need to provide a very specific message
regarding why you are rejecting the connection
(http://www.rfc-ignorant.org/policy-postmaster.php).
> > Leaving the choice of what and when to the mail admin, or possibly
> > some future RFC.
> Yes, this is about giving the mail admin choices of fast-fail. But
> you're suggesting a solution to give RFC authors choices.
No, as noted above, I am proposing a general syntax so that we have a
consistent approach to whatever we need to do in response to evolving mail
RFCs or user requirements.
> > And, just as a talking point, I think that we may want a Mailet
> > that explicitly provides a return code and message so that we
> > can better collect statistics.
> I believe that was addressed. If you mean to separate the two pieces
> of data, then you've hardcoded responses to how SMTP handles responses.
I am saying that there ARE cases where it is important in the protocol state
machine to know what responses have come before. If you issue a 554 in
response to a connection, it carries implications for future processing. I
don't want to have to parse the response string.
In any event, I don't see this as something we need to hash out right now.
:-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Was: SMTPACL
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> I agree with some of your comments, I disagree with some others. In
> general, I would rather not artificially restrict the approach to implement
> a usage policy. And we have other services, e.g., NNTP, where this could be
> useful.
It is incorrect to say we have other services. There is only 1: NNTP.
POP3 and IMAP (which we do not have) do not relate to mailets.
Fetchmail we can only fetch whole messages so is not affected by SMTPACL.
SMTPACL is attempting to expand the use of mailets, which are already
heavily tied to SMTP processing, to a faster-fail environment. More on
NNTP below...
> I would permit something like:
>
> <filter event="<event>">
> </filter>
This implies there are more protocols and events than we actually have.
If there are others, let's list them and figure out a pattern.
> so that one might be allowed to say:
>
> <filter event="<CONNECT>">
> ... DNS RBL checks ...
> </filter>
This doesn't really relate to the mailet API, instead to our
server-container. A basic interface addresses this:
public interface ConnectionCredential {
public boolean accept(InetAddress);
}
This should be part of Avalon and if/when we add this, we can pass it
back to them. Are we sure this is legal for a mail server to reject
this way, except temporarily such as responding to a DOS attack?
> <filter event="MAIL FROM">
> ... sender checks, e.g., sender in fake domain or SPF ...
> </filter>
This is a possible place to check grant you.
> <filter event="RCPT TO">
> ... recipient checks, e.g., quota, relaying, etc., ...
> </filter>
This is the area that we have been discussing which the SMTPACL and my
changes address.
> Leaving the choice of what and when to the mail admin, or possibly some
> future RFC.
Yes, this is about giving the mail admin choices of fast-fail. But
you're suggesting a solution to give RFC authors choices. Also I had
asked the mailing list a few months ago whether we wanted to evolve
James towards a richer mail server (gear it towards mail admins) or
collection of mail protocol implementations (gear towards Java server
developers). The response was overwhelmingly towards the former, and I
think your ideas speak to possible issues of the latter.
> And, just as a talking point, I think that we may want a Mailet that
> explicitly provides a return code and message so that we can better collect
> statistics.
I believe that was addressed. If you mean to separate the two pieces of
data, then you've hardcoded responses to how SMTP handles responses.
In terms of NNTP, I don't know enough about how we're using mailets.
But, in NNTP you can either retrieve the message headers or the full
message. So in terms of supporting a fast-fail notion, you could allow
matchers & mailets declare they can operate on a partial MimeMessage
(though I'm not sure how you would represent).
> But rather than hash any of this out now, I think we should do it
> post-release.
I look forward to the hashing and nashing.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Was: SMTPACL
Posted by "Noel J. Bergman" <no...@devtech.com>.
I agree with some of your comments, I disagree with some others. In
general, I would rather not artificially restrict the approach to implement
a usage policy. And we have other services, e.g., NNTP, where this could be
useful.
I would permit something like:
<filter event="<event>">
</filter>
so that one might be allowed to say:
<filter event="<CONNECT>">
... DNS RBL checks ...
</filter>
<filter event="MAIL FROM">
... sender checks, e.g., sender in fake domain or SPF ...
</filter>
<filter event="RCPT TO">
... recipient checks, e.g., quota, relaying, etc., ...
</filter>
Leaving the choice of what and when to the mail admin, or possibly some
future RFC.
And, just as a talking point, I think that we may want a Mailet that
explicitly provides a return code and message so that we can better collect
statistics.
But rather than hash any of this out now, I think we should do it
post-release.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Was: SMTPACL
Posted by Serge Knystautas <se...@lokitech.com>.
Ok, I've already got corrections. Need to wait 15 minutes before
sending these...
Serge Knystautas wrote:
> I got the proposal for SMTPACL and generally think it's very sound. I
> like the idea of using the mailet API, with certain restrictions.
>
> There are two things I would suggest changing:
> 1. The name. ACL doesn't make sense as this isn't a list of anything.
> This is specific to SMTP, and in fact I might make it a bit more
> specific to SMTP...
Ideas:
i. SMTPSession
ii. SMTPTransaction
For example...
public class HostIsLocal
extends GenericRecipientMatcher
implements SMTPTransaction {
}
and
public class SetMailAttribute
extends GenericMailet
implements SMTPTransaction {
}
Note that I'm suggesting these get added to the Mailet API to define how
mailets get used within the SMTP transaction.
> 2. The class/state structure. You need to be sure that both mailets AND
> matchers are aware that this is during an SMTP transaction and we do not
> have a MimeMessage. So I would do two changes:
> a. class-wise, make an interface (probably empty interface) that
> declares that this matcher and mailet can be used in the <rcpt> tag,
> i.e., they don't care about the MimeMessage.
The implication of implementing this no-arg interface is:
i. you do not access mail.getMimeMessage() (the mail should throw an
exception).
ii. a matcher does not return partial matches. This chain will need to
get called after every single RCPT TO line, so you cannot fork
processing (a nice benefit is that this makes this version of
"LinearProcessor" a lot easier).
> b. state-wise, just use the existing state/errorMessage fields.
> Instead of SMTPAccept, you just leave getState() as Mail.DEFAULT.
> Instead of SMTPReject, you do setState(Mail.ERROR) and
> setErrorMessage("550 cannot find MX for your domain").
Sorry, this is a bit more complicated. This is a bit more feasible...
i. mail.getState() returns Mail.INCOMING to start.
ii. If you want to accept it, you do mail.setState(Mail.DEFAULT);
iii. If you want to reject it, you do mail.setState(Mail.ERROR);
mail.setErrorMessage("550 cannot find MX for your domain").
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Was: SMTPACL
Posted by Alex Zhukov <zh...@ukrpost.net>.
Serge Knystautas wrote:
> I got the proposal for SMTPACL and generally think it's very sound. I
> like the idea of using the mailet API, with certain restrictions.
>
> There are two things I would suggest changing:
> 1. The name. ACL doesn't make sense as this isn't a list of anything.
> This is specific to SMTP, and in fact I might make it a bit more
> specific to SMTP...
> 2. The class/state structure. You need to be sure that both mailets AND
> matchers are aware that this is during an SMTP transaction and we do not
> have a MimeMessage. So I would do two changes:
why? you just supply Mail implementation to matcher and this Mail
implementation is dynamically initialized during smtp dialog.
think of the following:
you can get content of message only after server has sent data after
DATA command
you can get sender right after MAIL FROM command
so if you matcher operates on data but admin has put it after rcpt it
will just think mail has no content it wont break and it will be
compatible with mailet api.
the greatest advantage of such an architecture is compatibility with
mailet api. you dont have to rewrite _anything_ in you matchers to use
matchers in smtpacl. code reuse rules! :)
as for SMTPResult it is yet another abstract mailet again compatible
with mailet api. this type of mailets are handled by SMTPHandler during
smtp acl processing.
As for name (SMTPACL) this name was first mentioned in Exim mailer so i
decided to keep it anyway it _is_ a list (L) to control(C) access(A) to
services of SMTPHandler. But I'm open to name change if you think it is
wrong. For admins acl is a good hint. you have acls in cisco routers to
control who is allowed to connect to this or that service.
> a. class-wise, make an interface (probably empty interface) that
> declares that this matcher and mailet can be used in the <rcpt> tag,
> i.e., they don't care about the MimeMessage.
> b. state-wise, just use the existing state/errorMessage fields.
> Instead of SMTPAccept, you just leave getState() as Mail.DEFAULT.
> Instead of SMTPReject, you do setState(Mail.ERROR) and
> setErrorMessage("550 cannot find MX for your domain").
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org