Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Work around crazy emails with non-base64 encoded attachments #283

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Commits on Jan 1, 2017

  1. Work around crazy emails with non-base64 encoded attachments

    GMail IMAP push will get in a weird state if it encounters an email
    which is encoded in this manner. The connection will be reset after a
    long timeout after encountering this binary crap.
    
    I suspect an earlier version of GMail server software, or some non-IMAP
    import allows or allowed this in at some point, and yet it is not
    possible to upload it back verbatim.
    
    For my purposes, it suffices to skip these rare species but in general
    the email parts should be re-encoded as base64, or the problematic
    invalidly encoded attachments should be removed.
    
    The illegally encoded binary emails are detected here by looking for the
    PNG magic string with bytes that SHOULD NOT appear in any legitimate
    email data.
    
    A screenshot of one of the affected emails is at
    https://imgur.com/a/i09Xa.
    Elias Kunnas committed Jan 1, 2017
    Configuration menu
    Copy the full SHA
    b672599 View commit details
    Browse the repository at this point in the history

Commits on May 4, 2017

  1. Generalize checking against bad base64 data

    This commit tests all base64-encoded parts of emails to push.
    
    This generalizes the previous ad hoc method which only worked for
    detecting the PNG magic header anywhere in the message.
    
    If a email parts/payloads claim to be base64 encoded but contain
    invalid characters outside the base64 alphabet, the email is never pushed
    to server. The erroneous emails are NOT sent to quarantine since they
    are assumed/observed to be both rare and can be detected client
    side (and notably CANNOT be detected server-side as such because they
    break the protocol contract).
    eliask committed May 4, 2017
    Configuration menu
    Copy the full SHA
    0826037 View commit details
    Browse the repository at this point in the history