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 Jason Webb <jw...@inovem.com> on 2002/10/22 11:41:10 UTC
SMTP Handler
I've noticed in the past (and at the moment) that James is very fussy
about SMTP syntax for email addresses (MAIL TO etc). Although this is
not a significant problem, Qmail has a much better outlook on life:
1) Accept anything (no <>)
2) Send only strict RFC addresses.
And, yes I know about the standards, but some clients out there play
fast and loose with them, so I'd like James to be a little more flexible
on this front.
-- Jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SMTP Handler
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > I've noticed in the past (and at the moment) that James is very fussy
> > about SMTP syntax for email addresses (MAIL TO etc).
> Can you possibly make a list of acceptable but malformed addresses
> that James should accept but does not.
There are existing sources of really weird address forms that we could test.
The various ORB testing groups have them (including malformed addresses) to
mimic what spammers use to try to get past address checking.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SMTP Handler
Posted by Jason Webb <jw...@inovem.com>.
I've had a chat with some of my colleagues. The ones we've all seen
(only sometimes and usually spammers) are of the form:
C: RCPT TO: test2@localhost
S: 250.*
C: QUIT
S: 221.*
C: RCPT TO: "test2@localhost"
S: 250.*
C: QUIT
S: 221.*
That's all folks!
As I said before, I agree with Danny in principal that we should educate
people with bad SMTP clients or servers. But, as a lot of these people
couldn't care (spammers) I think it's a lost cause. And, no, I don't
think it's a bad idea to pander to spammer's clients. It's important to
deal with them properly (via Mailets etc), rather than just have the
server fail them. Otherwise such bad clients will often keep trying,
time and time again. If James can absorb the message and deal with it,
then so much the better. This type of situation won't be helped until
James can reject mail in the SMTP handler, rather than waiting until the
mailets run.
-- Jason
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SMTP Handler
Posted by Harmeet Bedi <ha...@kodemuse.com>.
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> I've noticed in the past (and at the moment) that James is very fussy
> about SMTP syntax for email addresses (MAIL TO etc). Although this is
> not a significant problem, Qmail has a much better outlook on life:
Jason, Can you possibly make a list of acceptable but malformed addresses
that James should accept but does not. Would be best to do it as a script
like
# SMTP protocol session to test for invalid addresses.
S: 220.*
C: HELO foobar
S: 250.*
C: MAIL FROM: <te...@localhost>
S: 250.*
#good address
C: RCPT TO: <te...@localhost>
S: 250.*
#bad address but accepted by some server but not James
C: RCPT TO: test2@localhost
S: 250.*
C: QUIT
S: 221.*
We could fire off against specific server implementations and James to
figure out, match and validate the correct behavior.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SMTP Handler
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: 22 October 2002 12:15
> To: James Developers List
> Subject: RE: SMTP Handler
>
>
> Jason,
>
> James does need well formed addresses, including incoming
> ones, to route mail with, and the standards are quite clear
> about what is and isnt acceptable. I expect we could accept a
> wider variety than we do, but why would we?
The only once we've ever come across is missing the <> around the email
addr.
> Mail is pretty much wholly dependant on people following the
> rules, and IMO if we don't alert them to errors on their part
> we're guilty of conspiring to water down the standards. I'd
> be happy enough if the standards were changed, but really not
> happy to see a de-facto standard arise which is an
> un-documented and moving target.
I generally agree with you. It was just a comment from some of the Qmail
people.
>
> James may well still be rejecting valid but unusual
> addresses, we need'd really test cases for that though.
>
> What kind of problems have you been seeing?
To be honest I've only normally seen this sort of behaviour for 2
reasons:
1) Badly written bulk mail tools
2) Me trying to send SMTP by hand ;-)
>
> d.
>
<snip'd>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SMTP Handler
Posted by Danny Angus <da...@apache.org>.
Jason,
James does need well formed addresses, including incoming ones, to route mail with, and the standards are quite clear about what is and isnt acceptable.
I expect we could accept a wider variety than we do, but why would we?
Mail is pretty much wholly dependant on people following the rules, and IMO if we don't alert them to errors on their part we're guilty of conspiring to water down the standards.
I'd be happy enough if the standards were changed, but really not happy to see a de-facto standard arise which is an un-documented and moving target.
James may well still be rejecting valid but unusual addresses, we need'd really test cases for that though.
What kind of problems have you been seeing?
d.
> -----Original Message-----
> From: Jason Webb [mailto:jw@inovem.com]
> Sent: 22 October 2002 10:41
> To: James Developers List
> Subject: SMTP Handler
>
>
> I've noticed in the past (and at the moment) that James is very fussy
> about SMTP syntax for email addresses (MAIL TO etc). Although this is
> not a significant problem, Qmail has a much better outlook on life:
> 1) Accept anything (no <>)
> 2) Send only strict RFC addresses.
> And, yes I know about the standards, but some clients out there play
> fast and loose with them, so I'd like James to be a little more flexible
> on this front.
>
>
> -- Jason
>
>
> --
> 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>