Graham Murray wrote:
will the 'typical' big ISP user want to use a From: address
which is different from the ISP allocated (MAIL FROM)
address?
If that typical user is me, then yes. The German market has a
lot of call-by-call ISPs for modem / ISDN users, and depending
on the time and the day of the week I use different ISPs.
Most of these ISPs offer mail services. And a majority of the
ISPs with mail services allow POP3 access independent of the
IP (i.e. I can get my mail from ISP A even if I'm online using
ISP B). But ISP A won't allow me to send mail while I'm using
another ISP.
Therefore I use my address at ISP A always as From: address,
but my MAIL FROM depends on the mail provider (ISP A, or a MSA
of a 3rd party, or the smart host of another ISP).
I have no idea how usual or unusual that is, but the default
smart host of the biggest German ISP enforces a From: address
matching the MAIL FROM matching the identified user (RADIUS):
They simply replace From: and MAIL FROM. Many Usenet users
(not exactly "typical") are very unhappy with this practice.
he always has the option of using a mail hosting service or
moving to a smaller ISP which does offer this.
Sure, but these services are generally not "free", i.e. not
included by call-by-call ISP services. One of the SPF ideas
is that this is a voluntary thing. Sender-Id would force MSAs
of 3rd parties to implement RfC 2476 8.1 "MAY" even if they're
not interested in Sender-Id, _or_ the users of these MSAs could
upgrade their MUA to do this automatically, _or_ they insert a
Sender: manually, _or_ they don't know what's going on, their
mail is rejected, and they're unhappy with this MARID business,
where they can't use their favourite From: address everywhere.
If the only problem in this case is the missing Sender:, why
not handle the Return-Path as "PRA" (only in this case) ? The
MUA of the recipient wants to display a verified "PRA", so this
MUA knows the new "PRA" concept, and therefore it could handle
this obvious problem.
Bye, Frank