In <C3C7A88E-E7C6-11D8-A1FF-000A95B3BA44(_at_)hxr(_dot_)us> Andrew Newton
<andy(_at_)hxr(_dot_)us> writes:
At IETF 60, I was approached by a very large ISP willing to do some
testing of the MARID proposals (Sender ID & CSV).
Great!
Quite simply, they are seeking advice on the variables to measure and
guidelines for deployment and evaluation of such tests.
For Sender ID, the stuff that Mark Lentczner reported was quite
useful. Or, at least, I found the detailed reports to be useful. My
analysis of the data and why various parts are important can be found
at:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02776.html
Mark wrote a perl script to generate this data, but it makes the
assumption that there are no post-edge MTA relays, which is not true
for my mail boxes nor for the Spamassassin corpus. I'm fiddling with
Mark's script to see if I can get good data from either source.
So, your advice is welcome. But I do ask one favor: please do not
formulate any such advice in the form of Sender ID vs CSV.
I suspect that only SPF-classic has enough published domains to do any
real testing on.
Currently, Sender ID makes the assumption that v=spf1 records are
valid to be used for Sender ID checks. While I personally agree that
this asumption is almost always true, it was decided at the IETF-60
session that this was not a safe assumption. One useful thing to test
for is whether this assumption is really true or not.
Personally, I think it would be very useful to also test the
SPF-classic results for both the MAIL FROM and the HELO.
As far as CSV testing, my understanding is that few domains have
published the SRV records needed to test it. I suspect that people
more knowledgable about CSV deployment may be needed to develop useful
tests.
A couple of days ago, I went through my inbox to see how many valid
emails I have received that had HELO domains that did not resolve to
the IP address of the client MTA. I never finished going through the
list or giving a real report, but I thought the following list was
interesting none the less.
[192.74.137.143] helo=TheWorld.com
Maybe if this "Barry Shein" guy had more experience running a
public ISP, he wouldn't have his HELO domain wrong.
[205.143.207.126] helo=hera.prod.geico.com
Yeah, no one would mind losing email from GEICO.
[66.35.250.206] helo=sc8-sf-mx2.sourceforge.net
These guys have no idea about creating and using software.
[128.242.147.150] (helo=nu.jumpserver.net)
this is the registrar/DNS hoster that I've used since the mid 90s.
[206.222.212.237] helo=midwestcs.com
The guy is an idiot.
[216.145.52.229] helo=yahoo-inc.com
Small, two-bit company with no experience with email and they
haven't been around very long anyway.
[206.45.235.30] helo=mail.pan-am.ca
This guy obviously has no clue about designated sender systems and
what needs to be done to make them work reliably.
(I thought I had sendmail.com for a sec, but it is just their forward
and reverse not matching.)
[216.239.56.194] helo=cwar25.prod.google.com
Yeah, another two-bit company that has nothing to do with email.
[208.198.98.24] helo=CORPMAIL1.roving.com
What can I say? Email is not their thing.
</VERY heavy sarcasm>
Mind you, these were emails to my person-to-person inbox, not stuff
from mailing lists, so the volume is fairly low and fairly restricted.
I think the above list represents about half of the MTAs that used
invalid HELO domains. Overall, I found that around 20% of all
valid, person-to-person email I received had an invalid HELO domain.
-wayne