Conventions about sending email

Digging up the network configuration of your environment is easily done. Using Linux, you can retrieve the outside DNS information using the domain name with one command. So if you give your mail address, please... ;)

I participated in a question quite recently, about an external service that receives mail, does some de-spamming and de-virusing, and then sends it on to the real mail-server through a secure connection. I'll be a bean if I can remember what the service was (poor Dutchism). I'll try to find it, if you think it's interesting.

To get more response, I think you should place additional 20 point questions in other TA's that discuss mail, like Networking. Put a link in that question to this question.

It is becoming more common practice, and I think all the engineers who institute the policy are security crazies.

It is an effort to cut back on spam and viruses that spread like spam.  However, it ends up, in overly broad strokes, cutting out many smaller companies and people with personal domains, depending on the level of check.

Some examples of varying checks:

1) sending SMTP server has no in-arpa record -- this shoudl not hapen.  if you have your own dedicated T1 or better circuit, with your own static IP address, you shoudl be able to assign an in-arpa.  If you are using an IP address assigned and owned by your ISP, whether dynamic or static, that ISP really ought to register the in-arpa.  I agree with rejections of this sort.  If your ISP won't cooperate, geta  different ISP.

2) sending server has an in-arpa that does not match your e-Mail domain. Stupidest check you could conduct.  You woudl only have one in-arpa record for the IP, and if the SMTYP server at taht address supports multiple domains, there is no way to satisfy the requirement.

3) server must have matching mx record for domain.  I'm mixed on this one, beacuse it means you must put all your outbound SMTP servers as inbound as well. Though you can manage this with MX priority in your zone records, nevertheless, it means those servers have to expect to accept inbound messages.

4) sender ID (that's the pobox solution) -- special TXT records in DNS indicate where all your outbound mail will be sourced; any messages claiming to be from an address in your domain but arriving from an SMTP server not listed in sender ID will be rejected.  If the receivver does not accept mail fro domains without sender ID available, they must be mad, because most domains do nothave sender ID yet.  For domains with sender ID, this makes perfect sense.  Just be aware, if you set up sender ID, to alway be darn careful to update it BEFORE you add/change a mail server... because a good deal of your outbound mail will get rejected if you ever mess this up.

5) Do not accept mail without HELO (the HELO command starts most SMTP sessions, and includes the FQHN of the sender) --  agree with this wholeheartedly

6) Do not accept mail if the HELO's FQHN does not resolve to the IP address of the sending SMTP.  I also agree with this.  If you haev a static IP address, it is no problem whatsoever.  If you haev a dynamic IP, you are in trouble, but you can use a dynamic DNS server, such as DynDNS.org.  Of course, every time your IP address is changed, there is a window between the change and the dynamic DNS update, and messages sent during that period will fail.  In addition, because of DNS caching, this perod can be longer than you think.  Don't forget -- the dynamic DNS providers typically set TTL to zero or a very low number, but upstream DNS servers often specify a minimum cache time of 2 hours, 6 hours, or a day.  Sorry, Charlie, but you probably should move SMTP, FTP, and HTTP servers to static addresses.

Did I leave anything out?  I think there are a cople of other variants for these checks.

The reverse lookup is becoming a very popular spam prevention tecnique, but it does result in a lot of false-positives. Is it part of RFC compliance? Not sure on that , but I don't think so. Either way you are best to set it up as a lot of companies and even some ISPs are starting to use it.

You could check the RFCs for SMTP. RFC2821 gives SMTP detail at this link ... http://www.faqs.org/rfcs/rfc2821.html

GL :)