Re: [jsieve] RFC5882 or RFC882

[David Leangen]

> Yet another bg topic.

:-)

> Mime4J is an effort to remove that dependency in James. There is still a
> lot of work to do to reach that goal (most notably in the mailet-container).

Is that what the DOM is for? I.e., is this supposed to be the MIME message you 
are talking about?

 —> 
https://github.com/apache/james-mime4j/blob/master/dom/src/main/java/org/apache/james/mime4j/dom/Message.java
 



Cheers,
=David

Re: [jsieve] RFC5882 or RFC882

[Tellier Benoit]

On 22/05/2020 17:19, David Leangen wrote:
>>> Perhaps provide a “default” MailAdapter? In that case, then the factory 
>>> could even just take an email and a SieveScript InputStream and apply the 
>>> default MailAdapter. The method with the MailAdapter signature would only 
>>> be needed for custom MailAdapters.
>>
>> JSIEVE (core) don't depend on "mailet-api". For the sake of minimalist
>> dependencies, I am not sure this is a dependency we want to add. We will
>> have to "adapt" things all the time then.
> 
> Yeah, it is indeed better to reduce compile-time dependencies as much as 
> possible for sure!
> 
> Then again, the Sieve spec appears to be dependent on “valid” emails, which 
> are represented by javax.mail.Message.
> 
> On that note… what is the canonical representation of an email in the James 
> ecosystem? I am guessing that there has to be some kind of lingua franca 
> representation of this core concept, no? Is it javax.mail.Message (which 
> would be a reasonable assumption, and known to all components of the 
> ecosystem)? Of course, it’s ok to have a projection of an email for each 
> component, represented by a different class.
> 
> If javax.mail.Message (I’ll just write j.m.M to save my hands a little 
> writing) is used by all components, and any specialized representation is 
> expected to have a from(j.m.M) and toMessage() method (for example), then it 
> would be trivial to communicate an email between the different components 
> without creating any dependency other than javax.mail.
So...

Yet another bg topic.

First we need to use a common language, and define *entities*:
 - A Mime message represents what you call above a mail. (it is the
content of the letter)
 - A mail is a mime message getting carried other from a sender to a
recipient. So it is a mime message along with SMTP envelop (the full letter)

Yes, historically, javax.mail.Message is used to represent a Mime object
in James.

This is a pretty bad thing because javax.mail is pretty hard to use.

Mime4J is an effort to remove that dependency in James. There is still a
lot of work to do to reach that goal (most notably in the mailet-container).

> If jSieve could accept a javax.mail.Message, then the default adapter would 
> work.

That wouldn't be wise.

JSieve is a separated library in order to encourage usage outside of James.

We can't expect users versions to be aligned.

For users not relying on javax.mail.Message, they would still have to
carry over transformation of the mail entity.

Also, the entity Sieve expects is a mail, not a mime message. That would
be the wrong entity.

> 
> Cheers,
> =David
> 
> 
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
> 

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [jsieve] RFC5882 or RFC882

[David Leangen]

>> Perhaps provide a “default” MailAdapter? In that case, then the factory 
>> could even just take an email and a SieveScript InputStream and apply the 
>> default MailAdapter. The method with the MailAdapter signature would only be 
>> needed for custom MailAdapters.
> 
> JSIEVE (core) don't depend on "mailet-api". For the sake of minimalist
> dependencies, I am not sure this is a dependency we want to add. We will
> have to "adapt" things all the time then.

Yeah, it is indeed better to reduce compile-time dependencies as much as 
possible for sure!

Then again, the Sieve spec appears to be dependent on “valid” emails, which are 
represented by javax.mail.Message.

On that note… what is the canonical representation of an email in the James 
ecosystem? I am guessing that there has to be some kind of lingua franca 
representation of this core concept, no? Is it javax.mail.Message (which would 
be a reasonable assumption, and known to all components of the ecosystem)? Of 
course, it’s ok to have a projection of an email for each component, 
represented by a different class.

If javax.mail.Message (I’ll just write j.m.M to save my hands a little writing) 
is used by all components, and any specialized representation is expected to 
have a from(j.m.M) and toMessage() method (for example), then it would be 
trivial to communicate an email between the different components without 
creating any dependency other than javax.mail.

If jSieve could accept a javax.mail.Message, then the default adapter would 
work.


Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [jsieve] RFC5882 or RFC882

[Tellier Benoit]

I created https://issues.apache.org/jira/browse/JSIEVE-116 based on this
thread.

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [jsieve] RFC5882 or RFC882

[Tellier Benoit]

[...]

>> - The SieveFactory takes a SieveScript inputstream, and a Mail adapter,
>> and returns a list of Action that results from the sieve script
>> execution against the supplied email.
> 
> +1
> 
> Perhaps provide a “default” MailAdapter? In that case, then the factory could 
> even just take an email and a SieveScript InputStream and apply the default 
> MailAdapter. The method with the MailAdapter signature would only be needed 
> for custom MailAdapters.

JSIEVE (core) don't depend on "mailet-api". For the sake of minimalist
dependencies, I am not sure this is a dependency we want to add. We will
have to "adapt" things all the time then.

Regards,

Benoit

-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [jsieve] RFC5882 or RFC882

[David Leangen]

Thanks for the comments.

>> So I gather than the email must be RFC882 compliant, which means that its 
>> implementing class must also be RFC882 compliant. Further, the implementing 
>> class must also be RFC5228 compliant. So the email object must effectively 
>> be both RFC882 **AND** RFC5882 compliant.
>> 
>> First, what is the relationship with RFC882? This is the spec for "DOMAIN 
>> NAMES - CONCEPTS AND FACILITIES”, so I’m having trouble understanding why it 
>> is relevant here.
> 
> Likely none.

> RFC-822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES seems
> related to too. And given the "one number mistake rule" is likely what
> the javadoc author intended to reference.



The “one number mistake rule” indeed! Just not by the Javadoc author, but by 
me. 
The Javadoc does indeed say RFC822. 

Even still, how the different concepts are made to come together here is still 
a bit confusing to me, so:

> We would need to rework it to make its usage easier.

That would be really helpful.


> And this should be likely done before documenting it (why invest in
> documentation that will outdate itself?)

+1

> Given our previous exchanges I **propose** a first step:
> 
> - As part of JSieve provide a `MailAdapter` class, that "just
> represent" a mail. It would be a Plain Old Java Object (POJO) along with
> it's builder. (it adapts a mail within JSieve context)

+1

> - The SieveFactory takes a SieveScript inputstream, and a Mail adapter,
> and returns a list of Action that results from the sieve script
> execution against the supplied email.

+1

Perhaps provide a “default” MailAdapter? In that case, then the factory could 
even just take an email and a SieveScript InputStream and apply the default 
MailAdapter. The method with the MailAdapter signature would only be needed for 
custom MailAdapters.



> ```
> void runSieveScript(JamesMail jamesMail, InputStream sieveScript) {
>MailAdapter mailAdapter = MailAdapter.builder()
>.subject(jamesMail.getSubject)
>.to(jamesMail.headers().to())
>...
>.build();
>List actions = sieveFactory.evaluate(sieveScript, mailAdapter);
>// Do stuff with the actions
> }
> ```

...

> That way library users don't need to extend anything

+1

> interacts with a simple POJO they need to populate

+1

> and can implement the actions they want to support.

+1

> This makes the entire API easier to discover. And it looks achievable with 
> limited investment.



> I also believe documenting that will be easier.

Indeed!


> I just want to conclude that, by challenging what exists, you are far
> from loosing your time. You might very well have been initiating the
> most important contribution to the JSieve library in the past few years.

Ok, good to know. Thanks!

Cheers,
=David


-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Re: [jsieve] RFC5882 or RFC882

[Tellier Benoit]

Hi David.

It looks like you struggled much with badly written javadoc...

> (I am assuming that “RFC32028” is actually RFC3028 [5], which should be 
> updated to RFC5228 [6]).

That typo needs to be fixed.

> So I gather than the email must be RFC882 compliant, which means that its 
> implementing class must also be RFC882 compliant. Further, the implementing 
> class must also be RFC5228 compliant. So the email object must effectively be 
> both RFC882 **AND** RFC5882 compliant.
> 
> First, what is the relationship with RFC882? This is the spec for "DOMAIN 
> NAMES - CONCEPTS AND FACILITIES”, so I’m having trouble understanding why it 
> is relevant here.

Likely none.

Reading "RFC3028"

```
This document describes a language for filtering e-mail messages at
time of final delivery.
```

Emails refers to SMTP here, and the closer relevant RFC number I can get is

RFC-821 SIMPLE MAIL TRANSFER PROTOCOL

RFC-822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES seems
related to too. And given the "one number mistake rule" is likely what
the javadoc author intended to reference.

Clearly I would advocate referencing a "modern" SMTP RFC like RFC-5321,
with the wording "represent a e-mail messages at
time of final delivery as per RFC5321"...

> Also, for some reason the name “MailAdapter” is throwing me off. Yes, it is 
> adapting a “mail” object, but in a way that it can be tested by a filter. So 
> am I correct to think of “MailAdapter” as a “SieveTestAdapter” that takes a 
> Mail as an argument?
> 
> I live in Japan, where electricity is 100V. If I were to go to France, for 
> example, where the voltage is 240V, I would not take a “100V” adapter because 
> I already have a product that works with 100V. Rather, I would need a “240V” 
> adapter because I want to convert my 100V product to be used with a 240V 
> grid. So for me it is more natural to name the adapter with the thing I am 
> adapting it to, not the thing that gets adapted.
> 
> 
> Am I understanding all this correctly?

+1
> If so, then the next step to be able to explain to others how to use this 
> library is to explain how to validate the email (and get a 
> “RFC882CompliantMail” object, then adapt that to a “RFC5228Compliant” 
> object). The only example I can find is 
> org.apache.james.transport.mailets.jsieve.SieveMailAdapter, but that is 
> bringing together so many other things that it is diverging, rather than 
> converging, making this task much more complicated than I expected it would 
> be.
> 
> I don’t need to understand the innards of the library, just like any user of 
> the library does not need to know every line of code. However, it would be 
> nice to understand how to use it.
> 
> Any pointers would be useful, else I will soon run out of time and energy and 
> will have to move on to the next task. I was expecting that the code would be 
> written in a way to make it easier to understand. Am I missing something 
> obvious, or am I going down the wrong track?

I think you proved the current JSieve API to be badly designed.

We would need to rework it to make its usage easier.

And this should be likely done before documenting it (why invest in
documentation that will outdate itself?)

Given our previous exchanges I **propose** a first step:

 - As part of JSieve provide a `MailAdapter` class, that "just
represent" a mail. It would be a Plain Old Java Object (POJO) along with
it's builder. (it adapts a mail within JSieve context)

 - The SieveFactory takes a SieveScript inputstream, and a Mail adapter,
and returns a list of Action that results from the sieve script
execution against the supplied email.

 -

Given the following proposal a usage examples would look like:

```
void runSieveScript(JamesMail jamesMail, InputStream sieveScript) {
MailAdapter mailAdapter = MailAdapter.builder()
.subject(jamesMail.getSubject)
.to(jamesMail.headers().to())
...
.build();
List actions = sieveFactory.evaluate(sieveScript, mailAdapter);
// Do stuff with the actions
}
```

That way library users don't need to extend anything, interacts with a
simple POJO they need to populate, and can implement the actions they
want to support. This makes the entire API easier to discover. And it
looks achievable with limited investment.

I also believe documenting that will be easier.

If there is no objection, I will create a JIRA as an output of this
discussion.

I just want to conclude that, by challenging what exists, you are far
from loosing your time. You might very well have been initiating the
most important contribution to the JSieve library in the past few years.

Cheers,

Benoit

> 
> Cheers,
> =David
> 
> 
> [1] 
> https://github.com/apache/james-jsieve/blob/1052708f5b00764b5e3fec39016e0abfc0bbadd4/core/src/main/java/org/apache/jsieve/SieveFactory.java#L40
> [2] 
>