Mail server lookup

[Roman Gelfand]

My "send from" domain is unbeatablesale.com. The mail server domain
is pmx1.unbeatablesale.biz.

It appears some receiving smtp servers, microsoft, very few, require
the txt spf record of the sending mail server. Is this correct spf
implementation? If yes, do all mainstream mail providers that have
spf checking check for mail server's spf txt record? The reason why I
am asking is that I would rather put spf record on the outbound mail
server, ie pmx1.unbeatablesale.biz, rather than on "send from" domain
unbeatablesale.com.

Thanks in advance

[alan]

At 16:03 29/09/2013 Sunday, you wrote:
>My "send from" domain is unbeatablesale.com. The mail server domain
>is pmx1.unbeatablesale.biz.
>
>It appears some receiving smtp servers, microsoft, very few, require
>the txt spf record of the sending mail server.

as all should

> Is this correct spf implementation?

yes

> If yes, do all mainstream mail providers that have spf checking check for mail server's spf txt record?

unfortunately many have never even read the docs

> The reason why I am asking is that I would rather put spf record on the outbound mail
>server, ie pmx1.unbeatablesale.biz,

you should as its easy

> rather than on "send from" domain unbeatablesale.com.

its not an either or, you should authenticate both, but as always you never have to use spf at all


yes spf is used to check/prevent forgeries on both

the helo/ehlo domain of the sending server
AND
the 'mail from'/envelope-sender

a pass/hardfail/neutral/none/softfail on either (depending on receiver policy) effects the accept/reject decision making

some servers do not bother checking for forgeries of the helo/ehlo, some do
(i know I do with spf,csv,dns and syntax checking to name a few)
it really helps avoid a lot of bot-mail where its obvious the helo is invalid
(as few bots have a domain pointed at their ip that passes any of the above)
and most send mail from domians that do not use spf or do not hardfail so envelope-sender checking is useless in those cases

the reasoning is obvious
setting up an spf for the helo domain is easy (as most mailservers only have one sending ip and there is never a need for a neutral or softfail response)
(protects against people claiming to send their spam via your servers)
additionally hints that your server is potentially well-run which earns trustability points with providers like myself

setting up an spf for the envelope-sender is still advised however
as people can and do send forgeries via otherwise legit un forged smtp servers
and by not protecting your envelope-senders domain you would be allowing anyone to forge it via any other mailserver.






>Thanks in advance
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-ec5a0568
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20130929110339:5131C64A-2918-11E3-824D-9A1E85D97AD6
>Powered by Listbox: http://www.listbox.com

[Gino Cerullo]

In addition to what Alan said, as a general rule of thumb, any domain or hostname that publishes an ‘A‘ record should have a corresponding SPF record that tells the world whether it is allowed to send mail and, if allowed, what IP addresses are authorized. Otherwise all those domain/host names are subject to abuse.


On 2013-09-29, at 12:00 PM, alan <***@alandoherty.net> wrote:

> At 16:03 29/09/2013 Sunday, you wrote:
>> My "send from" domain is unbeatablesale.com. The mail server domain
>> is pmx1.unbeatablesale.biz.
>>
>> It appears some receiving smtp servers, microsoft, very few, require
>> the txt spf record of the sending mail server.
>
> as all should
>
>> Is this correct spf implementation?
>
> yes
>
>> If yes, do all mainstream mail providers that have spf checking check for mail server's spf txt record?
>
> unfortunately many have never even read the docs
>
>> The reason why I am asking is that I would rather put spf record on the outbound mail
>> server, ie pmx1.unbeatablesale.biz,
>
> you should as its easy
>
>> rather than on "send from" domain unbeatablesale.com.
>
> its not an either or, you should authenticate both, but as always you never have to use spf at all
>
>
> yes spf is used to check/prevent forgeries on both
>
> the helo/ehlo domain of the sending server
> AND
> the 'mail from'/envelope-sender
>
> a pass/hardfail/neutral/none/softfail on either (depending on receiver policy) effects the accept/reject decision making
>
> some servers do not bother checking for forgeries of the helo/ehlo, some do
> (i know I do with spf,csv,dns and syntax checking to name a few)
> it really helps avoid a lot of bot-mail where its obvious the helo is invalid
> (as few bots have a domain pointed at their ip that passes any of the above)
> and most send mail from domians that do not use spf or do not hardfail so envelope-sender checking is useless in those cases
>
> the reasoning is obvious
> setting up an spf for the helo domain is easy (as most mailservers only have one sending ip and there is never a need for a neutral or softfail response)
> (protects against people claiming to send their spam via your servers)
> additionally hints that your server is potentially well-run which earns trustability points with providers like myself
>
> setting up an spf for the envelope-sender is still advised however
> as people can and do send forgeries via otherwise legit un forged smtp servers
> and by not protecting your envelope-senders domain you would be allowing anyone to forge it via any other mailserver.



--
Gino Cerullo

Pixel Point Studios
21 Chesham Drive
Toronto, ON M3M 1W6

416-247-7740

[Sanford Whiteman]

Roman, it's frustrating to see you re-ask the same questions that a
few of us have already answered in detail. It's like you want SPF to
conform to your expectations instead of believing we really know how
it works! (Why would you "rather" have the SPF for your HELO than have
the SPF for the sender domain? What basis do you have for such a
preference, or for the notion that it's an either/or situation?)

Imagine you're accused of a crime and you need to prove it isn't you
on a surveillance cam.

You don't know what side the camera is shooting from, or what part of
your body is captured.

Every SPF record is a "distinguishing mark" you have that the perp
doesn't.

Would you want to *reduce* the number of marks that distance you from
the actual bad guy?

OK, maybe the analogy is a stretch, but the message should be clear
from this and other threads you've started. In order to honestly say
you use SPF to protect against impersonation, you MUST have an SPF
record for your sender domain(s). If you send bounces from your
mailserver (which you almost certainly do), you also MUST have an SPF
record for your HELO hostname(s); if you do not send bounces from your
mailserver, you still SHOULD have an SPF record for your HELO. As Gino
points out, you also COULD have SPF records for any A record you have,
even those not legitimately used for mail.

Each of these records is used in one or more scenarios. Sometimes they
protect directly against use of your domain by other mailservers;
sometimes, they authorize messages from your mailservers with a simple
yes/no decision; other times, as Alan notes, they help legitimate
connections from your mailserver do better on a weighted anti-spam
scale because they imply you know how to run the IT part of your
business.

There is no excuse for not having the maximum amount of SPF coverage
if you are the DNS admin for all involved domains. As we've all said
in earlier e-mails, nothing forces you to use SPF. But good sense and
technical understanding should force you to either use it widely or
don't use it all. Note "widely" doesn't necessarily mean every record
needs to end with hardcore -all (though, yes, that would be ideal).
What it means is that you should maintain records for every situation
in which a remote mailserver might show interest.

-- S.