a-mango / dai-lab-smtp Goto Github PK

Some constructors erroneously have a "package" visibility constructor which should be public.

Create the class files and public methods necessary to testing. Leave them empty and return null if needed.

Depends on #2

Create lists of victims emails and prank messages.
Put them in the resources folder.

Add support to specify port and host as well as a verbose mode

Fix unchecked input of the groupSize variable in the main function of the SmtpClient class. We should check for 0 and probably restrict the maximum limit.

Maven error:

Error: /home/runner/work/dai-lab-smtp/dai-lab-smtp/smtpclient/src/main/java/ch/heig/dai/lab/smtp/Client.java:[48,23] unreported exception java.io.FileNotFoundException; must be caught or declared to be thrown

Error probably introduced by pr #25

The EHLO step of the SMTP exchange doesn't work correctly. The client prints multiple unexpected even though the mail is successfully delivered to the server.

Fix the Parser class using wrong method parameters in class diagram.

Refactor class names to something more telling. Exemple: Parser becomes GroupParser, Worker becomes MailWorker, etc.

• Generate some assets of the execution of the program

We should create some basic tests for each class to insure that each component works well individually. We'll naturally skip testing of trivial accessors.

We should create a class diagram before starting to code. This would make collaboration easier by allowing us to split concerns between team members.

Some classes of the diagram have their member declarations inverse : String Foo instead of Foo: String.

• Fix the format of the messages which shouldn't include any quotes at the start or the end of the message.
• Use more subtle texts which include special characters and escape sequences

See https://ncona.com/2011/06/using-utf-8-characters-on-an-e-mail-subject/

The error handles in run method of the Handler class should throw the caught exception for it to be caught higher up in the call hierarchy.

This was not caught during the original PR review and should be fixed with another bugfix PR.

• Rename the methods in the enum classes as per the class diagram
• General cleanup
• Check if possible to implement them as maps or as enums nested withing the MailWorker

Extend the validation of the input. Check for :

an invalid number of groups, an invalid e-mail address that does not contain a '@' character, an invalid format

• Check that input is valid utf-8 or ascii
• Check if first line matches email regex for email list validation

Add Runnable interface implementation to Handler class and refactor private members.

• Fix MailDev port number not being 1025 and 1080 in order to comply with instructions.

Refactor the parser class to be more reusable (OO)

• Store the messages and emails as an ArrayList to be able to remove them or mark them as picked
• Create methods that can random the lists on the fly
• Avoid throwing in the constructor

Create a Github workflow that packages the software, creates and tags release on GitHub (taking it's data from the Maven file). The worker must only be trigger on merge on the main branch.

See Publishing Java packages with Maven.

The name of the branch should probably be something distinctive e.g. "ci-packaging".

Create the report in the README.md file.

Excerpt from INSTRUCTIONS.md :

• A brief description of your project: if people exploring GitHub find your repo, without a prior knowledge of the API course, they should be able to understand what your repo is all about and whether they should look at it more closely.

• Instructions for setting up your mock SMTP server. The user who wants to experiment with your tool but does not really want to send pranks immediately should be able to use a mock SMTP server.

• Clear and simple instructions for configuring your tool and running a prank campaign. If you do a good job, an external user should be able to clone your repo, edit a couple of files and send a batch of e-mails in less than 10 minutes.

• A description of your implementation: document the key aspects of your code. It is a good idea to start with a class diagram. Decide which classes you want to show (focus on the important ones) and describe their responsibilities in text. It is also certainly a good idea to include examples of dialogues between your client and an SMTP server (maybe you also want to include some screenshots here).

We could refactor the SmtpProcedureStep enumeration by renaming it SmtpCommand and adding values with the command string to the enum.

Remove unused variables from classes and enums

Make class implementations follow the UML class diagram

Create tests that can run the program and the mock smtp server programmatically to check their behavior.

The parser does not handle the verification of uniqueness while creating the groups.

• Revisit the UML diagram to change the string array to a list
• Refactor the code the remove a picked sender/victim or message from the list, hence making sure no repetitions ever happen
• Extend the tests to check for this scenario

Add more information to the header section of the message (DATA part of the conversation). Necessary changes may include refactoring the Mail record and Worker class. Tests also need to be adjusted.

Example :

C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C:     05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <[email protected]>
C: Subject:  The Next Meeting of the Board
C: To: [email protected]
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C:                         John.
C: .
S: 250 OK

Multiple changes done over the last few days should be shown in the class diagram.

• Worker class
• Client class