It was thus said that the Great Pete Turnbull once stated:
I think the next test would have been something involving a message
ostensibly from the "<>" address (which represents the mailer daemon),
and
then some tests involving forged addresses intended to look like your own
domain, and then assorted routed or malformed addresses. Some of these are
very important, and your site hasn't been tested for most of them.
I've had to harden sendmail against some of these attacks (by modifying
sendmail.cf [1]). Assuming that ``sean(a)conman.org'' (my spam catching
address) is the one being targeted, and ``armigeron.com'' (which I do some
side work for from time to time) is the host being used for the relay, I've
had to check for:
"sean@conman.org"@armigern.com
sean@conman.org@armigeron.com
"sean%conman.org"(a)armigeron.com
sean%conman.org(a)armigeron.com
"sean(a)conman.org"%armigeron.com
sean(a)conman.org%armigeron.com
There may be a few more obscure methods, but I think those where the only
ones I needed to protect against.
-spc (Been there, done that, used be listed on MAPs or ORBs or one of
those systems ... )
[1] I modified the current senamil.cf because I had modified the
sendmail configuration to support virtual domains (before sendmail
had included support through virtusertable[2]) and using a more
current sendmail.cf would have removed such modifications.
[2] I decided not to use sendmail.cf's virtusertable because the method
I used was more flexible (each domain has their own file) and
because a customer of Armigeron had the ability to modify the email
addresses for their domains (whereas using virtusertable, *every*
domain is in a single file). Plus, a recipient email address can
have more than one destination address (another restriction of
virtusertable that requires some nasty workarounds).