Yeah, I think serializable Map is the way to go. But... if you want a short term solution that doesn't require changing the repositories (much), what you can do is migrate the independent error field into one of the new generic attributes (which actually should be done anyway). Then you can repurpose the existing error field in the store to be the string representation of a Properties object. So that field goes from "something bad happened" to "error=something bad happened".
You'd need to increase the size of the field obviously, but then you could even write a bit of exception handling in the store to have it migrate from the individual String to the Properties object as it gets resaved. Anyway, probably a bad idea since I do think a serializable Map is the better long term solution, but it's a thought. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com Noel J. Bergman wrote: > Serge, > > I reviewed the store code, and I see your point about stores. Not too bad > for the file system stores, a bit more more work the JDBC stores. > > Obviously, this sort of change should be made once, so if we are going to > add ANY attribute, we should add it as a container so that we don't need to > keep doing this each time an attribute is added. > > The "easiest" thing is to add a Properties object to Mail objects. > Alternatively, we could use a Hashmap to store keyed objects, but that gets > us into the realm of having to make sure that all of the stored objects are > Serializable, and I don't know if it really gains us anything to add the > additional complication. Thoughts? > > Either way, the metadata would be stored as a single blob. The > understanding will be that we cannot query based upon such metadata, because > it won't have independent existance in the database, although I suppose one > could fudge it in the case of a property table, since it is stored as string > content. > > Are there any current properties that you'd move from the object into the > map? I'm inclined to not buy into that much editing (and potential breaking > of third party matchers/mailets), but I could always maintain the current > interface; only the storage would change. > > --- Noel > > -----Original Message----- > From: Serge Knystautas [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 31, 2002 7:03 > To: James Developers List > Subject: Re: Open relay with SMTP-AUTH > > > Yeah, I think adding setAttribute/getAttribute would be very helpful. > Certainly would help you sort this out. Then you could define a > constant for the name of the attribute you would look for the SMTP-AUTH > info. This is going to require changing the mail/spool stores though > and might create some upgrade problems, which is probably the biggest > reason it hasn't been done yet. > > -- > Serge Knystautas > Loki Technologies - Unstoppable Websites > http://www.lokitech.com/ > > Noel J. Bergman wrote: > >>Serge, >> >>Instead of an X- header, why can't we add an "authenticatedSender" (pick a >>name) property to the mail object? That kind of metadata would travel > > with > >>the object (and clones) within the system, but can't be forged from the >>outside. Does the fact that we authenticated it have any meaning once it >>leaves JAMES? I don't think so. If it did, that would be part of the > > RFC. > >>Back in June, you and I were discussing Matcher <-> Mailet communication, >>and you mentioned that you wanted to add Mail.setAttribute() / >>Mail.getAttribute() to the Mailet API. Do you want me to add this now, or >>add a fixed property? >> >> --- Noel >> >>-----Original Message----- >>From: Serge Knystautas [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, July 30, 2002 22:53 >>To: James Developers List >>Subject: Re: Open relay with SMTP-AUTH >> >> >>Yeah, I agree. I never quite understood how SMTP AUTH was implemented >>effectively because there isn't an easy way to do that. I don't know... >>maybe add an "X-" header to the message itself to record that it's >>authenticated (and make sure there isn't one there already). But yeah, >>I agree with Noel's idea. >> >>-- >>Serge Knystautas >>Loki Technologies - Unstoppable Websites >>http://www.lokitech.com/ >> >>Noel J. Bergman wrote: >> >> >>>Peter, >>> >>>At a quick glance, it looks OK, but please ask Serge what he thinks. And >> >>I >> >> >>>believe that I have an alternative solution. >>> >>>I don't like that right now we have to force SMTP AUTH for everyone under >>>all circumstances, or not use it at all. I'd rather that AUTH was >> >>optional, >> >> >>>and that there was a way for the mail to be tagged with the meta-data that >>>it was authenticated. That way, our configuration could toss people who >>>aren't on an acceptable IP to a processor that checked for AUTH, and if >> >>the >> >> >>>mail was tagged, it could pass it on for delivery. >>> >>>I don't mean to tag the message, e.g., with a forgable header. I mean to >>>tag the mail object, e.g., with a new property. But right now once the >> >>mail >> >> >>>object has left the handler, there is nothing preserved to tell us that it >>>was sent by an authenticated sender. The only reason why SMTP AUTH and <> >>>turns JAMES into an open relay is that we have to disable >>>RemoteAddrInNetwork. If we could keep RemoteAddrInNetwork, and check for >>>AUTH in the failure case, we could address this problem differently. >>> >>> --- Noel >>> >>>-----Original Message----- >>>From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] >>>Sent: Tuesday, July 30, 2002 21:57 >>>To: 'James Developers List' >>>Cc: [EMAIL PROTECTED] >>>Subject: RE: Open relay with SMTP-AUTH >>> >>> >>> >>>Noel, >>> >>>Right. So locally generated bounces shouldn't traverse the gate logic >>>in SMTPHandler.java (and hence should be sent even if they have a null >>>Sender header) while bounces from other servers should only be delivered >>>locally if authRequired is true. So we can change the SMTPHandler code >>>as I suggested earlier and we should be ok. Your thoughts? >>> >>>--Peter >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] >>>>Sent: Tuesday, July 30, 2002 6:56 PM >>>>To: James Developers List >>>>Cc: [EMAIL PROTECTED] >>>>Subject: RE: Open relay with SMTP-AUTH >>>> >>>>Peter, >>>> >>>>Internally, messages are sent by calling James.sendMail(), which calls >>>>spool.store() to put the message on the incoming message spool. If >>>>you look at SMTPHandler, you'll see that it does the same thing. It >>> > calls > >>>>mailServer.sendMail(), which it sounds as if you've already noticed. >>>> >>>> --- Noel >>>> >>>>-----Original Message----- >>>>From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] >>>>Sent: Tuesday, July 30, 2002 20:48 >>>>To: 'James Developers List' >>>>Subject: RE: Open relay with SMTP-AUTH >>>> >>>> >>>> >>>>Noel, >>>> >>>>That looks right. The relevant logic is in the SMTPHandler. >>>> >>>>Does the LocalDelivery bounce even invoke the SMTPHandler? I don't >>> >>>see >>> >>> >>> >>>>why it wouldn't just place an outgoing message on the spool directly. >>>>That's what it appears to do. >>>> >>>>I'm going to play with some configurations here and see what >>> >>>happens... >>> >>> >>> >>>>--Peter >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] >>>>>Sent: Tuesday, July 30, 2002 4:39 PM >>>>>To: James Developers List >>>>>Cc: [EMAIL PROTECTED] >>>>>Subject: RE: Open relay with SMTP-AUTH >>>>> >>>>>Seems like we have the following combination: >>>>> >>>>> local receiver remote receiver >>>>>local sender OK OK >>>>>remote sender OK DENY >>>>> >>>>>with respect to null senders, which is the same as for other >>>> >>>messages. >>> >>> >>> >>>>>Am I missing something? >>>>> >>>>> --- Noel >>>>> >>>>>-----Original Message----- >>>>>From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]] >>>>>Sent: Tuesday, July 30, 2002 16:03 >>>>>To: James Developers List; [EMAIL PROTECTED] >>>>>Subject: Re: Open relay with SMTP-AUTH >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>If we're going to enforce that mail will null senders does not >>>>> >>>leave >>> >>> >>> >>>>the >>>> >>>> >>>> >>>>>>host, then this should be: >>>>> >>>>>Maybe this assumption originates from me, sorry. It is not true. I >>>> >>>>have >>>> >>>> >>>> >>>>>fogotten that bounce messages generated by james also went through >>>> >>>the >>> >>> >>> >>>>>mailet spool (or am I wrong again?). >>>>> >>>>>At least the bounces generated locally by james must leave the >>>> >>>server >>> >>> >>> >>>>(and >>>> >>>> >>>> >>>>>the bounces MUST have null sender accordingly to RFC 1123 5.3.3). >>>>> >>>>>I agree on that preventing open relay should not require adding >>>> >>>>mailets to >>>> >>>> >>>> >>>>>the default configuration file. >>>>> >>>>>----- Original Message ----- >>>>>From: "Peter M. Goldstein" <[EMAIL PROTECTED]> >>>>>To: "'James Developers List'" <[EMAIL PROTECTED]> >>>>>Sent: Tuesday, July 30, 2002 8:54 PM >>>>>Subject: RE: Open relay with SMTP-AUTH >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>All, >>>>>> >>>>> >>>>>>From Serge's description it just seems that the not null sender >>>>> >>>> >>>>check is >>>> >>>> >>>> >>>>>>unnecessary. The code now is: >>>>>> >>>>>> // If this is a delivery failure notification (MAIL >>>>> >>>>FROM: >>>> >>>> >>>> >>>>>><>) >>>>>> // we don't enforce authentication >>>>>> if (authRequired && state.get(SENDER) != null) { >>>>>> // Make sure the mail is being sent locally if not >>>>>> // authenticated else reject. >>>>>> if (!state.containsKey(AUTH)) { >>>>>> String toDomain = recipientAddress.getHost(); >>>>>> if (!mailServer.isLocalServer(toDomain)) { >>>>>> out.println("530 Authentication >>>>> >>>Required"); >>> >>> >>> >>>>>> getLogger().error("Authentication is >>>>> >>>>required >>>> >>>> >>>> >>>>>>for mail request"); >>>>>> return; >>>>>> } >>>>>> } else { >>>>>> >>>>>>If we're going to enforce that mail will null senders does not >>>>> >>>leave >>> >>> >>> >>>>the >>>> >>>> >>>> >>>>>>host, then this should be: >>>>>> >>>>>> // If this is a delivery failure notification (MAIL >>>>> >>>>FROM: >>>> >>>> >>>> >>>>>><>) >>>>>> // we don't enforce authentication >>>>>> if (authRequired) { >>>>>> // Make sure the mail is being sent locally if not >>>>>> // authenticated else reject. >>>>>> if (!state.containsKey(AUTH)) { >>>>>> String toDomain = recipientAddress.getHost(); >>>>>> if (!mailServer.isLocalServer(toDomain)) { >>>>>> out.println("530 Authentication >>>>> >>>Required"); >>> >>> >>> >>>>>> getLogger().error("Authentication is >>>>> >>>>required >>>> >>>> >>>> >>>>>>for mail request"); >>>>>> return; >>>>>> } >>>>>> } else { >>>>>> >>>>>> >>>>>>I haven't looked at the LocalDelivery mailet, but I imagine it may >>>>>>require modification to ensure that mails with empty senders that >>>>> >>>>are >>>> >>>> >>>> >>>>>>routed to non-existent addresses don't bounce. >>>>>> >>>>>>I don't agree that this is a matcher issue. It shouldn't require >>>>> >>>>any >>>> >>>> >>>> >>>>>>complex configuration to prevent open relay behavior. Turning on >>>>> >>>>SMTP >>>> >>>> >>>> >>>>>>authentication is a standard and expected behavior to prevent open >>>>> >>>>relay >>>> >>>> >>>> >>>>>>behavior. Additional configuration of matchers is not. >>>>>> >>>>>>Any thoughts? >>>>>> >>>>>>--Peter >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Hontvari Jozsef [mailto:[EMAIL PROTECTED]] >>>>>>>Sent: Tuesday, July 30, 2002 12:54 AM >>>>>>>To: James Developers List >>>>>>>Subject: Re: Open relay with SMTP-AUTH >>>>>>> >>>>>>>But is it possible at all to configure james correctly? >>>>>>>If he is using smtp authentication, likely he hasn't so called >>>>>> >>>>"local" >>>> >>>> >>>> >>>>>>>hosts. >>>>>>> >>>>>>>This is the required behaviour, when the mail from is empty >>>>>> >>>(i.e. >>> >>> >>> >>>>>>bounce >>>>>> >>>>>> >>>>>> >>>>>>>message): >>>>>>>-if the recipient is local then delivery the message >>>>>>>(-if the recipient is local, but the mailbox does not exist, >>>>>> >>>then >>> >>> >>> >>>>do >>>> >>>> >>>> >>>>>>>nothing, you must not bounce a bounce message) >>>>>>> >>>>>>>-if the recipient is not local but the remote host is >>>>>> >>>>authenticated >>>> >>>> >>>> >>>>>>then >>>>>> >>>>>> >>>>>> >>>>>>>relay the message (although I guess this rarely occurs) >>>>>>>-if the recipient is not local and the remote host is not >>>>>> >>>>>>authenticated >>>>>> >>>>>> >>>>>> >>>>>>>then >>>>>>>do nothing (usual servers simply would not accept the mail) >>>>>>> >>>>>>>BUT: there is no matcher which can decide if the sender is >>>>>> >>>>>>authenticated >>>>>> >>>>>> >>>>>> >>>>>>>or >>>>>>>not, so we cannot configure correctly. >>>>>>> >>>>>>>I think the best configuration - which can be done at this >>>>>> >>>moment >>> >>> >>> >>>>- >>>> >>>> >>>> >>>>>>simply >>>>>> >>>>>> >>>>>> >>>>>>>removes the message if the recipient isn't local and the sender >>>>>> >>>is >>> >>> >>> >>>>>>empty. >>>>>> >>>>>> >>>>>> >>>>>>>----- Original Message ----- >>>>>>>From: "Serge Knystautas" <[EMAIL PROTECTED]> >>>>>>>To: "James Developers List" <[EMAIL PROTECTED]>; >>>>>>><[EMAIL PROTECTED]> >>>>>>>Sent: Tuesday, July 30, 2002 8:21 AM >>>>>>>Subject: Re: Open relay with SMTP-AUTH >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Even if you have a server that only is accepting SMTH AUTH, >>>>>>> >>>it's >>> >>> >>> >>>>>>still >>>>>> >>>>>> >>>>>> >>>>>>>best >>>>>>> >>>>>>> >>>>>>> >>>>>>>>practices to accept "MAIL FROM: <>" messages (i.e., you can't >>>>>>> >>>>just >>>> >>>> >>>> >>>>>>>disable >>>>>>> >>>>>>> >>>>>>> >>>>>>>>that). That said, messages with a null sender should not >>>>>>> >>>leave >>> >>> >>> >>>>your >>>> >>>> >>>> >>>>>>>server, >>>>>>> >>>>>>> >>>>>>> >>>>>>>>so I think it's either a conf issue or a bug in some matcher >>>>>>> >>>>that >>>> >>>> >>>> >>>>>>isn't >>>>>> >>>>>> >>>>>> >>>>>>>>probably capturing that and preventing the relaying. >>>>>>>> >>>>>>>>Serge Knystautas >>>>>>>>Loki Technologies >>>>>>>>http://www.lokitech.com/ >>>>>>>> >>>>>>>>----- Original Message ----- >>>>>>>>From: "Peter M. Goldstein" <[EMAIL PROTECTED]> >>>>>>>>To: "'James Developers List'" <[EMAIL PROTECTED]> >>>>>>>>Sent: Monday, July 29, 2002 8:21 PM >>>>>>>>Subject: FW: Open relay with SMTP-AUTH >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>All, >>>>>>>>> >>>>>>>>>I've just confirmed this on the latest code base. The cause >>>>>>>> >>>>is >>>> >>>> >>>> >>>>>>pretty >>>>>> >>>>>> >>>>>> >>>>>>>>>obvious - there is a comment in SMTPHandler.java: >>>>>>>>> >>>>>>>>> // If this is a delivery failure notification >>>>>>>> >>>>(MAIL >>>> >>>> >>>> >>>>>>FROM: >>>>>> >>>>>> >>>>>> >>>>>>>>><>) >>>>>>>>> // we don't enforce authentication >>>>>>>>> if (authRequired && state.get(SENDER) != null) { >>>>>>>>> >>>>>>>>>Removing the (state.get(SENDER) != null) clause closes the >>>>>>>> >>>>open >>>> >>>> >>>> >>>>>>relay. >>>>>> >>>>>> >>>>>> >>>>>>>>>But can anyone clarify the comment? Is this comment >>>>>>>> >>>referring >>> >>> >>> >>>>to >>>> >>>> >>>> >>>>>>>>>messages being generated by the James server in response to >>>>>>>> >>>>local >>>> >>>> >>>> >>>>>>>>>delivery failures? Clearly the code as it stands in >>>>>>>> >>>>insecure... >>>> >>>> >>>> >>>>>>>>>--Peter >>>>>>>>> >>>>>>>>>-----Original Message----- >>>>>>>>>From: [EMAIL PROTECTED] >>>>>>>> >>>>>>[mailto:[EMAIL PROTECTED]] >>>>>> >>>>>> >>>>>> >>>>>>>>>Sent: None >>>>>>>>>To: [EMAIL PROTECTED] >>>>>>>>>Subject: Open relay with SMTP-AUTH >>>>>>>>> >>>>>>>>> >>>>>>>>>Hello >>>>>>>>> >>>>>>>>>I think I found a bug when using SMTP-AUTH >>>>>>>>> >>>>>>>>>if you enable smtp-auth and sends a <> as the sender >>>>>>>>>the servers allows the relay of any message, if you >>>>>>>>>specify a correct email address the server enforces the >>>>>>>> >>>>>>authentication >>>>>> >>>>>> >>>>>> >>>>>>>>>I created a patch for this, is there any other solution? >>>>>>>>> >>>>>>>>>following a session that shows the problem >>>>>>>>> >>>>>>>>>Trying XXXXXX... >>>>>>>>>Connected to XXXXXXXXX. >>>>>>>>>Escape character is '^]'. >>>>>>>>>220 myMailServer SMTP Server (JAMES SMTP Server 2.0a3-cvs) >>>>>>>> >>>>ready >>>> >>>> >>>> >>>>>>Mon, >>>>>> >>>>>> >>>>>> >>>>>>>29 >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>Jul 2002 20:31:04 -0400 >>>>>>>>>helo test >>>>>>>>>250-myMailServer Hello test (XXXXXXX) >>>>>>>>>250 AUTH LOGIN PLAIN >>>>>>>>>mail from: <> >>>>>>>>>250 Sender <> OK >>>>>>>>>rcpt to: <[EMAIL PROTECTED]> >>>>>>>>>250 Recipient <[EMAIL PROTECTED]> OK >>>>>>>>>..... >>>>>>>> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
