Am 04.02.2016 um 19:51 schrieb Alan Hodgson:
On Thursday, February 04, 2016 07:41:44 PM Reindl Harald wrote:which people don't know this? admins? don't maintain services then! users? just use the SMTP server your mailprovider tells you and no other one and for smtp-admins: just don't accept enevlope senders for which you would not accept incoming mail that is as easy as something can beYeah, it's really really not.
it is
I'm in a 50 person company and we have our internal mail server, 3 different ESPs sending mail on our behalf for diffferent applications, Google calendar sending on our behalf, and 2 different SAAS customer service platforms sending as us. I can't even imagine how many different sources a large company has.
normally all that "on our behalf" are using their own envelope and the From-Header, this applies to Google and all legit mass-senders
if it's not mass-senders nothing easier than tell a MTA to relay over the correct MTA including authentication, that's what we do for many years when we send "on behalf" of a customer not hosting mail on our infrastructure
And SPF doesn't do anything about the only part of the message the users care about, the message headers.
different storybut "~" is for TESTING and if i don't intend to *really* use SPF i don't start with it and if i don't grok that difference at least i do not demand from others how they have to setup their mail domains
In any event, SPF is legacy. DKIM and DMARC are the present and near future of mail services. DMARC uses SPF only as a fallback for broken or missing DKIM signatures
DKIM is way to fargile at all - guess why SpamAssasin just uses T_DKIM_INVALID instead of DKIM_INVALID - because it randomly failed for untouched legit mail, Google for other parts of mailsystems then SA which has and have the same issues and the come back and talk about the future
signature.asc
Description: OpenPGP digital signature
