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]>
> 




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to