Michael Scheidell wrote:
-----Original Message-----
From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED]
You find me a large scale installation that is actually checking, and
rejecting on, SPF records before DATA and isn't frequently rejecting
mail their users want and I'll buy you lunch.
You find me a large scale installation that is rejecting SPAM and isn't
frequently rejecting mail their users want and I'll buy dinner.
Luckily I'm on my way home for dinner now.
In my mind there's a huge difference between rejecting mail based on the
behaviour and actions of the sender than there is rejecting mail based
on actions of the recipient (choosing to forward their mail).
The only way I can see that they'd be the same is if you fault the
sender for publishing SPF records.
Lets face it: SMTP is broken, but the fixes are just compromises between
allowing spam, viruses, phishing and email.
Any changes to SMTP will break legitimate email.
You wonder what happens if you enforce all the RFC's on email?
How many large installations use 'localhost.localdomain' as the FQDN for
their outbound helo?
(send an email to [EMAIL PROTECTED] and see the headers!)
How many large installations doesn't use ANY fqdn for RDNS, and the PTR
and A records don't match?
How many large installations don't have abuse@ or postmaster@ records?
http://www.rfc-ignorant.org/tools/lookup.php?domain=hotmail.com
http://www.rfc-ignorant.org/tools/lookup.php?domain=gmail.com
http://www.rfc-ignorant.org/tools/lookup.php?domain=yahoo.com
(with a bad whois record, can't they lose their yahoo.com domain :-)?
Even if you enforce existing RFC's, you will drop email 'users want'.
All actions of the sender, not the recipient.
For 12 years, people have been arguing about how to fix it.
If someone wants to advertise spf records, and wants to use ?all, or
~all if they are timid, more power to them.
The record itself is not the issue. It's what action the recipient
system takes based on the record.
host -t txt microsoft.com
microsoft.com descriptive text "v=spf1 mx include:_spf-a.microsoft.com
include:_spf-b.microsoft.com include:_spf-c.microsoft.com ~all"
host -t txt hotmail.com
hotmail.com descriptive text "v=spf1 include:spf-a.hotmail.com
include:spf-b.hotmail.com include:spf-c.hotmail.com
include:spf-d.hotmail.com ~all"
OK, citing Microsoft's records wouldn't be my first choice when arguing
in favour of SPF.
For starters, they're basically saying we're not sure where our mail
comes from... last time I counted their records covered over 11 million
hosts. So everyone arguing about "security of email" can't seriously
consider this a good example.
Second, while they publish SPF compatible records, they treat other
people's records more like PRA and even when they treat them as SPF
they'll tell you that they don't even fully support SPF mechanisms.
host -t txt _spf.google.com
_spf.google.com descriptive text "v=spf1 ip4:216.239.56.0/23
ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all"
I have no idea what your point is here.
If a bank decides that forwarding email send to clients is a bad idea,
and wants to publish -all records, that's fine also.
Why should that be up to the bank and not their customer. If their
control over security needs to be that far reaching they should coat
their ATM cards in something that prevents me from writing the PIN
number on it with a permanent marker. There's a far better chance of my
account being compromised that way then due to me forwarding mail from
one system I, or someone I trust, control to another.
Besides, even if the bank should have a say over whether you should be
able to forward mail, what happens when your forwarder implements SRS.
Oh no, the bank no longer has a say, they've lost the control they
apparently should have.
I guess it's a good thing that SRS is essentially vapourware.
If an ISP wants to trigger additional tests for email that softfails, or
block at smtp session email that hardfails, then all they are doing is
taking the suggestions of the sending domain.
I still maintain that blocking based on the actions of the end-user
recipient isn't the right thing to do when it comes to sender
authentication schemes.
host -t txt chase.com
chase.com descriptive text "v=spf1 ip4:170.148.48.0/24
ip4:159.53.36.0/24 ip4:159.53.46.0/24 ip4:159.53.110.0/24 -all"
Hey, I recognize chase.com. They're the bank that goes out of their way
to make their email look like phishing mail.
Anyway... I'm sure the SpamAssassin user's list is getting bored now.
Daryl
