On 9/16/22 11:42 AM, Jaroslaw Rafa via mailop wrote:
Well, when I'm sending the mail, I can never be sure which route it will take. What I know is that in *first step* the mail will be sent from X, Y or Z. But there's always the possibility that the mail I send to [email protected] will be forwarded from there to [email protected]. I can't know that.
You can also have a bad actor at domain1.com spoofing email to [email protected] pretending to be you.
Hence I fall back on /I/ /only/ /authorize/ X, Y, and Z to send email fro my domain. I'm very well aware that domain1.com is not in the X, Y, nor Z list. As such, domain1.com is /NOT/ /authorized/ to send email as my domain.
And as you surely know, forwarding breaks SPF. You can argue about rewriting the envelope-from, but this doesn't matter because standard forwarding as it is configured in MTAs doesn't do this and you have to use special tools.
The standard configuration of the MTA software doesn't take a lot of things into account which have changed since the venerable .forward was new; reverse DNS, SPF, DKIM, DMARC, spam, viruses, etc. It's not 1995 any more and it's time to let go of some simpler minded ides from 25+ years ago.
SRS is an option. I use SRS to successfully forward email to Gmail. Other systems have .forward or .procmailrc forwarding that generates a new message with the original message as an attachment. There are options.
But domain1.com is /NOT/ /authorized/ to send email as my domain.
And I don't agree with those who say we should give up forwarding and instead use fetching mail via POP or IMAP by the "target" server from the "source" one.
Note well how I'm /not/ giving up on forwarding. I've just changed how I forward to keep up with contemporary SMTP ecosystem.
This is a crazy concept that might appear only as a poor workaround for mailbox providers that didn't give the users an option to forward mails. Forwarding is much simpler and more flexible (eg. you can set up a filter to forward only selected messages) and is compatible with the whole concept of email, which works on "push" and not "pull" principle. Not mentioning the fact that you have to store credentials for your "source" account on the "target" server, which may be a security concern.
I agree with all of that. You can even forward different message to different places. ;-)
So I can never be sure what IP addressess will my emails be actually sent from.
I disagree. Unless your out-bound MTA is on a dynamic IP and even then, I maintain you should know what IP address(es) will /originate/ your messages.
Therefore, for me "-all" doesn't make sense; the most we can say is "~all", but even this can be doubtful; what is "actually true", and what the sender knows for sure, is "?all" - nothing more.
It becomes a question of who do you authorize to (re)send email claiming to be from you? -- It seems as if you personally have chosen to say that you allow some other people to send email claiming to be from you. That's /you/ /choice/ /to/ /make/. I respect that. I also respectfully disagree with the choice that you have made. But again, /it's/ /your/ choice/.
There is one and only one case where "-all" is actually meaningful: when it is the only token in the SPF record, that is, the domain declares that it doesn't send mail at all.
That's your opinion. An opinion that I obviously disagree with.P.S. Yes, I'm fully aware that there are other protection mechanism like DKIM and DMARC / ARC. But I believe in a belt and suspenders approach where I close and latch every single picket fence gate that I can.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
