Re: spf and relay

For email to Internet MTAs / SMTP servers,
for SPF, I'd be inclined to have in the SPF record, first, the data
which covers the
IP client address(es) as will be seen by the receiving servers as the client IP
of those TCP connections.  And, reason for that is efficiency / best
practices - notably server
will then have the IP data from SPF record, and can check whether or
not that matches the
client IP address of the TCP connection as seen by the server, without
doing any further DNS
lookups - most alternative and/or additional SPF data will generally
require further DNS lookups,
and for some SPF data, even multiple DNS lookups - so generally best
to keep that as
efficient as possible.  Not always feasible to do it that way (e.g.
one may not be able to control
what those IPs are and they may be subject to change beyond one's
control, in which case may
need to specify them indirectly). And in server having looked up the
SPF data itself (DNS
TXT record), it already has, before even doing that lookup, domain, so
once the SPF
record is received it also has that data to work with on matching (but
generally starts with that
from SMTP envelope (not header) FROM and/or HELO data).  So, at that
point it can check
that client IP as seen by server from the SMTP connection, and domain name match
as expected.  And, well, if it needs to do further DNS lookups based
upon the SPF data, well,
then it will do so.  And of course, beyond SPF itself, server may also
use that data to aid
in determining ham vs. spam calculations/estimates, e.g. how
does/doesn't it match/correlate
to the mail headers, what about "reverse" DNS (PTR record(s) for the
IP), is it present, and
how does/doesn't it match or correlate, how (in)efficient is the SPF
data (if a quite long chain
of inclusions and DNS lookups and tons of data, maybe that's more
prone to errors and ought
not be trusted quite as much), etc.

Anyway, for most all modern/current SMTP traffic on The Internet, to
generally be accepted and
have a fighting chance of landing in "inbox" (as opposed to "spam" or
the like), SPF is pretty much
effectively required for most Internet SMTP servers.  Similarly, DKIM
is generally rather to highly
recommended (if not effectively required).  Neither of these
mechanisms are "perfect", but they're
a generally good start for having SMTP servers reject much of spam
that's attempted.  Certainly
not 100%, but with that/those measures, plus reputation, and actual
content, that goes quite a
way on not having spam in "inbox" or the like, while mostly landing
legitimate mail in "inbox"
Anyway, SPF, most basic and pretty much effectively "mandatory" to be
able to mostly be able
to successfully get email into "inbox" (and likewise appropriate PTR record(s)),
and also rather/quite important and not far behind, DKIM.  Other than
that, mostly the content itself,
and also factors such as reputation, and also matters such as delivery
rates (how many emails per
TCP connection/second/minute/hour, how many simultaneous TCP connections, etc.).

On Thu, Mar 13, 2025 at 4:41 AM Ivan Sergio Borgonovo
<[email protected]> wrote:
>
> Here my older ISP provided to be so incompetent at so many levels that
> I've finally decided to pick up a new one.
>
> The new one came with a fixed IP...
> Now my server at home has a static dns entry as well.
>
> Personally I never had too many problems sending email out, but if I can
> do things more properly, I'd be happy.
>
> What I do is I've a postfix server at home that collect all the emails
> from my lan and relay via sender_dependent_relayhost_map and
> smtp_sasl_password_maps to my [service I use to manage my web space and
> email].
> All PCs at home run a local postfix instance that relay on my main
> server at home.
>
> They seems to do a pretty good job to manage my email, they monitor
> incoming and outgoing mail, they take care of the spf record etc...
>
> I was wondering since my MTA is in the chain of delivery and it is
> listed in the "Received:" headers if I should ask that my now fixed ip
> should be added to my spf record or I can do anything else to improve
> the chances my email doesn't get dropped by spam filters.
>
> thanks
>
>
> --
> Ivan Sergio Borgonovo
> https://www.webthatworks.it https://www.borgonovo.net
>
>
>
> _______________________________________________
> conspire mailing list
> [email protected]
> http://linuxmafia.com/mailman/listinfo/conspire

_______________________________________________
conspire mailing list
[email protected]
http://linuxmafia.com/mailman/listinfo/conspire