Comparison of "
Factory Method" and "
Chain of Responsibility" is not very proper because of below reason.
"
Factory Method" is a Creational Pattern and "
Chain of Responsibility" is a Behavioral Pattern.
"Factory Method"
http://www.dofactory.com/Patterns/PatternFactory.aspx
If you read above article you will understand in "Factory Method" final outcome is "Product"(Interface) instantiated by "ConcreteProduct". This "Product" is created after specific decision made by "ConcreteCreator".
For Example - When you Order a Pizza(Product) to "PizzaStore"(ConcreteCreator) it can be "ThickCrustDough"(ConcreteProduct) ;P or "PlumTomatoSauce"(ConcreteProduct) ;P or something else.
"PizzaStore"(ConcreteCreator) will instantiate Pizza(Product) by either of "ConcreteProduct" based on your Order. One Pizza will be made at a time.(But you can order as many as you want :))
"
Chain of Responsibility"
http://www.dofactory.com/Patterns/PatternChain.aspx
From the above article you will understand their is one "Handler" and their can be multiple "ConcreteHandler" inherited by it.
In one common Work/Goal, "ConcreteHandler" handles the responsibilities for the in scope tasks and then delegates remaining to its Successor(which is again a different "ConcreteHandler"). So eventually one common Work/Goal gets complete by contribution of multiple "ConcreteHandler".
Now considering your requirement. In case if you are expecting Bulk of emails at a time, then
Chain of Responsibility is the valid choice.
You can have one "Handler"(Interface) which will be implemented in multiple "ConcreteHandler". Every "ConcreteHandler" will be responsible for specific Email Type and will delegate responsibility to its Successor for different email type.
When your application will traverse through these Emails. "ConcreteHandler" will handle the emails of its type and will delegate the responsibility to next Successor("ConcreteHandler") when their is a different type of email.
Hope it helps. :)