This is what I was doing last week when I noticed that all the email sent by my website’s registration system was apparently from FinkyPieheimer@zoobatz.com. That’s definitely not what I set, and I confirmed that a valid from address was being used. The only recent change was that a friendly display name was now being included, instead of just the email address by itself. So what gives?

Upon examining the raw email (When viewing an email in Mailinator, click the Text View button), I noticed a linebreak in the From header.

...
MIME-Version: 1.0
From: "Quux Baz"
 <noreply@foo.bar>
To: test@mailinator.com
...

While that’s unusual, other email programs and systems handle it just fine. Mailinator, however, doesn’t like it one bit. It seems to regard it as invalid, and as such, replaces the field with FinkyPieheimer@zoobatz.com as a sort of placeholder.

So what can you do about it? If you’re just registering on a website, don’t worry about it. If you’re working on your own website, see if you can change how the From email address is set.

In my case, I was using .NET’s SmtpClient, MailMessage and MailAddress classes. I found a StackOverflow question about the strange carriage return & line feed, which only appears when you set the DisplayName property of a MailAddress instance. This only happens under .NET 4.0, and you can see the hardcoded “\r\n ” are the end of the MailAddress.Encode(Int32) method. To resolve this, either convert the project to .NET 3.5, remove the display name, or, if you have an intermediate delivery system, add a processing step to fix this after it leaves the .NET SmtpClient.

On the I/O side, Manta offers support for managing hardlinks, reparse points, junctions, symbolic links. It also comes with unit tests and documented methods and classes.

On the web side, Manta enables easy manipulation of URLs, RSS feeds and phpBB posts. It too features unit tests and documentation.

You can find out more about Manta or download it from CodePlex.

List<T>.Enumerator enumerator = characterList.GetEnumerator();

while (condition) {
	if (!enumerator.MoveNext()) {
		enumerator.Reset();
		enumerator.MoveNext();
	}

	Consume(enumerator.Current);
}

Oddly, I was getting a compilation error on line 5, as enumerator doesn’t have a Reset() method despite the IEnumerator interface defining one. MSDN quickly cleared things up, though, revealing that List<T>.Enumerator explicitly implements the method as void IEnumerator.Reset(), which is implicitly private. You can still call private interface methods if you first cast to that interface, so I changed line 5 to the following:

		((IEnumerator) enumerator).Reset();

I thought that was the end of it, but bizarely, the second call to MoveNext() on line 6 also returns false. I confirmed that the private Reset() method actually implements reset functionality, which it certainly does, yet it seemed to have no effect.

The answer lies in the fact that List<T>.Enumerator is a struct. This means that behind the scenes, the cast to IEnumerator is creating a boxed copy of enumerator, and that’s what’s being reset. The original is left untouched, so the call to MoveNext() will naturally return false. Rather than trying to keep the boxed copy that you get from the cast, the correct solution is to use IEnumerator<T> from the outset, rather than List<T>.Enumerator:

IEnumerator<T> enumerator = characterList.GetEnumerator();

while (condition) {
	if (!enumerator.MoveNext()) {
		enumerator.Reset();
		enumerator.MoveNext();
	}

	Consume(enumerator.Current);
}

All this drama could have been avoided if I hadn’t checked the return type for List<T>.GetEnumerator() and used that. So much for more explicit typing being helpful.

Still, it’s rather odd that List<T>.Enumerator is both public and a struct. The former encourages its direct use, and the latter results in the problem I was experiencing. Sadly, this design is constant throughout the System.Collections.Generic namespace. By contrast, the equivalent non-generic collection is ArrayList, and there, the GetEnumerator() method returns an IEnumerator, which is implemented by a private class nested within the ArrayList type – a design that is constant throughout the rest of the System.Collections namespace, and is, in my opinion, better for everyone.