You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by Steve Brewin <sb...@synsys.com> on 2003/05/30 15:42:00 UTC
Is this a valid From: address?
Hi,
org.apache.mailet.MailAddress throws a parse exception proceessing the
following From: address...
<"nlt: Mail Administrator">
My reading of RFC 822 suggests that MailAdress is correct, this is an
invalid From: address.
Firstly, am I correct?
Secondly, assuming MailAddress and I are correct, is it a good idea for
James to strictly enforce the RFC for originator fields?
org.apache.james.core.MailImpl takes a MailAddress as the sender, so a
message with an invalid originator cannot be passed to MailImpl for
processing. Messages, such as the above, may have passed through many other
MTAs before James spits it out, presumably because they aren't so picky
about the originator fields. Perhaps James should take the same attitude and
only be strict on recipient addresses?
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
Re: Is this a valid From: address?
Posted by Serge Knystautas <se...@lokitech.com>.
Steve Brewin wrote:
> Secondly, assuming MailAddress and I are correct, is it a good idea for
> James to strictly enforce the RFC for originator fields?
It does look invalid, but it's been a while since I've examined the spec
exactly. There's a crazy regex that checks for email address format you
could try as well to get confirmation another way...
http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
I could see this enforcement as an optional mailet (or matcher). Most
likely use would be to help catch spam, but they just forge the
addresses nowadays anyway.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Is this a valid From: address?
Posted by Danny Angus <da...@apache.org>.
Sheldon wrote:
> I don't think so. It looks valid, because:
>
> 1) Unqualified localparts are legal, and
> 2) Quoted strings in localparts are legal, and whitespace is legal
> within them.
I agree James should be handling this as a quoted local part with no host or domain part.
i.e. "nlt: Mail Administrator"@localhost
What you say below I disagree with..
> I've just given up on implementing a strictly compliant syntactic
> validator because it's so complex. I just leave it up to $other_mta
> [1], now. I've looked at the C code used in $other_mta, and it's
> hair-raising. :-)
> Assuming you're smartrouting outbound mail through a more mature system,
> I'd recommend leaving the decision up to that host for now. After all,
> you're using James for extensibility and application integration, rather
> than high performance delivery and mature spool management and auditing
> features, right?
It is not IMO our intention to create a dependant piece of software, nor should it be.
James aims to be a fully functional MTA (and then some), we do strive to comply with all relevant rfcs, but as you say 822 & 2822 are the mother of all bitches, and seem to be comprised mainly of escapes allowing the perverse exceptions required to maintain historic compatibilities with mediaeval address formats.
James doesn't rely on routing outbound mail though a more mature system, unless you consider JavaMail more mature (IMO *not*, just better funded)
I'm quite sure that "power users" of James _will_ be gateing James with sendmail or some other worthy MTA, but James is equally at home as the primary MTA of SME systems.
Finally, (rant nearly over!) in this particular case an unqualified local part shouldn't really have been used as the MAIL FROM address by an MTA with an ounce of brain, as James (or $other_mta) should have rejected it based upon it not being a valid local user, never mind any other considerations.
d.
Re: Is this a valid From: address?
Posted by Sheldon Hearn <sh...@starjuice.net>.
On (2003/05/30 14:42), Steve Brewin wrote:
> org.apache.mailet.MailAddress throws a parse exception proceessing the
> following From: address...
>
> <"nlt: Mail Administrator">
>
> My reading of RFC 822 suggests that MailAdress is correct, this is an
> invalid From: address.
>
> Firstly, am I correct?
I don't think so. It looks valid, because:
1) Unqualified localparts are legal, and
2) Quoted strings in localparts are legal, and whitespace is legal
within them.
> Secondly, assuming MailAddress and I are correct, is it a good idea for
> James to strictly enforce the RFC for originator fields?
I've just given up on implementing a strictly compliant syntactic
validator because it's so complex. I just leave it up to $other_mta
[1], now. I've looked at the C code used in $other_mta, and it's
hair-raising. :-)
Assuming you're smartrouting outbound mail through a more mature system,
I'd recommend leaving the decision up to that host for now. After all,
you're using James for extensibility and application integration, rather
than high performance delivery and mature spool management and auditing
features, right?
Ciao,
Sheldon.
[1] Some established Unix MTA. No need to get into specifics and risk a
flamewar.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org
RE: Is this a valid From: address?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> org.apache.mailet.MailAddress throws a parse exception proceessing the
> following From: address...
> <"nlt: Mail Administrator">
What exactly is the exception? Text and stacktrace context would be
helpful.
> My reading of RFC 822 suggests that MailAdress is correct, this is an
> invalid From: address.
RFC 2822 says (abbreviated):
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
group = display-name ":" [mailbox-list / CFWS] ";"
[CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
Normally, a mailbox is comprised of two parts: (1)
an optional display name that indicates the name of the recipient
(which could be a person or a system) that could be displayed to the
user of a mail application, and (2) an addr-spec address enclosed in
angle brackets ("<" and ">"). There is also an alternate simple form
of a mailbox where the addr-spec address appears alone, without the
recipient's name or the angle brackets. The Internet addr-spec
address is described in section 3.4.1.
When it is desirable to treat several mailboxes as a single unit
(i.e., in a distribution list), the group construct can be used. The
group construct allows the sender to indicate a named group of
recipients. This is done by giving a display name for the group,
followed by a colon, followed by a comma separated list of any number
of mailboxes (including zero and one), and ending with a semicolon.
Because the list of mailboxes can be empty, using the group construct
is also a simple way to communicate to recipients that the message
was sent to one or more named sets of recipients, without actually
providing the individual mailbox address for each of those
recipients.
Reviewing the above, and Appendix A of RFC 2822, it would appear that
<"nlt: Mail Administrator">
should be properly interpreted as a quoted local-part lacking a domain. I
do not see where the pseudo-BNF permits a missing domain. RFC 2821 section
4.1.2 says nothing different, other than adding that <postmaster> must be
accepted without a domain, as the exception.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-user-help@jakarta.apache.org