David Brodbeck wrote:
Andriy G. Tereshchenko wrote
Wrong. In case if you are using non-SPF aware ISP you must
be able to
perform email filtering in your MUA. You can check IP address from
Received: against SPF records and move forgery to "Spam" folder.
This is dangerous. Your MUA may be retrieving that mail days
or even weeks after it was sent. The SPF record that was in
force when the mail was sent may no longer be the same as the
one you're checking against.
Nothing really dangerous.
It can be possible to set some limit on age or organize a third-party service
that will keep historical data for SPF records and
reputation.
Or this is can be possible to add a "produced on DD/MM/YYYY, best before
DD/MM/YYYY" timestamps on SPF records to increase consumer
awareness.
Instead of drawbacks - this can provide us additional benefits.
Due to latency in reputation services this is impossible to reject first
10.000s of emails from troyaned PC.
Your MTA or MUA has to recheck reputation after some time if it was not changed
to negative or positive.
This is that that person with flawed auto responder propose to do. Delay email
delivery on 3-5 minutes.
My proposed is to not delay - but recheck SPF/reputation data during or after
MTA->MUA delivery.
This will make it possible for users to use custom configurations different
from generic server one.
Additional level of flexibility at _almost_ no additional costs.
MUA can act as hidden MXs. You can send a bounce from MUA (not only from MTA).
Threat all published MX as secondary and thread your MUA as hidden primary one.
I've configured MXs for my domain in somewhat similar (but not exactly the
same) manner.
24.odessa.ua MX preference = 10, mail exchanger = mail.24.odessa.ua
24.odessa.ua MX preference = 50, mail exchanger = home.24.odessa.ua
If my server is down - let everybody try to deliver emails using SMTP directly
to my home PC (if it's turned on ;-)
If my Outlook was able to accept mail directly from SMTP - you will be unable
to find any difference in MUA/MTA.
SMTP/POP3/IMAP are simply different versions of email transport protocols.
There are at least two different ways to deliver email - Push and Pull.
SPF must attempt to scale for all of them.
Including Bus-Net (Floppy-Net) scenario for disconnected villages of Africa
(I've described before ;-)
--
Andriy G. Tereshchenko
Odessa, Ukraine