Page 1 of 1

Strange gargled email address

Posted: Wed Jun 06, 2007 9:11 am
by garethjax
Hi there (again).

I've been doing some experiments with swiftmailer and wampserver (an apache+php+mysql package for window) and i've realized my own
little "frontend" to switfmailer.

My frontend can process both a list of address from a form and a list of address loaded from a text file.

My problem is that sometimes the destination email is sent like this:

To: =?iso-8859-1?Q?user@domain.com?=

i'm using a code like this:

Code: Select all

$recipients =& new Swift_RecipientList();
foreach ($addresses as $value) {
	
	$recipients->addTo($value); //or we can just add the address
    //echo "-".$value."<br>";
}
If i add an email "manually" with the addto function, i don't get that strange error.

I must also specify that the email is correctly parsed by gmail, outlook express and other email clients, but it's probably rejected by Lotus Notes (which is used by many users of my mailing).

Any idea ? :(

Posted: Wed Jun 06, 2007 1:37 pm
by Chris Corbyn
That should only ever happen for invalid (non us-ascii) addresses. Anything in the ascii range should never need to be encoded like that... can you post some examples of addresses which are doing this? Also, be sure to trim() whitespace from the addresses before sending... I'm adding this to forthcoming versions myself since whitespace can cause some strange things (possibly this included) in addresses with Swift, and in SMTP.

In subversion my Swift_Address class has it's setAddress() method changed to this, though I've not released the changes yet:

Code: Select all

/**
   * Set the email address
   * @param string
   */
  function setAddress($address)
  {
    $this->address = trim((string)$address);
  }

Posted: Wed Jun 06, 2007 1:41 pm
by garethjax
It looks like i'm always creating troubles that you have to solve :D

Regarding the emails they are like:

a.scarpetta@mycompany.com

Posted: Wed Jun 06, 2007 2:50 pm
by Chris Corbyn
Are you able to recreate this with 100% certainty? The functions which make the decision upon whether or not to encode are these:

Code: Select all

/**
   * This function checks for 7bit *printable* characters
   * which excludes \r \n \t etc and so, is safe for use in mail headers
   * Actual permitted chars [\ !"#\$%&'\(\)\*\+,-\.\/0123456789:;<=>\?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\[\\\]\^_`abcdefghijklmnopqrstuvwxyz{\|}~]
   * Ranges \x00-\x1F are printer control sequences
   * \x7F is the ascii delete character
   * @param string Data to check against
   * @return boolean
   */
  function is7BitPrintable($data)
  {
    return (!preg_match('/[^\x20-\x7E]/', $data));
  }
  /**
   * Check that a string does not contain any evil characters for headers.
   * @param string The string to check
   * @return boolean
   */
  function isHeaderSafe($data)
  {
    return ($this->is7BitPrintable($data) && strpos($data, ";") === false);
  }
Called like:

Code: Select all

//If the header is 7-bit printable it's at no risk of injection
      if ($encoder->isHeaderSafe($row) && !$this->forceEncoding)
      {
        //snip (no encoding at all)
      }
      elseif ($this->encoding == "Q") //QP encode required
      {
        //snip (qp encoding -- this is where you're going!!)
      }
      elseif ($this->encoding == "B") //Need to Base64 encode
      {
        //snip (base64 encoding)
      }
So either:

a) The address contains something that's matching '/[^\x20-\x7E]/', or that has a semi-colon in it
b) Encoding has been forced by calling $message->headers->forceEncoding(true);

I'll rule out the obvious one first ;) Have you called forceEncoding()?

EDIT | Or option c) One of the servers it relays through is changing the headers