On Wed, 23 Feb 2005, David MacQuigg wrote:
Sometimes a simple reply is effective in getting the owner of the machine
to install an antivirus product. I once called my neighbor, "Connie, I
just got an ad for penis pills from you. Are you trying to tell me
something?" Took me a few minutes to re-assure her I understood the
message wasn't from her, but it did come from her computer."
How would you know it really came from her computer, unless you checked
the IP address? What if she was on a dynamic IP? It may not have been
her PC at all - but a zombie on the other side of the world, or on a desk at
some BigCorp.
Sending a reply to a spam/virus is always rude, igorant, and annoying
*unless* you have authenticated the address used for the reply.
If using MAIL FROM for the reply, passing (not just a neutral result)
SPF or SES is a requirement. If using header From or Reply-To, passing
DomainKeys or SenderID is a requirement.
Sending a DSN is always appropriate. DSN is delivery status notification.
If you are not delivering the email because it contains a virus, then
a DSN telling the user that is the RFC recommended response. Unlike replies,
DSNs are easily filtered if the MAIL FROM was forged.
I'm skeptical of the SPF/SRS/SES procedure described above, even if there
is nothing wrong with the technical details. The anti-SPF folks will
ridicule it as "patching a fundamentally broken SPF based on false
assumptions", etc. No doubt this is a bunch of FUD, but it is effective
SES is not a patch for SPF. It works fine to authenticate email without
SPF, and stops forged bounces and bounced MAIL FROM forgeries without
any cooperation from anyone else - so there is a huge benefit to deploying
it even without widespread adoption.
It complements SPF in that each validates MAIL FROM in a slightly different
way. SPF validates the IP it comes from. SES validates a crypto
signature in the MAIL FROM itself. Deploy them both together, and the system
is tolerant of configuration errors because either validation will get legit
mail through to an SPF checking recipient that forgot about forwarders.
FUD. So what should we do, FUD back? How are we going to get broader
acceptance of email authentication? Are the benefits worth the cost of
Just use it, and require your business partners to use some form of
authentication "so you know it really them". Don't tell them to use SPF or any
other method. Just ask them what they are using for authentication. If they
already have a method, try to add that to your arsenal. If they don't, wait
for them to ask you for suggestions, then suggest SPF (which is the simplest
for a sender to deploy, and can be used for whitelisting business email even
when the record ends with ?all).
We are cool if the sender simply has an RFC2821 compliant HELO name - which
is sufficient authentication for most whitelisting. However, there
was one email admin recently, who simply did not understand why
"JUPITER" was not a valid HELO name and didn't think RFC2821 was
worth paying attention to "since it isn't real world email". Sigh.
Another reasonable non-SPF method is a PTR record for the connection IP that
ends in their domain or some domain associated with them.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.