Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

COMP30023 Project 2
Email client

1 Project Overview

The aim of this project is to familiarize you with socket programming. Your task is to write a simple email client that downloads and parses email from a standards-compliant IMAP server.

Writing network code relies on conformance to standards, and so part of this project is to look up the relevant standards (Requests for Comments, RFCs). You may also refer to online tutorials; if you do, then please mention them in the comments of your code.

Your email client must be written in C or, if you get prior permission, in Rust. Submissions that do not compile and run on a cloud VM may receive zero marks.

2 Project Details

2.1 Program execution / command line arguments

The program should be be launched using the command:

The options beginning with “-” can occur in any order, including between and/or after the 2 positional arguments.

The arguments in square brackets are optional.

All assessed output must be printed to stdout.

If you want to output debugging information, use stderr.

2.2 Logging on

• Create an IPv6 socket (or fall back to IPv4 if IPv6 is not supported) on port 143 (or a TLS socket on port 993 if you are doing the extension task and -t was specified) to the host named on the command line.
• Log in to the IMAP server using: tag LOGIN username password

Each line ends with the standard internet end-of-line sequence \r\n (not the standard C end-of-line).

If this succeeds, you will receive a string starting with the tag, followed by a single space, (a case-insensitive) OK, and another single space. For more details, refer to the response, response-done, and response

-tagged rules of the formal syntax.

If it fails, you should print the string Login failure\n to stdout and exit with status 3.

You may assume that the LOGINDISABLED capability will not be advertised, and do not need to support

RFC5738: IMAP Support for UTF-8.

tag SELECT folder

If the folder doesn’t exist, print the string Folder not found\n to stdout and exit with status 3.

You should read from the folder INBOX if no folder is specified on the command line.

The next steps depend on which command is being executed.

2.3 Retrieve

If messageNum (the message sequence number) was not specified on the command line, then fetch the last added message in the folder (Hint: Take a look at the seq-number rule in the formal syntax).

If this succeeds, the response will be the contents of the email, including the headers.

For more details, refer to the response, message-data, and msg-att-static rules of the formal syntax.

If message with sequence number messageNum does not exist, then print the string Message not found\n to stdout and exit with status 3 (apply this to parse and mime also).

Once you have retrieved the email, print the raw email to stdout and exit with status 0.

2.4 Parse

You may get this information from the raw email, or by issuing more specific IMAP commands such as

BODY.PEEK[HEADER.FIELDS (FROM)] or ENVELOPE that explicitly fetch header fields.

Note that a header field body may be split over multiple lines using RFC 5322’s “folding” syntax. You must unfold such lines before printing, so that each header is printed as a single line.

2.5 MIME

MIME encoding (RFC 2045, RFC 2046) is used to encode attachments, and also to allow both an HTML and plain text version of an email. In this project, it is introduced by headers of the form:

MIME-Version: 1.0

Content-type: multipart/alternative; boundary="boundary parameter value"

• The MIME-Version header, with value of 1.0 (There will be no “comment strings”.)

• The Content-Type header, with multipart/alternative media type, and boundary parameter

The body of the email will then contain body parts separated by boundary delimiter lines like:

where the boundary parameter value matches the value in the Content-Type header of the top-level message.

The final block is ended with a line:

CRLF --boundary-parameter-value--

Your program is expected to match and print the first UTF-8 text/plain body part:

• Content-Type: text/plain, with charset=UTF-8

• Content-Transfer-Encoding: quoted-printable | 7bit | 8bit

Note that header field names, parameter names, charset parameter value, Content-Transfer-Encoding mechanism,

Content-Type media type and subtype are case-insensitive.

The RFC allows multipart entities to be nested, but that is not required by this project.

If the mime command is given, the output should consist only of the body area of the the first utf-8 text/plain body part that was matched, with no further decoding.

2.6 List

If the command is list, then print to stdout the subject lines of all the emails in the specified folder, sorted by message sequence number. If the mailbox is empty, print nothing and exit with status 0.

Output the message sequence number, followed by a colon and a space, followed by the body of the subject header (not the initial Subject: or any additional leading or trailing whitespace). For example:

You can use the SEARCH command from RFC 3501 section 6.4.4, or the FETCH command from RFC 3501 section 6.4.5 with the range 1:*, or any other method you choose.

You may assume that the contents of the selected mailbox will not be changed during this list operation.

2.7 Stretch Goal – TLS using OpenSSL

This task is only for those aiming to get 15/15 for the assignment. If you think the assignment is too big, then focus on the non-stretch goals.

If setting up the connection fails, provide meaningful output to stdout and then exit with status 2.

If implementing in C, you may find the following OpenSSL functions helpful.

Note that the test server will have a self-signed certificate, and so you must add the root certificate to your trust store.

If you implement this extension, you can test your implementation of fetchmail against the IMAP server of an actual email provider. It is suggested that you create a disposable account for this purpose.

For Gmail, You will need to get a Google app password, following the instructions at [https://support. 

google.com/accounts/answer/185833]:

3 Marking Criteria

The marks are broken down as follows:

Task 1. Correctly requests email message 

Your code correctly establishes a connection, navigates to the specified folder and makes at least one of the requests (retrieve, parse, mime or list).

Task 3. Displays headers

Task 4. Displays text/plain version of the email

Task 5. Displays list of email

Task 6. Safety

Your code should not allow injection of IMAP commands through malicious command line arguments or email contents.

Network code should never crash, even if the command line is invalid or the hosts on the other side behave poorly.

If interaction with the server fails at any point, an informative error message should be displayed. The program may either attempt to continue, or exit cleanly.

For the purpose of assessment, use the following predefined status codes:

1. Command-line parsing error, argument validation failure (if implemented)

2. Connection initiation errors

3. Unexpected IMAP or server responses (e.g. unexpected disconnect, random characters)

4. Parse failure (e.g. Expected header is missing (optional), text/plain part not found)

5. Other errors

Task 7. Build quality 

• The repository must contain a Makefile that produces an executable named “fetchmail”, along with all source files required for compilation. Place the Makefile at the root of your repository, and ensure that running make places the executable there too.
• Make sure that all source code is committed and pushed. make clean && make -B && ./fetchmail <...arguments> should execute the submission.
• Compiling using “-Wall” should yield no warnings (C).
• Compiling using “cargo build” should yield no warnings (Rust).
• Do not suppress any default warnings inline.
• Running make clean should remove all object code and executables.
• Do not commit fetchmail or other executable files. Scripts (with .sh extension) are exempted.

If this fails for any reason, you will be told the reason, and be allowed to resubmit (with the usual late penalty). If it still fails, you will get 0 for Tasks 1–6 and the stretch goal. Test this by committing regularly, and checking the CI feedback. (If you need help, ask on the forum.)

Task 8. Quality of software practices

4 Submission

You must not use or adapt any code or libraries relating to IMAP or Internet Messages.

You may link with the openssl library present on the system, or use any of the libc, openssl, openssl sys, and openssl-probe crates for the purpose of implementing TLS or (optionally) SASL Authentication only. openssl must be dynamically linked. The openssl-src crate must not be included as a sub-dependency.

For Rust submissions, any invocation of cargo build must include the --frozen, --offline, and --release options. A vendor rule must be defined in your Makefile, to vendor crates prior to offline compilation. The vendor directory must be present in .gitignore, and must not be committed at any stage of the git history. The vendor directory must not be removed by make clean. Cargo.lock files must be committed. Unless otherwise approved, your crate should not rely on any custom build scripts. You may assumethat the latest stable version of Rust will be installed in the build environment.

If you import code from somewhere else, within the collaboration policy, there should be a commit that does nothing but import that code, with a commit message saying “importing code from [reference]”. You should then customise the imported code in later commits.

GitHub

We strongly encourage you to commit your code at least once per day. Be sure to push after you commit. This is important not only to maintain a backup of your code, but also because the git history may be considered for matters such as special consideration, extensions and potential plagiarism. Proper use of git will have a positive effect on the mark you get for quality of software practices.

Submission

Executable files (that is, all files with the executable bit that are in your repository other than .sh files) will be removed before marking. Hence, ensure that none of your source files have the executable bit.

2. Submit the full 40-digit SHA1 hash of the commit you want us to mark to the Project 2 Assignment on the LMS.

You are allowed to update your chosen commit by resubmitting the LMS assignment as many times as de sired. However, only the last commit hash submitted to the LMS before the deadline (or approved extension) will be marked without a late penalty.

Please be aware that we will only mark the commit submitted via the LMS. It is your responsibility to ensure that the submission is correct and corresponds to the commit you want us to mark.

We strongly encourage you to allow sufficient time to follow the submission process outlined above. Leaving it to the last minute usually results in a submission that is a few minutes to a few hours late, or in the submission of the incorrect commit hash. Either case leads to late penalties.

The submission date is determined solely by the date in which the LMS assignment was submitted. Forgetting to submit via the LMS or submitting the wrong commit hash will result in a late penalty that will apply regardless of the commit date.

We will not give partial marks or allow code edits for either known or hidden cases without applying a late penalty (calculated from the deadline).

Extension policy: If you believe you have a valid reason to require an extension, please fill in the Project 2 extension request form available on the LMS at the earliest opportunity, which in most instances should be well before the submission deadline. Extensions will not be considered otherwise. Requests for extensions are not automatically granted and are considered on a case-by-case basis. You are required to submit supporting evidence such as a medical certificate. In addition, your git history should illustrate the progress made on the project up to the date of your request.

If you have a chronic condition or an AAP, please complete an extension request early, even if you hope not to need it. This will allow us to spend more time helping people near the deadline instead of doing paperwork. If you need special consideration, an extension may not be the best way to help you, especially if you would need a long extension. When you apply, please think of other things we could do to help you to submit on time.

5 Testing

Project 2 Repository: The project skeleton and sample outputs are available from: feit-comp30023-2024/project2.

Continuous Integration Testing:

The requisite ci.yml file has been provisioned and placed in your repository, but is also available from the

6 Team Work

7 Getting help

8 Collaboration and Plagiarism

Note also that solicitation of solutions via posts to online forums, whether or not there is payment involved, is also Academic Misconduct. You should not post your code to any public location (e.g., GitHub) until final subject marks are released.

Do not post your code on the subject’s discussion board Ed, except in a Private thread.

Plagiarism policy:

Using git properly is an important step in the verification of authorship. We should see the stages of your codebeing written, not just the finished product.

If the AI has built you something that gains you points for Task 1, then you will not get points for Task 1; the AI will get all those points.

If the AI has built you something that gains no marks by itself, but you only need to modify five lines to get something that works, then you will get credit for identifying and modifying those five lines.

If these rules seem too strict, then do not use the AI tools.

These issues are new, and this may not be the best policy, but it is this year’s policy. If you have suggestions for better rules for future years, please mention them on the forum.