headers
Barry Leiba | 2 Apr 15:37
Picon
Favicon

Conference on Email and Anti-Spam final call for papers


This seems sufficiently on-topic for this list:
The 2008 Conference on Email and Anti-Spam submission deadline is approaching, 
and has been extended by a week, to 10 April.  If you have any work to report on 
in the area of Internet messaging abuse and its prevention — not limited to 
email spam; see the topic list in the CfP, below — please form it into a paper 
by next week, and submit it.

Barry

----------------------------------------------------------------------
      THE FIFTH CONFERENCE ON EMAIL AND ANTI-SPAM (CEAS 2008)

            Thursday August 21 and Friday August 22, 2008
                   Microsoft Research Silicon Valley
                      Mountain View, California
                        <http://www.ceas.cc>

                       FINAL CALL FOR PAPERS

The Conference on Email and Anti-Spam (CEAS) invites the submission
of papers for its fifth meeting. Papers are invited on all aspects of
electronic communication including email, instant messaging, text
messaging, and voice over internet protocol (VoIP). Topics of interest
include novel applications of electronic messaging, abatement of abuses
of electronic messaging, spam, spit (spam over internet telephony), spim
(spam over instant messenger), phishing, identity theft via messaging,
viruses, and spyware.

Paper submissions can be either research papers, extended abstracts,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Valdis.Kletnieks | 22 Apr 04:03
Picon
Favicon

C-T-E: base64 and the real world.. what should an MUA do?

(Sorry I've been silent on this list for a while, I've been off doing other
stuff for the nonce and only posting if something egregious happened to
catch my eye...)

OK, so the following mail showed up on the linux-kernel mailing list (and it's
not a singleton mail, I've seen this same broken behavior a lot lately...)

It had 1 bodypart, correctly tagged as

Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: base64

Majordomo then goes and sticks some stuff on the end, so the last few lines
of the message are:

--- cut here ---
IGRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZ0X2F0dHIpOwo+ICAgICAgICAgfQo+ICAgICAg
ICAgaWYgKGRldi0+Y2xhc3MpIHsKPgo+ICAtLQoKQXBwbHlpbmcgdGhpcyBwYXRjaCB3b3JrZWQg
Zm9yIG1lLgoKVGhhbmtzIQogICAgICBNaWxlcwo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
--- cut here ---

Of course, the last 5 lines are bogus as base64, and it's easy to just say
"Majordomo is at fault".  But such things happen in the real world, and what's
the recommended algorithm for an MUA to recover from this?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tony Hansen | 22 Apr 04:49
Picon
Favicon

Re: C-T-E: base64 and the real world.. what should an MUA do?


If there's a padding "=" at the end of the base64, you can stop 
processing right at that point. You *could* also stop processing when 
you run into a non-whitespace character that isn't in the base64 
alphabet, such as the "-" or ":" in your example. It's not perfect.

	Tony Hansen
	tony <at> att.com

Valdis.Kletnieks <at> vt.edu wrote:
> (Sorry I've been silent on this list for a while, I've been off doing other
> stuff for the nonce and only posting if something egregious happened to
> catch my eye...)
> 
> OK, so the following mail showed up on the linux-kernel mailing list (and it's
> not a singleton mail, I've seen this same broken behavior a lot lately...)
> 
> It had 1 bodypart, correctly tagged as
> 
> Content-type: text/plain; charset=UTF-8
> Content-transfer-encoding: base64
> 
> Majordomo then goes and sticks some stuff on the end, so the last few lines
> of the message are:
> 
> --- cut here ---
> IGRldmljZV9yZW1vdmVfZmlsZShkZXYsICZkZXZ0X2F0dHIpOwo+ICAgICAgICAgfQo+ICAgICAg
> ICAgaWYgKGRldi0+Y2xhc3MpIHsKPgo+ICAtLQoKQXBwbHlpbmcgdGhpcyBwYXRjaCB3b3JrZWQg
> Zm9yIG1lLgoKVGhhbmtzIQogICAgICBNaWxlcwo=
> --
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arnt Gulbrandsen | 22 Apr 09:35
Favicon

Re: C-T-E: base64 and the real world.. what should an MUA do?


Valdis Klētnieks writes:
> Of course, the last 5 lines are bogus as base64, and it's easy to just 
> say "Majordomo is at fault".  But such things happen in the real 
> world, and what's the recommended algorithm for an MUA to recover 
> from this?

Stop decoding at '=' (that's two thirds of the cases). Stop decoding 
when you see "--" at the beginning of a line (that's most of the rest).

And if all else fails, following the rules in RFC 2045 result in a few 
random bytes at/after the end of the decoded data. Usually harmless.

Arnt
Permalink | Reply | 0 comments |

Gmane