aboutsummaryrefslogtreecommitdiffstats
path: root/spec/lib/mail_handler/mail_handler_spec.rb
diff options
context:
space:
mode:
authorMark Longair <mhl@pobox.com>2013-04-30 14:50:25 +0100
committerMark Longair <mhl@pobox.com>2013-05-16 09:06:27 +0100
commitf93caeb5fad489943615453304b8b41062e67aa5 (patch)
treec4dbb648694eefcb44333c6eed07acb0ed216dab /spec/lib/mail_handler/mail_handler_spec.rb
parentbe5077d5f1af176c34aadd3dcfc6fd3ac9422a3d (diff)
Add a test to check that anything in the MIME epilogue is ignored
There is currently a difference in behaviour in the parsing of nested MIME multipart attachments between the Mail and TMail based backends. This commit adds a test that will pass if the behaviour is the same as the the old (TMail-based) version, which I believe is correct according to RFC 1521. The example email has a PNG attachment after the final MIME boundary, and the RFC says that anything after the final boundary ("the epilogue") should be ignored.
Diffstat (limited to 'spec/lib/mail_handler/mail_handler_spec.rb')
-rw-r--r--spec/lib/mail_handler/mail_handler_spec.rb11
1 files changed, 11 insertions, 0 deletions
diff --git a/spec/lib/mail_handler/mail_handler_spec.rb b/spec/lib/mail_handler/mail_handler_spec.rb
index 487f3bf0d..eca5e2dd4 100644
--- a/spec/lib/mail_handler/mail_handler_spec.rb
+++ b/spec/lib/mail_handler/mail_handler_spec.rb
@@ -310,6 +310,17 @@ describe 'when getting attachment attributes' do
attributes.length.should == 2
end
+ it 'should ignore anything beyond the final MIME boundary' do
+ # This example raw email has a premature closing boundary for
+ # the outer multipart/mixed - my reading of RFC 1521 is that
+ # the "epilogue" beyond that should be ignored.
+ # See https://github.com/mysociety/alaveteli/issues/922 for
+ # more discussion.
+ mail = get_fixture_mail('nested-attachments-premature-end.email')
+ attributes = MailHandler.get_attachment_attributes(mail)
+ attributes.length.should == 3
+ end
+
it 'should ignore a TNEF attachment with no usable contents' do
# FIXME: "no usable contents" is slightly misleading. The
# attachment in this example email does have usable content in