Hi !!
Adding one header field like you describe does not account for:
1. Multiple recipients
the header can contain more than one address
It can but its not worth it.
why ?
2. BCC cases where it is desirable to hide recipient address from
appearing in the email header
as the header should be added by a mta, that could be handled at
mta level.
You don't understand about BCC if you answered this way. To put
it another way, not every sender (be it at MUA or MTA level) would
necessarily want to show to end-user recipient the address to which
it actually sent email to.
well, if you look at the received lines you will get that info,so there
is no secret to keep.
yes, it could also be found on To: or Cc: headers
No, it could not. Like "From" and "Sender" RFC2822 header fields are
not the same as RFC2821 MAILFROM, so is true that To and CC are not
the same as RFC2821 RCPT TO.
yes, it COULD also be found on To: This does not mean that it always
could be found, in real world in a great percentge of cases both
the envelope recipient and the From: are the same
To be honest, even with new header field, I simply do not see how this
algorithm could be used to "solve SPF forwarding" problem
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 would run contrary to what SPF is supposed to be
used for and how. And it really would not actually allow to authorize
the MAILFROM (or some other) address - just allow to bypass the check
in some cases and this is not a solution long-term.
i'm not talking about bypass the check, i'm talking about rejecting
a softail which is about rejecting an email that otherwise will
bypass the spf check.
It does not matter what header field you interpret - they could all be
faked. And in this case faked header field really does not do anything
> for the bad guys (unless they know your forwarding address so as to
> properly fake the field).
well, it could be faked if the bad guys know which email addresses
forward email to every each user on the net. I think this is a bit
complicated to know if not impossible, so faking this header with
a bad address will cause a rejection.
Where ISP's own trusted forwarder list (based on what its users
provided to it) is a lot easier to keep
up at ISP level and allows to bypass failed SPF checks at the SMTP
level rather then at DATA.
this looks good, if you relate the forwarder ip address, the sender
domain and the recipient, but it allows anyone faking the sender domain
to bypass the check using that forwarder. If you also check the header
after data you totally eliminate the chance of a forgery.
Obviously softfail would not solve the actual MAILFROM forging
problem, but rcpt-to "bypass" system would not solve
it either.
i never talk about bypassing anything, i talk about not bypassing
softfail results.
If you have special modifier and with that modifier you know that "~all"
is to be interpreted as "-all" in such and such case, then that is what
you do, i.e. you then know that is the sender's intent. If sender
otherwise
wants to publish ~all, they'd have to settle for ?all instead (of
course new %all would be better indicating this particular situation,
but it would not be compatible with spf1).
looks better to have something comaptible with spf1
Remember that SPF and DKIM operate at different identities, you can't
substitute one for the other
yes, they are suposed to be complementary. But right now SPF is not
too useful if -all could not be published without having problems
with forwarders, so now you end rejecting a very small amount of
forgeries in spf pre-DATA checks and the real work is done after DATA
Nor can you easily substitute checks at RFC2822 stage for solution
> intended to be used for SMTP2821 session and the other way around
i would mean that if the anti-forgery detection stage is to be done
after DATA, then why use SPF ? (just a philosofical question) what i
mean is that due to forwarders the real work has to be done after
DATA (if you do not get a fail on the pre-DATA spf check), in that
case if you have a softfail you are able to turn it onto a fail if
you know for sure if the message has been forwarded or not. Now, on
most real cases almost all forgeries have the envelope recipient
address in the To: header, so a modifier in the spf record that says
'you could turn a softfail to fail if messsage has not been forwarded'
will stop most of them. The problem is that when people publish such
this modifier bad guys could just use a faked To: