Hector Santos wrote:
If I send mail to a host which is listed as the MX destination,
and unbeknown to me this SPF ignorant host receives and relays
to mail to some "real final destination" host using SPF, the
real host will result with a SPF=FAIL.
Yep, that's precisely what happens if nobody cares about it. If
you are lucky you get a nice 551 emulation (NDR from forwarder),
and you <eai> can make another plan </eai>.
If I was DKIM signing my mail, the "real final destination"
host supporting DKIM, won't reject this multiple hop relay
issue that raw SPF has.
Right, to get in trouble with DKIM you need a clueless mailing
list or resender, and SSP. On the other hand DKIM without SSP
might not really help you, if nobody bothers to whitelist you.
There is no SSP record for gmail.com. The only reliance I
have that this is even worthy of complex processing is when
its valid 1st party domain.
That they don't have SSP *yet* is no surprise. They also have
no SPF FAIL, maybe they don't like FAIL because they fear that
it causes more support costs than not adding it. Or they want
that users can use their GMail address as envelope sender via
other routes to some ("NEUTRAL") degree, and there was so far
no issue with massive forgeries. AOL also uses only PASS, it
helps - you can accept PASS on probation, and bounce it later.
Or add white lists on top of a PASS, same idea as with DKIM...
1) 3rd party signer, but uses From: xxxx(_at_)gmail(_dot_)com
If this is spam, I have a lot of wasted processing time,
never mind the potential harm to end users. They can
also continue to spoof my gmail.com against me and others.
...right, so you won't add that third party to your white list.
2) No Signature, someone can continue to use my gmail.com
and send spam, malicious mail.
You could emulate SSP by treating "no signature from gmail" as
less than NEUTRAL. Admitteldly I don't like this, "less than
NEUTRAL" mails will often die after 30 days in a spam folder,
especially if it's a reliable spam folder otherwise. But less
than NEUTRAL is also not bad enough for a reject, "SSP" is not
per se a bad idea. Only the "first author" part hardwired in
RFC 5016 limits it to shaky assumptions about what "Bob" does.
Now GMAIL.COM is an ESP and like other free accounts large ESPs,
the gmail.com domain is already considered a junk address,
people use it for JUNK, just look at your JUNK address.
Nope, after twenty rounds of trying to find a free user account
for something (it wasn't GMail at this point in time, maybe it
was googlepages) I had enough and started the keyboard-random-
generator. It's my second best address at the moment (the best
has of course SPF FAIL like my old addresses) for public use,
testing if IMAP is better today, etc.
If you don't think people see that with a "hmmmmm" pause, you
should because it appears to be just like all the other spam
junk.
Not really worse than nobody(_at_)xyzzy, no wannabe-spam deterrent.
Most people I know use the gmail.com account to direct their
junk to and also use it for junk sign ups or to hide their
identity, etc.
Using a *Google* service to hide their identity, now here's a
seriously flawed idea. I'd try "mailinator" for this, if it
still exists, only for harmless cases.
If bank.com does not have a strict SSP policy, it will be
just as vulnerable as gmail.com.
If bank.com is too timid for SPF FAIL like gmail.com it also
won't be happy with SSP, mechanisms having an effect measured
by "rejects" cut in both directions depending on the receiver.
If legit mails can be trapped in spam folders they are lost,
no matter whose fault that was, and maybe bank.com fears this
outcome more than forgeries. Look at Ebay and Paypal. Either
a mechanism is toothless, or not, and then it can bite you.
DKIM/SSP must have a benefit on its own.
Sure. DKIM alone must have a benefit of its own, I'd bet on
"more reliable than PRA PASS" wrt "traditional forwarding".
we use an automated white/black list system.
[...]
I don't wish to get into the actual details so please don't
nit pick on that. :-)
Don't worry, I thought about some "auto-white" DKIM-PASS-no-
spam feedback loop, but then didn't mention it because five
minutes thinking weren't enough, not obviously trivial... ;-)
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html