Hi !!
the header can contain more than one address
It can but its not worth it.
why ?
Its going to be impractical for certain cases of mass mailing from list
to to large ISP with many subscribers on that list.
ok, i see, you mean that cases where the mta route the message to
another host and sends it using multiple envelope recipients and
just one DATA. then the only way is to look at the first Received
line ...
wel, if you kown if a message has not been forwarded you could
turn softfail to fail, if the message has not been forwarded then
you could check if it comes from a known forwarding address.
It does not give you verified identity and does not authorize MAILFROM
for those cases.
yes, but you could use it to reject forgeries.
Solution must involve being able to do authorization
in all cases rather then only being able to bypass failures.
it does not bypass failures, it allows to reject forgeries that
oterwise will be accepted.
Trusted forwarder and this algorithm are not solutions to forwarding issue -
they are temporary intermediate actions to minimize the rate of errors
and that is all.
yes, the real forwarding problem has no total and feasible solution from
the spf point of view.
This "philosophical question" is really a question on that current
email system is not built very well and that is why you only have
two stages - envelope with very small number transport data fields
(and very hard to add new ones into system)
yes, but there are mechanisms to add arguments to the mail from:
command, the problem is that most mta's will reject that arguments
altough they should igonore them by rfc.
BTW - using To and For and doing DATA stage verification are not the
only ways to go. One possiblity (and this finally reminded me as to when
I heard about this before) is using ORCPT extension which is passed as
part of SMTP parameters and is by now supported by most mail servers.
See RFC3461 (which updated earlier RFC1891 which first introduced ORCPT
back in 1996) - http://www.faqs.org/rfcs/rfc3461.html. And obviously for
senders starting to use ORCPT is no more difficult (in fact its easier
as its already standard) then adding new header field.
sometime ago i checked how some mta's react to receiving a mail from:
with arguments, even when using well know arguments (like auth=) most
mta's just rejected it due to syntax errors. The question is, what will
they do when receiving ORCPT ? I'm sure many mta's tha announce DSN
on the EHLO will simply reject smtp commands with that argument, so
solutions in that way that are perfectly rfc compliant will fail just
because there are many non 100% compliant mta's. That kind of changes
are really need but involve changes on all mta's and this is something
that could take many many years, and this does not mean that we could
give up, but we also have to find temporary solutions.
--
Best regards ...
----------------------------------------------------------------
David Saez Padros http://www.ols.es
On-Line Services 2000 S.L. e-mail david(_at_)ols(_dot_)es
Pintor Vayreda 1 telf +34 902 50 29 75
08184 Palau-Solita i Plegamans movil +34 670 35 27 53
----------------------------------------------------------------
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com