On Thu, 18 Nov 2004 18:26:42 -0500, Vivien M. <vivienm(_at_)dyndns(_dot_)org>
wrote:
Web-based mail systems tend to be common, yes (to my great chagrin, as I
happen to loathe such things when there are far more elegant alternatives
like IMAP out there), but again, that doesn't answer one of the issues.
Namely, how do you tell Aunt Mary (in my previous example) that her
POP3-based setup that has let her send mail from home using her work From:
address can't be used anymore?
What did Aunt Mary do when leaded gasoline was phased out and her car
started knocking? She had to use an additive or buy a new car.
What did Aunt Mary do when the dairy no longer delivered milk, eggs,
OJ, etc to her door?
The fact that someone used to do something a certain way does not mean
that they have an inalienable right to do that thing the same way
forever.
How do you tell Aunt Mary anything? Things change.
I'm not discounting that there is a problem with forged mail from, but I'm
saying that there is also a problem with semi-legitimately forged mail from
that things like SPF can't separate from fully forged mail.
If I show you 20 pieces of email, can you correctly identify which are
"semi" and which are "fully" forged? Forging is forging. Once you
allow forged mail you have no way of distinguishing which is which.
The test for "semi-legitimately forged mail" (okay, so I'm not great at
coming up with names for concepts) should be something like "mail that is
sent by or on direct behalf of the human being entitled to use that From:
address outside of the setting allowed by the domain owner's SPF record".
"Fully forged mail" would be mail sent by someone who knows, or ought to
know, that they have no right to use that address.
So what's your point? That's like saying there is a difference between
big lies and little lies and that the person being lied to should
recognize the difference between the two. That the little lie is
really to their benefit and the big lie is not. That little lies will
always be good and big lies will always be bad.
As far as SPF is concerned, both my semi-legitimately forged mail and fully
forged mail are viewed in the same way. For Aunt Mary, there's a huge
difference. Same thing with people using the "send <articles/greeting
cards/invitations/etc" features on most "mainstream" (where mainsteam means
targetting an audience with significantly different demographics from, say,
this list) web sites. SPF kills those. Is there a solution that lets you
separate the two? Perhaps not, I'll grant you that. Some of these things can
be re-engineered (e.g. greeting card sites can send from
AuntMary+blah-edu(_at_)egreetings(_dot_)com or something, which will look
ugly, but
will work) with a certain cost. Others can't unless the domain owner decides
to invest money/resources into officially supporting a scenario that used to
work but was not officially supported (e.g. organization doesn't block port
110 from outside, people set up machines at home to POP3 and send using the
ISP SMTP... that form of semi-legitimately forged mail doesn't require
official support from the IT department, but the deployment of an SMTP AUTH
alternative does).
Go back and look at what egreetings.com publishes for SPF1. Then look
at the headers on an email motification from egreetings. Works fine
under SPF1. IT meets the requirements of the various RFCs regarding
email as well as SPF1 (Classic SPF).
Breaks when SenderID/PRA is applied because it wasn't intended to say
anything about RFC2822 identities.
So, email from egreetings.com is not semi-legitimately forged (in the
context of this discussion). It is what it says it is. It is sent from
the MTAs which the published SPF record says are allowed to send mail
for egreetings.com.
Looking at the RFC2822 headers, the mail uses the sender header to
indicate that it is sent on behalf of the customer. Again, this
matches exactly what the RFCs say should be done when one person sends
mail on behalf of another.
To talk about semi-legitimate forging makes it impossible to do
anything practical about the problem of domain forgery. Just as the
recipient (domain) gets to set the rules on what mail they will
accept/reject, the owner/administrator of a domain gets to set/publish
the emailing policy for their domain.
And yes, I agree with shouting at the IT managers if necessary :) The
problem is, in a large organization, there's going to be a big bureaucracy.
Is the IT manager (who, like most IT managers, probably doesn't have enough
staff and funding) going to allocate money/time/staff to implement SMTP AUTH
because someone at the bottom of the organizational flow chart complained?
Doubtful. So then, basically, the only hope is for the CEO to send
semi-legitimately forged mail and encounter this issue him/herself.
I guess the real question is how important email is to your business.
If it is considered non-core and a nuisance then you will see just the
situation described. If it is considered core to the business then you
will find that it is taken care of. It may not be taken care of the
way you as an individual might like. But then how many other corporate
policies are there that you adhere to but don't like?
As usual, just my 2 cents.
Mike