parsing email with mime4j - email

I encountered a problem when parsing email with mime4j.
The email has an attachment, and I use MimeStreamParser to parse it.
The parser does not call startMultipart method at all. Instead, it only calls body method once, and the BodyDescriptor is "text/plain".
I do not know the root of this problem, the email format or my program?
Here is my test program:
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStream;
import org.apache.james.mime4j.*;
import org.apache.james.mime4j.dom.BinaryBody;
import org.apache.james.mime4j.dom.Body;
import org.apache.james.mime4j.dom.Entity;
import org.apache.james.mime4j.dom.Header;
import org.apache.james.mime4j.dom.Message;
import org.apache.james.mime4j.dom.MessageBuilder;
import org.apache.james.mime4j.dom.Multipart;
import org.apache.james.mime4j.dom.TextBody;
import org.apache.james.mime4j.dom.address.Mailbox;
import org.apache.james.mime4j.dom.address.MailboxList;
import org.apache.james.mime4j.dom.field.AddressListField;
import org.apache.james.mime4j.dom.field.ContentTypeField;
import org.apache.james.mime4j.dom.field.DateTimeField;
import org.apache.james.mime4j.dom.field.UnstructuredField;
import org.apache.james.mime4j.field.address.AddressFormatter;
import org.apache.james.mime4j.message.BodyPart;
import org.apache.james.mime4j.message.MessageImpl;
import org.apache.james.mime4j.message.DefaultMessageBuilder;
import org.apache.james.mime4j.message.SimpleContentHandler;
import org.apache.james.mime4j.parser.ContentHandler;
import org.apache.james.mime4j.parser.MimeStreamParser;
import org.apache.james.mime4j.stream.BodyDescriptor;
import org.apache.james.mime4j.stream.Field;
import org.apache.james.mime4j.stream.MimeConfig;
public class TestClass extends SimpleContentHandler{
public static void main(String[] args) throws MimeException, IOException {
ContentHandler handler = new TestClass();
MimeConfig config = new MimeConfig();
MimeStreamParser parser = new MimeStreamParser(config);
parser.setContentHandler(handler);
InputStream instream = new FileInputStream("mail/testuser1");
try {
parser.parse(instream);
} finally {
instream.close();
}
}
#Override
public void headers(Header arg0) {
// TODO Auto-generated method stub
System.out.println("headers args: "+arg0);
}
#Override
public void body(BodyDescriptor bd, InputStream is) {
// TODO Auto-generated method stub
System.out.println("body descriptor: "+bd);
}
public void startMessage(){
System.out.println("startMessage");
}
public void endMessage(){
System.out.println("endMessage");
}
public void startBodyPart(){
System.out.println("startBodyPart");
}
public void endBodyPart() {
System.out.println("endBodyPart");
}
public void preamble(InputStream is){
System.out.println("preamble");
}
public void epilogue(InputStream is) {
System.out.println("epilogue");
}
public void startMultipart(BodyDescriptor bd){
System.out.println("startMultipart");
}
public void endMultipart() {
System.out.println("endMultipart");
}
public void raw(InputStream is) {
System.out.println("raw");
}
}
Here is a part of my email file:
From MAILER_DAEMON Wed Aug 21 19:24:53 2013
Date: Wed, 21 Aug 2013 19:24:53 +0800
From: Mail System Internal Data <MAILER-DAEMON#mail.abc.com>
Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
Message-ID: <1377084293#mail.abc.com>
X-IMAP: 1377072167 0000000003
Status: RO
This text is part of the internal format of your mail folder, and is not
a real message. It is created automatically by the mail system software.
If deleted, important folder data will be lost, and it will be re-created
with the data reset to initial values.
From testuser2#abc.com Sat Aug 24 10:53:42 2013
Return-Path: <testuser2#abc.com>
X-Original-To: testuser1#abc.com
Delivered-To: testuser1#abc.com
Received: from shupc (unknown [192.168.75.130])
by mail.abc.com (Postfix) with SMTP id C0F5B1EFBC3
for <testuser1#abc.com>; Sat, 24 Aug 2013 10:53:42 +0800 (CST)
Message-ID: <7F1C30C9CB284CA594D01CBE210257D3#shupc>
From: "john" <testuser2#abc.com>
To: "smith" <testuser1#abc.com>
Subject: aaa
Date: Sat, 24 Aug 2013 10:53:42 +0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000B_01CEA0B8.32903020"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512
X-UID: 3
Status: O
Content-Length: 386430
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01CEA0B8.32903020
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000C_01CEA0B8.32903020"
------=_NextPart_001_000C_01CEA0B8.32903020
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: base64
dGVzdCBhYSBiYiBjYw==
------=_NextPart_001_000C_01CEA0B8.32903020
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w
MC4yOTAwLjU1MTIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj50ZXN0IGFhIGJiIGNjPC9G
T05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo=
------=_NextPart_001_000C_01CEA0B8.32903020--
------=_NextPart_000_000B_01CEA0B8.32903020
Content-Type: application/octet-stream;
name="10112716229607.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="10112716229607.doc"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAFAAAAKAIAAAAAAAAA
EAAAKgIAAAEAAAD+////AAAAACMCAAAkAgAAJQIAACYCAAAnAgAA////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAcWAJBAAA8FK/AAAAAAAAEAAAAAAABgAArJ0CAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAA
AAAECBYAOBIDABM6AQATOgEA1gwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w

The problem is with the sample email which not multipart. It contains, as inline text, a multipart email.
Remove the first headers ("FROM MAILER") and then make sure all lines following after Content-Type are indented (eg charset and boundary) by at least one whitespace character as required by the spec (RFC822 or later) or remove the linefeed. See example:
Change from :
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000B_01CEA0B8.32903020"
to either:
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000B_01CEA0B8.32903020"
or:
Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01CEA0B8.32903020"
Alternatively, try a different message.

Use the following library based on mime4j:
email-mime-parser
The provided sample code takes care of email parsing and the resulting 'email' object provides convenience method for the solution of your problem :
ContentHandler contentHandler = new CustomContentHandler();
MimeConfig mime4jParserConfig = new MimeConfig();
BodyDescriptorBuilder bodyDescriptorBuilder = new DefaultBodyDescriptorBuilder();
MimeStreamParser mime4jParser = new MimeStreamParser(mime4jParserConfig,DecodeMonitor.SILENT,bodyDescriptorBuilder);
mime4jParser.setContentDecoding(true);
mime4jParser.setContentHandler(contentHandler);
InputStream mailIn = 'Provide email mime stream here';
mime4jParser.parse(mailIn);
Email email = ((CustomContentHandler) contentHandler).getEmail();

Related

Hide server version from header in jetty

I know config.setSendServerVersion(false); should hide the server version from Header.
But it's not happening even I debug the code get into
public void setSendServerVersion(boolean sendServerVersion) {
this._sendServerVersion = sendServerVersion;
}
And found sendServerVersion always true even we are passing false.
Here is how I'm calling
HttpConfiguration http_config = new HttpConfiguration();
http_config.setOutputBufferSize(32768);
http_config.setSendServerVersion(false);
Can somebody help me out with how to remove the header server?
Content-Type: text/html;charset=utf-8
Date: Thu, 28 Oct 2021 10:57:29 GMT
Server: Jetty(9.4.42.v20210604)
Strict-Transport-Security: max-age=31556926; includeSubDomains
Transfer-Encoding: chunked
.
.
.
Configuring the common Response headers is definitely done with the HttpConfiguration, but it has to be tied to a specific ServerConnector for that configuration to have any impact.
Take this example.
Available on jetty-project/embedded-jetty-cookbook as HttpConfigExample
Pay attention to the branch on embedded-jetty-cookbook, as there are examples for jetty-9.4.x, jetty-10.0.x, and also jetty-11.0.x
package org.eclipse.jetty.cookbook;
import java.io.IOException;
import java.net.URI;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.eclipse.jetty.client.HttpClient;
import org.eclipse.jetty.client.api.ContentResponse;
import org.eclipse.jetty.server.HttpConfiguration;
import org.eclipse.jetty.server.HttpConnectionFactory;
import org.eclipse.jetty.server.Request;
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.server.ServerConnector;
import org.eclipse.jetty.server.handler.AbstractHandler;
import org.eclipse.jetty.util.component.LifeCycle;
public class HttpConfigExample
{
public static void main(String[] args) throws Exception
{
Server server = new Server();
HttpConfiguration httpConfigOff = new HttpConfiguration();
httpConfigOff.setSendDateHeader(false);
httpConfigOff.setSendServerVersion(false);
httpConfigOff.setSendXPoweredBy(false);
ServerConnector connectorOff = new ServerConnector(server, new HttpConnectionFactory(httpConfigOff));
connectorOff.setPort(9090);
server.addConnector(connectorOff);
HttpConfiguration httpConfigDefault = new HttpConfiguration();
ServerConnector connectorDefault = new ServerConnector(server, new HttpConnectionFactory(httpConfigDefault));
connectorDefault.setPort(9191);
server.addConnector(connectorDefault);
server.setHandler(new AbstractHandler()
{
#Override
public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException
{
response.setCharacterEncoding("utf-8");
response.setContentType("text/plain");
response.getWriter().println("Greetings.");
baseRequest.setHandled(true);
}
});
HttpClient client = new HttpClient();
try
{
client.start();
server.start();
// Let's show what the default Response headers look like.
dumpResponse("Default Response", client.GET(URI.create("http://localhost:9191/")));
// Let's show what the default Response headers look like.
dumpResponse("Configured Response", client.GET(URI.create("http://localhost:9090/")));
}
finally
{
LifeCycle.stop(server);
LifeCycle.stop(client);
}
}
private static void dumpResponse(String heading, ContentResponse response)
{
System.out.printf("--- %s ---%n", heading);
System.out.printf("Request to %s%n", response.getRequest().getURI());
System.out.printf("Response: %s %d %s%n", response.getVersion(), response.getStatus(), response.getReason());
System.out.println(response.getHeaders());
System.out.println(response.getContentAsString());
}
}
This sets up 2 ServerConnector objects ...
On port 9191 is the default HttpConfiguration
On port 9090 is the configured (some common response headers turned off) HttpConfiguration
If we make a simple request to both ports we can see the results ...
--- Default Response ---
Request to http://localhost:9191/
Response: HTTP/1.1 200 OK
Date: Thu, 28 Oct 2021 13:22:41 GMT
Content-Type: text/plain;charset=UTF-8
Content-Length: 11
Server: Jetty(9.4.44.v20210927)
Greetings.
--- Configured Response ---
Request to http://localhost:9090/
Response: HTTP/1.1 200 OK
Content-Type: text/plain;charset=UTF-8
Content-Length: 11
Greetings.

Delphi/Indy 10 - Sending a text or HTML email with attachments adds an attachment for the text (body) itself

For years, we've been using Indy 10 to send emails (text, not HTML) with one or more PDF attached to it and we never had any problem.
Recently (maybe since Tokyo release 3 ?), our customers noticed that the text part of the email (body) is now an attachment and not part of the email itself.
I've searched the Internet for solutions, and everything I tested did not fix this problem.
I tried some of the solutions proposed on StackOverflow by Remy Lebeau with no success.
Here's the code (based on a post found on StackOverflow)
procedure TForm1.btnSendEmailClick(Sender: TObject);
var
smtp : TIdSMTP;
msg : TidMessage;
builder: TIdMessageBuilderHtml;
begin
msg := TidMessage.Create(nil);
try
builder := TIdMessageBuilderHtml.Create();
try
// FIsBodyHtml IS FALSE
if FIsBodyHtml then begin
builder.Html.Text := edText.Lines.Text;
builder.HtmlCharSet := 'utf-8';
builder.HtmlContentTransfer := 'quoted-printable';
end else begin
builder.PlainText.Text := edText.Lines.Text;;
builder.PlainTextCharSet := 'utf-8';
builder.PlainTextContentTransfer := 'quoted-printable';
end;
// Add attached file here
if (edFile.Text <> '') and FileExists(edFile.Text) then begin
builder.Attachments.Add(edFile.Text);
end;
builder.FillMessage(msg);
finally
builder.Free;
end;
msg.From.Name := 'From name here';
msg.From.Address := 'From email address here';
msg.Subject := edSubject.Text;
msg.Recipients.EmailAddresses := edEMail.Text;
// msg.CCList.EmailAddresses := CCAddresses;
// msg.BccList.EmailAddresses := BCCAddresses;
smtp := TIdSMTP.Create(nil);
try
smtp.Host := 'Host IP here';
// Smtp.UseTLS := utNoTLSSupport;
smtp.Port := 25;
// smtp.Username := '';
// smtp.Password := '';
// smtp.AuthType := satDefault;
smtp.Connect();
try
smtp.Send(msg);
finally
smtp.Disconnect;
end;
finally
smtp.Free();
end;
finally
msg.Free();
end;
ShowMessage('EMail with attachment sent.');
end;
RAW data BEFORE our service provider changed something :
X-Spam-Flag: NO
X-Envelope-From: stephans#xys.com
Return-Path: <stephans#xyz.com>
Received: from alt44.smtp-out.videotron.ca (alt44.smtp-out.videotron.ca [23.233.128.31])
by mail124c7.megamailservers.com (8.14.9/8.13.1) with ESMTP id w8IE2EaJ031620
for <stephans#xyz.com>; Tue, 18 Sep 2018 10:02:16 -0400
Received: from STEPHANS (99.99.99.99])
by Videotron with SMTP
id 2GZxgRaQACk662GZygKZJC; Tue, 18 Sep 2018 10:02:14 -0400
Message-ID: <0575a0d8ec54a7560be55a121df5deb7#smtp.videotron.ca>
X-Authority-Analysis: v=2.3 cv=I/dLuuog c=1 sm=1 tr=0
a=dE52as2XWJrk6k5j72Z8kA==:117 a=dE52as2XWJrk6k5j72Z8kA==:17
a=9DvhAHx2yrWFMPxQWpQA:9 a=ddwX9jWfLaJL_gwCi7EA:9 a=QEXdDO2ut3YA:10
a=x4g3fk4yahj5Vy8AyNEA:9 a=n3BslyFRqc0A:10 a=QGevMSd5eboA:10
From: "Stephan St-Denis" <stephans#xyz.com>
Subject: Sending an email with an attachment
To: stephans#xyz.com
Content-Type: multipart/mixed; boundary="sYOn6pS43NerAC6V2swiiWL68DI9=_SoRR"
MIME-Version: 1.0
Date: Tue, 18 Sep 2018 10:02:11 -0400
X-CMAE-Envelope: MS4wfKOiVw8oDz+nXCTnbMSWSKyXaMU478wM3VDSWQBABhzflbVLGHq70qeoq1ROGHLKj2lDQPx1LLDrcmvbcOtrdhj4j8xx2kLFmh3LfsDxgKpXpd44Lyvy
UHG4KDKHPNZy4UAAlgA05WwJ7eshsOWamzFhqA3QrXuliQNQVttLQNbhbjg2fqOR387/8VrwqftGFg==
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-RefID: str=0001.0A020201.5BA10569.0015,ss=1,re=0.000,recu=0.000,reip=0.000,vtr=str,vl=0,cl=1,cld=1,fgs=0
X-CSC: 0
X-CHA: v=2.3 cv=TIBrtWta c=1 sm=1 tr=0 a=C7+rQaujYuxIIavLKnSTDg==:117
a=dE52as2XWJrk6k5j72Z8kA==:17 a=dueAcN81E1cA:10 a=JBFolyDoGHsA:10
a=9DvhAHx2yrWFMPxQWpQA:9 a=ddwX9jWfLaJL_gwCi7EA:9 a=QEXdDO2ut3YA:10
a=x4g3fk4yahj5Vy8AyNEA:9 a=n3BslyFRqc0A:10 a=QGevMSd5eboA:10
X-WHL: LR
X-EsetId: 37303A298E2AB560627366
This is a multi-part message in MIME format
--sYOn6pS43NerAC6V2swiiWL68DI9=_SoRR
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;filename="Attachment"
This is the text that will be sent along with the attached file. This =
email is in text only format and not HTML.
The text should not be attached but should be part of the email.
--sYOn6pS43NerAC6V2swiiWL68DI9=_SoRR
Content-Type: application/pdf;
name="Embarcadero.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="Embarcadero.pdf"
Content-ID: <Embarcadero.pdf>
JVBERi0xLjYKJf////8gd3d3LnN5bmFjdGlzLmNvbQoxIDAgb2JqCjw8Ci9DcmVhdGlvbkRhdGUo
RDoyMDE3MDIxNDE2MjAyMykKL1RpdGxlKENhc19kZV90ZXN0X0NBMS5wZGYpCi9BdXRob3IoTWFj
Q3JhemVlIEluYy4pCi9Qcm9kdWNlcihQREZCb3ggdmVyc2lvbiBpbnRlcm5lIExQQykKL0NyZWF0
b3IoTGVzIFByb2dpY2llbHMgQ29uY2VwdCBpbmMuKQo+PgplbmRvYmoKNSAwIG9iago8PAovTGVu
Z3RoIDMyNTcKPj4Kc3RyZWFtCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA3NjUu
MDAyIFRkCiggICAgPVJFTEVWRSBERSBUUkFOU0FDVElPTj0pIFRqCkVUCkJUCi9GMCAxMiBUZgow
IDAgMCByZwowIFRjCjE5Ljg0MyA3NTMuMDk3IFRkCiggICAgID09VFJBTlNBQ1RJT04gUkVDT1JE
PT0pIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA3NDAuOTA4IFRkCihU
UFYyMjAzNjIzOSAgICAgICAgTUFSQ0g1MDAwMjEwNSkgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAw
IHJnCjAgVGMKMTkuODQzIDcyOS4wMDIgVGQKKFBST0dJQ0lFTFMgQ09OQ0VQVCkgVGoKRVQKQlQK
L0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDcxNy4wOTcgVGQKKDIyMTgsQ1VSRSBMQUJF
TExFKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNzA0LjkwOCBUZAoo
U1QtSkVST01FICAgICwgUUMpIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0
MyA2OTMuMDAyIFRkCihDQVJURS9DQVJEOiBJTlRFUkFDKSBUagpFVApCVAovRjAgMTIgVGYKMCAw
IDAgcmcKMCBUYwoxOS44NDMgNjgxLjA5NyBUZAooTk8uIDQ1NDAgMTIqKiAqKioqIDk2NjcpIFRq
CkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA2NjguOTA4IFRkCihDT01QVEUv
QUNDT1VOVDogQ0hFUVVFL0NIRVFVSU5HKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBU
YwoxOS44NDMgNjU3LjAwMiBUZAooQUlEOiBBMDAwMDAwMjc3MTAxMCkgVGoKRVQKQlQKL0YwIDEy
IFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDY0NS4wOTcgVGQKKEFQUEw6IEludGVyYWMpIFRqCkVU
CkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA2MzIuOTA4IFRkCihFTVBML0NMRVJL
OiAyMDApIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA2MjEuMDAyIFRk
CihTRVEuOiAwMTQgICBMT1QvQkFUQ0g6IDAwNCkgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJn
CjAgVGMKMTkuODQzIDYwOS4wOTcgVGQKKE5PLiBSRUZFUkVOQ0U6IDAwMDAzOSkgVGoKRVQKQlQK
L0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDU5Ni45MDggVGQKKDIwMTcvMDIvMTQgMTY6
MjA6MTQgQ0ExKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNTg1LjAw
MiBUZAooQUNIQVQvUFVSQ0hBU0UgICAgICAgICAgICAkMTAuMDApIFRqCkVUCkJUCi9GMCAxMiBU
ZgowIDAgMCByZwowIFRjCjE5Ljg0MyA1NzMuMDk3IFRkCihBVVRPUi4vQVVUSE9SLjogMTYyMDE0
KSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNTYwLjkwOCBUZAooICAg
ICAgICAgICAwMCAgQVBQUk9VVkVFIC0gTUVSQ0kpIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCBy
ZwowIFRjCjE5Ljg0MyA1NDkuMDAyIFRkCiggICAgIENvbnNlcnZlciBjZXR0ZSBjb3BpZSkgVGoK
RVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDUzNy4wOTcgVGQKKCAgICAgICBw
b3VyIHZvcyBkb3NzaWVycy4pIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0
MyA1MjQuOTA4IFRkCiggICAgICAgICBDT1BJRSA6IENMSUVOVCkgVGoKRVQKQlQKL0YwIDEyIFRm
CjAgMCAwIHJnCjAgVGMKMTkuODQzIDUxMy4wMDIgVGQKKCoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNDY1LjA5
NyBUZAooICAgID1SRUxFVkUgREUgVFJBTlNBQ1RJT049KSBUagpFVApCVAovRjAgMTIgVGYKMCAw
IDAgcmcKMCBUYwoxOS44NDMgNDUyLjkwOCBUZAooICAgICA9PVRSQU5TQUNUSU9OIFJFQ09SRD09
KSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNDQxLjAwMiBUZAooVFBW
MjIwMzYyMzkgICAgICAgIE1BUkNINTAwMDIxMDUpIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCBy
ZwowIFRjCjE5Ljg0MyA0MjkuMDk3IFRkCihQUk9HSUNJRUxTIENPTkNFUFQpIFRqCkVUCkJUCi9G
MCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA0MTYuOTA4IFRkCigyMjE4LENVUkUgTEFCRUxM
RSkgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDQwNS4wMDIgVGQKKFNU
LUpFUk9NRSAgICAsIFFDKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMg
MzkzLjA5NyBUZAooQ0FSVEUvQ0FSRDogSU5URVJBQykgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAw
IHJnCjAgVGMKMTkuODQzIDM4MC45MDggVGQKKE5PLiA0NTQwIDEyKiogKioqKiA5NjY3KSBUagpF
VApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgMzY5LjAwMiBUZAooQ09NUFRFL0FD
Q09VTlQ6IENIRVFVRS9DSEVRVUlORykgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMK
MTkuODQzIDM1Ny4wOTcgVGQKKEFJRDogQTAwMDAwMDI3NzEwMTApIFRqCkVUCkJUCi9GMCAxMiBU
ZgowIDAgMCByZwowIFRjCjE5Ljg0MyAzNDQuOTA4IFRkCihBUFBMOiBJbnRlcmFjKSBUagpFVApC
VAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgMzMzLjAwMiBUZAooRU1QTC9DTEVSSzog
MjAwKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgMzIxLjA5NyBUZAoo
U0VRLjogMDE0ICAgTE9UL0JBVENIOiAwMDQpIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwow
IFRjCjE5Ljg0MyAzMDguOTA4IFRkCihOTy4gUkVGRVJFTkNFOiAwMDAwMzkpIFRqCkVUCkJUCi9G
MCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyAyOTcuMDAyIFRkCigyMDE3LzAyLzE0IDE2OjIw
OjE0IENBMSkgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDI4NS4wOTcg
VGQKKEFDSEFUL1BVUkNIQVNFICAgICAgICAgICAgJDEwLjAwKSBUagpFVApCVAovRjAgMTIgVGYK
MCAwIDAgcmcKMCBUYwoxOS44NDMgMjcyLjkwOCBUZAooQVVUT1IuL0FVVEhPUi46IDE2MjAxNCkg
VGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDI2MS4wMDIgVGQKKCAgICAg
ICAgICAgMDAgIEFQUFJPVVZFRSAtIE1FUkNJKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcK
MCBUYwoxOS44NDMgMjQ5LjA5NyBUZAooICAgICAgICBDT1BJRSA6IE1BUkNIQU5EKSBUagpFVApC
VAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgMjM2LjkwOCBUZAooKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKiopIFRqCkVUCmVuZHN0cmVhbQplbmRvYmoKNCAwIG9iago8PAov
VHlwZS9QYWdlCi9QYXJlbnQgMiAwIFIKL01lZGlhQm94WzAgMCA2MTIgNzkyXQovQ29udGVudHMg
NSAwIFIKPj4KZW5kb2JqCjYgMCBvYmoKCls2MDAgMCAwIDAgNjAwIDAgMCAwIDAgMCA2MDAgMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgCjYwMCA2
MDAgMCAwIDYwMCAwIDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgNjAwIDAgNjAwIDYwMCA2MDAgMCAwIDAgNjAwIDAgMCAwIAowIDYwMCA2MDAg
NjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCBdCmVuZG9iago3IDAgb2JqCjw8Ci9UeXBlL0ZvbnRE
ZXNjcmlwdG9yCi9Gb250TmFtZS9Db3VyaWVyIzIwTmV3Ci9Bc2NlbnQgODMyCi9EZXNjZW50IC0z
MDAKL0l0YWxpY0FuZ2xlIDAKL0NhcEhlaWdodCA4MzIKL0ZsYWdzIDM0Ci9Gb250QkJveFswIDAg
MCAwXQo+PgplbmRvYmoKOCAwIG9iago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1RydWVUeXBlCi9O
YW1lL0YwCi9CYXNlRm9udC9Db3VyaWVyIzIwTmV3Ci9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcK
L0ZpcnN0Q2hhciAzMgovTGFzdENoYXIgMTE4Ci9XaWR0aHMgNiAwIFIKL0ZvbnREZXNjcmlwdG9y
IDcgMCBSCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlL0NhdGFsb2cKL1BhZ2VzIDIgMCBSCj4+
CmVuZG9iagoyIDAgb2JqCjw8Ci9UeXBlL1BhZ2VzCi9LaWRzWwo0IDAgUgpdCi9Db3VudCAxCi9S
ZXNvdXJjZXMgMyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwKL1Byb2NTZXRbL1BERi9UZXh0L0lt
YWdlQ10KL0ZvbnQ8PAovRjAgOCAwIFIKPj4KPj4KZW5kb2JqCnhyZWYKMCAxMAowMDAwMDAwMDAw
IDY1NTM1IGYNCjAwMDAwMDAwMzIgMDAwMDAgbg0KMDAwMDAwNDI4MyAwMDAwMCBuDQowMDAwMDA0
MzU3IDAwMDAwIG4NCjAwMDAwMDM1MjIgMDAwMDAgbg0KMDAwMDAwMDIxMyAwMDAwMCBuDQowMDAw
MDAzNjA3IDAwMDAwIG4NCjAwMDAwMDM5MTEgMDAwMDAgbg0KMDAwMDAwNDA2MiAwMDAwMCBuDQow
MDAwMDA0MjM1IDAwMDAwIG4NCnRyYWlsZXIKPDwKL1NpemUgMTAKL1Jvb3QgOSAwIFIKL0luZm8g
MSAwIFIKL0lEWyg0Mjc4MDY4MDhzZWVkKSg0Mjc4MDY4MDhzZWVkKV0KPj4Kc3RhcnR4cmVmCjQ0
MjYKJSVFT0YK
--sYOn6pS43NerAC6V2swiiWL68DI9=_SoRR--
RAW data AFTER our service provider changed something
X-Spam-Flag: NO
X-Envelope-From: stephans#xyz.com
Return-Path: <stephans#xyz.com>
Received: from alt14.smtp-out.videotron.ca (alt14.smtp-out.videotron.ca [135.19.0.27])
by mail141c7.megamailservers.com (8.14.9/8.13.1) with ESMTP id w8JCvhOr015926
for <stephans#xyz.com>; Wed, 19 Sep 2018 08:57:45 -0400
Received: from STEPHANS ([99.99.99.99])
by Videotron with SMTP
id 2c34gzZ4bMdc62c35g1R7X; Wed, 19 Sep 2018 08:57:43 -0400
Message-ID: <5283e5cb2949102f2e22f509477dacaa#smtp.videotron.ca>
X-Authority-Analysis: v=2.3 cv=PoG9kTE3 c=1 sm=1 tr=0
a=dE52as2XWJrk6k5j72Z8kA==:117 a=dE52as2XWJrk6k5j72Z8kA==:17
a=9DvhAHx2yrWFMPxQWpQA:9 a=PyNp0P9dkJ191ZjJjSMA:9 a=ddwX9jWfLaJL_gwCi7EA:9
a=QEXdDO2ut3YA:10 a=x4g3fk4yahj5Vy8AyNEA:9 a=n3BslyFRqc0A:10 a=QGevMSd5eboA:10
From: "Stephan St-Denis" <stephans#xyz.com>
Subject: Sending an email with an attachment
To: stephans#xyz.com
Content-Type: multipart/mixed; boundary="2oubkSu12F4FBVsrQ1qmkA=_rIo3IvFYNM"
MIME-Version: 1.0
Date: Wed, 19 Sep 2018 08:57:42 -0400
X-CMAE-Envelope: MS4wfBPFtECskEptewv8r0bLuVgVpcybKuamQgK0q+veOE3mDcPmuU0j2BlwRMolPNl4KeDVRtyCVMVmkK8N5jufk8voKnE1l6SnBAVceHp6p6Ohg6KTOIp1
srRHBcfqKq4iTOHzsbt4HfC5vzAuQXm6H3d2pHYX2JNz8N1Pq6ze3mdvvacTtuYNEbvI0Ny8ev9LrA==
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
X-CTCH-RefID: str=0001.0A02020C.5BA247CA.0005,ss=1,re=0.000,recu=0.000,reip=0.000,vtr=str,vl=0,cl=1,cld=1,fgs=0
X-CSC: 0
X-CHA: v=2.3 cv=feyDNXYF c=1 sm=1 tr=0 a=csAb9/S9F4eoTzVqV71Dmw==:117
a=dE52as2XWJrk6k5j72Z8kA==:17 a=WrA80cmexyYA:10 a=JBFolyDoGHsA:10
a=9DvhAHx2yrWFMPxQWpQA:9 a=PyNp0P9dkJ191ZjJjSMA:9 a=ddwX9jWfLaJL_gwCi7EA:9
a=QEXdDO2ut3YA:10 a=x4g3fk4yahj5Vy8AyNEA:9 a=n3BslyFRqc0A:10
a=QGevMSd5eboA:10
X-WHL: LR
X-EsetId: 37303A298E2AB560627264
This is a multi-part message in MIME format
--2oubkSu12F4FBVsrQ1qmkA=_rIo3IvFYNM
Content-Type: multipart/alternative;
boundary="DhsioUcQxViR3rGTk=_q17PSufSL3rps7M"
--DhsioUcQxViR3rGTk=_q17PSufSL3rps7M
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
An HTML viewer is required to see this message
--DhsioUcQxViR3rGTk=_q17PSufSL3rps7M
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
This is the text that will be sent along with the attached file. This =
email is in text only format and not HTML.
The text should not be attached but should be part of the email.
--DhsioUcQxViR3rGTk=_q17PSufSL3rps7M--
--2oubkSu12F4FBVsrQ1qmkA=_rIo3IvFYNM
Content-Type: application/pdf;
name="Embarcadero.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="Embarcadero.pdf"
Content-ID: <Embarcadero.pdf>
JVBERi0xLjYKJf////8gd3d3LnN5bmFjdGlzLmNvbQoxIDAgb2JqCjw8Ci9DcmVhdGlvbkRhdGUo
RDoyMDE3MDIxNDE2MjAyMykKL1RpdGxlKENhc19kZV90ZXN0X0NBMS5wZGYpCi9BdXRob3IoTWFj
Q3JhemVlIEluYy4pCi9Qcm9kdWNlcihQREZCb3ggdmVyc2lvbiBpbnRlcm5lIExQQykKL0NyZWF0
b3IoTGVzIFByb2dpY2llbHMgQ29uY2VwdCBpbmMuKQo+PgplbmRvYmoKNSAwIG9iago8PAovTGVu
Z3RoIDMyNTcKPj4Kc3RyZWFtCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA3NjUu
MDAyIFRkCiggICAgPVJFTEVWRSBERSBUUkFOU0FDVElPTj0pIFRqCkVUCkJUCi9GMCAxMiBUZgow
IDAgMCByZwowIFRjCjE5Ljg0MyA3NTMuMDk3IFRkCiggICAgID09VFJBTlNBQ1RJT04gUkVDT1JE
PT0pIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA3NDAuOTA4IFRkCihU
UFYyMjAzNjIzOSAgICAgICAgTUFSQ0g1MDAwMjEwNSkgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAw
IHJnCjAgVGMKMTkuODQzIDcyOS4wMDIgVGQKKFBST0dJQ0lFTFMgQ09OQ0VQVCkgVGoKRVQKQlQK
L0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDcxNy4wOTcgVGQKKDIyMTgsQ1VSRSBMQUJF
TExFKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNzA0LjkwOCBUZAoo
U1QtSkVST01FICAgICwgUUMpIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0
MyA2OTMuMDAyIFRkCihDQVJURS9DQVJEOiBJTlRFUkFDKSBUagpFVApCVAovRjAgMTIgVGYKMCAw
IDAgcmcKMCBUYwoxOS44NDMgNjgxLjA5NyBUZAooTk8uIDQ1NDAgMTIqKiAqKioqIDk2NjcpIFRq
CkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA2NjguOTA4IFRkCihDT01QVEUv
QUNDT1VOVDogQ0hFUVVFL0NIRVFVSU5HKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBU
YwoxOS44NDMgNjU3LjAwMiBUZAooQUlEOiBBMDAwMDAwMjc3MTAxMCkgVGoKRVQKQlQKL0YwIDEy
IFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDY0NS4wOTcgVGQKKEFQUEw6IEludGVyYWMpIFRqCkVU
CkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA2MzIuOTA4IFRkCihFTVBML0NMRVJL
OiAyMDApIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA2MjEuMDAyIFRk
CihTRVEuOiAwMTQgICBMT1QvQkFUQ0g6IDAwNCkgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJn
CjAgVGMKMTkuODQzIDYwOS4wOTcgVGQKKE5PLiBSRUZFUkVOQ0U6IDAwMDAzOSkgVGoKRVQKQlQK
L0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDU5Ni45MDggVGQKKDIwMTcvMDIvMTQgMTY6
MjA6MTQgQ0ExKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNTg1LjAw
MiBUZAooQUNIQVQvUFVSQ0hBU0UgICAgICAgICAgICAkMTAuMDApIFRqCkVUCkJUCi9GMCAxMiBU
ZgowIDAgMCByZwowIFRjCjE5Ljg0MyA1NzMuMDk3IFRkCihBVVRPUi4vQVVUSE9SLjogMTYyMDE0
KSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNTYwLjkwOCBUZAooICAg
ICAgICAgICAwMCAgQVBQUk9VVkVFIC0gTUVSQ0kpIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCBy
ZwowIFRjCjE5Ljg0MyA1NDkuMDAyIFRkCiggICAgIENvbnNlcnZlciBjZXR0ZSBjb3BpZSkgVGoK
RVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDUzNy4wOTcgVGQKKCAgICAgICBw
b3VyIHZvcyBkb3NzaWVycy4pIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0
MyA1MjQuOTA4IFRkCiggICAgICAgICBDT1BJRSA6IENMSUVOVCkgVGoKRVQKQlQKL0YwIDEyIFRm
CjAgMCAwIHJnCjAgVGMKMTkuODQzIDUxMy4wMDIgVGQKKCoqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNDY1LjA5
NyBUZAooICAgID1SRUxFVkUgREUgVFJBTlNBQ1RJT049KSBUagpFVApCVAovRjAgMTIgVGYKMCAw
IDAgcmcKMCBUYwoxOS44NDMgNDUyLjkwOCBUZAooICAgICA9PVRSQU5TQUNUSU9OIFJFQ09SRD09
KSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgNDQxLjAwMiBUZAooVFBW
MjIwMzYyMzkgICAgICAgIE1BUkNINTAwMDIxMDUpIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCBy
ZwowIFRjCjE5Ljg0MyA0MjkuMDk3IFRkCihQUk9HSUNJRUxTIENPTkNFUFQpIFRqCkVUCkJUCi9G
MCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyA0MTYuOTA4IFRkCigyMjE4LENVUkUgTEFCRUxM
RSkgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDQwNS4wMDIgVGQKKFNU
LUpFUk9NRSAgICAsIFFDKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMg
MzkzLjA5NyBUZAooQ0FSVEUvQ0FSRDogSU5URVJBQykgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAw
IHJnCjAgVGMKMTkuODQzIDM4MC45MDggVGQKKE5PLiA0NTQwIDEyKiogKioqKiA5NjY3KSBUagpF
VApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgMzY5LjAwMiBUZAooQ09NUFRFL0FD
Q09VTlQ6IENIRVFVRS9DSEVRVUlORykgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMK
MTkuODQzIDM1Ny4wOTcgVGQKKEFJRDogQTAwMDAwMDI3NzEwMTApIFRqCkVUCkJUCi9GMCAxMiBU
ZgowIDAgMCByZwowIFRjCjE5Ljg0MyAzNDQuOTA4IFRkCihBUFBMOiBJbnRlcmFjKSBUagpFVApC
VAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgMzMzLjAwMiBUZAooRU1QTC9DTEVSSzog
MjAwKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgMzIxLjA5NyBUZAoo
U0VRLjogMDE0ICAgTE9UL0JBVENIOiAwMDQpIFRqCkVUCkJUCi9GMCAxMiBUZgowIDAgMCByZwow
IFRjCjE5Ljg0MyAzMDguOTA4IFRkCihOTy4gUkVGRVJFTkNFOiAwMDAwMzkpIFRqCkVUCkJUCi9G
MCAxMiBUZgowIDAgMCByZwowIFRjCjE5Ljg0MyAyOTcuMDAyIFRkCigyMDE3LzAyLzE0IDE2OjIw
OjE0IENBMSkgVGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDI4NS4wOTcg
VGQKKEFDSEFUL1BVUkNIQVNFICAgICAgICAgICAgJDEwLjAwKSBUagpFVApCVAovRjAgMTIgVGYK
MCAwIDAgcmcKMCBUYwoxOS44NDMgMjcyLjkwOCBUZAooQVVUT1IuL0FVVEhPUi46IDE2MjAxNCkg
VGoKRVQKQlQKL0YwIDEyIFRmCjAgMCAwIHJnCjAgVGMKMTkuODQzIDI2MS4wMDIgVGQKKCAgICAg
ICAgICAgMDAgIEFQUFJPVVZFRSAtIE1FUkNJKSBUagpFVApCVAovRjAgMTIgVGYKMCAwIDAgcmcK
MCBUYwoxOS44NDMgMjQ5LjA5NyBUZAooICAgICAgICBDT1BJRSA6IE1BUkNIQU5EKSBUagpFVApC
VAovRjAgMTIgVGYKMCAwIDAgcmcKMCBUYwoxOS44NDMgMjM2LjkwOCBUZAooKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKiopIFRqCkVUCmVuZHN0cmVhbQplbmRvYmoKNCAwIG9iago8PAov
VHlwZS9QYWdlCi9QYXJlbnQgMiAwIFIKL01lZGlhQm94WzAgMCA2MTIgNzkyXQovQ29udGVudHMg
NSAwIFIKPj4KZW5kb2JqCjYgMCBvYmoKCls2MDAgMCAwIDAgNjAwIDAgMCAwIDAgMCA2MDAgMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgCjYwMCA2
MDAgMCAwIDYwMCAwIDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg
NjAwIDYwMCA2MDAgNjAwIDYwMCAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgNjAwIDAgNjAwIDYwMCA2MDAgMCAwIDAgNjAwIDAgMCAwIAowIDYwMCA2MDAg
NjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCBdCmVuZG9iago3IDAgb2JqCjw8Ci9UeXBlL0ZvbnRE
ZXNjcmlwdG9yCi9Gb250TmFtZS9Db3VyaWVyIzIwTmV3Ci9Bc2NlbnQgODMyCi9EZXNjZW50IC0z
MDAKL0l0YWxpY0FuZ2xlIDAKL0NhcEhlaWdodCA4MzIKL0ZsYWdzIDM0Ci9Gb250QkJveFswIDAg
MCAwXQo+PgplbmRvYmoKOCAwIG9iago8PAovVHlwZS9Gb250Ci9TdWJ0eXBlL1RydWVUeXBlCi9O
YW1lL0YwCi9CYXNlRm9udC9Db3VyaWVyIzIwTmV3Ci9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcK
L0ZpcnN0Q2hhciAzMgovTGFzdENoYXIgMTE4Ci9XaWR0aHMgNiAwIFIKL0ZvbnREZXNjcmlwdG9y
IDcgMCBSCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlL0NhdGFsb2cKL1BhZ2VzIDIgMCBSCj4+
CmVuZG9iagoyIDAgb2JqCjw8Ci9UeXBlL1BhZ2VzCi9LaWRzWwo0IDAgUgpdCi9Db3VudCAxCi9S
ZXNvdXJjZXMgMyAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwKL1Byb2NTZXRbL1BERi9UZXh0L0lt
YWdlQ10KL0ZvbnQ8PAovRjAgOCAwIFIKPj4KPj4KZW5kb2JqCnhyZWYKMCAxMAowMDAwMDAwMDAw
IDY1NTM1IGYNCjAwMDAwMDAwMzIgMDAwMDAgbg0KMDAwMDAwNDI4MyAwMDAwMCBuDQowMDAwMDA0
MzU3IDAwMDAwIG4NCjAwMDAwMDM1MjIgMDAwMDAgbg0KMDAwMDAwMDIxMyAwMDAwMCBuDQowMDAw
MDAzNjA3IDAwMDAwIG4NCjAwMDAwMDM5MTEgMDAwMDAgbg0KMDAwMDAwNDA2MiAwMDAwMCBuDQow
MDAwMDA0MjM1IDAwMDAwIG4NCnRyYWlsZXIKPDwKL1NpemUgMTAKL1Jvb3QgOSAwIFIKL0luZm8g
MSAwIFIKL0lEWyg0Mjc4MDY4MDhzZWVkKSg0Mjc4MDY4MDhzZWVkKV0KPj4Kc3RhcnR4cmVmCjQ0
MjYKJSVFT0YK
--2oubkSu12F4FBVsrQ1qmkA=_rIo3IvFYNM--
We have the same sort of problem with Microsoft Mail. It is caused by the "Content-Disposition: inline" line in the text part which causes MS Mail to show the text part as a downloadable attachment. Removing the Content-Disposition line fixes this but requires you to modify TIdMessageClient.SendBody. Frankly I think MS Mail is to blame.

How to validate DKIM body hash manually?

This is an auto forwarded email.
I'm trying to verify the bh field as per rfc5322.
But the sha256 hash value received is not matching this value.
The message body is: for forwarded mail
Any suggestions to validate the bh= field correctly?
I have included some sample header field data. Please do explain (relaxed) canonical procedure too
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1516798995;
s=jan2017; d=headsup.co.in; i=sender#headsup.co.in;
h=Date:From:To:Message-Id:Subject:MIME-Version:Content-Type; l=627;
bh=ODw8icD/S+4UGcXgR4ocNpxXDh4PolWtd1IUXjh0AUs=;
b=G2vTZ+uQ+krw49l+4aMnaeZjUvAJXPPRA8bvOhs3XZNbd2Ng+odB/F5PI3tRpdhr
C0CJA5KPv4VncP2V1PjNdkgKLjs1eTzLSaqmPjhhQDc8mWQRT0rzcPP3V9v6BeXF987
54Zns/QWtR+RbSacFXvUjyBEOlaWUVAmaVcqw5S8=
//Message: for forwarded mail
//Example Data
Date: Wed, 24 Jan 2018 18:33:08 +0530
From: sender <sender#headsup.co.in>
To: "receiver" <receiver#gmail.com>
Message-Id: <1612843d10d.d305604a24030.1212846966506749871#headsup.co.in>
Subject: Test Arc Seal
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_76205_1329960269.1516798988558"
X-Priority: Medium
//Cannonicalization code (relaxed)
package canonicalization;
import java.io.IOException;
public class Canonicalization {
public String canonicalizeHeader(String name, String value) {
name = name.trim().toLowerCase();
value = value.replaceAll("\\s+", " ").trim();
return name + ":" + value;
}
public String canonicalizeBody(String body) {
if (body == null || "".equals(body)) {
return "\r\n";
}
body = body.replaceAll("[ \\t\\x0B\\f]+", " ");
body = body.replaceAll(" \r\n", "\r\n");
// The body must end with \r\n
if (!body.endsWith("\r\n")) {
return body + "\r\n";
}
// Remove trailing empty lines ...
while (body.endsWith("\r\n\r\n")) {
body = body.substring(0, body.length() - 2);
}
return body;
}
public static void main(String[] args) {
Canonicalization obj=new Canonicalization();
System.out.println(obj.canonicalizeHeader("Date"," Wed, 24 Jan 2018 18:33:08 +0530"));
System.out.println(obj.canonicalizeHeader("From"," sender <sender#headsup.co.in>"));
System.out.println(obj.canonicalizeHeader("To"," \"receiver\" <receiver#gmail.com>"));
System.out.println(obj.canonicalizeBody("for forwarded mail"));
}
}
You don't provide any code to illustrate how you are attempting to verify the body hash, but most likely you are incorrectly canonicalizing the input fed to the hashing function.
The code works fine for emails sent in plaintext format (Content-Type: text/plain;)
But by default, emails are sent by Rich Text Format (Content-Type: multipart/alternative;), hence the body hashes did not match

Does openstack4j support set header when upload image?

I have some problem about OpenStack swift object storage. I want to set an expiration for objects. I use openstack4j. My upload object code
public void add(String objectName, InputStream imageStream) {
OSClientV3 clientV3 = OSFactory.clientFromToken(swiftOS.getToken());
Map<String, String> metaData = new HashMap<>();
metaData.put("X-Delete-After", "120");
ObjectPutOptions objectPutOptions = ObjectPutOptions.create();
objectPutOptions.metadata(metaData);
clientV3.objectStorage().objects().put(container, objectName,
Payloads.create(imageStream), objectPutOptions);
}
But it doesn't work.
Then I tried to use swift command line.
swift stat test test-19b8e4d4-1085-490d-b866-97f0ada0d46c
What I get is
Account: AUTH_01d73f1e49ed4dfd9535c831eed4ccf9
Container: test
Object: test-19b8e4d4-1085-490d-b866-97f0ada0d46c
Content Type: application/octet-stream
Content Length: 2414
Last Modified: Wed, 20 Dec 2017 07:58:56 GMT
ETag: 1cb55838010ed189c0698b6b5cade3ed
Meta X-Delete-After: 120
X-Openstack-Request-Id: tx4f1f57ef08e34d9296bfd-005a3a184b
X-Timestamp: 1513756735.97761
X-Trans-Id: tx4f1f57ef08e34d9296bfd-005a3a184b
Accept-Ranges: bytes
When I upload an object by
swift upload test test.jpg -H "X-Delete-After: 120"
and then
swift stat test test.jpg
What I get is
Account: AUTH_01d73f1e49ed4dfd9535c831eed4ccf9
Container: test
Object: test.jpg
Content Type: application/octet-stream
Content Length: 1688
Last Modified: Wed, 20 Dec 2017 08:03:20 GMT
ETag: 8a2d75ff8db40610a52a492abac09d3b
Meta Mtime: 1513755398.217256
X-Delete-At: 1513757119
Accept-Ranges: bytes
X-Timestamp: 1513756999.02865
X-Trans-Id: txc016e1aff901450aa934b-005a3a194c
X-Openstack-Request-Id: txc016e1aff901450aa934b-005a3a194c
It is like openstack document said.
The X-Delete-After header takes an integer number of seconds.
The proxy server that receives the request will convert this
header into an X-Delete-At header using its current time plus
the value given.
But why openstack4j doesn't work?
Looks like we can use
objectPutOptions.getOptions().put("X-Delete-After", "120");
As the getOptions call returns the headers map straight up.
You should use header instead of metadata:
objectPutOptions.header("X-Delete-After", "120");

Why is Jetty serving css with text/html content type

I'm using an embedded Jetty server in a Scalatra app. The issue is that it serves css files with text/html content type:
Here is the main method:
package yard.web
import org.eclipse.jetty.server.Server
import org.eclipse.jetty.webapp.WebAppContext
import org.scalatra.servlet.ScalatraListener
object JettyMain {
def main(args: Array[String]) {
val server = new Server(9080)
val context: WebAppContext = new WebAppContext("src/main/webapp", "/")
context.setServer(server)
context.setInitParameter(ScalatraListener.LifeCycleKey, "yard.web.ScalatraBootstrap")
context.addEventListener(new ScalatraListener())
server.setHandler(context)
server.start()
println("Press ENTER to stop server")
Console.readLine()
server.stop()
server.join()
}
}
The file is located at src/main/webapp/libs/bootstrap/css/bootstrap.css, and served with:
$ curl --head http://localhost:9080/libs/bootstrap/css/bootstrap.css
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Last-Modified: Sat, 06 Apr 2013 14:30:35 GMT
Content-Length: 127247
Accept-Ranges: bytes
Server: Jetty(8.1.10.v20130312)
Why is Jetty thinking it's an html file?
Here is the ScalatraBootstrap class for completeness:
package yard.web
import org.scalatra.LifeCycle
import javax.servlet.ServletContext
import yard.Settings
import yard.db.Store
class ScalatraBootstrap extends LifeCycle {
override def init(context: ServletContext) {
val settings = Settings.default
val db = Store(settings).db
context mount (new MainServlet, "/")
}
}
Update: Using a ResourceHandler causes the css to be served with correct content type. However, the app doesn't work :(
The CSS file is typically served from the org.eclipse.jetty.servlet.DefaultServlet.
Which is declared in the etc/webdefault.xml file in the distribution.
Since you are using embedded mode, you'll want to provide this manually by calling WebAppContext.setDefaultsDescriptor(String) with the path to your etc/webdefault.xml file.
And finally, the mime types themselves are loaded by the DefaultServlet via the mime.properties file, which is loaded by Jetty via a call to Classloader.getResource("/org/eclipse/jetty/http/mime.properties").
Note: the mime.properties file is found in the jetty-http-8.1.10.v20130312.jar file.