none
Inundated with spam from a foreign country, Postini not working, block by TLD?

    Question

  • Hello all,

    Until now, we have used Google's Postini services to block spam with mixed results.

    Recently, spammers spoofing our own domain name are inundating some of our user's mailboxes with dating spam: "Find true love", etc..

    Besides placing the spam filter settings at the highest level (using the Postini web interface) for the users in question, I am wondering if I would gain anything by enabing the native spam filtering functionality in Exchange 2007 (Hub Transport, no ET here) and attempting to block by top level domain - country in this case?

    I do not seem to have such an option with Postini - at least not with the service we are using.

    As I said, the email address is spoofed: user@ourdomain.com but if I look at the message details, I can see the original though obfuscated address: adfkhegbarkdmenrnfadfmdsg@whatever.tld

    -------------------------------------------------------------------------

    Some more questions...

    Assuming Postini does block the vast majority of spam, what kind of load would enabling spam filtering services place on the HT server?

    Other question:

    Would it be worth it?

    if I block by sender domain, let's say .fr or .uk or .ca, will Exchange know enough to find the "real" country domain in the message details even though OUR domain - user@ourSpoofedDomain.tld - is displayed in the address?

    Sunday, October 09, 2011 7:30 PM

All replies

  • On Sun, 9 Oct 2011 19:30:15 +0000, Le Pivert wrote:
     
    >Until now, we have used Google's Postini services to block spam with mixed results.
    >
    >Recently, spammers spoofing our own domain name are inundating some of our user's mailboxes with dating spam: "Find true love", etc..
     
    Do you normally have inbound e-mail from your own domain? If not,
    block senders in that domain.
     
    Publishing a SPF (both version 1 and 2) record in your DNS would also
    help you, and others that may be receiving e-mail that claims to be
    from your domain.
     
    >Besides placing the spam filter settings at the highest level (using the Postini web interface) for the users in question, I am wondering if I would gain anything by enabing the native spam filtering functionality in Exchange 2007 (Hub Transport, no ET here) and attempting to block by top level domain - country in this case?
     
    That's not eaactly "spam filtering," but it would work. But if the
    mail is from your own domain name, how would you make that work???
     
     
    >I do not seem to have such an option with Postini - at least not with the service we are using.
    >
    >As I said, the email address is spoofed: user@ourdomain.com but if I look at the message details, I can see the original though obfuscated address: adfkhegbarkdmenrnfadfmdsg@whatever.tld
     
    Where do you see that (in which header)?
     
     
    >Assuming Postini does block the vast majority of spam, what kind of load would enabling spam filtering services place on the HT server?
     
    Not much if all you're doing is sender filtering. Just be sure you've
    properly identified all the SMTP relay servers in your organization so
    you don't apply whatever filtering you do to them.
     
    >Other question:
    >
    >Would it be worth it?
    >
    >if I block by sender domain, let's say .fr or .uk or .ca, will Exchange know enough to find the "real" country domain in the message details even though OUR domain - user@ourSpoofedDomain.tld - is displayed in the address?
     
    You'd have to state in which RFC2822 header you see the sender's
    address. Sender filtering usually works on the RFC2821 address in the
    MAIL FROM command (or Return-Path header).
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, October 09, 2011 11:54 PM
  • Hello Rich,

    Thanks for helping out.

    Where do you see that (in which header)?

    Here is an example taken from "Internet header":

    Received: from psmtp.com (64.18.2.191) by mail.ourdomain.com (x.x.x.x) with
    Microsoft SMTP Server id 8.2.255.0; Fri, 7 Oct 2011 22:36:51 -0400
    Received: from device.lan ([190.250.51.41]) by exprod7mx184.postini.com
    ([64.18.6.14]) with SMTP; Fri, 07 Oct 2011 22:36:51 EDT
    Received: from 190.250.51.41(helo=ourdomain.com) by ourdomain.com with esmtpa (Exim
    4.69) (envelope-from ) id 1MM0L9-1266wm-DU for <user1@ourdomain.com>; Fri, 7 Oct
    2011 21:36:50 -0500
    From: <user1@ourdomain.com>
    To: <user1@ourdomain.com>
    Subject: Can Romance last forever
    Date: Fri, 7 Oct 2011 21:36:50 -0500
    MIME-Version: 1.0
    Content-Type: text/plain; charset="us-ascii"
    Content-Transfer-Encoding: 7bit
    X-Mailer: rboyinsadr_66
    Message-ID: <8450914395.M8J8DA21091779@ahvdyhcfzt.accjwt.su>
    X-pstn-neptune: 0/0/0.00/0
    X-pstn-levels: (S: 0.02101/96.03835 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 )
    X-pstn-settings: 5 (2.0000:2.0000) s cv gt3 gt2 gt1 r p m c
    X-pstn-addresses: from <user1@ourdomain.com> forward (org good) [db-null]
    Return-Path: 0-ja@cancer.org

     

    -> BTW, x.x.x.x is the IP of our mail server.

     

    Publishing a SPF (both version 1 and 2) record in your DNS would also
    help you, and others that may be receiving e-mail that claims to be
    from your domain.

    Of course, and I requested that the company in charge of our external DNS do exactly that (a while ago, in fact, so it does not seem to be working).

    That's not eaactly "spam filtering," but it would work. But if the
    mail is from your own domain name, how would you make that work???

     

    That's precisely the question.

    Couldn't I make an exception for the IP of our mail server, for example: 192.168.0.1?

    Wouldn't this apply?

    Not much if all you're doing is sender filtering. Just be sure you've
    properly identified all the SMTP relay servers in your organization so
    you don't apply whatever filtering you do to them.

    We don't have relay servers (one mail server and one alone).

     

     

     

     

     

     

     

     

    Monday, October 10, 2011 4:32 PM
  • Just found this. Wonder if it would apply to my situation?

    http://exchangepedia.com/2008/09/how-to-prevent-annoying-spam-from-your-own-domain.html

    Monday, October 10, 2011 5:03 PM
  • On Mon, 10 Oct 2011 16:32:01 +0000, Le Pivert wrote:
     
    >>Where do you see that (in which header)?
     
    >Here is an example taken from "Internet header":
     
    >Received: from psmtp.com (64.18.2.191) by mail.ourdomain.com (x.x.x.x) with Microsoft SMTP Server id 8.2.255.0; Fri, 7 Oct 2011 22:36:51 -0400 Received: from device.lan ([190.250.51.41]) by exprod7mx184.postini.com ([64.18.6.14]) with SMTP; Fri, 07 Oct 2011 22:36:51 EDT Received: from 190.250.51.41(helo=ourdomain.com) by ourdomain.com with esmtpa (Exim 4.69) (envelope-from ) id 1MM0L9-1266wm-DU for <user1@ourdomain.com>; Fri, 7 Oct 2011 21:36:50 -0500 From: <user1@ourdomain.com> To: <user1@ourdomain.com> Subject: Can Romance last forever Date: Fri, 7 Oct 2011 21:36:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: rboyinsadr_66 Message-ID: <8450914395.M8J8DA21091779@ahvdyhcfzt.accjwt.su> X-pstn-neptune: 0/0/0.00/0 X-pstn-levels: (S: 0.02101/96.03835 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 5 (2.0000:2.0000) s cv gt3 gt2 gt1 r p m c X-pstn-addresses: from
    ><user1@ourdomain.com> forward (org good) [db-null] Return-Path: 0-ja@cancer.org
     
    Okay, the message is from "0-ja@cancer.org" (taken from the
    "Return-Path" header, and that's not from "another country"). The
    "From:" header is "user1@ourdomain.com".
     
    The IP address (190.250.51.41) is listed in a number of DNSBLs.
     
    >-> BTW, x.x.x.x is the IP of our mail server.
     
    >>Publishing a SPF (both version 1 and 2) record in your DNS would also help you, and others that may be receiving e-mail that claims to be from your domain.
     
    >Of course, and I requested that the company in charge of our external DNS do exactly that (a while ago, in fact, so it does not seem to be working).
     
    I guess I'd have to ask you what you mean by "not working." Without
    knowing the domain name it isn't possible to check anything from out
    here. :-)
     
    What's Postini's policy (or your choice of options) for handling SPF
    failures? Note, that the MAIL FROM domain is what's going to be
    checked, not the contents of the "From" header.
     
    The SPF info for cancer.org doesn't include the 190.250.51.41 IP
    address of the sender, do it's a pretty good guess that the setup you
    have at Postini isn't checking for SPF failures.
     
    >>That's not eaactly "spam filtering," but it would work. But if the mail is from your own domain name, how would you make that work???
    >
    >That's precisely the question.
    >
    >Couldn't I make an exception for the IP of our mail server, for example: 192.168.0.1?
     
    Sure. But you would probably use 192.168.0.0/24.
     
    >Wouldn't this apply?
    >
    >>Not much if all you're doing is sender filtering. Just be sure you've properly identified all the SMTP relay servers in your organization so you don't apply whatever filtering you do to them.
    >
    >We don't have relay servers (one mail server and one alone).
     
    I'd start with the properties page at Organization Configuration | Hub
    Transport | Global Settings | Transport Settings. Select the "Message
    Delivery" tab and add 192.168.0.0/24. Continue adding the networks, or
    IP address ranges, or individual IP addresses of the Postini servers
    that send you your filtered e-mail. That will inform Exchange to skip
    any "Received" headers in the messages until it finds the first one
    that doesn't belong in that set of addresses. Exchange will then use
    that Received header to extract the sender's IP address.
     
    Then move to the "Anti-pam" tab and enable "Sender ID". Then look at
    its property page and select the "Action" tab. You can pick what you
    want Exchange to do when SenderID detects a problem. SenderID will
    check the PRA (http://en.wikipedia.org/wiki/Sender_ID). You can decide
    if you want to use SenderID with "pra" or "mfrom" (or both), but the
    SPF/mfrom won't pick up a PRA from your own domain if the MAIL FROM is
    using some other domain.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Monday, October 10, 2011 7:02 PM
  • On Mon, 10 Oct 2011 17:03:57 +0000, Le Pivert wrote:
     
    >
    >
    >Just found this. Wonder if it would apply to my situation?
    >
    >http://exchangepedia.com/2008/09/how-to-prevent-annoying-spam-from-your-own-domain.html
     
    Yes, it does. But if you every hire a 3rd party e-mail to advertise
    you won't get any of the e-mail they send. ;-)
     
    You'd also have problems with employees using other e-mail systems
    that allow them to spoof your domain.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Monday, October 10, 2011 7:06 PM
  • Okay, the message is from "0-ja@cancer.org" (taken from the
    "Return-Path" header, and that's not from "another country"). The
    "From:" header is "user1@ourdomain.com".

    OK. What led me to believe the mail originally... originated from somewhere else was this:

     

    Message-ID: <8450914395.M8J8DA21091779@ahvdyhcfzt.accjwt.su> 

     

    Some were .in and so forth.

     

    Could you tell me what Message-ID designates?

     

    Thanks.

    Tuesday, October 11, 2011 3:32 PM
  • You'd also have problems with employees using other e-mail systems
    that allow them to spoof your domain.

     

    Like... Constant Contact?

    http://www.constantcontact.com/index.jsp

     

    I've heard they spoof domains (for legitimate purposes).

    Hmmm. No easy solution here.

    Tuesday, October 11, 2011 3:35 PM
  • On Tue, 11 Oct 2011 15:32:52 +0000, Le Pivert wrote:
     
    >
    >
    >Okay, the message is from "0-ja@cancer.org" (taken from the "Return-Path" header, and that's not from "another country"). The "From:" header is "user1@ourdomain.com".
    >
    >OK. What led me to believe the mail originally... originated from somewhere else was this:
    >
    >
    >
    >Message-ID: <8450914395.M8J8DA21091779@ahvdyhcfzt.accjwt.su>
    >
    >
    >
    >Some were .in and so forth.
    >
    >
    >
    >Could you tell me what Message-ID designates?
     
    The contents of the Messages-ID header are meaningful only within the
    sending organization. It's used only to uniquely identify a message.
     
    In many cases the part to the right of the "@" is the name of a
    machine, but it can be anything as long as it conforms to the RFCs.
     
    The sender (whoever they were) spoofed the domain in the MAIL FROM
    command. If you were using SPF that would have been detected. If you
    were using SenderID the PRA (in your domain) would have been seen as
    spoofed.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Tuesday, October 11, 2011 7:48 PM
  • Until now, we have used Google's Postini services to block spam with mixed results.

    So, just drop such a service and handle the filtering "in house" :)

    All in all, it isn't all that difficult, even without using any 3rd party tool, exchange allows you to set up some quite good filtering; it's just a matter of taking the time to understand how the filters have been designed and how they interact each other; maybe it will take some time or maybe not (I've no idea about your skill level) but, in either case, it will be worth and, at least, will allow you to get a better grip on Exchange

    You may start by configuring IP whitelists (see here), those will help avoiding false positives since an IP which gets a match on a whitelist will bypass blacklists checks; then you may go on configuring IP blacklists (see here) to reject emails from "bad senders" (which, by the way, won't be whitelisted); then, you may go on setting proper SCL scores; those will help you fine-tuning your filters, then, to get a better grip on the overall filtering, you may want to read this and this and you may also want to enable logging (at a bare minimum, to enable this log) and to (at least at the beginning) regularly check the various logs (this tool will help in such a task); also, and since we're at filtering, it would also be a good idea installing an "integrated AntiVirus" on your exchange box, I'm not referring to an AV scanning the filesystem but to something which will tightly integrate with the Exchange server and scan all the inbound and outbound email messages... just ensure to configure such a tool so that it will issue a straight "reject" (SMTP error 5xx) and avoid generating bounces (see here for a detailed explanation); by the way you may also want to enable SenderID/SPF checks and publish your own SPF record in DNS (it's a good idea and will help your mailserver getting a better "reputation"); also, and since we're at it, ensure that your Exchange is using both "recipient filtering" and "tarpitting" (see here); this is mandatory, the recipient filtering will avoid your exchange to send out NDRs to non-existing or spoofed senders, while the tarpitting will avoid "address harvesters"

    Then... ok, there's a lot more, but I hope that the above may allow you to get started

     


    • Edited by ObiWan Wednesday, October 12, 2011 1:08 PM
    Wednesday, October 12, 2011 1:07 PM
  • So, just drop such a service and handle the filtering "in house" :)

    I thought it would be preferable to block spam (to the extent that it IS blocked) upstream before it reaches our Hub Transport server. Yes, that's right, at least until now, and because we are using Postini, we do not have an Edge Transport server.

    All in all, it isn't all that difficult, even without using any 3rd party tool, exchange allows you to set up some quite good filtering; it's just a matter of taking the time to understand how the filters have been designed and how they interact each other; maybe it will take some time or maybe not (I've no idea about your skill level) but, in either case, it will be worth and, at least, will allow you to get a better grip on Exchange.

    I've managed Exchange 2007 in a small setting (100+ mailboxes, several thousand contacts, some in GAL, most in Public Folders) for 2.5 years. I've worked with some of the Exchange anti-spam methods in practice for Microsoft certification in a test lab at home. However, because we use Postini, I have not had the chance to (try to) make them work in real life.

    But... as long as enabling those features does not tax the Exchange server, I think move in that direction, if only for the reason you state: getting a better grip on Exchange, with which I enjoy working very much. 

     

    Thursday, October 13, 2011 1:04 PM
  • So, just drop such a service and handle the filtering "in house" :)

    I thought it would be preferable to block spam (to the extent that it IS blocked) upstream before it reaches our Hub Transport server. Yes, that's right, at least until now, and because we are using Postini, we do not have an Edge Transport server.

    Well... that's a choice, and, as any other choices has pros and cons; having direct control over your mailserver (ok, Mail eXchanger, aka "MX") allows you to fine tune your filters to exactly match your needs... and this, by the way, will be almost impossible if using a 3rd party email service; all in all, such services can't "narrow" their filters too much; the usual "my spam is someone's else ham" principle applies here :)

    All in all, it isn't all that difficult, even without using any 3rd party tool, exchange allows you to set up some quite good filtering; it's just a matter of taking the time to understand how the filters have been designed and how they interact each other; maybe it will take some time or maybe not (I've no idea about your skill level) but, in either case, it will be worth and, at least, will allow you to get a better grip on Exchange.

    I've managed Exchange 2007 in a small setting (100+ mailboxes, several thousand contacts, some in GAL, most in Public Folders) for 2.5 years. I've worked with some of the Exchange anti-spam methods in practice for Microsoft certification in a test lab at home. However, because we use Postini, I have not had the chance to (try to) make them work in real life.

    But... as long as enabling those features does not tax the Exchange server, I think move in that direction, if only for the reason you state: getting a better grip on Exchange, with which I enjoy working very much. 

    Well... if you want to try that (and in my opinion it could be a good idea), here's my suggestion

    Start by enabling your exchange spam filters, but ensure to add the "google postini" IP addresses (the ones currently delivering email to your exchange) to the "trusted IP list" so that email flow will keep going as it is now... till now we just enabled spam filtering but, in reality, we didn't change anything at all :)... now...

    Configure the DNS whitelists (aka "DNS allow lists" in Exchange 2010 parliance) by following this document (look at the bottom of page for some decent DNSWL providers); done that, go on and configure the DNS block lists (DNSBLs) following this (again, there's a list of providers at bottom); also, and since we're at it, ensure to enable SenderID (aka SPF) filtering and also to enable recipient filtering and tarpitting so that, in case a given message is addresses to a non-existing mailbox, your exchange will issue a straight SMTP reject (SMTP error 5xx) instead of generating an NDR also known as "bounce" which is a BAD THING (more infos here) also, and since we are at SenderID/SPF; it may be a good idea publishing an SPF/SenderID record for your domain(s); to do so, just use the wizard found here which will help you correctly generating such a record (which you'll then need to add to your DNS zone as a "TXT" record) as a note the simpler form of SPF/SenderID record is "v=spf1 mx -all"; such a record will just tell to the world that the only hosts allowed to send email for that given domain are the ones indicated as "MX" in the domain DNS zone :)

    As for DNS blacklists; the default exchange reject message is a generic one; something like "550 5.7.1 Recipient not authorized, your IP has been found on a block list" now, such a message isn't of help in case a poor folk, whose mailserver IP was blacklisted, will try sending you emails, so, my suggestion is to customize the DNSBL reject messages (you'll have to do so for each and every DNSBL you'll use) to be meaningful; Exchange comes to help in such a task since it allows to use some "macro" expressions inside the reject message, namely

     

    {0}: Sender IP address
    {1}: Filtering rule name
    {2}: DNSBL provider FQDN
    

     


    as a note, Exchange 2003 used a different syntax, so, instead of using "{x}"  you'll have to use "%x" (so %0, %1 %2) in your macro; at any rate, my suggestion is to set up your custom DNSBL reject message so that it will look this way

     

    Message refused by {1}: your IP {0} is listed by {2} (see http://multirbl.valli.org/lookup/{0}.html for details).
    

    the above means that, assuming that the sending IP was 192.0.2.1, the rule name was "ZEN" and the blacklist was "zen.spamhaus.org", your exchange server will emit an error which will look this way

     

     

    Message refused by ZEN: your IP 192.0.2.1 is listed by zen.spamhaus.org (see http://multirbl.valli.org/lookup/192.0.2.1.html for details).
    

    as you see, a message like the above will be much more meaningful and will allow the sender to find out why the email was refused, which IP it came out from and which blacklist caused the reject... so, hopefully, allowing him to fix the issue and get delisted

     

    Then... ok, there's a lot more to say, but I think and hope that the above may allow you to get started

     


    • Edited by ObiWan Thursday, October 13, 2011 1:59 PM
    Thursday, October 13, 2011 1:57 PM
  • Thanks for all the tips.

    In fact, I had requested that the people in charge of our external DNS publish a SPF record.

    I used the formula recommended by Rich Matheisen at the time.

    Thursday, October 13, 2011 2:24 PM
  • Thanks for all the tips.

    In fact, I had requested that the people in charge of our external DNS publish a SPF record.

    I used the formula recommended by Rich Matheisen at the time.

    You're welcome; as for SPF records and "external DNS"... why don't you "get in charge" with your domain DNS servers :) ? No, I'm not kidding, it's not "rocket science"; all you'll need is having a (possibly in DMZ) published DNS server; configure it to be authoritative only (recursion disabled, no root-hints or forwarders), load your DNS zone(s) on it as standard primary zones and then publish its port 53 (UDP and TCP) on the internet; done that, open up an account here (the basic account is free, but you may opt for the paid one which btw won't cost you an arm and a leg :D) and proceed setting up secondary DNS servers for your domain; point them to your published DNS IP (as above) and wait for the zone transfer to take place and you'll be in business; from that moment on, to issue any change to your public DNS zone you'll just need to perform the needed changes on your local (DMZ) DNS and those will then be propagated to the secondary servers and be in effect in a short while... not bad imHo :)

    Uh ... as for the SPF settings... which "recommended formula" are you referring to ?

     

    Thursday, October 13, 2011 2:47 PM
  • ObiWan,

    Here is the thread where we discuss the "formula":

    http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/0e32f437-21b8-4d53-a346-66742ce6c1ae


    Friday, October 14, 2011 8:01 PM
  • On Fri, 14 Oct 2011 20:01:00 +0000, Le Pivert wrote:
     
    >
    >
    >ObiWan,
    >
    >Here is the thread where we discuss the "formula":
    >
    >http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/0e32f437-21b8-4d53-a346-66742ce6c1ae
     
    Not much of a "formula", just common sense and good practice. Use IP
    addresses where you can to reduce the number of DNS queries.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Friday, October 14, 2011 9:39 PM
  • Not much of a "formula", just common sense and good practice. Use IP addresses where you can to reduce the number of DNS queries.

    Well... yes and no; using IP addresses will reduce DNS queries, sure, but will also limit the flexibility of the whole mechanism; just to make an example, let's say we have a domain called "example.com" and that the email for the domain is handled by a server called "mail.example.com" sitting at IP 192.0.2.100 and which is also defined as the MX for the domain

    We may then have an SPF record like this "v=spf1 ip4:192.0.2.100 -all" which will tell to the world that the only host allowed to send email on the behalf of "example.com" is the one sitting at 192.0.2.100 ... fine ... but what if, in a future, we add some more servers (possibly sitting on different subnets for fault-tolerance purposes) or if we change the IP/subnet of our server ?

    In such cases, we'll need to remember to change the SPF record or we'll start having delivery issues... on the other hand, using an SPF record like this "v=spf1 mx -all" would allow us to have a "set and forget" since with such a record we'll just have to add whatever MX record in our DNS zone and, due to the SPF record, it will automatically be allowed to send email for our domain

    As for DNS lookups, don't forget that the DNS uses a caching mechanism, so using the "mx" or "a" mechanism in the SPF record won't cause any big issue but, at the same time, will allow us to have a more flexible setup

    Also, and since we're at it; probably you noticed that I used the "-all" mechanism, this is due to the fact that while the "~all" is accepted, it's meant to be used during initial SPF "test" phase and to be replaced once the testing is over with the "-all" since the "softfail" (~all) verb won't really block other senders from spoofing your domain

     

    Monday, October 17, 2011 7:28 AM
  • Also, and since we're at it; probably you noticed that I used the "-all" mechanism, this is due to the fact that while the "~all" is accepted, it's meant to be used during initial SPF "test" phase and to be replaced once the testing is over with the "-all" since the "softfail" (~all) verb won't really block other senders from spoofing your domain.

     

    Yes, that's probably why (assuming it was set up correctly) the "spoofers" are not being blocked.

    This is excellent information and I wish I was not a "one-man (IT) show" where I work so I could concentrate more on Active Directory and Exchange in particular.

    But then again, a job is a job.

    --------------------------------

    Just did a nslookup on my domain with type = txt:

     

    "v=spf1 a:outbound.mydomain.tld ip4:x.x.x.10 ~all"

     

    Yes, those x'es hide my real IP address and "outbound.mydomain.tld" is the FQDN (slightly modified) associated with my send connector.

    And as you can see, it is ~all rather than -all

     

    Monday, October 17, 2011 9:45 PM
  • On Mon, 17 Oct 2011 07:28:57 +0000, ObiWan wrote:
     
    >Not much of a "formula", just common sense and good practice. Use IP addresses where you can to reduce the number of DNS queries.
    >
    >Well... yes and no; using IP addresses will reduce DNS queries, sure, but will also limit the flexibility of the whole mechanism;
     
    That depends on the frequency with which you change that external IP
    address. Assuming it's a static IP you'd only change it when your ISP
    assigned you a new on -- which is pretty darned infrequently.
     
    If it's a dynamic IP address you're probably using a SMTP relay to
    send your mail and, in that case, you'd use the information supplied
    by the ISP.
     
    >just to make an example, let's say we have a domain called "example.com" and that the email for the domain is handled by a server called "mail.example.com" sitting at IP 192.0.2.100 and which is also defined as the MX for the domain
     
    >We may then have an SPF record like this "v=spf1 ip4:192.0.2.100 -all" which will tell to the world that the only host allowed to send email on the behalf of "example.com" is the one sitting at 192.0.2.100 ... fine ... but what if, in a future, we add some more servers (possibly sitting on different subnets for fault-tolerance purposes) or if we change the IP/subnet of our server ?
     
    I'd assume you had the sense to modify the TXT record in advance of
    the change, just as you would have modified the TTL in advance.
     
    >In such cases, we'll need to remember to change the SPF record or we'll start having delivery issues...
     
    No kidding?
     
    >on the other hand, using an SPF record like this "v=spf1 mx -all" would allow us to have a "set and forget" since with such a record we'll just have to add whatever MX record in our DNS zone and, due to the SPF record, it will automatically be allowed to send email for our domain
     
    Assuming that you use the same IP address for sending and receiving --
    which may not be the case at all. I know it hasn't been the case at
    the last three companies I've worked for.
     
    >As for DNS lookups, don't forget that the DNS uses a caching mechanism, so using the "mx" or "a" mechanism in the SPF record won't cause any big issue but, at the same time, will allow us to have a more flexible setup
     
    Caching happens at the sender's side, not the client. Since most of
    e-mail is spam I doubt that caching plays a big part at all.
     
    >Also, and since we're at it; probably you noticed that I used the "-all" mechanism, this is due to the fact that while the "~all" is accepted, it's meant to be used during initial SPF "test" phase and to be replaced once the testing is over with the "-all" since the "softfail" (~all) verb won't really block other senders from spoofing your domain
     
    If your intention is to test SPF then you should be using the "?all"
    mechanism so the results (at the receiving end) are neutral.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Monday, October 17, 2011 10:04 PM
  • Just did a nslookup on my domain with type = txt:

     

    "v=spf1 a:outbound.mydomain.tld ip4:x.x.x.10 ~all"

     

    Yes, those x'es hide my real IP address and "outbound.mydomain.tld" is the FQDN (slightly modified) associated with my send connector.

    And as you can see, it is ~all rather than -all

    I see; as for the "outbound" that one tells to "the world" that any IP belonging to the "A" record(s) called "outbound.mydomain.tld" are allowed to send email on the behalf of the domain which is a good idea since gives you more flexibility; then you added the IPv4... which is ok too, although, I prefer avoiding that if possible (notice that you may also specify a CIDR range like, for example ip4:192.0.2.0/24) by the way, as I already wrote if your sending IP (outbound SMTP) is the same used by your MX then you may just use a "v=spf1 mx -all" since that will state that any host listed as an MX for your domain is allowed to also send email for the domain

    As for the "~all" it's called "softfail"; now, while the "hardfail" (-all) means that emails failing SPF checks should be immediately rejected (SMTP error 5xx) the softfail means "accept the email but check it more carefully since it may or may not be spoofed" ... then, ok, there's the "?all" too, but that doesn't make sense; it just means "act like I never published any SPF record" which, as you probably see, doesn't really make much sense :)

     

    Wednesday, October 19, 2011 6:55 AM
  • That depends on the frequency with which you change that external IP
    address. Assuming it's a static IP you'd only change it when your ISP
    assigned you a new on -- which is pretty darned infrequently.
    Well... it mostly depends from what/how you configured things; you may have a number of subnets used to send out messages from time to time (yes, it happens)
    I'd assume you had the sense to modify the TXT record in advance of
    the change, just as you would have modified the TTL in advance.
    Sure, but what if you'll have to switch over to a different IP if your main connection fails ?
    Assuming that you use the same IP address for sending and receiving --
    which may not be the case at all. I know it hasn't been the case at
    the last three companies I've worked for.
    Yes, mine was just an example related to a common setup (which also seems to reflect the setup used by the OP); then, if this isn't the case, you may just create a child DNS zone (e.g. mxout.example.com) add all the outbound IP addresses to this zone and use something like "v=spf1 a:mxout.example.com -all" and that will allow you to manage everything from that zone without the need to touch your SPF record which, by the way, may be cached on the remote side
    Caching happens at the sender's side, not the client. Since most of
    e-mail is spam I doubt that caching plays a big part at all.
    Uh ? Sorry didn't understand your statement; whenever an MX receives an incoming SMTP session, it checks the SPF record using its configured DNS and such a record is then cached by that DNS so, caching happens on the receiver side
    If your intention is to test SPF then you should be using the "?all"
    mechanism so the results (at the receiving end) are neutral.

    Not exactly; using "?all" would just mean "totally ignore the SPF record" whereas the "~all" will allow you to really test the SPF without getting straight rejects

    [edit]

    Just as a reference; see RFC-4408 pages 7/8, sections 2.5.1 through 2.5.5; those explain pretty well the effect of the various options (note: consider ?all=neutral, ~all=softfail, -all=fail)

     

    • Edited by ObiWan Thursday, October 20, 2011 11:02 AM
    Wednesday, October 19, 2011 7:11 AM